作者 | 馬小強，陳健

什么是數據工程

數據工程是軟件工程的一部分，但不是傳統軟件工程在數據領域的簡單重現。數據工程是一套完整的體系，其包含了需求探索、架構設計、平臺構建、測試、維護演進等一系列階段，涵蓋了項目管理、開發過程管理、工程工具與方法、構建管理、質量管理等，是一套為了應對規模化生產和使用數據、為業務提供數據支撐，最終產生價值的體系。

數據工程與軟件工程的差異

從廣義來講，數據平臺也屬于計算機軟件的一種，只不過通常意義上我們所說的計算機軟件是指應用程序、工具和庫等，其主要目的是為用戶提供功能和服務，以滿足他們的個人或商業需求；而數據平臺則是指用于存儲、處理和管理數據的基礎設施和工具集合。數據平臺通常包括硬件、操作系統、數據庫、數據倉庫、數據湖、ETL管道、數據可視化和數據分析工具等，它們的主要目的是為企業提供可靠、高效、安全和可擴展的數據處理和管理能力，以支持業務決策和數據驅動的戰略。這里我們將軟件工程從產出物類型的角度劃分為數據類和應用類，可以從如下三個視角來對比數據類和應用類：

• 使用方不同：數據類主要面向數據分析師、數據科學家等數據專業人士，提供數據處理、數據存儲、數據分析等方面的技術支持，幫助用戶從海量數據中提取有用信息，支持數據驅動的業務決策；而應用類主要面向企業的業務人員以及終端用戶。
• 系統關注點不同：數據類主要關注數據處理、數據存儲、數據分析、數據可視化等方面的技術，重點在于數據的準確性、完整性、一致性和安全性等方面；而應用類主要關注軟件的功能、性能、可靠性和安全性等方面的技術，重點在于軟件的功能實現、用戶體驗和代碼質量等方面。
• 產出物不同：數據類的產出物主要是數據處理流程、數據倉庫、數據分析報告、數據可視化報表等數據相關的產品和服務；而應用類的產出物主要是軟件系統、軟件模塊、軟件組件、軟件文檔等軟件相關的產品和服務。

為什么要做好數據項目的工程化

雖然數據平臺和應用類軟件面向的用戶不同、考慮的首要需求不同、面對的數據量和工具也不盡相同，但是要進行長久的運營，是一定要面對功能性、健壯性、易用性、拓展性、可維護性等關鍵指標，而要滿足這些指標，就要進行科學的工程化。并且一般而言數據平臺的生命周期也遠遠大于傳統軟件，所以，數據工程落地的好壞，直接關系到數據能否快速產生價值。

數據項目工程化是加速數據到價值過程規模化的最佳實踐，那么我們就需要了解在實現數據到價值過程中所經歷的數據接入、集成、清洗、處理、分析、使用等環節所涉及到的痛點和挑戰都有哪些。

• 數據治理年年做，但又年年做不好。在面對多鏈路、多業態的企業數據平臺中，需要接入眾多部門/系統的業務數據，然而數據平臺并不涉及業務流程，也就意味著數據的生產源頭、流程、業務邏輯等信息的梳理、主題域的劃分、數據血緣管理、元數據的管理等就顯得非常重要。否則，就會遇到需求方不知道當前企業有哪些可用的數據，數據質量如何，數據由誰負責，當前數據做過什么樣的處理，數據如何使用等問題。
• 如何降低數據平臺的維護成本。在數據平臺的維護過程中，業務/需求側，會面臨源頭的業務梳理、業務變動、需求變動等；技術側，需要維護分布式的數據平臺基座，面對不同異常情況的數據處理，數據處理邏輯和數據的版本維護等。
• 怎么能高效地進行數據處理。高效地數據處理不僅僅是引入強大高效的計算引擎就可以解決的，需要考慮在常規和異常情況下如何能夠處理“僅需要”處理的數據，從而避免造成時間和資源的浪費。
• 怎么設計才能滿足業務的變動和快速變化的需求。數據平臺如何進行分層，解耦，需要做哪些解耦，來響應變化和多樣的需求場景。
• 數據平臺如何賦能業務。數據平臺找不到高價值的業務場景，無法清晰度量業務價值。
• ...

