作者 | 廖光明

隨著數(shù)據(jù)在越來越多的企業(yè)中被應(yīng)用，數(shù)據(jù)技術(shù)的發(fā)展可謂突飛猛進(jìn)。不僅基于Hadoop的大數(shù)據(jù)生態(tài)在持續(xù)完善，我們也能看到很多新興的分布式技術(shù)如潮水般涌現(xiàn)。

雖然數(shù)據(jù)技術(shù)發(fā)展飛快，但是對于做數(shù)據(jù)開發(fā)的我們，整個數(shù)據(jù)項目開發(fā)過程還是很痛苦。我們接觸過的客戶常常這樣抱怨：

• 搞不懂?dāng)?shù)據(jù)怎么算出來的，反正很復(fù)雜
• 數(shù)據(jù)庫里面好幾百個SQL，代碼都很長
• 經(jīng)常延遲出數(shù)據(jù)，流水線總是出問題
• … 

這是什么原因呢？我們發(fā)現(xiàn)這常常是由于團隊的數(shù)據(jù)工程實踐做得不夠好。

想要規(guī)?；瘜嵤┢髽I(yè)數(shù)據(jù)項目開發(fā)，除了數(shù)據(jù)技術(shù)之外，數(shù)據(jù)工程實踐也得跟上。

這篇文章的內(nèi)容是結(jié)合我們在多個客戶的數(shù)據(jù)項目經(jīng)驗，給大家分享一些行之有效的數(shù)據(jù)工程實踐。

數(shù)據(jù)工程與敏捷數(shù)據(jù)工程

首先，我們需要了解一下什么是數(shù)據(jù)工程。

我們一般理解的工程是以解決實際生活中的復(fù)雜問題為目標(biāo)，通常是以團隊為單位進(jìn)行實施，綜合利用各種科學(xué)知識及經(jīng)驗解決問題（參考wiki）。軟件工程則是在軟件開發(fā)領(lǐng)域的工程，它綜合利用各類軟件構(gòu)建知識、技術(shù)工具及經(jīng)驗來構(gòu)建復(fù)雜軟件。

IEEE將軟件工程定義為：

將系統(tǒng)化的、規(guī)范的、可度量的方法用于軟件的開發(fā)、運行和維護(hù)的過程，即將工程化應(yīng)用于軟件開發(fā)中。

數(shù)據(jù)工程是在數(shù)據(jù)開發(fā)這個特定的軟件開發(fā)領(lǐng)域的軟件工程，可以定義為綜合利用各類軟件構(gòu)建知識、數(shù)據(jù)技術(shù)及工具、經(jīng)驗來構(gòu)建復(fù)雜的數(shù)據(jù)產(chǎn)品。

1.敏捷數(shù)據(jù)工程

敏捷軟件開發(fā)已經(jīng)成為應(yīng)用軟件開發(fā)的主流工程方法。有大量團隊驗證了敏捷方法中推薦的實踐的有效性。

數(shù)據(jù)開發(fā)屬于一個特定的軟件開發(fā)領(lǐng)域，大部分的應(yīng)用軟件開發(fā)方法可適用于數(shù)據(jù)開發(fā)，敏捷軟件開發(fā)方法自然也不例外。因此，我們可以將敏捷數(shù)據(jù)工程定義為：

將敏捷軟件開發(fā)的思想應(yīng)用于數(shù)據(jù)開發(fā)過程中，得到的一系列工程方法的合集。

很多敏捷軟件開發(fā)思想源于極限編程，其要旨在于通過將好的實踐做到極致來改善軟件質(zhì)量。例如，構(gòu)建持續(xù)集成流水線可以讓每次提交代碼都進(jìn)行集成，從而避免集成造成的問題。另外，通過將盡可能多的項目內(nèi)容代碼化，可借助版本控制工具來追蹤每次修改的內(nèi)容。

