將一個系統置于恒定的約束之下可能會導致脆弱性的進化。-- C.S. Holling, ecologist

成為一個數據驅動的組織是許多公司的戰略目標之一，因為數據驅動的好處顯而易見: 基于數據和個性化提供最好的客戶體驗; 通過數據驅動的優化降低運營成本和時間; 給予員工具有趨勢分析和商業智能的力量。然而，盡管在構建數據平臺方面付出了越來越多的努力和投資，仍然會發現結果并不理想。

當前的技術進步解決了數據處理計算的規模問題，但還有問題懸而未決: 數據產生場景的變化、數據來源的擴散、數據用例和用戶的多樣性以及對變化的反應速度。Data Mesh或許可以解決這些問題。

1. 數據是什么？

數據到底是什么意思？又是一個“每個人心中都有一個哈姆雷特”的問題。數據通常被分為操作數據和分析數據。從數據庫的視角來看，即我們常說的OLTP和OLAP。一般地，操作數據位于服務提供業務功能的數據庫中，具有事務性質，保持當前狀態并服務于運行業務的應用程序的需求。分析數據是隨著時間的推移對業務事實的時間和聚合視圖，通過建模以提供回顧性或未來的洞察力，訓練機器學習模型或為分析報告提供信息。

當前的技術、架構和組織的狀態導致了這兩個數據領域的分歧，存在兩個層次，集成而又分離。這種分歧往往會導致架構的脆弱性。也導致了ETL 和不斷增長的迷宮般數據管道的復雜性。對于許多試圖連接這兩個領域的人來說，數據從操作數據領域流動到分析數據領域，然后再返回操作數據領域。

分析數據領域主要有兩個體系結構和技術棧: 數據湖和數據倉庫，而數據湖支持數據科學的訪問模式，數據倉庫支持分析和商業智能報告訪問模式。而實踐中常常出現，數據倉庫試圖搭載數據科學的工作流，數據湖又試圖服務于數據分析師和商業智能。

2. 數據領域面臨的挑戰

首先，數據平臺的發展大約經歷了三個階段：

• 專有的企業數據倉庫和商業智能平臺。這是一個價格昂貴的解決方案，給公司留下了大量的技術債務; 成千上萬的無法維護的 ETL 、表格和報告中的技術債務，同時只有少數專業人員能夠理解，導致對業務的積極影響沒有得到充分實現。
• 以數據湖為靈丹妙藥的大數據生態系統。復雜的大數據生態系統和由高度專業化的數據工程師組成的數據團隊長期運行批處理作業，創造了數據湖怪物，充其量只能讓一小部分研發分析成為可能，承諾過多而實現不足。
• 目前的數據平臺與前兩個階段或多或少有些相似，具有現代化的轉變: (a)使用諸如 Kappa 這樣的架構實現實時數據可用性的流，(b)將數據轉換的批處理和流處理這樣的框架統一起來，以及(c)完全接受基于云的存儲、數據管道執行引擎和機器學習平臺的管理服務。

顯然，第三代數據平臺正在彌補前幾代的一些差距，如實時數據分析，以及降低管理大數據基礎設施的成本，但是，仍然存在著諸多的挑戰。

2.1 中心化架構的挑戰

數據平臺從企業的各個角落攝取數據，包括運行業務的操作和事務系統，或者增加企業知識的外部數據提供者。例如，在流媒體業務中，數據平臺負責獲取大量數據: “媒體播放器表現”、“用戶如何與播放器互動”、“播放的歌曲”，以及業務上的“標簽”、與藝術家之間的“交易”，以及外部市場研究數據，如“人口統計”信息。清理、豐富源數據并將其轉換為可信賴的數據，以滿足不同使用者的需求。這將嘗試將用戶的操作流程和行為重構為聚合視圖。

數據平臺為具有不同需求的各種消費者提供數據集服務。這包括從分析性消費到探索數據，從基于機器學習的決策制定，到總結業務表現的商業智能報告。單一數據平臺承載并擁有邏輯上屬于不同領域的數據，例如“播放事件”、“銷售指標”、“藝術家”、“專輯”、“標簽”、“音頻”、“播客”、“音樂事件”等來自大量不同領域的數據。

