數據工程的介紹

我們可以將數據視為一種新興的生產要素或生產原材料。通過對其進行加工可以創造更多的價值，這些價值通常圍繞著業務和場景展開。因此，我們需要以一種能夠將數據生產和加工應用到實際場景和價值中的方式來使用數據。

《數據工程白皮書》中的數據范疇包括結構化、非結構化和半結構化的各種類型數據。這是因為我們需要處理各種形式的數據，無論是二維表格，還是圖像、音頻、視頻等等。這些數據的加工和處理，是我們實現更智能化場景的關鍵。因此，我們需要以數據為中心，去面對并解決這些數據加工的挑戰。

數據越來越重要

(資料圖片僅供參考)

在面對不同的問題和企業發展現狀時，數據需求也會有所不同。為了更好地說明這一點，《數據工程白皮書》列舉了信息化、數字化和智能化三個階段。在信息化階段，企業更多地關注業務流程和線上化，在構建系統時，我們需要先關注功能實現，而非數據的整合和平臺化。在功能實現之后，我們需要將業務流程的變化信息轉化為數據，并將這些數據串聯起來，以形成業務數據化的大方向。在智能化方面，像ChatGPT和文本生成等技術最近非常火熱。然而，實現智能化需要依賴于訓練數據樣本、構建模型、測試和優化等過程，這些過程都需要使用數據作為基礎。因此，數據在智能化過程中的使用至關重要。

企業所處的不同階段

在使用數據的過程中，不同階段的企業都需要從四個大方向考慮。首先，在業務數據化過程中，需要用數據展現業務經營過程，例如數據洞察和可執行業務動作。包括了現有業務過程、銷售額提升、銷售額提升的結構和下一步行動方向。

企業使用數據的四個階段

這里可以用銷售提升3%為例：

3%的銷售額提升是描述了企業目前正在發生什么 3%銷售額的提升是原有業務開展還是新興業務開展描述了企業發生變化的原因 3%銷售額的提升對企業運營來說，是需要繼續投入新業務抑或是需要保持優勢業務的持續開展描述了下一步的方向在哪里 企業發展訴求是要達到5%銷售額的提升，那么需要如何投入、如何發力描述了企業如何確保業務發展方向與預想保持一致

數據在企業中的應用場景將越來越多，因此對于數據工程的概念可能存在不同的理解。需要澄清的是，數據工程是一個體系，涵蓋了從企業數據戰略、需求設計、技術設計到開發、質量管控和流程等方面。它源于軟件工程的實踐，但是在數據工程中被提煉出來并映射到數據層面的工作。需要強調的是，數據工程不僅僅是數據開發。

為了快速實現數據工程這個復雜體系，需要規模化的方式來提高開發效率，并減少人員更替和交接所帶來的影響。為此，《數據工程白皮書》提出了相關實踐和對人員能力的要求，并提到了數據工程成熟度的概念。不同企業的需求和狀態不同，有些企業可能只需要遵循一些規范化的開發原則，而有些企業需要應對幾十人甚至上百人的開發團隊，保證在每個項目上都能發揮更高的工作效率。這時，需要對整個企業的數據工程成熟度進行評估，以有針對性地提升相關方向。

Thoughtworks對于數據工程概念的定義

數據工程的價值

數據轉化為業務價值的過程與企業使用數據的四個階段緊密相連。對于銷售額提升 3% 的需求，我們需要將這個數字拆解并了解其背后所要使用的數據以及所需經歷的過程，比如銷售額是含稅還是不含稅、單位是按照什么樣的金額進行換算等。在處理數據時，也會涉及到不同系統的選擇和數據信息的持續定義和澄清過程，最終才能得到真正的洞見。在整個數據流轉過程中，我們需要不斷提升各個步驟的效率。

數據在企業內流轉過程