在將敏捷思想應(yīng)用于數(shù)據(jù)工程時，也需要根據(jù)實際情況進(jìn)行適當(dāng)?shù)牟眉艉驼{(diào)整。

數(shù)據(jù)工程內(nèi)容非常廣泛，包括數(shù)據(jù)需求分析、數(shù)倉設(shè)計、數(shù)據(jù)開發(fā)過程、數(shù)據(jù)測試、數(shù)據(jù)運維、數(shù)據(jù)項目管理等。結(jié)合敏捷的思想，本文希望拋磚引玉，挑選三個方面的實踐方法做一些分享：

• 代碼化一切
• 數(shù)據(jù)復(fù)用與代碼復(fù)用
• 以ETL為單位的持續(xù)集成

2.代碼化一切

在應(yīng)用軟件開發(fā)中，“代碼化一切”被討論得很多。常見的代碼化XX有：

• 配置即代碼（Configuration as code）：將配置文件放入代碼倉庫進(jìn)行管理，可以實現(xiàn)配置修改的可追溯性。
• 基礎(chǔ)設(shè)施即代碼（Infrastructure as code）：將基礎(chǔ)設(shè)施需要的通用能力抽象出來，以便可以用代碼來定義基礎(chǔ)設(shè)施。然后將基礎(chǔ)設(shè)施代碼放入代碼倉庫進(jìn)行管理，可實現(xiàn)隨時可重建的基礎(chǔ)設(shè)施。通常借助一些工具實現(xiàn)，比如Kubernetes支持用yaml文件代碼來定義基于容器的基礎(chǔ)設(shè)施，Terraform支持用yaml文件代碼定義各類基礎(chǔ)設(shè)施，并通過插件來支持幾乎所有的基礎(chǔ)設(shè)施提供商（如本地服務(wù)器、AWS/GCP/Azure云服務(wù)等）。
• 流水線即代碼（Pipeline as code）：避免通過持續(xù)集成工具（如Jenkins）的UI上的復(fù)雜配置來定義流水線，而是通過代碼來定義持續(xù)集成流水線。早在2016年就在Thoughtworks的技術(shù)雷達(dá)上提出，后來得到了各種主流的持續(xù)集成工具的支持。比如Jenkins支持用Groovy代碼來定義流水線，GitHub Actions/GitLab/Circle CI/Travis CI等支持用yaml代碼來定義流水線。

還有更多的比如：

• 微服務(wù)的可觀察性即代碼（observability as code）
• 安全策略即代碼（Security policy as code）
• 圖表即代碼（Diagrams as code）
• ......

3.代碼化的優(yōu)勢

從上面這些“代碼化XX”中，我們可以看到一個趨勢，似乎我們正在嘗試把“一切”代碼化。為什么“代碼化”這么有吸引力？

這要追溯到開發(fā)人員日常工作方式中。作為一個程序員，每天做得最多的事情是寫代碼，最習(xí)慣最熟練的工作也是寫代碼。通過一個熟悉的集成開發(fā)環(huán)境（IDE）或者文本編輯器，開發(fā)人員可以高效的編寫、調(diào)試代碼并完成工作。

正由于此，現(xiàn)在市場上有大量成熟的幫助開發(fā)人員寫代碼的工具。它們大都支持了數(shù)量眾多的快捷鍵，可輔助編寫代碼的智能代碼提示，語法檢查等等對代碼編寫非常友好的功能。開發(fā)人員還往往會根據(jù)自己的習(xí)慣對這些工具進(jìn)行配置，以便達(dá)到最高的編碼效率。

不難看出，正是由于這些工作方式，所以開發(fā)人員會更希望以代碼化的方式來工作，這也就推動了“代碼化一切”這樣的工程思想的發(fā)展。

除了可以高效編輯之外，代碼化之后還能獲得這樣一些好處：

• 可追蹤變更歷史記錄：開發(fā)人員有成熟的代碼版本控制工具可用于記錄每一次修改內(nèi)容、修改人、修改時間、注釋等。如果有必要，還可以比較任意兩個版本的差異。對于診斷問題而言，這無疑是非常高效的。
• 可回退到任一版本：由于待開發(fā)的功能往往非常邏輯復(fù)雜，因此，常常會隱藏一些問題在交付的軟件中。如果實現(xiàn)了“代碼化”，則可根據(jù)需要隨時回退到某一個無問題的版本。
• 可融入開發(fā)人員的日常開發(fā)實踐：代碼化之后，可以更容易的融入到開發(fā)團隊的日常實踐中，比如代碼評審Code Review

4.數(shù)據(jù)開發(fā)中的“代碼化”

數(shù)據(jù)開發(fā)中，我們一般要面對這樣幾類開發(fā)資源：基礎(chǔ)設(shè)施、安全配置、ETL代碼、ETL任務(wù)配置、數(shù)據(jù)流水線、運維腳本、業(yè)務(wù)注釋等。

事實上，這些資源均可以很容易的被“代碼化”。

基礎(chǔ)設(shè)施可以通過Terraform進(jìn)行代碼化。如果整個系統(tǒng)運行在類似Kubernetes這樣的容器平臺上，也可以Kubernetes提供的YAML來定義基礎(chǔ)設(shè)施。

安全配置代碼化常常需要一定的開發(fā)成本，一般可借助于各類安全管理應(yīng)用提供的API進(jìn)行代碼化。一個推薦的做法如下。首先根據(jù)具體的應(yīng)用場景設(shè)計安全管理模型，并據(jù)此模型定義（較少的）配置項，然后提供一個程序讀取這些配置，并根據(jù)安全管理模型生成安全管理工具提供的API所對應(yīng)的數(shù)據(jù)，最后調(diào)用安全管理工具提供的API完成安全配置的應(yīng)用。

ETL一般以代碼的形式存在，大部分的數(shù)據(jù)開發(fā)工具都提供了功能，使得開發(fā)者可以用SQL的來開發(fā)ETL。但是只有SQL常常難以滿足開發(fā)需求，比如，我們很難在SQL中發(fā)送HTTP請求、打印日志或斷點調(diào)試。這里可以推薦Thoughtworks開源的Easy SQL，它基于SQL進(jìn)行語法增強，提供了一種方式使得我們可以更加模塊化的組織ETL代碼，支持了變量、日志打印、斷言、調(diào)試、外部函數(shù)調(diào)用等等功能。有了這些功能，我們可以在ETL代碼中完成各式各樣的工作，無需再結(jié)合其他工具使用，也無需自己編寫復(fù)雜的代碼。

ETL任務(wù)配置是指ETL任務(wù)運行時使用的各類配置。很多數(shù)據(jù)計算引擎都提供了配置接口，以便我們可以根據(jù)需要來配置最適當(dāng)?shù)挠嬎阗Y源、配置程序運行所需的外部文件、配置算法等。這些配置看起來不起眼，但是也非常重要，因為它們常?？梢詻Q定程序運行時性能，而這跟ETL任務(wù)的運行時間、穩(wěn)定性緊密相關(guān)。所以，將ETL配置納入到代碼庫中管理就顯得十分必要。Easy SQL提供了一種能力，使得開發(fā)人員可以在ETL文件中定義ETL執(zhí)行所需的配置，是一種支持將配置與對應(yīng)的代碼放在一起的好的實踐。