面對上述的痛點和挑戰，僅僅使用大數據的相關組件是無法解決的，只有進行系統地設計規劃才能做好數據項目的工程化。我們總結了多年數據工程交付的經驗，提煉了一些核心思想，這些往往是大家在進行數據工程落地時容易忽略的點。

數據梳理

數據梳理就是要全域分析數據粒度，規劃數據層次以及統一數據口徑。這么做的目的是整理清楚數據所代表的業務含義、去除跨部門和跨場景在理解上的不一致、尋找使用數據和計算的統一口徑、找到能夠維護數據的管理者，最終構建在企業內部能夠描述數據流轉過程、數據變化過程的全景。這么做的好處是讓數據使用者能夠對數據的變化有全面的認識，對于后續數據項目開展提供扎實的基礎。

數據的背后是信息、是業務知識，因此我們想要理清楚有哪些數據，就需要先對業務流程進行梳理，根據項目類型的不同需要梳理的業務流程范圍也會有所不同，比如:圍繞整個公司視角的梳理、圍繞某個場景的梳理，但無論是哪種范圍，都需要把業務流程梳理出來。業務流程的梳理僅僅是第一步，業務流程梳理的目的是在于產出基于業務流程關鍵節點有哪些數據，通常來講我們需要精確到字段級。對于數據工程而言數據梳理可以從以下視角來審視。

• 數據分級分類。面對企業多業態、多鏈路復雜流程的場景下，會涉及不同角色不同部門的不同級別和類別的數據，因此在前期我們需要對齊數據的分級分類。數據梳理的核心其實是領域模型、實體模型和業務流程的梳理，需要從組織架構、業務流程等進行主題域的分組劃分以及確定所涉及的實體和實體屬性的信息。分級分類一方面可以更好的理解業務和數據，從而更清晰的得到數據全景圖，為后續的數據處理和使用做準備，另一方面可以了解其數據分布，在運營階段更好的進行數據管理。此外，基于數據的分級分類，可以更清晰的劃分數據邊界，幫助業務更好的梳理和優化業務流程。同時，也需要基于安全的視角對數據進行分級分類，從公開數據、內部數據、機密數據等級別進行劃分，從而決定后續的數據共享策略。

• 統一口徑。在上述梳理完數據的分級分類后，應該已經對整個業務流程所涉及的實體有了清晰的認知，那么口徑的統一是在統一什么?這里提到的主要是實體的口徑統一和實體內指標的口徑統一。對于實體的口徑，在業務系統的設計開發階段，通常都是圍繞業務流程進行，也就意味著并不會過多考慮同一個實體跨業務系統的定義，導致同一實體在不同業務系統的業務定義、業務邊界等不相同，但是口語間的業務傳遞描述又是相同的實體，即相同現實世界中的實體在數據視角下的業務定義和邊界可能不同。實體的邊界劃分通常是基于業務決定。對于指標的口徑，通常在使用數據進行分析或數據挖掘時，指標信息的業務邏輯定義就尤為關鍵，在業務復雜的場景下，指標信息的定義從大分組上定義相似，但是又有細微的邏輯差別。
• 約定數據Owner。在業務流程中，不同的部門和系統會使用已有的數據，并可能會對已有的數據在某個業務流程的節點上進行修改，同時也可能基于現有數據產生新的數據。那么面對多版本、多邊界的實體數據，如何保證使用數據的部門和系統所使用的數據就是所期望的數據呢?因此我們需要進行數據的owner梳理。這里與其說是梳理數據owner，倒不如說是梳理業務流程中不同實體的生命周期變化的關鍵負責人。當然這里所講的數據并非一個實體，而是會細粒度到實體的某個屬性，甚至是某個屬性的某個值，如訂單狀態的值。同樣，到底是粗粒度的實體還是細粒度的屬性值定義邊界，依然是由業務決定，即是基于業務流程中的核心節點來決定。通常來講數據owner與數據在映射管理關系是一個一對多的過程，即一個數據owner會負責至少一個數據或者是一類數據。企業根據數據owner所處的部門、負責的業務域、所對接的業務部門、所處的權限級別，可以將分級分類后的數據域數據owner進行映射，形成企業自己的數據管理體系。數據owner需要定義數據的業務含義、業務邊界、數據標準和數據的使用權限等。
• 構建數據標準管理流程。我們知道了要找誰來修改數據，可是如果數據被修改錯誤、或者是修改的不符合業務場景和標準，可能會引發一系列新的問題。我們約定數據管理者的初衷是能夠讓數據得到正確的修改，而不是引發新的問題。因此我們需要的是讓數據管理者根據技術對數據的要求、業務對數據的要求對數據進行修改，所以構建的數據標準管理體系要包括數據標準、數據安全權重。到目前為止，我們有了管理數據的人、管理數據的方式，我們就擁有了可用的數據，無論是將數據提供給其他系統還是為即將開展的項目提供數據基礎就已經具備一定的基礎了。從數據使用的視角來看這些數據可以通過集中管理的方式來提供出去。