在數據工程中，數據從原料加工到成品需要考慮很多因素，如指標計算口徑、數據異常預警等。同時，數據需要在不同階段進行設計和實現，以體現企業經營的狀況。在數據工程的設計中，需要考慮到各個階段的注意要素，以保障數據工作的有效性和準確性。在業務和數據的融合過程中，需要將業務訴求與數據處理有效地融合在一起。業務和數據的邊界越來越模糊，因此需要技術支撐和保障，實現業務、數據和技術的有機融合，這是實現數據到價值過程的核心要素。

數據“原料”到“成品”對加工示例

數據工程是一個復雜的體系，需要從人員層面解決開發成本和效率的問題。有標準化的設計和管控可以提高數據工程的效率和面對規模化時的應對能力。團隊之間需要統一數據標準，解決數據孤島問題，降低業務場景下的聯動成本。對于企業能夠快速滿足業務需求，以更小的成本實現業務訴求。根本目的是打造一個高響應力的企業流程，以提高數據生產和加工的效率。只有在數據生產的相關原材料準確無誤，才能挖掘數據的價值和實現智能化的演進。因此，統一、標準化和提高效率是數據工程的核心要素。

數據工程對企業對價值

數據工程的價值觀

我們看到了數據工程的價值，那么為了更好地落地數據工程，我們需要明確數據工程的價值觀。思特沃克數據和人工智能團隊根據我們服務的不同的客戶及過往的項目經驗，總結了如下的價值觀。我們參考了敏捷宣言中xxx勝過xxx的方式，我們認為右邊的也有價值，但是更重視左邊的價值，因為每個企業都有自己的發展規模和階段，在每個時期會有不同的側重點。我們也期望在企業內部，根據自身的實際情況，建立符合企業需求的價值觀，同時不斷地調整和演進。

一、以數據產生的業務價值為交付結果

我們應該關注數據處理后能為業務帶來的價值，而非僅僅關注數據接入和處理指標的數量。例如，我們可以關注數據如何幫助了解銷售訂單的趨勢及其原因，以便為業務提供有益的指導。盡管不一定非得用業務收入作為衡量標準，但我們應該努力實現數據產生的業務價值作為交付結果。

我們觀察到有些企業在建立數據中臺或數據平臺時，非常關注接入的數據量和計算指標的多少，將其作為衡量項目成功與否的重要指標。雖然數據接入、處理和指標計算可以作為衡量數據平臺或數據中臺成果的指標，因為它們反映了工作量和處理量，但我們不建議將它們視為北極星指標或非常重要的指標。我們強調的是數據產生的價值，即經過處理后的數據如何服務于實際業務場景。

二、建立全功能的團隊，實現端到端交付

許多企業在數據處理過程中存在類似的問題，如一個業務場景的實現可能會涉及數據湖、數據倉庫和報表可視化等部門，這個跨組、部門帶來的協作隔閡是非常影響交付結果的。雖然我們不一定要完全打破現有的組織形式，但我們應該改進我們的協作方式，盡量減少溝通隔閡，提高團隊的協作效率。比如，建立基于項目的臨時交付團隊。

三、面向業務域的劃分和面向未來的設計

隨著數據驅動的業務和企業愿景的發展，數據分析需求將不斷擴大，企業數據應用預計會有很大的發展潛力。因此，在規劃時要具有一定的前瞻性，考慮到企業未來對數據存儲、計算和分析的需求。

在這個背景下，數據存儲、計算框架的技術選擇都需要謹慎考慮。例如，選擇傳統數據庫還是Hive，Iceberg等，大數據處理框架如Spark、Flink，還是pandas就可以。此外，還需要考慮如何劃分數據存儲，例如數據庫的劃分。在這里，我們推薦按照業務域進行劃分，包括存儲、ETL組織、ETL調度（DAG）和報表規劃等。這樣，可以根據業務需求變化進行靈活調整，適應企業的發展。

四、團隊知識積累和傳承勝過簡單的文檔交接