數(shù)據(jù)流水線常常以一種“非代碼化”的方式進(jìn)行開發(fā)。很多調(diào)度工具都提供了界面，使得我們可以通過拖拽及配置來完成流水線的開發(fā)。比如阿里的Dataworks，Azure的ADF等。以“非代碼化”的方式開發(fā)流水線的靈活性很差且無法享受到版本控制的優(yōu)勢。一些開源工具提供了代碼化能力，比如受到很多數(shù)據(jù)開發(fā)人員喜愛的Airflow，它支持用python代碼來定義數(shù)據(jù)流水線，然后根據(jù)流水線定義進(jìn)行可視化展示。對開發(fā)人員更友好的方式是，提供一種自動管理數(shù)據(jù)流水線的機制，這樣開發(fā)人員就無需編寫流水線了。這是可能的，事實上，完全可以編寫一個程序，解析出ETL代碼中的輸入輸出表，然后根據(jù)這些信息自動提取ETL間的依賴關(guān)系，接著根據(jù)這些依賴關(guān)系就可以自動生成數(shù)據(jù)流水線了。

運維腳本常常以代碼的形式呈現(xiàn)，但是很多數(shù)據(jù)工具希望將此類腳本納入工具內(nèi)部管理。這容易讓我們喪失代碼化的能力，因為它總是鼓勵我們將此類代碼配置到工具的UI界面里（可以想象一下在Jenkins還不支持用Groovy編寫CI/CD流水線時的使用方式）。

