作者 | 馬小強，陳健

什么是數(shù)據(jù)工程

數(shù)據(jù)工程是軟件工程的一部分，但不是傳統(tǒng)軟件工程在數(shù)據(jù)領(lǐng)域的簡單重現(xiàn)。數(shù)據(jù)工程是一套完整的體系，其包含了需求探索、架構(gòu)設(shè)計、平臺構(gòu)建、測試、維護演進等一系列階段，涵蓋了項目管理、開發(fā)過程管理、工程工具與方法、構(gòu)建管理、質(zhì)量管理等，是一套為了應(yīng)對規(guī)?；a(chǎn)和使用數(shù)據(jù)、為業(yè)務(wù)提供數(shù)據(jù)支撐，最終產(chǎn)生價值的體系。

數(shù)據(jù)工程與軟件工程的差異

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

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

為什么要做好數(shù)據(jù)項目的工程化

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

數(shù)據(jù)項目工程化是加速數(shù)據(jù)到價值過程規(guī)?；淖罴褜嵺`，那么我們就需要了解在實現(xiàn)數(shù)據(jù)到價值過程中所經(jīng)歷的數(shù)據(jù)接入、集成、清洗、處理、分析、使用等環(huán)節(jié)所涉及到的痛點和挑戰(zhàn)都有哪些。

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

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

數(shù)據(jù)梳理

數(shù)據(jù)梳理就是要全域分析數(shù)據(jù)粒度，規(guī)劃數(shù)據(jù)層次以及統(tǒng)一數(shù)據(jù)口徑。這么做的目的是整理清楚數(shù)據(jù)所代表的業(yè)務(wù)含義、去除跨部門和跨場景在理解上的不一致、尋找使用數(shù)據(jù)和計算的統(tǒng)一口徑、找到能夠維護數(shù)據(jù)的管理者，最終構(gòu)建在企業(yè)內(nèi)部能夠描述數(shù)據(jù)流轉(zhuǎn)過程、數(shù)據(jù)變化過程的全景。這么做的好處是讓數(shù)據(jù)使用者能夠?qū)?shù)據(jù)的變化有全面的認識，對于后續(xù)數(shù)據(jù)項目開展提供扎實的基礎(chǔ)。

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

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

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

低運維

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

1.冪等性

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

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

2.日志分級分類

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

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

3.完善的數(shù)據(jù)監(jiān)控機制 

在數(shù)據(jù)平臺的數(shù)據(jù)使用階段，我們要盡可能的避免數(shù)據(jù)異常問題在數(shù)據(jù)使用階段被暴露發(fā)現(xiàn)，這樣不僅會導(dǎo)致平臺的數(shù)據(jù)信譽度下降，異常數(shù)據(jù)流入下游系統(tǒng)或?qū)σ恍┓治鰶Q策造成影響，都會嚴重影響到業(yè)務(wù)。因此我們期望數(shù)據(jù)從開始接入到使用階段，應(yīng)當有完善的數(shù)據(jù)監(jiān)控機制。在數(shù)據(jù)接入階段，我們需要有識別上游變更的能力，即主動識別上游的系統(tǒng)變更、通道變更、數(shù)據(jù)結(jié)構(gòu)變更等。在數(shù)據(jù)處理階段，基于業(yè)務(wù)定義的錯誤數(shù)據(jù)的級別分類，配置不同的預(yù)警，確保需要業(yè)務(wù)配合的異常數(shù)據(jù)調(diào)整及時預(yù)警并調(diào)整數(shù)據(jù)。在數(shù)據(jù)使用階段，通過貼合業(yè)務(wù)的數(shù)據(jù)測試自動化流程來識別異常數(shù)據(jù)。

完善的數(shù)據(jù)監(jiān)控機制目的是為了將異常問題更早的暴露出來，同時可以推動業(yè)務(wù)系統(tǒng)或流程的完善。

數(shù)據(jù)測試

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

測試金字塔理論是傳統(tǒng)軟件工程指導(dǎo)測試工作的核心理論，在數(shù)據(jù)工程領(lǐng)域，測試金字塔理論也同樣適用，只不過需要進行一些改造。

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

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

小結(jié)

綜上所述，做好數(shù)據(jù)項目的工程化具有重要的意義和價值。數(shù)據(jù)平臺和應(yīng)用類軟件雖然面向不同的用戶和需求，但長期運營的關(guān)鍵指標是功能性、健壯性、易用性、拓展性和可維護性，而科學(xué)的工程化可以滿足這些指標。數(shù)據(jù)項目工程化是加速數(shù)據(jù)到價值過程規(guī)?；淖罴褜嵺`，因此我們需要了解數(shù)據(jù)項目中的痛點和挑戰(zhàn)，其中包括數(shù)據(jù)治理、降低維護成本、高效數(shù)據(jù)處理、靈活設(shè)計以滿足業(yè)務(wù)變化和賦能業(yè)務(wù)。