原文鏈接：
https://martinfowler.com/articles/data-mesh-principles.html

作者簡介：Zhamak是ThoughtWorks的首席技術顧問，專注于企業的分布式系統架構和數字平臺策略。作為ThoughtWorks技術顧問委員會的成員，她為創建ThoughtWorks技術雷達做出了貢獻。

我們渴望通過數據來增強和改善商業和生活的各個方面，這驅使我們在大規模管理數據方面進行范式轉變。 盡管過去十年的技術進步已解決了數據量和數據處理計算的規模問題，但它們無法解決其他方面的規模問題：數據格局的變化，數據來源的泛濫，數據用例和用戶的多樣性 ，以及對變化的響應速度。 Data Mesh解決了這些問題，它由以下四個原則組成：面向領域的去中心化數據所有權和架構，數據即產品，自助服務數據基礎設施即平臺，聯合治理。 每個原則都驅動著技術架構和人員組織結構的新的邏輯視圖。

當前，許多企業面臨的挑戰在于如何在技術架構和人員組織層面形成數據驅動、運用數據建立競爭優勢以及規模化地利用數據驅動價值，“從單體數據湖到分布式數據網格”對上述痛點有深入的理解（我鼓勵您先閱讀該文章）。它提供了一種替代的觀點，該觀點吸引了許多組織的注意力，并給我們帶來了一個不同前景的希望。雖然這篇文章描述了這種觀點，但它在很多設計和實現的細節上留下了讓人想象的空間。 我并不想在本文中過分規范這些，以至于扼殺了大家實現Data Mesh的想象力和創造力。但是，我認為作為推動范式向前發展的墊腳石，本文只負責在架構層面規范它的定義。

本文是上述文章的后續， 它通過列舉Data Mesh的基本原則和這些原則驅動的高級邏輯架構，總結出了Data Mesh方法。 在我之后寫文章深入研究Data Mesh核心組件的詳細架構之前，建立高級邏輯模型是非常必要的。 因此，如果您正在為Data Mesh尋求確切的工具和方法，那么本文可能會讓您感到失望。 如果您正在尋求簡單且無關技術細節的模型來建立描述該方法的通用語言，請快來。

合理劃分數據

數據到底是什么？ 這個問題的答案取決于您問誰。從現階段的視角來看， 我們將數據分為業務數據和分析型數據。 業務數據位于業務微服務背后的數據庫中，它具有事務性，能夠記錄當前狀態并且滿足業務應用的需求。 分析型數據是一段時間內業務事實形成的聚合視圖，它的數據模型通常被用來支持歷史數據分析或未來趨勢預測， 也用于機器學習的模型訓練或生成分析報告。

目前，技術、架構和組織結構的現狀都反映了業務與分析數據平面的差異，它們集成在一起但是又相互獨立存在。這種差異使架構變得脆弱。 對于那些試圖連接這兩個平面，想要將數據從業務數據平面流轉到分析平面然后再返回到業務數據平面的人來說，不斷失敗的ETL（提取，轉換，加載）流程以及日益復雜的數據管道迷宮是一個很常見的現象。

圖1：合理劃分數據

分析型數據平面本身已經分叉為兩套主要的架構和技術棧：數據湖和數據倉庫。 數據湖支持數據科學訪問模式，數據倉庫支持分析和商業智能報告訪問模式。 在本文中， 我暫不考慮這兩種技術棧之間的交叉：數據倉庫試圖去引入數據科學工作流，而數據湖則試圖服務于數據分析師以及商業智能。前文中提到的“從單體數據湖到分布式數據網格”探討了現有分析數據平面架構的挑戰。

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

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

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

Data Mesh認可并尊重這兩個數據平面之間的差異：數據不同的數據性質和拓撲結構，不同的用例，不同的數據消費者，以及不同的訪問模式。 但是，它試圖以不同的結構（一個基于領域而不是技術棧的倒置模型和拓撲結構）連接這兩個平面，并且將關注點放在分析型數據平面上。 當今管理這兩種數據原型的可用技術的差異不應導致組織，團隊和工作人員的分離。 我認為，業務型的和事務性數據的技術和拓撲結構相對成熟，并且在很大程度上由微服務架構驅動。 數據隱藏在每個微服務的內部，并通過微服務的API進行控制和訪問。 是的，還需要繼續創新才能真正實現多云原生業務型數據庫解決方案，但從架構的角度來看，業務型數據平面已經滿足了業務的需求。 然而，管理和訪問分析型數據仍然是規模化問題。 而這便是Data Mesh的關注點。