盡管我們已經成功地將領域驅動設計和有界上下文應用到軟件系統中，但是在很大程度上忽略了數據平臺中的領域概念，從面向領域的數據所有權轉移到集中領域不可知的數據所有權。這種中心化架構可以適用于擁有較少不同消費案例且較簡單領域的組織，但是對于擁有豐富領域、大量來源和不同消費者集合的企業來說，難以滿足需求，原因如下：

無處不在的數據和數據擴散: 隨著越來越多的數據變得無處不在，在一個平臺的控制下消費所有數據并在一個地方協調它的能力會降低。

組織的創新和消費者的激增: 組織對快速實驗的需求引入了大量的用例來消費來自平臺的數據。這意味著數據聚合、預測和切片上的轉換越來越多，這些轉換用來滿足創新的測試和學習周期。滿足使用者需求的長響應時間歷來是組織摩擦點，目前仍然如此。

2.2 流水線耦合的挑戰

通常，數據平臺會被分解為數據處理階段的流水線。一條流水線，在高層次上實現了數據處理技術實現中的功能內聚，即攝取、準備、聚合、服務等。這種方式提供了一定程度的規模化，但將團隊分配到流水線的不同階段，有一個固有的限制，會導致交付變慢。流水線的各個階段之間具有高耦合性，以交付獨立的功能。

許多數據平臺提供了通用的和基于配置的數據攝取服務，可以處理諸如輕松添加新的數據源或修改現有的數據源以最小化引入的擴展開銷。但是，這并不會消除使用者引入新數據集導致端到端依賴關系的管理。雖然在表面上，流水線架構看起來好像已經達到了一個架構的規?；?，但實際上，整個流水線平臺必須改變以迎合新功能的最小單元: 解鎖一個新的數據集，并使其可用于新的或現有的消費者。這限制了對新消費者或新數據源實現高速規?；哪芰?。

2.3 數據所有權的挑戰

數據所有權與如何組織構建并擁有數據平臺的團隊有關。所謂的數據團隊是由專業化的數據工程師和數據產品經理組成，通常是孤立于業務組織的獨立單位，盡管會缺乏業務和領域知識，但在使用大數據工具方面有技術專長。數據團隊需要消費來自其他團隊的數據，而那那些團隊可能沒有提供有意義的、真實的和正確數據的動機。數據團隊對數據源的領域知道的有限，并可能缺乏專業的領域知識，卻需要為各種各樣的需求提供數據，無論是操作性數據還是分析性神經，而不需要清楚地了解數據的應用。

數據平臺團隊處于中間位置，只能全力以赴為所有來源和消費提供合適的數據。但實際上，資源的限制和不均衡，往往導致研發團隊和業務經理會另起爐灶，造成與數據團隊的緊張關系進一步加劇。這樣的組織結構缺乏擴展性，也沒有提供創建一個數據驅動組織所承諾的價值。

3 面對挑戰的數據平臺

鑒于此，數據平臺范式的轉變是必要的。數據平臺或許應該是分布式領域驅動架構、自服務平臺設計和產品思維與數據的融合。去中心化的數據平臺，需要顛倒我們對數據的看法，即它的本地性和所有權。領域需要以一種易于使用的方式托管和服務它們的領域數據集，而不是將數據從各自領域流向集中的數據湖。

3.1 數據與領域驅動架構的融合

領域驅動設計深刻影響了系統架構的思維方式，進而影響了組織建模。它通過將系統分解為圍繞業務域的分布式服務，從而成為微服務架構的誘因之一。它從根本上改變了團隊的形式，使得團隊可以獨立自主地擁有領域能力。

奇怪的是，在涉及到數據時，業務領域的概念被忽略了。DDD 在數據平臺中最接近的應用是讓數據源的系統發出它們的業務領域事件 ，并讓數據平臺消化它們。但之后，領域的概念和不同團隊對領域數據的所有權就丟失了。這需要我們的思維從傳統的ETL和事件流轉變為跨所有領域的推拉模型。在面向領域的數據平臺中，一個領域而不是流水線階段。

