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

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

搞不懂數(shù)據(jù)怎么算出來的，反正很復雜

數(shù)據(jù)庫里面好幾百個SQL，代碼都很長

經(jīng)常延遲出數(shù)據(jù)，流水線總是出問題

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

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

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

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

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

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

IEEE將軟件工程定義為：

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

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

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

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

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

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

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

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

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

代碼化一切

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

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

2.代碼化一切

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

配置即代碼（Configuration as code）：將配置文件放入代碼倉庫進行管理，可以實現(xiàn)配置修改的可追溯性。

基礎設施即代碼（Infrastructure as code）：將基礎設施需要的通用能力抽象出來，以便可以用代碼來定義基礎設施。然后將基礎設施代碼放入代碼倉庫進行管理，可實現(xiàn)隨時可重建的基礎設施。通常借助一些工具實現(xiàn)，比如Kubernetes支持用yaml文件代碼來定義基于容器的基礎設施，Terraform支持用yaml文件代碼定義各類基礎設施，并通過插件來支持幾乎所有的基礎設施提供商（如本地服務器、AWS/GCP/Azure云服務等）。

流水線即代碼（Pipeline as code）：避免通過持續(xù)集成工具（如Jenkins）的UI上的復雜配置來定義流水線，而是通過代碼來定義持續(xù)集成流水線。早在2016年就在Thoughtworks的技術雷達上提出，后來得到了各種主流的持續(xù)集成工具的支持。比如Jenkins支持用Groovy代碼來定義流水線，GitHub Actions/GitLab/Circle CI/Travis CI等支持用yaml代碼來定義流水線。

還有更多的比如：

微服務的可觀察性即代碼（observability as code）

安全策略即代碼（Security policy as code）

圖表即代碼（Diagrams as code）

......

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

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

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

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

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

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

可追蹤變更歷史記錄：開發(fā)人員有成熟的代碼版本控制工具可用于記錄每一次修改內(nèi)容、修改人、修改時間、注釋等。如果有必要，還可以比較任意兩個版本的差異。對于診斷問題而言，這無疑是非常高效的。

可回退到任一版本：由于待開發(fā)的功能往往非常邏輯復雜，因此，常常會隱藏一些問題在交付的軟件中。如果實現(xiàn)了“代碼化”，則可根據(jù)需要隨時回退到某一個無問題的版本。

可融入開發(fā)人員的日常開發(fā)實踐：代碼化之后，可以更容易的融入到開發(fā)團隊的日常實踐中，比如代碼評審Code Review

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

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

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

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

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

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

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

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

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

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

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

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

1.應用軟件開發(fā)中的復用

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

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

定義函數(shù)，在多個地方調用此函數(shù)實現(xiàn)代碼復用。各種編程語言均有支持。

創(chuàng)建文件，將一系列相關元素置于此文件，在多個地方引用此文件實現(xiàn)代碼復用。比如C語言中的include可以包含其他文件的內(nèi)容。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.基于代碼的復用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.選擇哪種復用方式

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

某些ETL要處理大量的數(shù)據(jù)，計算過程要消耗大量的資源，且運行時間特別長，建議以基于數(shù)據(jù)的復用方式為主，就可以有效控制資源

某些ETL只需要處理有限的數(shù)據(jù)，此時可以轉換為基于代碼的復用方式，從而獲得較高的靈活性

難以選擇時，優(yōu)先考慮使用基于代碼的復用方式

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

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

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

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

一是產(chǎn)品銷售量少，因為高端儀器價格昂貴，一年只能銷售數(shù)百臺。

二是銷售流程特別復雜。進口需要處理很多實際問題，包括競標、合同簽訂、物流、海關、進口貿(mào)易政策符合、維保等等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.如何實現(xiàn)

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

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

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

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

總結

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

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

來源：網(wǎng)絡