石秀峰薦語：Data Fabric、Data Mesh是當前流行的數字化前沿技術，代表了數據管理的未來。在之前的一篇文章《你知道數據治理，你聽過數據編織嗎？》中，有讀者留言說讓講講Data Mesh。今天這篇文章來自Data Mesh首創者Zhamak，我們看看作者提出Data Mesh的初衷以及她的觀點。

一、什么是數據網格數據網格（Data Mesh）

是一種應用在企業內部的數據平臺原則，其融合了分布式領域驅動的架構（Distributed Domain Driven Architecture），自助平臺設計（Self-serve Platform Design）以及將數據視為產品（Thinking Data as a Product）的思維。數據網格專注于將數據視為產品，產品團隊了解自己所使用的數據的方方面面（也就是所有的域）。并且 Data Mesh 將數據所有權上移給了負責某一項功能的團隊，讓他們按照他們更好使用的方式去創建，接觸元數據，對數據進行分類和存儲。數據創建階段時的數據管理和數據分類會讓數據更為透明，更易于使用，從而消除了團隊與團隊之間的知識孤島，并使數據真正民主化。從而幫助數據的使用方不必糾結于如何發現想要的數據，使其更加專注于如何從數據中產生價值。我們希望通過數據來增強和改善業務和生活的各個方面，這要求我們大規模管理數據的方式發生范式轉變。雖然過去十年的技術進步已經解決了數據量和數據處理計算的規模，但它們未能解決其他方面的規模問題：數據格局的變化、數據源的擴散、數據用例和用戶的多樣性，以及對變化的響應速度。Data Mesh為解決這些問題，建立了四個原則：面向領域的分散數據所有權和架構、數據作為產品、自助數據基礎設施作為平臺以及聯合計算治理。每個原則都推動了技術架構和組織結構的新邏輯視圖。

二、數據的巨大鴻溝我們對數據的真正含義是什么？

答案取決于你問誰。當今的格局被分為運營數據和分析數據。業務數據位于用微服務提供的業務能力背后的數據庫中，具有交易性質，保持當前狀態，并為運行業務的應用程序的需求服務。分析性數據是業務事實在一段時間內的時間和聚合視圖，通常被建模以提供回顧性或未來視角的洞察力；它訓練ML模型或為分析報告提供資料。技術、架構和組織設計的現狀反映了這兩個數據平面的分歧--兩個層次的存在，整合而又分離。這種分歧導致了一個脆弱的架構。不斷失敗的ETL（提取、轉換、加載）工作和不斷增長的數據管道迷宮的復雜性，是許多試圖連接這兩個平面的人所熟悉的場景，數據從操作數據平面流向分析平面，然后又回到操作平面。

圖 1：數據的巨大鴻溝

分析數據平面本身已經分化為兩個主要的架構和技術棧：數據湖和數據倉庫。數據湖支持數據科學訪問模式，數據倉庫支持分析和商業智能報告訪問模式。

在這篇文章中，我將兩個技術堆棧之間的關系放在一邊：數據倉庫試圖加入數據科學工作流，而數據湖試圖為數據分析師和商業智能提供服務。

圖 2：分析數據的進一步劃分 - 倉庫

圖 3：分析數據的進一步劃分 - 湖

數據網格承認并尊重這兩個層面之間的差異：數據的性質和拓撲、不同的用例、數據消費者的個人角色，以及最終的不同訪問模式。然而，它試圖在不同的結構下連接這兩個平面——基于域而不是技術堆棧的倒置模型和拓撲-專注于分析數據平面。當今管理這兩種數據原型的可用技術的差異不應導致組織、團隊和工作人員的分離。在我看來，操作和事務數據的技術和拓撲是比較成熟的，主要是由微服務架構驅動的；數據隱藏在每個微服務內部，通過微服務的 API 進行控制和訪問。是的，真正實現多云原生操作數據庫解決方案仍有創新空間，但從架構的角度來看，它滿足了業務的需求。然而，分析數據的管理和訪問仍然是一個大規模的摩擦點。這是數據網格關注的地方。我確實相信，在未來的某個時候，我們的技術會不斷發展，讓這兩個飛機更加靠近，但就目前而言，我建議我們將它們的關注點分開。

三、數據網格的核心原理和邏輯架構數據網格的目標