低運維

數據類平臺最核心的功能就是計算數據，通常來講，數據平臺需要維護的數據流水線能達到上百條，要管理、維護幾百條數據流水線的運維成本往往是最容易被忽略的。自動化是降低數據平臺運維成本和提高效率的關鍵。通過自動化工具和流程，可以減少手動干預和人工錯誤。例如，自動化部署、自動化監控和自動化故障恢復等。自動化部署和自動化監控一般都有開源的實現數據組件可以實現，相對而言比較易于實現，但是數據流水線的自動化故障恢復則困難重重。常常會遇到數據計算到一半需要刷數據重新跑、難以debug等各種問題。我們將低運維中最重要的三個點攤開，幫助減少手動干預和人為錯誤，提高可靠性和可用性，并降低數據平臺的運維成本。

1.冪等性

冪等性是數據流水線自動化故障恢復的核心，冪等性的定義是相同的參數重復執行得到相同的結果。ETL 的冪等性就要求 ETL 可以被重復多次執行，且不會影響最終的計算結果。在面對復雜的數據流時，數據處理過程中的異常或日常 運維需求都意味著 ETL 可能會隨時停止、隨時啟動，那么如何在 ETL 重復多次執行的情況下確保數據的準確性和一致性就極為關鍵。滿足 ETL 冪等性的核心邏輯在于處理數據階段待處理批次的數據隊列清晰有序且可控，同時對于所涉及數據要滿足業務依賴。從運維視角看，運維人員可以在不同需求場景下對 ETL 進行手動觸發，而不用擔心是否會影響數據的準確性，從而可以在保證數據質量的前提下降低運維成本。從設計視角來看，則是要將調度依賴和數據依賴進行解耦，這樣就能確保調度層面的異常不會影響到數據本身。從混沌工程的原則看，能確保在滿足數據質量的前提下，降低計算資源浪費。

基于冪等性的大原則下，實現任務和調度的解耦，層與層之間的解耦，異常分級分類的解耦，都能實現低運維，同時可以保證任務的高效運行。這里的高效運行不是靠強大的計算引擎來提高任務的執行效率，更多指的是無需浪費額外的計算資源，實現任務處理的資源最小化原則。

2.日志分級分類

數據處理會涉及到任務調度服務、資源調度管理、計算、存儲等多種技術組件，而在數據處理階段，每一個組件的異常都會導致數據處理的失敗，那么在定位問題時就需要去各個組件中查看問題的根源，這就導致了運維成本大大增加。因此需要將日志進行分類解耦，資源層面、調度層面、 計算層面、數據層面等不同數據問題進行分類，可以幫助我們更便捷地開展運維工作。同時，對數據的錯誤也進行了分級，在數據處理階段，對于異常數據不能進行一刀切的方式處理，而應當根據業務來決定異常數據的錯誤級別，哪些數據可以流入數據平臺，哪些需要被清理掉，在數據處理階段需要明確定義各類數據錯 誤的處理規范。

在運維場景下，要求運維人員了解所維護的數據流水線中的各種業務上下文和實現細節是不現實的。那么如何做到面對復雜數據流、復雜組件和復雜任務的場景中，快速識別和定位異常問題呢？因此結合上述對于日志的分級以及數據層面異常分類，可以將復雜的運維場景進行切分，同時結合統一的門戶或工作臺進行日志查詢，更好的實現低運維。 

3.完善的數據監控機制 