業(yè)務(wù)注釋是另一類可以考慮代碼化的資源。很多團隊將此類信息納入到一個名為元數(shù)據(jù)管理的應(yīng)用中進(jìn)行管理。元數(shù)據(jù)管理應(yīng)用通?？梢蕴峁┮恍┗谧匀徽Z言的搜索能力，而且可以提供友好的界面展示。這是其優(yōu)勢，但是對于此類信息的維護(hù)，就不得不在元數(shù)據(jù)管理應(yīng)用中完成。這常常帶來另一些問題。比如，當(dāng)我們重建某些數(shù)據(jù)庫表時，元數(shù)據(jù)管理應(yīng)用無法將原來的元數(shù)據(jù)遷移到新表。還比如，元數(shù)據(jù)管理應(yīng)用常常無法提供完善的數(shù)據(jù)版本管理功能，從而使得我們無法進(jìn)行版本追溯及回滾。如果將此類業(yè)務(wù)注釋放到代碼庫中進(jìn)行管理，就可以享受到代碼化的優(yōu)勢，并且，通過調(diào)用元數(shù)據(jù)管理應(yīng)用的API可以此元數(shù)據(jù)同步到元數(shù)據(jù)管理應(yīng)用，從而我們也能享受到元數(shù)據(jù)管理應(yīng)用提供的搜索即友好的數(shù)據(jù)展示的能力。

當(dāng)然，實際項目中可能還有其他一些沒有提到的資源類型，這里不在于為所有資源列舉代碼化方案，而是更多的提供一種代碼化一切的建議。當(dāng)我們發(fā)現(xiàn)團隊正在以一種非代碼化的方式進(jìn)行數(shù)據(jù)開發(fā)時，可能需要思考有沒有什么好的方案可以轉(zhuǎn)變?yōu)榇a化的方式。這將給我們的開發(fā)帶來非常多的好處。

數(shù)據(jù)復(fù)用與代碼復(fù)用

1.應(yīng)用軟件開發(fā)中的復(fù)用

在應(yīng)用軟件開發(fā)中，代碼復(fù)用是一項顯而易見的工作，開發(fā)人員幾乎每天都會進(jìn)行。良好的代碼復(fù)用可以有效降低代碼重復(fù)率，提高效率，并減少潛在的BUG。

應(yīng)用軟件開發(fā)中有哪些復(fù)用代碼的方式呢？從代碼復(fù)用的粒度上看，有兩種基本的形式：

• 定義函數(shù)，在多個地方調(diào)用此函數(shù)實現(xiàn)代碼復(fù)用。各種編程語言均有支持。
• 創(chuàng)建文件，將一系列相關(guān)元素置于此文件，在多個地方引用此文件實現(xiàn)代碼復(fù)用。比如C語言中的include可以包含其他文件的內(nèi)容。

2.數(shù)據(jù)開發(fā)中傳統(tǒng)的復(fù)用方式

數(shù)據(jù)開發(fā)與應(yīng)用軟件開發(fā)存在一個顯著不同，那就是進(jìn)行數(shù)據(jù)開發(fā)時，我們不僅要關(guān)注代碼還要關(guān)注數(shù)據(jù)。

(1) 數(shù)據(jù)計算成本

在應(yīng)用軟件開發(fā)中，有了現(xiàn)代CPU的支持，一般而言，一段代碼的運行非常快。但是在數(shù)據(jù)開發(fā)中，我們經(jīng)常會發(fā)現(xiàn)運行一個數(shù)據(jù)任務(wù)花費的時間甚至比開發(fā)這個任務(wù)花費的時間都長。這就導(dǎo)致我們不得不將很大的精力放在運行數(shù)據(jù)任務(wù)上。