有些領域自然地與數據源保持一致。領域的源數據集表示了業務的事實和現實，業務事實最好以業務領域事件的形式表示，可以作為時間戳事件的分布式日志進行存儲和服務，以供任何授權使用者訪問。領域捕獲的數據非常接近數據起源的業務系統。領域和數據源系統之間往往沒有一對一的映射，通常有許多系統可以提供屬于某個領域的部分數據。因此，存在許多數據源對齊的數據集，最終需要聚合到一個內聚的領域數據集中。源域數據集是最基礎的數據集，更改的頻率較低，因為業務事實不會經常更改。這些領域數據集預計將被永久捕獲和提供，以便隨著組織發展其數據驅動和智能服務，它們總是可以回到業務事實，并創建新的聚合或預測。

有些領域與消費密切相關，消費者領域數據集可以滿足一組緊密相關的用例。雖然數據集所有權從中心化平臺委托給各個領域域，但仍然需要清理、準備、聚合和服務數據，流水線的使用也是如此。

3.2 數據與產品思維的融合

將數據所有權和流水線分配到業務領域，人們會更關切對分布式數據集的可訪問性、可用性和協調性，這就是產品思維和學習方法派上用場的地方。把數據資產作為產品，把組織的其他數據科學家、機器學習和數據工程師作為客戶。

任何技術產品的一個重要品質是取悅消費者，為消費者提供最佳的用戶體驗，領域數據產品需要具備以下基本要素:

可發現：一個常見的實現是擁有所有可用數據產品的注冊表、數據目錄及其元信息，例如它們的所有者、來源、譜系、樣本數據集等。

可尋址：一旦發現一個數據產品，它應該有一個唯一的地址，以API方式訪問它。根據底層存儲和格式，可能對其數據采用不同的命名約定。

可信賴：數據產品的所有者圍繞數據的真實性提供一個可接受的SLA，以及如何近似地反映已經發生的事件的真實性，或者所產生洞察力的高可能性。提供數據來源和沿襲作為與每個數據產品相關聯的元數據，有助于使用者進一步確信數據產品及其是否適合他們的特定需求。

自描述：高質量的產品可以被獨立地發現、理解和消費，數據模式是提供自助服務數據資產的起點。

互操作：跨領域數據有效關聯的關鍵是遵循某些標準和協調規則。這樣的標準化屬于全局治理，以支持多領域數據集之間的互操作性。這種標準化工作的常見問題是字段類型格式化、識別跨領域的多義詞、數據集的地址約定、常見元數據字段、事件格式等。

安全性：對于每個領域的數據產品，訪問控制都是以更細的粒度應用的。訪問控制策略可以集中定義，但在訪問每個單獨的數據集產品時應用。SSO和RBAC是實現產品數據集訪問控制的一種簡便方法。

3.3 數據與自助服務的融合

將領域不可知的基礎設施功能收集和提取到數據基礎設施平臺中，解決了重復設置數據流水線引擎、存儲和流式計算的需要。數據基礎設施團隊可以提供必要的技術，而各個領域需要這些技術來捕獲、處理、存儲和服務它們的數據產品。將數據基礎設施構建為平臺的關鍵在于: 

不包括任何特定于領域的概念或業務邏輯，保持其與領域無關;

確保平臺隱藏了所有潛在的復雜性，并以自助服務的方式提供數據基礎設施組件。

自助式數據基礎設施可以降低“創建新數據產品的準備時間”，例如，通過配置和腳本自動化完成數據攝入，數據產品創建腳本及生成框架，自動將數據產品注冊到目錄中，等等。云作為底層，可以降低提供對數據基礎設施按需訪問的操作成本和工作量。

這樣的新型數據平臺， 被業界命名為“Data Mesh”。Data Mesh 平臺是一個分布式數據架構，通過共享和協調的自助服務數據基礎設施來實現互操作性，進而實現集中治理和標準化。

4. 什么是Data Mesh？

Data Mesh是現代數據管理的一種戰略方法，也是加強組織數字化轉型的一種方法，它集中于提供有價值且安全的數據產品。Data Mesh是超越利用數據倉庫和數據湖的數據管理方法，強調組織靈活性，通過授權數據生產者和數據消費者的訪問來管理數據，數據所有權分配給特定于領域的團隊，這些團隊將數據作為產品提供、擁有和管理。

4.1 Data Mesh 與 數據湖