在數據平臺的數據使用階段，我們要盡可能的避免數據異常問題在數據使用階段被暴露發現，這樣不僅會導致平臺的數據信譽度下降，異常數據流入下游系統或對一些分析決策造成影響，都會嚴重影響到業務。因此我們期望數據從開始接入到使用階段，應當有完善的數據監控機制。在數據接入階段，我們需要有識別上游變更的能力，即主動識別上游的系統變更、通道變更、數據結構變更等。在數據處理階段，基于業務定義的錯誤數據的級別分類，配置不同的預警，確保需要業務配合的異常數據調整及時預警并調整數據。在數據使用階段，通過貼合業務的數據測試自動化流程來識別異常數據。

完善的數據監控機制目的是為了將異常問題更早的暴露出來，同時可以推動業務系統或流程的完善。

數據測試

測試，是交付前必不可少的一道環節，是為了確保交付產物的正確性、完整性和安全性等而進行的一系列操作的過程，其最終目標是為了保證數據流水線的品質，對于保障軟件的穩定性和可靠性具有重要意義。

測試金字塔理論是傳統軟件工程指導測試工作的核心理論，在數據工程領域，測試金字塔理論也同樣適用，只不過需要進行一些改造。

我們將測試金字塔重新定義為：

• 單元測試為基礎確保最小邏輯的準確。其涵蓋兩方面:一、數據工程的基礎是 ETL，大部分數據工程均會有 一些工具來自動生成 ETL，而 ETL 自動生成代碼，就必然少不了單元測試。二、有了 ETL 之后，ETL 內部 仍然是由多個功能活方法組合而成，針對 ETL 內部方法的單元測試仍然不可或缺。由于單元測試相對獨立， 編碼成本較低，可以以小的代價運行。并且 ETL 為數據工程事實上的基本單位，對其進行的單元測試可以 覆蓋大部分細粒度的邏輯。 
• 分層測試確保單個模型的數據質量。在數據工程當中，為了快速響應變化、提高重復利用率以及減少性能瓶 頸，大部分的數據架構是縱向分層的架構，而不同層次有不同的數據處理邏輯，那么就需要先對每一層先進 行獨立測試驗證，再重點測試層與層之間的集成與功能。測試關注:元數據驗證、數據值、處理邏輯與處理 性能等。在保證每層數據、邏輯正確的情況下，才能為更高層次的功能與數據質量提供保證。
• 數據端到端測試確保交付需求的質量。端到端測試是從數據源到最終結果的驗證過程。覆蓋了數據全鏈路層 與層之間的耦合邏輯。一般而言，從數據源頭到最終數據應用鏈路很長，計算資源消耗也比較高，進行端到 端測試的方法一般是通過構建源數據，直接對比處理末端或應用端數據結果是否符合預期。數據端到端測試 雖然可以從最終結果上校驗功能，但其存在成本較高，數據用例構造復雜度較高、發現 Bug 定位困難、運 行時間超長等弊端，所以這層一般更多的是進行 happy path 的驗證與端到端性能測試，不會大范圍覆蓋所 有分支邏輯。
• 性能與安全測試。測試金字塔一般用來當做面向功能的測試策略。除了以上講到的在金字塔內部的多層測 試，在數據領域，由于數據量巨大以及數據往往會涉及到各種機密與隱私，所以數據安全測試、性能測試同 樣很重要。數據安全一般會根據具體項目情況涉及不同的測試策略，詳情可參閱數據安全篇章。而數據性能 則是另一個比較重要的點，一般的步驟為:預計數據量級，構造數據、準備生產仿真環境、準備測試用例、 產出性能測試報告、分析與改造等。 
• 人員與能力標準。數據工程測試金字塔從下到上技術細節逐漸減少，業務含義逐漸增多，通常來講，底層 ETL 測試主要由數據開發人員負責。中部數據分層測試由于包含對數據模型的驗證，需要有一定業務理解能 力的人員參與測試用例的制定，一般由數據測試、數據業務分析師以及數據工程師共同參與。而頂層的測試 用例由于很少涉及編碼細節，其測試基本可以由數據分析師和數據測試共同完成。 

小結

綜上所述，做好數據項目的工程化具有重要的意義和價值。數據平臺和應用類軟件雖然面向不同的用戶和需求，但長期運營的關鍵指標是功能性、健壯性、易用性、拓展性和可維護性，而科學的工程化可以滿足這些指標。數據項目工程化是加速數據到價值過程規模化的最佳實踐，因此我們需要了解數據項目中的痛點和挑戰，其中包括數據治理、降低維護成本、高效數據處理、靈活設計以滿足業務變化和賦能業務。