我們常常小心地設(shè)計或選擇算法，謹(jǐn)慎地優(yōu)化任務(wù)運行所需的資源，仔細(xì)的比較兩種不同的存儲類型的性能差異，反復(fù)在同一個數(shù)據(jù)集上面進(jìn)行驗證。

我們不得不這么做，因為一段性能低下的數(shù)據(jù)計算代碼，可能導(dǎo)致10倍的運行時間延長，最后不僅消耗了大量的計算資源，還無法滿足業(yè)務(wù)需求。

在應(yīng)用軟件開發(fā)中，這個問題沒那么顯著，但是在數(shù)據(jù)開發(fā)中，這個問題的重要性就凸顯出來。因為我們常常需要調(diào)度上百臺計算機同時進(jìn)行運算，這時，計算資源的支出就將成為我們不得不關(guān)注的問題。

以AWS云服務(wù)的定價進(jìn)行計算，采用AWS Glue服務(wù)做計算引擎，按照本文撰寫時的官方定價，如果調(diào)度100DPU進(jìn)行10小時的計算，則將花費的費用是100 * 10 * 0.44 = 440美元，也就是約3000人民幣的費用！

這還只是一個數(shù)據(jù)計算任務(wù)的費用，如果我們有100個任務(wù)呢？這個費用支出確實不菲！

做應(yīng)用軟件開發(fā)時，我們常常說，可以用廉價的計算成本來代替較高昂的人工成本。但是這一條規(guī)則在數(shù)據(jù)開發(fā)中并不那么適用。

(2) 基于數(shù)據(jù)復(fù)用

耗費如此長的時間與金錢才能計算出來的數(shù)據(jù)，自然是一筆重要的企業(yè)資產(chǎn)。于是，在數(shù)據(jù)開發(fā)中，我們采用最多的復(fù)用方式是基于數(shù)據(jù)的復(fù)用。

在數(shù)倉分層設(shè)計方法中，我們常常構(gòu)建可復(fù)用的數(shù)據(jù)分層，下圖是一個典型的數(shù)倉分層結(jié)構(gòu)。

ODS貼源層作為一個可復(fù)用的數(shù)據(jù)分層，為DWD明細(xì)層及公共維度層提供數(shù)據(jù)。DWD明細(xì)層及公共維度層作為基礎(chǔ)數(shù)據(jù)，為上層的眾多指標(biāo)開發(fā)提供數(shù)據(jù)支持。開發(fā)出來的指標(biāo)數(shù)據(jù)作為一個分層，支持更上層的數(shù)據(jù)應(yīng)用層數(shù)據(jù)。（此處的數(shù)據(jù)分層命名僅供參考，業(yè)界尚無統(tǒng)一的標(biāo)準(zhǔn)）

在實踐中，我們常常需要仔細(xì)設(shè)計數(shù)據(jù)分層，在不失靈活性的同時達(dá)到良好的復(fù)用效果。

2.基于數(shù)據(jù)復(fù)用的問題

基于數(shù)據(jù)分層的方式進(jìn)行復(fù)用應(yīng)用非常廣泛，但是它也存在一些缺點。

(1) 首先是靈活性較差。

后一層對前一層的數(shù)據(jù)存在很強的依賴，所以，如果前一層的數(shù)據(jù)結(jié)構(gòu)沒有被設(shè)計出來時，就無法進(jìn)行后一層的開發(fā)。而當(dāng)我們希望設(shè)計一個數(shù)據(jù)分層可以滿足后一層的大量的數(shù)據(jù)需求時，這里的設(shè)計又會變得特別復(fù)雜，常常要左右權(quán)衡，花費了大量的后一層開發(fā)不愿意等待的時間。當(dāng)前一層數(shù)據(jù)構(gòu)建好了之后，如果后一層需要的數(shù)據(jù)無法滿足時，還不得不修改上一層的代碼并重新運行計算任務(wù)。

(2) 其次是整體數(shù)據(jù)計算過程難以理解。