數據湖是一種技術方法，其主要目標是作為一個單一的存儲，以盡可能簡單的方式將數據轉移到中央團隊負責管理的地方。雖然數據湖可以提供顯著的業務價值，但它們也存在許多問題。主要的問題是，一旦數據被移動到湖中，它就失去了上下文，例如，可能有許多文件包含客戶的定義，一個來自物流系統，一個來自支付，一個來自營銷，哪一個適合使用呢？此外，數據湖中的數據沒有經過預處理，因此不可避免地會出現數據問題。然后，數據使用者通常必須與數據湖團隊聯系，以理解和解決數據問題，這將成為使用數據回答初始業務問題的瓶頸。

相比之下，Data Mesh不僅僅是技術，它結合了技術和組織，包括數據所有權、數據質量和數據自治。因此，數據消費者對數據質量和數據所有權有著清晰的認識，數據問題可以更有效地發現和解決，最終可以使用和信任數據。

數據湖不再是Data Mesh的中心，而是將數據湖的一些原則應用于面向數據源的領域數據產品。然而，無論是用于數據產品的內部實現，還是作為共享數據基礎設施的一部分，人們仍然繼續使用數據湖工具。Data Mesh是把領域數據產品作為第一類關注點，把數據湖工具和管道作為第二類關注點。同樣的原則也適用于用于業務報表和可視化的數據倉庫。它只是Data Mesh上的一個節點，可能位于面向消費者的網絡邊緣。也就是說， 將大數據整體分解成一個協調、協作和分布式的數據網格生態系統。

4.2 Data Mesh 與 Data Fabric

Data Fabric 側重于各種技術能力的集成，這些技術能力相互協作為最終用戶生成一個接口。許多Data Fabric 的支持者通過像機器學習這樣的技術來實現自動化，使得終端用戶能夠以更簡單的方式訪問數據。對于簡單的數據使用來說，這是很有價值的，但是對于更復雜的情況，或者需要將業務知識集成到數據中的情況，那么 Data Fabric 的局限性就會變得明顯。

可以說，Data Fabric 可以用作 Data Mesh 自助服務平臺的一部分，在這個平臺中，Data Fabric 將數據公開給領域，這些領域可以將其業務知識嵌入到最終的數據產品中。

Data Mesh的目標是為從分析數據和歷史事實中獲得價值創造一個基礎，這些數據和歷史事實在規模上適應于數據場景的不斷變化、數據來源和消費者的擴大化、用例需要的轉換和處理的多樣性以及對變化的反應速度。

5 Data Mesh 的 四個核心原則

Data Mesh 的四項核心原則作為一個整體是必要且充分的，使規模具有彈性，同時解決不兼容數據的孤立問題或運營成本增加的問題。

5.1 領域驅動的數據所有權和數據架構

要理解什么是領域域驅動數據，必須知道領域是什么。在Data Mesh 中，領域是負責數據管理的相關數據和創建的業務功能，負責聚合、轉換和向最終用戶提供數據。最終，該領域將其數據作為數據產品公開，其整個生命周期由該領域自身所有。

也就是說，Data Mesh 的核心是建立去中心化并把責任分配給最接近數據的人，以支持持續的變化和可擴展性。那么，如何分解和去中心化數據生態系統的組成部分及其所有權呢？包括分析數據、元數據和為其服務所需的計算。

為了促進這種分解，需要一個按領域排列分析數據的架構。在此架構中，領域與組織其余部分的接口不僅包括操作能力，還包括對該領域所服務的分析數據的訪問。這意味著必須消除耦合，以使領域服務于它們的分析數據，并使計算數據的代碼獨立于其他領域。為了擴展，必須支持領域團隊在其操作或分析數據系統的發布和部署方面的自主性。當然，每個領域可以依賴于其他領域的操作和分析數據端點。

5.2 數據即為產品

發現、理解、信任并最終使用高質量數據是個重要的問題，隨著提供數據領域的團隊數量增加，這個問題只會隨著Data Mesh而惡化，這就是領域自治的結果。數據即產品原則是為了解決數據質量和數據豎井問題而設計的，例如 Gartner 所說的暗數據——信息資產組織在日常業務活動中收集、處理和存儲，但通常不能用于其他目的。領域提供的分析數據必須被視為一種產品，數據的消費者應該被視為客戶。