在項目過程中，需要業務分析師、開發人員和測試人員緊密合作，共同了解需求，通過緊密協作進行知識傳承。在實際開發過程中，我們鼓勵結對編程、Code Review等方式進行知識傳承。我們的測試人員通常會在項目開始階段就參與需求了解，與業務和開發人員共同參與需求的確定。這樣的知識傳承方式有助于項目順利進行，而不是業務分析師把一堆文檔交給開發和測試。

我們希望這些價值觀能夠引導大家進行深入思考，更好地落地數據工程。不只關注交付結果，更加關注交付流程中的需求、開發、測試和業務的協作和流程，從而提升交付效率和質量，建立更加和諧的數據應用交付團隊。

數據工程的7條原則

基于上面的價值觀，我們形成了7條原則來指導各種場景下的應用。我們將原則打印并放在顯眼位置提醒團隊成員。在日常工作中遇到分歧時，我們回顧這些原則以指導數據開發過程的改進，確保團隊始對數據工程的一致理解。

原則一、功能設計與開發要從價值交付考量：

我們會通過一系列的活動確保項目的交付是基于業務價值的。通過愿景工作坊，針對高層管理者確定項目業務愿景。接下來，通過業務訪談，需求分析師和產品經理與一線用戶進行溝通，了解現狀、痛點和工作流程。基于收集的信息，我們進行桌面研究，整合類似客戶和項目經驗以及行業前沿洞見。

然后，我們通過訪談不同業務角色，為平臺用戶創建不同的用戶畫像（persona）。有時會為用戶起有趣的名字，以便討論時更加生動。接著，通過服務藍圖工作坊梳理業務流程、系統支撐和數據產生交互過程。在梳理出需解決問題和需完成任務后，我們通過優先級考量方式對功能進行排序，平衡緊急程度和價值，從數據、技術和業務三個維度進行考量。

通過一系列活動確保我們是在為業務交付價值，在交付過程中，我們也會有一些其他的實踐確保和業務的緊密合作。

原則二、合理的架構設計不僅指解決現有問題，還能夠在一定程度解決未來問題：

數據類項目的重構成本比傳統應用開發要高一些，因為數據遷移和上下游庫表的強依賴。所以，我們建議數據平臺的架構要有一定的前瞻性。

在設計過程中，考慮四個方向：面向領域的設計，即按照領域維度拆分DAG構建和庫表結構；演進式的平臺和工具設計，在選擇成熟的數據平臺工具時，要注意短時的易用性與長期的可維護性之間的平衡；最后是數據模型設計的前瞻性，通過領域專家進行邏輯建模并達成共識，方便基于邏輯模型進行討論和實現。

原則三、我們倡導通過統一的工作標準和流程提升團隊協作效率：

雖然敏捷開發不鼓勵一定要遵循某個流程，但我們仍然需要一定的工作標準。這些流程應該是可調的，以便隨著時間的推移和團隊的進步進行調整。

我們通過多年的實踐，摸索出一套適合國內環境的敏捷開發流程。我們形成了一個穩定的交付周期，每兩周進行一次迭代。在這個迭代開始前，我們會不斷地與業務方溝通以確定優先級，確定迭代交付的內容。在迭代中，對每個故事卡的完成情況進行驗收，確保數據準確性，并在最后進行持續發布。完整的迭代過程包括，拆分故事卡，迭代計劃，故事卡墻的建立，迭代開發，功能演示，用戶驗收，持續發布，迭代回顧。

過程中，如何進行數據探測，單元測試，代碼審核，代碼提交規范，數據質量校驗，都會形成團隊自己的工作標準和流程，減少協作的隔閡。

原則四、工具是知識沉淀的具體表現，有效的工具能夠提升規模化開發效率：

工具是知識沉淀的具體表現，通過有效的工具可以提升我們的開發效率。數據項目的交付可能包括數據集、報表、模型等可見部分，以及不可見的數據處理流程。我們需要在數據處理中提升效能，逐漸沉淀一些工具，例如數據接入層的自動化工具、ETL框架、工作臺等，以提升開發效能。