我相信，在將來的某個時刻，不斷發展的技術，將使這兩個平面更加緊密地聯系在一起，但就目前而言，我建議將它們的關注點分開。

Data Mesh的核心原理和邏輯架構

Data Mesh的目標是為大規模地從分析型數據和歷史事實中獲得價值提供基礎，以適應數據格局的不斷變化、數據源和消費者的大量涌現，用例所需的轉換和處理的多樣性，對變化的響應速度。 為了實現此目標，我認為，任何Data Mesh的實現都應體現四個基本原則，以實現規模化的承諾，同時保證數據可用所需的質量和完整性：1）面向領域的去中心化的數據所有權和架構，2 ）數據即產品； 3）自助式數據基礎設施即平臺； 4）聯合治理。

盡管我預見這些原則的實踐、技術和實現會隨著時間的推移而變化和成熟，但是這些原則會保持不變。

我有意讓這四個原則在總體上是必要和充分的；以實現具有韌性的擴展，同時解決不兼容數據的孤島和增加的運營成本的擔憂。 讓我們深入研究每個原理，然后設計支持該原理的概念架構。

領域所有權

Data Mesh的核心是將責任分散，并分配給最接近數據的人，從而能夠支持持續的變更和擴展。問題是，如何分解和分散數據生態和它們的所有權？這里的組件是由分析數據，元數據和服務數據所需的算力組成。

Data Mesh沿著組織單元的交界線作為分解軸。現在我們的組織是基于他們的業務領域來劃分的。這樣的劃分，在很大程度上局部化了持續變更和演進所帶來的影響。因此，通過業務領域的上下文來劃分數據的所有權是一個很好的選擇。

在本文中，我將繼續使用和之前文章相同的用例，一家數字媒體公司。你可以想象這家公司是基于領域來劃分業務，各個業務部門都有支持運營的系統和團隊。例如，podcasts（播客）業務，其團隊和系統管理 podcast 發行物和其主持人；還有 artists （藝術家）業務，其團隊和系統負責artists的入職并支付其費用，等等。Data Mesh 的觀點是分析數據的所有權和其提供的服務應該遵從于這些領域的劃分。例如，對于管理 podcasts，以及提供 API 來發布 podcasts 的團隊，他們應該同時提供過去一段時間內已經發布的“播客” 和收聽率數據。想要更深入的了解這個劃分原則，可以參考《面向領域的數據分解和所有權》這篇文章。

邏輯架構：面向領域的數據和計算

為了推動這樣的劃分，我們需要建立一個把分析數據安放到各個領域去的架構模型。在這個架構中，某領域暴露給組織中其他領域的接口，不僅僅暴露業務能力，還暴露對于這個領域的分析數據的訪問能力。例如，Podcast 這個領域，不僅提供了“創建新一集的 podcast”的API，也提供了獲取“過去n個月的所有 podcasts 數據”的接口。這意味著該架構必須移除所有阻力或者耦合，以便讓領域對外暴露分析數據，發布計算數據的代碼，這必須是獨立于其他領域的。為了擴展，該架構必須支持各領域團隊的自治，使得各領域團隊能夠自主發布和部署其業務系統和分析數據系統。

下面這個例子展示了面向領域的數據所有權原則。圖例只是邏輯上和示例性的表示，并不試圖展示完整的例子。

每個領域可以暴露一個或多個業務型API，以及一個或多個分析型數據端點。

圖4: 注意：領域，及其包含的分析數據能力和業務能力

自然地，各個領域可以依賴其他領域的業務和分析數據 API。在下面這個例子中，podcasts 領域消費 users 領域提供的用戶更新的分析數據，從而通過 podcasts 聽眾數據集，來提供 podcasts 聽眾人口統計全貌。

圖5：示例：面向領域劃分分析數據和業務能力所有權

在這個例子中，我使用了命令式的語言來訪問業務數據或者能力，例如付錢給 artists。這只是想要強調訪問業務數據和分析數據意圖之間的不同。實際上業務API會使用一種更表意的方式來實現，例如訪問 RESTFul 資源或者通過GraphQL 查詢。

數據即產品