當(dāng)我們發(fā)現(xiàn)計算結(jié)果不符合預(yù)期時，我們往往要追溯從數(shù)據(jù)源開始的整個數(shù)據(jù)計算過程，仔細(xì)分析內(nèi)部轉(zhuǎn)換邏輯，才能找到問題。當(dāng)存在多個數(shù)據(jù)分層時，我們不得不往下查找每一層的計算過程。而越往下越難。這通常是由于下層在設(shè)計上要保持更高的適用度，以便支持更多的上層數(shù)據(jù)需求，而這導(dǎo)致很多與當(dāng)前需要的數(shù)據(jù)無關(guān)的計算雜糅在一起。

在分析問題時，一個較理想的情況是，和某個指標(biāo)相關(guān)的ETL的全部代碼都在一個文件里面，這樣就不需要多個文件跳轉(zhuǎn)。同時，我們也不希望有不相關(guān)的邏輯存在于這個ETL文件中，這樣我們就可以專注在問題分析上?；跀?shù)據(jù)分層的復(fù)用恰好產(chǎn)生了與期望相反的副作用。

3.基于代碼的復(fù)用

在這里我希望給大家介紹“基于代碼的復(fù)用”這一實踐?；诖a的復(fù)用方式雖然可能會由于不能共享計算資源而導(dǎo)致付出較大的計算資源成本，但沒有上述缺點。而且，如何處理得當(dāng)，基于代碼的復(fù)用也可以一定程度上避免計算資源浪費。

基于代碼的復(fù)用方式在數(shù)據(jù)開發(fā)中實踐不太多，但卻是非常值得嘗試的一個方向。

在數(shù)據(jù)開發(fā)時，如何使用在應(yīng)用軟件開發(fā)中廣泛使用的基于代碼的復(fù)用方式呢？

(1) 數(shù)據(jù)庫視圖

大部分?jǐn)?shù)據(jù)庫都提供了視圖機制，視圖是一個虛擬的表，它本身僅僅包含了一些轉(zhuǎn)換邏輯，但并沒有真實的將數(shù)據(jù)計算出來并存放在物理存儲中。這給我們帶來了一些啟示。是不是可以利用視圖的原理進(jìn)行代碼復(fù)用呢？視圖可以理解為一段代碼，查詢視圖即是在進(jìn)行代碼復(fù)用。

事實上，現(xiàn)在的很多數(shù)據(jù)庫還在視圖的基礎(chǔ)上提供了物化視圖的機制，我們可以將一個視圖轉(zhuǎn)換為物化視圖，讓數(shù)據(jù)庫在合適的時機將視圖中的數(shù)據(jù)計算出來，從而自動的提升數(shù)據(jù)計算性能。

視圖及物化視圖給我們提供了非常好的靈活性，因為我們輕松的可以在基于數(shù)據(jù)的復(fù)用和基于代碼的復(fù)用兩者之間切換。

物化視圖還在一定程度上采用基于代碼復(fù)用的方式實現(xiàn)了基于數(shù)據(jù)的復(fù)用。

(2) 實現(xiàn)ETL執(zhí)行驅(qū)動器

除了基于視圖進(jìn)行代碼復(fù)用，還可以自實現(xiàn)一個ETL執(zhí)行驅(qū)動器，由它來提供一些代碼復(fù)用的機制。比如dbt Easy SQL就是這樣一些開源的ETL執(zhí)行驅(qū)動器。

Easy SQL提供了模板來實現(xiàn)類似函數(shù)級別的復(fù)用，詳情可以參考這里。同時它也提供了基于文件的復(fù)用，通過Include指令可以將其他ETL文件包含到當(dāng)前文件，詳情可以參考這里。

除了使用這些開源工具，想要自實現(xiàn)一個這樣的驅(qū)動器也不復(fù)雜。如果我們的計算引擎是 Spark，那么我們可以使用Spark的DataFrame API，進(jìn)行一些開發(fā)就可以完成。