原則五、欣然面對需求變化，及時調整交付策略 ：

這個原則主要是關于面對變化，并及時調整交付策略。基于一個Backlog的管理需求，我們需要處理來自不同來源的需求，如業務需求、公司規劃舉措、產品用戶反饋和線上問題等。這些需求將被歸入到一個Backlog中，并根據優先級和緊迫性進行排序，再放入后續迭代中。

然而，我們需要注意一點：在應對需求變化時要避免過于隨意。例如，當客戶在今天晚上提出需求，希望明天就能完成時，我們需要評估需求的緊迫性是否真的如此之高，并考慮如何更好地支持這種需求，例如通過改造系統，讓業務自己完成。原因在于開發需要有自己的節奏，如果頻繁地切換上下文或打破開發節奏，可能會對開發帶來反向影響。因此，我們需要小心管理這些需求。

總之，在面對需求變化和管理業務變化時，要注意避免隨意的變化，并確保開發能夠保持自己的節奏。這樣，我們才能更好地應對和管理需求變化。

原則六、數據治理需要滲透到整個數據工程落地過程當中：

在實際操作中，我們倡導精益數據治理。這是因為在企業內進行大而全的數據治理會消耗大量的人力物力，并且實施起來相當困難。

因此，我們現在的原則是基于數據應用驅動的數據治理。例如，在做一個訂單相關的報表時，我們首先針對這部分的數據治理，解決數據質量、數據安全等問題，并根據應用場景設計相應的解決方案。當我們需要處理其他方面的數據，如簽收和物流時，可以按照數據應用的角度逐步完善數據治理制度。

在數據項目的實施過程中，可能會遇到一些數據問題，這些數據問題需要反向到業務系統的數據源進行改變。但業務系統的變化可能會較慢或響應遲緩，這時可以通過技術債進行管理，在數據平臺可以暫時采用Workaround來解決問題。

總之，我們需要采用切片式的數據治理，并通過技術債進行全面數據質量管理。

原則七、人是數據工程落地的核心，要注重人員培養、知識傳承：

雖然我們將這個原則放在第七位，但實際上它是最重要的原則。敏捷宣言中提到個人和交互勝過流程和工具，所以對于整個數據工程來說，人員是核心。我們經常在跟客戶探討數據項目的交付實踐的時候，最后都會歸結到員工能力和文化上。因此，我們會注重人員本身的培養，包括知識傳承和成長。

這里的成長并不僅僅指企業內部的職業發展路線，而是指在項目或產品開發過程中的成長。我們有一些好的實踐，如項目初期，團隊成員會介紹自己的能力背景，并期望在項目中的成長。在項目過程中，我們通過讀書會、分享、結對編程和代碼審查等方式，為數據工程師和數據分析師提供學習機會。對于長期項目，我們需要有意識的逐漸培養人才梯隊。上圖中這里有一句話：“你需要長得這么高才能敏捷嗎？”實際上，并非如此，一個團隊中會有不同層次的人才，我們需要提供一個成長環境，讓大家能夠提升能力和傳承知識。

總結

數據工程是數字經濟下確保數據價值轉化的重要保障， 是加速數據轉化為價值的重要手段，數據工程能力應對的不僅僅是當下的挑戰，更是應對未來數字經濟大趨勢的秘密武器。隨著需要處理的數據量的增長，為了處理數據領域的各種新問題，各種新技術、新概念逐漸涌現，現代數據倉庫、數據湖、湖倉一體、分布式數據架構、機器學習、數據云原生等逐一登上舞臺，數據工程的發展道阻且長。

所以無論是站在企業內部的發展訴求還是站在企業所處的社會大環境，都在要求企業加速自己轉型、完善自己的數據能力，在激烈的市場競爭過程中獲得有利地位才能在未來數字經濟繁榮成熟期到來之前占據有利戰略發展位置。

關注Thoughtworks洞見公眾號，獲取Thoughtworks《數據工程白皮書》

標簽：