是為從大規模分析數據和歷史事實中獲取價值奠定基礎，并將其應用于不斷變化的數據環境、數據源和消費者的擴散、用例所需的轉換和處理的多樣性、速度。對變化的反應。為了實現這一目標，我建議有四個基本原則任何數據網格實現都體現為實現規模化承諾，同時提供使數據可用所需的質量和完整性保證：

1）面向領域的分散數據所有權和架構，

2）數據作為產品，

3）自助數據平臺，

4) 聯合計算治理。

雖然我預計這些原則的實踐、技術和實現會隨著時間的推移而變化和成熟，但這些原則保持不變。我打算讓這四項原則共同成為必要和充分，實現彈性擴展，同時解決不兼容數據孤島或運營成本增加的問題。讓我們深入研究每個原則，然后設計支持它的概念架構。

01 領域所有權數據網格的核心是分散?和將責任分配給最接近數據的人，以支持持續的變化和可擴展性。問題是，我們如何分解和分散數據生態系統的組成部分及其所有權。這里的組件由分析數據、其元數據以及為其提供服務所需的計算組成。數據網格遵循組織單元的接縫作為分解軸。我們今天的組織是根據其業務領域進行分解的。這種分解將持續變化和進化的影響——在大多數情況下——本地化到域的有界上下文中。

因此，使業務領域的有界上下文成為數據所有權分布的良好候選者。在本文中，我將繼續使用與原始文章“一家數字媒體公司”相同的用例。可以想象，媒體公司根據“播客”、管理播客發布的團隊和系統及其主機等領域來劃分其運營，因此支持運營的系統和團隊；“藝術家”、管理入職和付費藝術家的團隊和系統等。數據網格認為分析數據的所有權和服務應該尊重這些領域。例如，管理“播客”的團隊在為發布播客提供 API 的同時，還應負責提供代表“已發布播客”隨時間推移的歷史數據以及隨時間推移的“收聽率”等其他事實——面向領域的數據分解和所有權。邏輯架構：面向領域的數據和計算為了促進這種分解，我們需要建模一個按域排列分析數據的架構。在此架構中，領域與組織其他部分的接口不僅包括操作能力，還包括對域所服務的分析數據的訪問。例如，“播客”域提供了操作 API 來“創建新的播客集”，還提供了一個分析數據端點，用于檢索“過去個月內的所有播客集數據”。這意味著架構必須消除任何摩擦或耦合，以讓域提供其分析數據并發布計算數據的代碼，獨立于其他域。以下示例演示了面向領域的數據所有權原則。這些圖只是邏輯表示和示例性的。它們并不打算完整。每個域可以公開一個或多個操作 API，以及一個或多個分析數據端點：

圖 4：符號：域、其分析數據和操作能力

自然地，每個域都可以依賴于其他域的操作和分析數據端點。在以下示例中，“播客”域使用來自“用戶”域的“用戶更新”分析數據，因此它可以通過其“播客聽眾人口統計”數據集提供播客聽眾的人口統計圖。

圖 5：示例：除運營能力外，面向領域的分析數據所有權

注意：在示例中，我使用了一種命令式語言來訪問操作數據或功能，例如“付費藝術家”。這只是為了強調訪問操作數據與分析數據的意圖之間的區別。我確實認識到，實際上操作 API 是通過更具聲明性的接口實現的，例如訪問 RESTful 資源或 GraphQL 查詢。

02 數據作為產品現有分析數據架構的挑戰之一是發現、理解、信任和最終使用高質量數據的高摩擦和成本。如果不解決，這個問題只會隨著數據網格的增加而加劇，因為提供數據（域）的地方和團隊的數量會增加。這將是我們第一個去中心化原則的結果。數據即產品原則旨在解決數據質量和古老的數據孤島問題；或者正如 Gartner 所說的暗數據?——“組織在日常業務活動中收集、處理和存儲，但一般不用于其他目的的信息資產”。

域提供的分析數據必須被視為一種產品，而該數據的消費者應該被視為客戶——快樂和高興的客戶。原文中列舉了一系列功能，包括：可發現性、安全性、可探索性、可理解性、可信賴性等，數據網格實現應支持將域數據視為產品。它還詳細說明了組織必須引入的領域數據產品所有者等角色，負責確保數據作為產品交付的客觀措施。這些措施包括數據質量、減少數據消耗的前置時間，以及通過凈推薦值獲得的總體數據用戶滿意度，領域數據產品所有者必須深入了解數據用戶是誰，他們如何使用數據，以及他們習慣于使用數據的原生方法是什么。這種對數據用戶的深入了解導致設計出滿足他們需求的數據產品界面。