如果有足夠的研發(fā)投入，基于自實現(xiàn)ETL執(zhí)行驅(qū)動器的方式可以做得非常智能，達(dá)到甚至超過數(shù)據(jù)庫視圖和物化視圖的效果。一個可以考慮的方向是，程序可以自動分析所有ETL執(zhí)行過程，然后用算法識別可以有較多復(fù)用的中間結(jié)果，然后自動將中間結(jié)果保存到某處。在后續(xù)ETL執(zhí)行時，自動從中間結(jié)果取數(shù)據(jù)，而不是重新計算。

目前市場上還未見到此類智能的ETL執(zhí)行驅(qū)動器出現(xiàn)，不過，在我看來，這是一個不錯的研究方向。

4.選擇哪種復(fù)用方式

在實際項目中，如何選擇復(fù)用方式呢？有以下建議可以參考：

• 某些ETL要處理大量的數(shù)據(jù)，計算過程要消耗大量的資源，且運行時間特別長，建議以基于數(shù)據(jù)的復(fù)用方式為主，就可以有效控制資源
• 某些ETL只需要處理有限的數(shù)據(jù)，此時可以轉(zhuǎn)換為基于代碼的復(fù)用方式，從而獲得較高的靈活性
• 難以選擇時，優(yōu)先考慮使用基于代碼的復(fù)用方式

以ETL為單位的持續(xù)集成

我最近和一個做進(jìn)口貿(mào)易的朋友聊天，發(fā)現(xiàn)了一件很有意思的事：

他們公司進(jìn)口國外高端儀器，并幫助銷售公司處理競標(biāo)、合同簽訂、物流、海關(guān)、進(jìn)口貿(mào)易政策符合、維保等復(fù)雜的事務(wù)。我很好奇，為什么銷售公司不自己處理這些事務(wù)，反而出售給其他公司呢？向他請教后，獲得了很多啟示。

國內(nèi)工業(yè)起步較晚，雖然現(xiàn)在已成為世界工廠，但很多核心生產(chǎn)設(shè)備仍需要進(jìn)口。這個市場是一個萬億級的大市場。這個業(yè)務(wù)有什么特點呢？

• 一是產(chǎn)品銷售量少，因為高端儀器價格昂貴，一年只能銷售數(shù)百臺。
• 二是銷售流程特別復(fù)雜。進(jìn)口需要處理很多實際問題，包括競標(biāo)、合同簽訂、物流、海關(guān)、進(jìn)口貿(mào)易政策符合、維保等等。

那么，如何組織這種業(yè)務(wù)呢？

銷售是必須的，但其他事務(wù)是否必須自己做？這值得思考。因為銷售量不大，但其他事務(wù)特別復(fù)雜。如果培養(yǎng)一個專業(yè)團隊來做這些事，由于銷售量不大，團隊工作勢必不會飽和。如果減少團隊人員數(shù)量，這些事務(wù)又難以做得專業(yè)，容易出紕漏。

在市場嘗試和調(diào)整之后，專門做進(jìn)口貿(mào)易的企業(yè)就誕生了。他們負(fù)責(zé)產(chǎn)品銷售之外的大部分事務(wù)，包括競標(biāo)、合同簽訂、物流、海關(guān)、進(jìn)口貿(mào)易政策符合、稅收、維保方式設(shè)計等。他們通常是一個非常專業(yè)的團隊，可負(fù)責(zé)各個領(lǐng)域不同產(chǎn)品的進(jìn)口貿(mào)易業(yè)務(wù)。

于是，海外產(chǎn)品研發(fā)公司、國內(nèi)產(chǎn)品銷售公司和國內(nèi)進(jìn)口貿(mào)易公司的模式就在市場上慢慢形成并穩(wěn)定下來了。這種模式提高了整個行業(yè)的效率和質(zhì)量，也是進(jìn)口貿(mào)易企業(yè)得以存在的原因。

從進(jìn)口貿(mào)易企業(yè)的興起中可以看到業(yè)務(wù)的重構(gòu)和演變，即，通過合理的抽取和拆分提升了整體的效率。

1.以ETL為單位的持續(xù)集成

在應(yīng)用軟件開發(fā)中，我們常常僅設(shè)計一條持續(xù)集成流水線，在流水線中運行所有的測試，接著將所有代碼打包成一個大的產(chǎn)品包，然后部署到測試或產(chǎn)品環(huán)境中。

