作者 | 廖光明

隨著數據在越來越多的企業中被應用，數據技術的發展可謂突飛猛進。不僅基于Hadoop的大數據生態在持續完善，我們也能看到很多新興的分布式技術如潮水般涌現。

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

• 搞不懂數據怎么算出來的，反正很復雜
• 數據庫里面好幾百個SQL，代碼都很長
• 經常延遲出數據，流水線總是出問題
• … 

這是什么原因呢？我們發現這常常是由于團隊的數據工程實踐做得不夠好。

想要規模化實施企業數據項目開發，除了數據技術之外，數據工程實踐也得跟上。

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

數據工程與敏捷數據工程

首先，我們需要了解一下什么是數據工程。

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

IEEE將軟件工程定義為：

將系統化的、規范的、可度量的方法用于軟件的開發、運行和維護的過程，即將工程化應用于軟件開發中。

數據工程是在數據開發這個特定的軟件開發領域的軟件工程，可以定義為綜合利用各類軟件構建知識、數據技術及工具、經驗來構建復雜的數據產品。

1.敏捷數據工程

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

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

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

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

在將敏捷思想應用于數據工程時，也需要根據實際情況進行適當的裁剪和調整。

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

• 代碼化一切
• 數據復用與代碼復用
• 以ETL為單位的持續集成

2.代碼化一切

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

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

還有更多的比如：

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

3.代碼化的優勢

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

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

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

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

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

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

4.數據開發中的“代碼化”

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

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

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

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

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

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

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

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

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

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

數據復用與代碼復用

1.應用軟件開發中的復用

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

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

• 定義函數，在多個地方調用此函數實現代碼復用。各種編程語言均有支持。
• 創建文件，將一系列相關元素置于此文件，在多個地方引用此文件實現代碼復用。比如C語言中的include可以包含其他文件的內容。

2.數據開發中傳統的復用方式

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

(1) 數據計算成本

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

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

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

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

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

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

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

(2) 基于數據復用

耗費如此長的時間與金錢才能計算出來的數據，自然是一筆重要的企業資產。于是，在數據開發中，我們采用最多的復用方式是基于數據的復用。

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

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

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

2.基于數據復用的問題

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

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

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

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

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

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

3.基于代碼的復用

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

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

在數據開發時，如何使用在應用軟件開發中廣泛使用的基于代碼的復用方式呢？

(1) 數據庫視圖

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

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

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

物化視圖還在一定程度上采用基于代碼復用的方式實現了基于數據的復用。

(2) 實現ETL執行驅動器

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

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

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

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

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

4.選擇哪種復用方式

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

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

以ETL為單位的持續集成

我最近和一個做進口貿易的朋友聊天，發現了一件很有意思的事：

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

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

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

那么，如何組織這種業務呢？

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

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

于是，海外產品研發公司、國內產品銷售公司和國內進口貿易公司的模式就在市場上慢慢形成并穩定下來了。這種模式提高了整個行業的效率和質量，也是進口貿易企業得以存在的原因。

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

1.以ETL為單位的持續集成

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

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

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

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

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

在數據應用開發場景中，這也是具備可行性的。原因在于，相比應用軟件代碼中的一個一個類或代碼文件，ETL間幾乎沒有依賴。不同的ETL代碼通常有不同的入口，存在于一個獨立的文件。可以認為一個ETL就是一個獨立的數據應用。

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

看起來，在數據應用開發領域，以ETL為單位的持續集是順理成章的事。

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

2.如何實現

如何實現以ETL為單位的持續集成呢？

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

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

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

總結

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

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