現有分析型數據架構的挑戰之一是探索，理解，信任以及最終使用優質數據的高摩擦和高成本。 如果不解決，隨著提供數據（即領域）的場所和團隊數量的增加，該問題只會伴隨著數據網格加劇。 這是Data Mesh 第一原則去中心化將會造成的結果。數據即產品原則旨在解決數據質量和陳舊的數據孤島問題； 或Gartner所說的“暗數據”——“在正常的商業活動中收集，處理和存儲的信息資產，通常不能用于其他目的”。領域提供的分析數據須被視為產品，數據的消費者也應該被視為客戶。

“從單體數據湖到分布式數據網格”一文列舉了一系列能力，包括可發現性，安全性，可探索性，可理解性，可信賴性等，所以在實現Data Mesh時應該把領域數據視為一種產品。這片文章還詳細介紹了團隊必須引入的領域數據產品負責人，該角色負責定義客觀的度量指標來確保數據作為產品交付。這些度量指標包括數據質量，縮短數據消耗的前置時間，以及一般而言的通過凈推薦值（Net Promoter Score）所體現的數據用戶滿意度。 領域數據產品負責人必須深入了解數據用戶是誰，他們如何使用數據，以及他們消費數據的順手方法。 對數據用戶的深入了解可以設計出滿足其需求的數據產品接口。實際上，網格上的大多數數據產品，都有一些常規的用戶角色，比如數據分析師和數據科學家，基于他們獨有的工具和需求來使用數據。 所有數據產品都可以開發標準化的接口來支持消費者。 數據用戶與產品負責人之間的對話是建立數據產品接口的必要環節。

每個領域都會有數據產品開發人員，他們負責構建，維護和提供各自領域的數據產品。 數據產品開發人員將與該領域的其他開發人員一起工作。 每個領域團隊可以服務一個或多個數據產品。 也可以組建新的團隊，給那些不適合現有業務領域的數據產品提供服務。

注意：與過去的范式相比，這是一種責任的倒置模型。 數據質量的責任向上游轉移，盡可能靠近數據源。

邏輯架構：將數據產品視為架構量子

在體系結構上，為了支持數據作為領域可以自主服務或使用的產品，Data mesh引入了數據產品的概念，并作為其架構量子。由演進式架構定義的架構量子是最小的架構單元，它可以獨立部署，具有高度的功能內聚性，并包含其功能所需的所有結構元素。

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

• 代碼：包括

(a)數據流水線代碼，負責消費，轉換和服務來自業務領域系統或者上游數據產品的數據；

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

(c)強制約束性代碼，包含諸如訪問控制策略，合規性，來源等。

• 數據和元數據: 這就是我們的討論內容，以多種語言形態提供底層的分析和歷史數據。根據領域數據的性質及其消費模型，數據可以通過事件，批處理文件、關系型數據表、圖等方式提供給消費者，同時保持相同的語義。為了使數據可用，需要定義一組相關的元數據，包括數據計算文檔、語義和語法聲明、質量指標等。有些元數據是數據所固有的，例如語法定義，而有些元數據通過計算治理傳達數據特征，從而實現預期行為，例如 訪問控制策略。
• 基礎設施:基礎設施組件支持構建、部署和運行數據產品代碼，以及存儲和訪問大數據和元數據。

圖6：數據產品的組成部分

下面的示例建立在上一節的基礎上，展示了數據產品作為架構量子。圖例只包括示例內容，并不試圖包括完整的設計和實現細節。雖然這依舊是一種邏輯表示，但它離真實實現更近了一步。

圖 7：注意：領域，及其包含的分析數據能力和業務能力

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

注意:Data mesh模型不同于過去的范式，在過去的范式中，數據管道作為獨立組件管理，與它們產生的數據無關; 基礎設施，比如數據倉庫或數據湖存儲帳戶的實例，通常會在許多數據集之間共享。數據產品是所有組件(代碼、數據和基礎設施)在領域限界上下文粒度上的組合。

自助數據基礎設施平臺

可以想象，要構建，部署，執行，監控和訪問一個不起眼的六邊形（即數據產品），需要搭建和運行相當多的基礎設施。用來提供這些基礎設施的技術是相對專業的，并且難以在各個領域中復制。最重要的是，團隊能夠自主管理其數據產品的唯一方法，就是團隊可以訪問基礎設施的高級抽象——這層抽象移除了搭建數據產品和管理數據產品生命周期的復雜性和難度。這就需要一種新的原則，即使領域自治的自助數據基礎設施即平臺。