在數(shù)據(jù)應(yīng)用中，是不是也需要這樣做呢？這樣做的好處是可以將產(chǎn)品環(huán)境的制品與代碼倉庫中的版本對應(yīng)。其劣勢其實也很多，比如，修改一個局部的代碼，就不得不運行所有的測試，然后運行流水線中所有耗時的步驟，可能還需要進(jìn)入手工測試的環(huán)節(jié)，最后才能發(fā)布到線上。效率非常低下。

這一問題在數(shù)據(jù)應(yīng)用中更是被放大了。因為數(shù)據(jù)應(yīng)用通常涉及數(shù)百個指標(biāo)計算ETL，這些ETL的自動化測試只能用緩慢的集成測試來覆蓋，這就導(dǎo)致流水線中的測試步驟耗時很長。在我們的項目中，常常需要跑半小時到一小時才能跑完。

這就如同做進(jìn)口高端儀器銷售的公司，如果自己來做進(jìn)口貿(mào)易相關(guān)業(yè)務(wù)，不僅耗時特別長，而且出紕漏的可能性大（業(yè)務(wù)質(zhì)量低）。

有沒有更好的做法？既然只修改了某一個ETL，為什么不能就只部署和測試這個ETL？聯(lián)想到前面進(jìn)口貿(mào)易業(yè)務(wù)的抽取和拆分，是不是可以對流水線進(jìn)行抽取和拆分呢？即，做以ETL為單位的持續(xù)集成流水線。

在數(shù)據(jù)應(yīng)用開發(fā)場景中，這也是具備可行性的。原因在于，相比應(yīng)用軟件代碼中的一個一個類或代碼文件，ETL間幾乎沒有依賴。不同的ETL代碼通常有不同的入口，存在于一個獨立的文件?？梢哉J(rèn)為一個ETL就是一個獨立的數(shù)據(jù)應(yīng)用。

事實上，如果以ETL為單位進(jìn)行持續(xù)集成和部署，還不用擔(dān)心自己的部署會影響到其他的線上指標(biāo)計算ETL，這也在一定程度上增強了安全性。

看起來，在數(shù)據(jù)應(yīng)用開發(fā)領(lǐng)域，以ETL為單位的持續(xù)集是順理成章的事。

對比一下微服務(wù)實踐，還可以發(fā)現(xiàn)，這一實踐與微服務(wù)中推薦的為每一個服務(wù)搭建一條持續(xù)集成流水線的實踐幾乎是等同的。

2.如何實現(xiàn)

如何實現(xiàn)以ETL為單位的持續(xù)集成呢？

如果基于Jenkins，可以在流水線上面加一個參數(shù)，如“ETL文件路徑”，在運行流水線時，可以指定這個參數(shù)，讓流水線僅針對指定的ETL運行測試與部署。

如果覺得在Jenkins上面實施以ETL為單位的持續(xù)集成較為麻煩，也可以團隊自主開發(fā)一個專用的數(shù)據(jù)持續(xù)集成流水線。如果僅實現(xiàn)基本的功能，其實也并不復(fù)雜。

需要注意的是，一旦以ETL為單位進(jìn)行持續(xù)集成了，就需要有一種方式記錄每一個ETL對應(yīng)的代碼倉庫里面的版本號，方便版本追溯。實現(xiàn)方式有多種，比如，可以在部署ETL的時候，在生產(chǎn)環(huán)境寫入一個該ETL對應(yīng)的版本文件。

總結(jié)

本文介紹了什么是敏捷數(shù)據(jù)工程， 并分析了幾個有效的實踐。如果能靈活的在數(shù)據(jù)項目中應(yīng)用，將有效提升我們的數(shù)據(jù)產(chǎn)品交付質(zhì)量。

在數(shù)據(jù)開發(fā)領(lǐng)域，目前敏捷的應(yīng)用還處于前期探索階段，還有很多值得深入的方向，比如自動化的ETL測試、較短的單ETL文件、端到端數(shù)據(jù)能力的團隊等等。希望和大家一起探索！