領域數據產品所有者必須深入了解誰是數據用戶，他們如何使用數據，以及對使用數據感到舒適的方法是什么。這種對數據用戶的深入了解導致了滿足需求的數據產品接口設計，所有數據產品都可以開發支持標準化接口。數據用戶和產品所有者之間的對話是建立數據產品接口的必要部分。每個領域將包括數據產品開發人員的角色，負責構建、維護和服務領域的數據產品，數據產品的開發人員將與該領域的其他開發人員一起工作。每個領域團隊可以提供一個或多個數據產品，還可以組建新的團隊來服務那些自然不適合現有領域的數據產品。本質上，數據質量的問責制向上游轉移，盡可能接近數據源。

數據產品是網格上的節點，它封裝了功能所需的三個結構組件，作為產品提供對領域分析數據的訪問。

代碼: 它包括(a)負責消費、轉換和服務上游數據的數據流水線的代碼 (b)提供數據訪問、語義和語法模式、可觀測性指標和其他元數據的 API 代碼; (c)執行功能特性的代碼，如訪問控制政策、合規性、出處等。

數據和元數據: 根據領域數據的性質及其消費模型，數據可以作為事件、批處理文件、關系表、圖表等，同時保持相同的語義。為了使數據可用，有一組相關的元數據，包括數據計算文檔、語義和語法聲明、質量指標等; 數據固有的元數據，例如其語義定義，元數據用于實現預期行為的特征，例如訪問控制策略。

基礎設施: 基礎設施組件支持構建、部署和運行數據產品的代碼，以及存儲和訪問大數據及元數據。

總的來說，數據產品由領域生產，由下游領域或用戶使用，以創造業務價值。數據產品不同于傳統的數據集市，因為它們是獨立的，本身負責與確保數據保持最新有關的安全、來源和基礎設施等方面的問題。數據產品支持明確的所有權和責任，可以由其他數據產品或最終消費者直接使用，以支持商業智能和機器學習活動。

5.3 自助式的數據平臺

領域團隊能夠自主地擁有數據產品的唯一方法是訪問基礎設施的高級抽象，從而消除提供和管理數據產品生命周期的復雜性。這就需要一個新的原則，自服務數據基礎設施作為一個平臺，支持領域自治。

自助式數據基礎設施由許多功能組成，領域的成員可以輕松地使用這些功能來創建和管理其數據產品。自助式平臺功能按照模型中的調用分為多個類別或平面，每個平面服務于不同的用戶配置文件。一個平面類似于網絡中的控制層和數據層。自助式數據平臺由一個基礎設施工程小組提供支持，該小組的主要任務是對所使用的各種技術進行管理和操作。這是一種關注點分離，領域團隊關注數據，自助式數據平臺團隊關注技術。自助服務數據平臺的度量標準是領域的自主性。

也就是說，可以將數據平臺視為已經存在的用于運行和監視服務的交付平臺擴展。然而，當前用于操作數據產品的底層技術堆棧與數據服務的交付平臺非常不同，也是大數據技術棧與業務系統平臺的分歧。例如，業務領域域團隊可能服務部署為 Docker 容器，交付平臺使用 K8s， 然而，數據產品可能將其流水線代碼作為一個 Hadoop集群上的作業運行。這是兩套完全不同的基礎設施，而DataMesh 需要這種級別上的互操作性和互連性，在合理的地方趨于一致。

5.4 聯邦體系的治理

傳統的數據治理往往被看作是數據創造價值的阻礙因素。DataMesh 通過將治理關注點嵌入到領域的工作流中，數據治理有許多方面，使用度量和報告必須成為這個定義的一部分。數據的使用量以及如何使用這些數據是理解數據產品的價值從而獲得成功的關鍵點。

Data Mesh的實現需要一個治理模型，該模型包括領域自治、標準化的互操作性、動態拓撲結構，最重要的是平臺自動執行決策，可以稱之為聯邦計算的治理。一個由領域數據產品所有者和數據平臺產品所有者聯盟領導的決策模型，擁有數據所有權和領域本地決策權，同時創建并遵守一套全局規則，即一套適用于所有數據產品及其接口的規則，以確保生態系統的健康和互操作性。這個團隊有一個艱巨的任務: 維持集權和地方分治之間的平衡，哪些決策需要本地化到每個領域，哪些決策需要全局化到所有領域。最終，全局決策只有一個目的，即通過發現和組合數據產品，創建互操作性和復合網絡效應。