數據平臺可以被視為對已經存在的可以運行和監控各種服務的交付平臺的延伸。但現實是，用來操作數據產品的底層技術棧與針對業務服務的交付平臺 所使用的技術棧大相徑庭。這完全是由于大數據平臺與業務平臺之間技術棧的差異所導致的。例如，領域團隊可能使用Docker容器來部署其服務，而交付平臺使用Kubernetes進行編排；但是，相鄰的數據產品可能正在以Spark作業的形式在Databricks群集上運行數據流水線代碼。這需要搭建和連接兩組非常不同的基礎設施，數據網格之前的技術并不需要這種級別的互連性。我個人的希望是，在合理的地方開始看到業務和數據基礎設施的融合。例如，我希望能夠在和業務系統相同的編排系統上運行Spark，比如Kubernetes。

現實是，為了使多面手的開發人員可以開發分析數據產品，自助平臺除了簡化產品搭建外，還需要針對既有的領域開發人員提供一套新的工具和接口類別。自助數據平臺必須能創建工具，以支持領域數據產品開發人員在創建、維護和運行工作流時減少對專業技術知識的依賴。上篇文章中提到了自助數據平臺提供一系列功能列表，包括訪問：可擴展的不同類型的數據存儲，數據產品模式，數據管道聲明和編排，數據產品血緣，計算和數據本地性等。

邏輯架構：多平面數據平臺

自助服務平臺功能可分為多個類別或平面，如模型中所述。注意：平面對存在層面的抽象表達-他們相互集成但獨立。類似于物理或意識平面，或網絡中的控制和數據平面。平面既不是層，也不意味著森嚴的分層訪問模型。

圖9：注意：平臺中一個通過自服務接口提供了多種相關能力的平面

自助平臺可以具有多個平面，每個平面服務于不同類型的用戶。在以下示例中，列出了三個不同的數據平臺平面：

• 數據基礎設施配置平面：支持底層基礎設施的配置，這是運行數據產品和網格所必需的。其中包括配置分布式文件存儲，存儲帳戶，訪問控制管理系統，運行數據產品內部代碼的編排引擎，以及為數據產品集群提供分布式查詢引擎等。我希望其他任何數據平臺或高級數據產品開發人員都能直接使用這個平面提供的接口。這是一個相當底層的數據基礎設施生命周期管理平面。
• 數據產品開發人員體驗平面：這是典型的數據產品開發人員主要使用的接口。這些接口抽象了許多復雜的內容，以支持數據產品開發人員的工作流程。它提供了比“配置平面”更高的抽象級別。它使用簡單的聲明性接口來管理數據產品的生命周期。它會自動橫切一些關注點，這些關注點被定義為為一組標準和全局約定，適用于所有數據產品及其接口。
• 數據網格監督平面：有些能力最好能在網格（數據產品形成的網絡）層面全局地提供。盡管每個接口的實現可能都依賴于單獨的數據產品功能，但在網格層面提供這些功能更為方便。例如，最好通過搜索或瀏覽數據產品的網格來提供發現特定用例的數據產品的能力；或者最好通過在數據網格上執行跨數據產品的數據語義查詢操作來創造更高階的洞見。

以下模型僅是示例性的，并不完整。盡管圖中平面間存在層級，但并不表示平面間存在嚴格的層級關系。

圖10：多平面的自服務數據平臺 其中DP指的是數據產品

聯合治理

正如你所看到的，數據網格遵循分布式系統架構，由獨立的數據產品組成，每個數據產品具有獨立的生命周期，通常由獨立團隊構建和部署 。然而，在大多數現實場景下，為了通過高階數據集、洞見以及機器智能的形式獲取價值，獨立的數據產品需要相互操作；并能夠讓數據相互關聯、合并、找到交集，或者對數據進行大規模的圖或集合操作。為了實現這些操作，數據網格的實現需要一個治理模型，這個模型包含去中心化，領域自治，支持全局標準化的互操作性、動態拓撲，以及最重要的是由平臺自動執行決策。我稱之為聯合計算治理。它是由領域數據產品經理和數據平臺產品經理組成的聯合所領導的決策模型，具備自治權和領域內的決策能力，同時創建和遵守一套全局規則，這套規則應用于所有數據產品及其接口，以確保一個健康和可互操作的生態系統。該小組有一項棘手的工作：如何保持中央中心化和去中心化之間的平衡；哪些決策需要作用于單個領域，那些決策需要作用于所有領域。 最終，全局決策有一個目的，即通過發現和組合數據產品來創造互操作性和復雜的網絡效應。
Data mesh中治理的優先級不同于傳統的分析型數據管理系統。雖然它們最終都希望從數據中獲取價值，但是傳統的數據治理試圖通過中心化的決策權來達成目標并建立全局規范的數據呈現方式，但難以支持變更。相反的是， Data mesh 的聯合計算治理擁抱變化和多種解釋性上下文。