實際上，對于網格上的大多數數據產品，都有一些具有獨特工具和期望的傳統角色、數據分析師和數據科學家。所有數據產品都可以開發標準化的接口來支持它們。數據用戶與產品所有者之間的對話是建立數據產品接口的必要環節。每個域將包括數據產品開發人員角色，負責構建、維護和服務域的數據產品。數據產品開發人員將與該領域的其他開發人員一起工作。每個領域團隊可以提供一個或多個數據產品。也可以組建新的團隊來提供不適合現有運營領域的數據產品。注意：與過去的范例相比，這是一種倒置的責任模型。數據質量的責任在盡可能靠近數據源的地方向上游轉移。

邏輯架構：數據產品架構量子在架構上，為了支持數據作為域可以自主服務或消費的產品，數據網格引入了數據產品的概念作為其架構量子。由進化架構定義的架構量子?是最小的架構單元，可以獨立部署并具有高功能凝聚力，并包括其功能所需的所有結構元素。數據產品是網格上的節點，它封裝了其功能所需的三個結構組件，作為產品提供對域分析數據的訪問。代碼：它包括：

a）負責消費、轉換和服務上游數據的數據管道代碼——從域的操作系統或上游數據產品接收的數據；

b) 提供對數據、語義和語法模式、可觀察性指標和其他元數據的訪問的 API 代碼；

c) 用于執行特征的代碼，例如訪問控制策略、合規性、出處等。數據和元數據：這就是我們在這里的目的，以多語言形式提供基礎分析和歷史數據。根據領域數據的性質及其消費模型，數據可以作為事件、批處理文件、關系表、圖形等，同時保持相同的語義。為了使數據可用，有一組相關的元數據，包括數據計算文檔、語義和語法聲明、質量指標等；數據固有的元數據，例如其語義定義，以及傳達?計算治理使用的特征以實現預期行為的元數據，例如訪問控制策略。基礎設施：基礎設施組件支持構建、部署和運行數據產品的代碼，以及存儲和訪問大數據和元數據。

圖 6：作為一個架構量的數據產品組件

以下示例建立在上一節的基礎上，將數據產品演示為架構量子。該圖僅包含示例內容，并不旨在完整或包含所有設計和實施細節。雖然這仍然是一個邏輯表示，但它越來越接近物理實現。

圖 7：符號：域、其（分析）數據產品和操作系統

圖 8：服務于面向領域的分析數據的數據產品

注意：數據網格模型不同于過去將管道（代碼）作為與其產生的數據的獨立組件進行管理的范例；通常基礎設施，如倉庫或湖泊存儲帳戶的實例，在許多數據集之間共享。數據產品是所有組件（代碼、數據和基礎設施）的組合，以域的有界上下文為粒度。

03 自助數據平臺正如您可以想象的那樣，要構建、部署、執行、監控和訪問一個不起眼的六邊形——一種數據產品——需要配置和運行相當多的基礎設施；提供這種基礎設施所需的技能是專門的，很難在每個領域中復制。最重要的是，團隊可以自主擁有他們的數據產品的唯一方法是訪問高級抽象的基礎設施，從而消除配置和管理數據產品生命周期的復雜性和摩擦。這需要一個新的原則，將自助數據基礎設施作為實現域自治的平臺。數據平臺可以被認為是已經存在的用于運行和監控服務的交付平臺的擴展。然而，如今操作數據產品的底層技術堆棧與服務交付平臺看起來非常不同。這僅僅是由于大數據技術堆棧與操作平臺的差異。例如，領域團隊可能將他們的服務部署為 Docker 容器，而交付平臺使用 Kubernetes 進行編排；但是，相鄰的數據產品可能會在 Databricks 集群上將其管道代碼作為 Spark 作業運行。這需要配置和連接兩組非常不同的基礎設施，在數據網格之前，它不需要這種級別的互操作性和互連性。我個人的希望是，我們開始看到運營和數據基礎設施在有意義的地方融合。例如，可能在同一個編排系統（例如 Kubernetes）上運行 Spark。實際上，為了使通才開發人員可以訪問分析數據產品開發，對于現有的域開發人員配置文件，自助服務平臺除了簡化配置之外還需要提供一種新的工具和接口。自助數據平臺必須創建工具，以支持領域數據產品開發人員創建、維護和運行數據產品的工作流程，而現有技術假定的專業知識較少；自助式基礎設施必須具備降低當前成本和構建數據產品所需的專業化能力。最初的文章包括自助數據平臺提供的功能列表，包括訪問可擴展的多語言數據存儲、數據產品模式、數據管道聲明和編排、數據產品沿襲、計算和數據局部性等。邏輯架構：多平面數據平臺自助平臺功能分為模型中所稱的多個類別或平面。注意：一個位面代表了一個存在層次——既整合又分離。類似于物理和意識平面，或網絡中的控制和數據平面。平面既不是層，也不意味著強大的分層訪問模型。