一個支持性的組織結構、激勵模式和架構是聯邦治理模式發揮作用的必要條件: 在尊重地方領域自主性的同時，達成全局互操作性的決策和標準，并有效地執行整體策略。在所有領域及其數據產品的平臺實施和執行的全局標準化內容與留給領域決定的內容之間取得平衡或許是一門藝術。

6. Data Mesh的實現

Data Mesh的實現為那些希望在不確定的經濟環境中蓬勃發展的組織提供了靈活性，所有組織都需要能夠以低成本、高回報的方式來應對環境的變化。引入新的數據源、需要遵守不斷變化的法規要求或滿足新的分析要求，這些都是促使組織數據管理活動發生變化的驅動因素。當前的數據管理方法通?；趶碗s的、高度集成的 ETL，這些 ETL 位于業務系統和分析系統之間，需要努力及時變化以支持業務需求。Data Mesh為數據管理提供了一個更具彈性的方法，以有效地應對這些變化。

Data Mesh是一種涉及人、過程和技術的社會化技術方法，需要在人、過程和技術的所有三個維度上對組織進行變革，可能會將70% 的精力花在人員和流程上，30% 的精力花在技術上。人員從中心化的數據團隊分散到各個領域，現有的工作人員對于采用Data Mesh的成功至關重要，他們擁有的知識和技能會做出貢獻。因此，管理層級和獎勵機制也發生了變化。為了促進可持續和敏捷的數據架構，需要在組織內部進行流程更改?？紤]數據治理，將需要圍繞數據策略定義、實現和執行的新流程，這將影響訪問和管理數據的流程，以及將該數據作為業務流程的一部分進行利用。

技術能力是實現和運營Data Mesh的關鍵，可能需要新技術的原因如下:

• 減少跨技術開發的摩擦，這些新技術的互操作性可能是至關重要的。
• 使領域能夠自給自足，并將重點放在第一類關注點上，即數據而不是技術。
• 允許在線購買新的數據平臺，并且可以無縫地公開這些平臺所暴露的數據
• 支持跨Data Mesh的治理報告，例如數據產品使用情況、遵守標準情況和數據產品反饋。

在構建Data Mesh生態系統的時候，一個關鍵的 Data Mesh 實現原則是通過利用現有的投資來連接數據源: 數據湖或數據倉庫; 云或內部設施等。在生成跨所有不同數據集的連接之后，下一個目標是為業務和分析團隊創建一個用于查找數據的接口，稱之為邏輯域。需要的所有數據都駐留在各自的領域中，領域團隊有權自主工作。通過自助服務的概念，數據使用者可以獨立完成更多的工作。下一步是如何將數據集轉換為數據產品。然后，使用數據產品創建一個庫或數據產品目錄。創建數據產品是一項強大的功能，使數據消費者能夠非?？焖俚貜陌l現過渡到構想以及洞察。

事實上，Data Mesh 可能并不適合于每個組織，可能主要針對那些在運營和環境中遇到不確定性和變化的大型組織。如果組織在數據方面的需求很小，而且這些數據需求不會隨著時間的推移而改變，那么Data Mesh可能是一個不必要的開銷。

7 小結

面對數據產生場景的變化、數據源的增長和擴散、數據用例和用戶的多樣性以及對變化的反應速度，當前的數據平臺或數據中臺面臨著較大的挑戰，而Data Mesh 或許是解決這些問題的一種嘗試。

為了面對這些挑戰，以實現規?；某兄Z，同時提供使數據質量和完整性保證，任何Data Mesh的實現都體現了四個基本原則：

• 面向領域的分散數據所有權和體系結構
• 數據作為產品
• 自助數據基礎設施作為平臺
• 聯邦計算治理

一句話，Data Mesh是現代數據管理的一種戰略方法，也是加強組織數字化轉型的一種方法，它集中于提供有價值且安全的數據產品。