將系統置于恒定狀態會導致演進的脆弱。-- C.S. Holling, ecologist

邏輯架構：向網格中嵌入的計算策略

支持型的組織結構、激勵模型和架構對于聯合治理模型的運行必不可少：它們有助于在尊重本地領域自治的同時，制定全局互操作性決策和標準，并有效實施全局政策。

圖11：注意：聯合計算治理模型

如前所述，哪些應該針對所有領域和其數據產品進行全局標準化，實施，甚至強制執行？哪些應該留給領域自己決策？在這兩個問題之間作出平衡是一門藝術。例如，領域數據模型應該是領域自身需要關注的問題，因為領域最熟悉它。就像，如何定義“播客受眾”數據模型的語義和語法，這件事情必須交給“播客領域”團隊。然而，相比之下，如何識別“播客聽眾”是一個全局關注的問題。podcast 聽眾是“用戶”群體（其上游限界上下文）的成員，他們可以跨越領域的邊界并同時存在于“用戶播放流”之類的其他領域。統一的標識讓我們可以關聯既是“podcast聽眾”又是“播放流聽眾”的“用戶”的信息。
以下是 data mesh管理模型中涉及的元素的示例。 這不是一個全面的例子，僅說明了在全局范圍內的相關問題。

圖12：聯合治理包含的元素示例：團隊，動機//TODO，自動實現和全局標準化

作為中心化的職能， 數據網格之前的很多治理實踐，不再適用于數據網格。例如，過去被認為非常重要的黃金數據集認證（即經過集中質量控制和認證過程并標記為可信賴的數據集）作為中心治理功能將不再適用。這源于以下事實：在以前的數據管理范例中，無論質量和格式如何，數據都是從業務領域數據庫中提取，并集中存儲在數據倉庫或數據湖中，現在需要中心化的團隊來對數據進行清洗，整理和加密；這通常由中央治理小組負責。數據網格完全分散了這些問題。領域數據集僅在領域內通過了質量保障處理（滿足預期的數據產品質量指標和全局標準化規則）之后，才成為數據產品。領域數據產品經理最先決定如何衡量其領域的數據質量，因為他們最早了解產生數據的領域操作的詳細信息。盡管有這樣的本地化決策和自治權，但它們仍需要遵循由全局聯合治理團隊定義并由平臺自動化的全局質量標準和SLO（服務水平目標）規格進行建模。

下表展示了中心化的數據治理（如數據湖、數據倉庫）模型和數據網格之間的對比。

原則總結與頂層邏輯架構

綜上所述，我們討論了支撐Data mesh的四個原則。

• 面向領域的去中心化數據所有權和架構

因此，生產和消費數據的生態系統可以隨著數據源的數量、用例的數量和數據訪問模型的多樣性的增加而擴展; 只需增加網格上的自治節點就可以實現這種擴展。

• 數據即產品

因此，針對分布在多個領域的數據，其使用者可以很方便地去發現、理解以及安全地去使用這些高質量的數據，同時獲得良好的消費者體驗。

• 自助數據基礎設施即平臺

因此，領域團隊就可以通過平臺抽象自主地創建和使用數據產品，從而隱藏了構建、執行和維護安全且可互操作的數據產品的復雜性。

• 聯合治理

因此，數據用戶可以從獨立數據產品的聚合和關聯中獲得價值——數據網格就像遵循全局互操作性標準的生態系統，通過計算將標準整合到平臺中。

這些原理形成了一個邏輯架構模型，使分析數據和業務數據在同一個領域中更加緊密地聯系在一起, 同時尊重它們的基礎技術的差異。這些差異包括分析數據的存儲位置，處理業務服務和分析服務的不同計算機技術，查詢和訪問數據的不同方式等等。

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

我希望到這里我們已經建立了一套通用的語言和邏輯思維模型，可以用來進一步詳述Data Mesh組件的藍圖，例如數據產品，數據平臺和必需的標準。

ThoughtWorks洞見網站：https://insights.thoughtworks.cn/