圖 9：通過自助服務接口提供許多相關功能的平臺平面

自助服務平臺可以有多個平面，每個平面服務于不同的用戶檔案。在以下示例中，列出了三個不同的數據平臺平面：數據基礎設施供應平面：支持運行數據產品組件和產品網格所需的底層基礎設施供應。這包括提供分布式文件存儲、存儲帳戶、訪問控制管理系統、運行數據產品內部代碼的編排、在數據產品圖上提供分布式查詢引擎等。我希望其他數據平臺平面或者只有高級數據產品開發人員直接使用此接口。這是一個相當低級的數據基礎設施生命周期管理平面。數據產品開發者體驗平面：這是典型的數據產品開發者使用的主要界面。該接口抽象了支持數據產品開發人員工作流所需的許多復雜性。它提供了比“供應平面”更高級別的抽象。它使用簡單的聲明式接口來管理數據產品的生命周期。它自動實現被定義為一組標準和全局約定的橫切關注點，適用于所有數據產品及其接口。數據網格監督平面：有一組最好在網格級別提供的功能 - 連接數據產品的圖形 - 全局。雖然這些接口中的每一個的實現都可能依賴于單獨的數據產品功能，但在網格級別提供這些功能會更方便。例如，發現特定用例的數據產品的能力最好通過搜索或瀏覽數據產品的網格來提供；或關聯多個數據產品以創建更高階的洞察力，最好通過執行可以跨網格上的多個數據產品操作的數據語義查詢來提供。以下模型僅是示例性的，并不打算完整，雖然平面的層次結構是可取的，但下面沒有暗示嚴格的分層。

圖10：多平面自助數據平臺 *DP代表數據產品

04 聯合計算治理如您所見，數據網格遵循分布式系統架構，一組具有獨立生命周期的獨立數據產品，由可能的獨立團隊構建和部署。然而，對于大多數用例而言，為了以高階數據集、洞察力或機器智能的形式獲得價值，這些獨立的數據產品需要互操作；能夠關聯它們、創建聯合、查找交點或執行其他圖形或對它們進行大規模設置操作。為了使任何這些操作成為可能，數據網格實現需要一個治理模型，該模型包含去中心化和域自主權、通過全球標準化的互操作性、動態拓撲最重要的是平臺自動執行決策。我稱之為聯合計算治理。由域數據產品所有者和數據平臺產品所有者聯合領導的決策模型，具有自治和域本地決策權，同時創建并遵守一組全局規則——適用于所有數據產品及其接口的規則——以確保健康和可互操作的生態系統。該集團有一項艱巨的工作：保持中心化和去中心化之間的平衡;?哪些決策需要本地化到每個域，哪些決策應該針對所有域全局進行。最終，全球決策只有一個目的，即通過數據產品的發現和組合創造互操作性和復合網絡效應。數據網格中治理的優先級不同于分析數據管理系統的傳統治理。雖然他們最終都開始從數據中獲取價值，但傳統的數據治理試圖通過集中決策來實現這一目標，并在對變更的支持最少的情況下建立數據的全球規范表示。相比之下，數據網格的聯合計算治理包含變化和多種解釋上下文。將系統置于恒定的緊身衣中可能會導致脆弱性演變。—— CS Holling，生態學家 邏輯架構：嵌入在網格中的計算策略支持性的組織結構、激勵模型和?架構對于聯邦治理模型的運作是必要的：達成互操作性的全球決策和標準，同時尊重本地域的自主權，并有效地實施全球政策。

圖 11：符號：聯合計算治理模型

如前所述，在全球標準化、平臺對所有領域及其數據產品實施和強制執行的內容與由領域決定的內容之間取得平衡，是一門藝術。例如，域數據模型是一個應該本地化到最熟悉它的域的關注點。例如，“播客受眾”數據模型的語義和語法如何定義必須留給“播客領域”團隊。然而相比之下，關于如何識別“播客聽眾”的決定是一個全球關注的問題。播客聽眾是“用戶”群體中的一員——它的?上游有界上下文- 誰可以跨越域的邊界并在其他域中找到，例如“用戶播放流”。統一標識允許關聯關于既是“播客聽眾”又是“蒸汽聽眾”的“用戶”的信息。以下是數據網格治理模型中涉及的元素示例。這不是一個全面的例子，只是說明了全球層面的相關問題。

圖 12：：聯合計算治理元素示例：團隊、激勵措施、自動化實施和數據網格的全球標準化方面

數據網格前治理的許多實踐，作為一個集中的功能，不再適用于數據網格范式。例如，過去強調黃金數據集的認證——經過集中質量控制和認證并被標記為可信賴的數據集——作為治理的核心功能不再相關。這源于這樣一個事實，即在以前的數據管理范例中，無論質量和格式如何，數據都從運營域的數據庫中提取并集中存儲在倉庫或湖泊中，現在需要一個集中的團隊進行清理、協調及其加密過程；通常在集中治理組的監管下。數據網格完全分散了這種擔憂。領域數據集只有在域內，根據預期的數據產品質量指標和全球標準化規則，經過質量保證過程后，才成為數據產品。領域數據產品所有者最適合決定如何衡量其領域的數據質量，首先要了解產生數據的領域操作的細節。盡管有這樣的本地化決策和自主權，但他們需要遵守基于全球聯合治理團隊定義的全球標準的 SLO 質量和規范建模。下表顯示了數據治理的集中式（數據湖、數據倉庫）模型與數據網格之間的對比。

集中式的數據治理方面	數據網格的數據治理方面
中心化團隊	聯合團隊
負責數據質量	負責定義如何對構成質量的內容進行建模
負責數據安全	負責定義數據安全的各個方面，即平臺自動構建和監控的數據敏感度級別
負責遵守法規	負責定義平臺自動構建和監控的法規要求
數據集中保管	按域對數據進行聯合托管
負責全球規范數據建模	負責建模——跨越多個領域邊界的數據元素
團隊獨立于域	團隊由領域代表組成
以定義明確的靜態數據結構為目標	旨在實現有效的網格操作，包括網格的連續變化和動態拓撲
單體湖/倉庫使用的集中技術	每個域使用的自助平臺技術
根據管理數據（表格）的數量或數量衡量成功	基于網絡效應衡量成功 - 表示網格上數據消耗的連接
人工干預的手動流程	平臺實現的自動化流程
防止錯誤	通過平臺的自動化處理檢測錯誤并恢復

四、原理總結和高層邏輯架構

讓我們把它們放在一起，我們討論了支撐數據網格的四個原則：

面向領域的去中心化數據所有權和架構	因此， 創建和消費數據的生態系統可以隨著數據源數量、用例數量和數據訪問模型多樣性的增加而擴展； 只需增加網格上的自治節點。
數據作為產品	因此， 數據用戶能夠輕松發現、理解和安全使用高質量數據，體驗愉悅； 分布在多個域中的數據。
作為平臺的自助數據基礎設施	因此， 領域團隊可以使用平臺抽象自主創建和使用數據產品，隱藏構建、執行和維護安全且可互操作的數據產品的復雜性。
聯合計算治理	因此， 數據用戶可以從獨立數據產品的聚合和關聯中獲得價值——網格表現為遵循全球互操作標準的生態系統； 以計算方式融入平臺的標準。

這些原則推動了一個邏輯架構模型，該模型在將分析數據和操作數據在同一域下更緊密地結合在一起的同時，尊重它們的基礎技術差異。這些差異包括分析數據的托管位置、用于處理操作服務與分析服務的不同計算技術、查詢和訪問數據的不同方式等。

圖 13：數據網格方法的邏輯架構

我希望到此為止，我們現在已經建立了一種共同的語言和邏輯思維模型，我們可以共同推進網格組件的詳細藍圖，例如數據產品、平臺和所需的標準化。

致謝

感謝 Martin Fowler 幫助我完善了這篇文章的敘述和結構，并主持了這篇文章。特別感謝許多通過客戶實施和研討會幫助創建和提煉本文中的想法的 ThoughtWorker。還要感謝以下提供寶貴反饋的早期審稿人：Chris Ford、David Colls 和 Pramod Sadalage。