Data Mesh，數據架構的下一個變革！

作者 | 蔡芳芳

採訪嘉賓 | 白髮川

Data Mesh 的潛力既令人興奮又令人生畏，就像從前的微服務架構一樣。

自 2010 年左右興起到現在，微服務（Microservices）已經成爲事實上的軟件架構範式，被企業廣泛採用，並引發了圍繞面向領域設計模式優缺點的激烈討論。如今，這股浪潮開始席捲數據領域。

Data Mesh 是一種基於領域驅動和自服務的數據架構設計新模式，借鑑了微服務和 Service Mesh 的分佈式架構思想，最初源於 ThoughtWorks 首席技術顧問 Zhamak Dehghani 發表在 MartinFowler 官網上的兩篇文章《How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh》和《Data Mesh Principles and Logical Architecture》。

ThoughtWorks 在 2020 年 10 月發佈的技術雷達中，將 Data Mesh 從 “評估” 調升到了 “試驗”（ThoughtWorks 對“試驗” 階段的技術的建議是：“值得一試。瞭解爲何要構建這一能力是很重要的。企業應當在風險可控的前提下在項目中嘗試應用此項技術。”），這意味着 Data Mesh 已經通過可行性驗證，轉而進入建議採納階段。據瞭解，包括 Zalando、Intuit、Netflix、JPMorgan Chase 等公司都已經在嘗試實踐 Data Mesh 這個概念。

但對於國內開發者來說，很多人聽過 Service Mesh，甚至有不少人已經在實踐 Service Mesh 了，對 Data Mesh 卻知之甚少。圍繞 Data Mesh 的理念和架構設計、它能解決現有數據架構的哪些問題、現在是不是採用 Data Mesh 的好時機等話題，InfoQ 記者在 2021 ThoughtWorks 技術雷達峯會現場採訪了 ThoughtWorks 數據智能團隊技術負責⼈白髮川，一探 Data Mesh 究竟。

1 從微服務的視角看數據架構

沒有一個概念是無緣無故憑空冒出來的，Data Mesh 的誕生也是基於對企業數據平臺架構現狀和弊端的反思而提出來的。

企業數據平臺的演進大致可以分爲三個重要階段：

第一階段，專有的企業數據倉庫和商業智能平臺；
第二階段，以數據湖爲代表的大數據生態系統；
第三階段，雲上數據平臺，也是當前主流的混合實踐模式，包含實時數據流處理架構、整合批處理與流處理的框架，以及完全採用基於雲的存儲託管服務、數據流水線執行引擎和機器學習平臺。

而這些數據平臺架構存在一些共性的挑戰：

**難以啓動：**缺少用例支持，無法獲得業務支持；長時間的數據湖設計與技術評估；需要統一組織內多個業務或技術部門；
**數據源難以規模化：**缺少手段對錯綜複雜的源數據系統進行疏浚與管理；難以跟上不斷增長的數據源系統規模；
**數據消費難以規模化：**數據平臺項目跟不上企業創新要求；用例過窄，難以滿足規模化需求；平臺能力跟不上錯綜複雜的用例需求；
**數據難以商業化：**極高的開發和運營成本；難以將數據平臺真正轉化爲商業競爭力；難以形成創新文化。

這背後的根本原因在於，從業務的視角來看，企業數據平臺架構從第一到第三階段的演進其實一直延續着黑盒、集中式、單體架構的核心模式，由獨立且專業化的數據工程師團隊維護，業務方的可操控性非常弱，數據團隊很容易成爲響應的瓶頸。

實際上，當前數據架構面臨的挑戰，與微服務架構之前的單體軟件所面臨的挑戰非常類似：

**基礎設施⽆法響應業務彈性需求：**單體數據架構下，基礎設施資源所有業務共享，進⾏集中式的管理和維護，⽆法基於業務需求靈活進⾏資源調整；
**數據商業化成本⾼：**加⼯數據以⾮產品思路對數據進⾏處理，因此⼤部分數據處理結果集⽆法以商品的形式度量其業務價值；
**數據處理流⽔線復⽤成本⾼：**每⼀個數據流⽔線爲獨⽴的數據⼯作空間上下⽂，跨流⽔線的數據結果或者中間結果需要進⾏復⽤時成本較⾼，難度較⼤；
**數據處理成本較⾼：**單體數據架構模式下，⼤部分的數據處理⼯作進⾏集中統⼀管理，在涉及更多業務場景⽀持、更多團隊協作下，數據處理的成本較⾼。

Data Mesh 試圖基於微服務的架構思想設計數據架構，來解決上述問題。

2Data Mesh 核心思路和架構邏輯

Data Mesh 實際上是一組數據平臺架構原則，融合了分佈式領域驅動的架構（Distributed Domain Driven Architecture）、自助平臺設計（Self-serve Platform Design）以及將數據視爲產品（Thinking Data as a Product）的思維。

有別於數據倉庫 / 數據湖的集中式單體架構，Data Mesh 是高度分散的數據架構。

對於 Data Mesh 的核心設計思路，白髮川將其總結爲以下幾點：

從業務域視角出發，將業務解耦之後映射到數據視角，再將數據解耦，減少數據冗餘度；
將數據作爲產品，使數據服務端到端完備，就像一個微服務一樣，可以被直接訪問和調用；
自服務的基礎設施，微服務的成功很大程度上歸功於它有非常成熟的基礎設施，比如 Spring Cloud、K8s 等，而數據的基礎設施相對於微服務的成熟架構還有所缺失，這也是未來需要持續發力的地方；
生態治理，站在消費者使用數據的業務鏈調用看數據是怎麼被消費的，制定數據治理規範，讓數據更爲透明和易於使用；
通過網格編排的思想設計數據走向，使數據產品能夠支持不同模塊、不同域的銜接。

在 Data Mesh 架構下，治理的始終是具有業務價值的數據服務，而不是一個個的原始數據文件。Data Mesh 的架構邏輯如上圖：底層需要可自服務的數據基礎設施，至少具備穩定性和可伸縮性兩項能力；基礎設施之上，面向域構建一個個端到端的數據消費服務提供給上層業務，可以認爲每一個服務對應的就是一個數據產品，比如某個數據倉庫可能抽象成 Data Mesh 中的一個 Data Service，每一個 Data Service 會包含算力、存儲和服務這三項。不同的數據服務之間會有一個數據服務註冊和調度中心，可以讓不同的 Data Service 形成業務所需要的一系列數據服務編排。另外，圍繞數據服務中心會形成數據授信訪問申請、元數據管理、數據服務管理等一系列能力。

如果從軟件架構的視角來理解 Data Mesh，則微服務映射過來就是 Data Service，基於微服務編排設計出來的 Application 映射過來就是 Data Product，基於很多 Application 編排生成的網格 Service Mesh 映射過來就是 Data Mesh。

Data Mesh 目前有兩種落地形態，一種是閉環服務，也就是一個平臺提供工具的同時還提供結果管理服務，並且只能在平臺內部完成全生命週期的管理，即 Data as a Service；另一種形態則是平臺提供數據和工具能力，但是工具能力爲可選項，業務可以使用自己的工具，也可以使用平臺的工具，即 Data Platform as a Service。

3 會改變數據團隊的工作嗎？

同爲大數據領域近幾年誕生的新概念，Data Mesh、數據中臺、湖倉一體可能會讓很多人感到困惑：這三者有什麼本質區別呢？

針對 Data Mesh 和數據中臺的區別，白髮川認爲，數據中臺是一個概念而非架構形態，它更多強調的是站在業務視角思考企業數據消費的形態，在通過數據中臺理念梳理完數據的消費模式、業務場景之後，最終還需要用一個架構來承載和實現。而 Data Mesh 可以作爲數據中臺的一種實踐形態。

針對 Data Mesh 和湖倉一體的區別，白髮川則表示，湖倉一體主要是基於數據倉庫、數據湖這樣的成熟架構做整合，從體驗和交互上來說減少了做一件事情需要完成的步驟，屬於優化式架構，但它解決的問題只在於技術維度，解決不了業務團隊瓶頸問題，也解決不了基礎設施和業務解耦的問題。而 Data Mesh 首先從基礎設施層面對架構做了一些調整，同時還定義了在這個架構下的團隊分工協作。從架構層面來看，數據湖、數據倉庫、湖倉一體跟 Data Mesh 實際上是可以並存的，而非對立或替代關係，在 Data Mesh 架構中，數據湖、數倉可能被包含在一個個 Data Service 中。

從另一個維度來看，數據湖、數據倉庫或者湖倉一體架構的主要受衆是企業的數據團隊，只有數據團隊需要關注這些架構。但 Data Mesh 的受衆是數據團隊和業務團隊，他們都需要關心這個架構，這也是一個明顯的差別。

Data Mesh 將數據所有權上移給了負責某一項功能的業務團隊，他們可以按照自己更便於使用的方式去創建、接觸元數據，對數據進行分類和存儲。對應 Data Mesh 的架構來看，業務團隊負責創建自己需要的 Data Service，而數據團隊的工作更聚焦於底層數據基礎設施，包括爲 Data Service 初始化工作空間、將雲廠商的組件和企業自己的底層平臺能力組合包裝成業務可用的方式（可以理解爲迷你版的雲）、Data Service 之間的調用能力封裝等等。

這是否意味着 Data Mesh 改變了企業數據團隊原有的工作內容呢？

白髮川對此給出了否定答案，他認爲，現在很多行業都在談數字化轉型，但當企業說數字化轉型的時候，通常發生改變的只有數據團隊，而業務團隊卻不受影響，這是有問題的。數字化並不等於數字團隊，Data Mesh 實際上更好地定義了，當企業需要數據能力的時候，業務團隊應該做什麼樣的改變。原來大家會籠統地認爲凡是數據相關的都由數據團隊做，導致整個數據團隊從基礎設施到業務完全耦合在一起。Data Mesh 其實是把數據團隊和業務團隊的職責邊界做了更清晰的劃分，使數據團隊的職責更加聚焦和精簡，從技術角度看對數據團隊當前的工作不會有特別大的影響。不過過程中可能會涉及到一些人員的調整，比如原來數據團隊中負責業務相關數據分析工作的人員會直接劃到業務團隊去，而關注業務無關的基礎設施的人員則繼續留在數據團隊中。

4 現在是採用 Data Mesh 的好時機嗎？

前文提到，包括 Zalando、Intuit、Netflix、JPMorgan Chase 等公司都已經在嘗試實踐 Data Mesh，但 Data Mesh 還不是一個適合所有企業廣泛採納的架構模式。儘管 ThoughtWorks 推薦 “採納”Data Mesh，但這一推薦有一個重要前提，即 “風險可控”。

白髮川表示，當下企業落地 Data Mesh 主要的難點和風險可以從兩個角度來看：一是規劃視角，需要評估對數據架構做改造的投入產出比；二是技術視角，過去從數據倉庫到數據湖的轉變可以認爲是替代式架構（不是從數據倉庫演進到數據湖，而是造一個全新的），而 Data Mesh 屬於演進式架構，改造的模式和設計的思維方式都與從前不同，目前行業內在大數據演進式架構改造的人才和經驗方面相對都是有缺失的。

其中，性價比是企業在考慮是否採用 Data Mesh 時首先要考慮的。不管是微服務也好，Data Mesh 也好，都存在一個最基本的底線成本。回顧前文提過的 Data Mesh 架構，它需要基於底層彈性基礎設施來打造，可以認爲雲是做 Data Mesh 的起點，如果企業當前的數據架構不是基於雲來做的，那從當前架構迭代到 Data Mesh 架構的過程中就需要更多改造步驟，比如要先做彈性化改造，這樣初步投入的成本就會變高。此外，構建 Data Mesh 需要的投資還包括構建自服務的數據平臺、支持對領域進行組織結構變更以長期維護其數據產品，以及一個激勵機制，來獎勵將數據作爲產品提供和使用的領域團隊等等。如果企業衡量改造的投入產出比之後，發現收益無法超過成本，可能 Data Mesh 就不適合。

除了考慮性價比問題，白髮川建議企業基於三個維度來評估自己是否應該採用 Data Mesh，分別是規模化、常態化和高門檻。其中，規模化指的是企業存在大量的領域且數據接入、數據消費規模都非常龐大，比如有大量產生數據的系統和團隊，或者多種數據驅動的用戶場景和訪問模式；常態化指的是數據的使用頻率很高，而不是一次性的；高門檻指的是企業需要非常精通大數據的技術人員來駕馭自己的數據架構。如果這三點都符合，就意味着企業需要考慮數據團隊和業務團隊之間的分工問題了，Data Mesh 可能是一個解決辦法。同時企業也需要結合自身的業務現狀來評估，如果企業已經做了數據倉庫、做了數據湖，但在前述三個維度下業務仍然出現了明顯的不可工作或協作瓶頸導致數據平臺跟不上業務發展節奏，那這可能就是一個考慮採用 Data Mesh 的比較好的時機點；反之，如果業務本身毫無問題，也就沒有改造的必要了。

據白髮川介紹，目前國內外有很多企業都已經在嘗試實踐 Data Mesh 的架構理念，尤其是一些數據規模特別龐大的企業，他們已經碰到集中式單體數據架構的瓶頸，開始探索向面向域的分佈式數據架構轉變以解決問題，只是他們可能沒有將這個概念抽象總結成 Data Mesh。

當提及 Data Mesh 未來應用推廣道路上可能遇到的挑戰時，白髮川特別強調了組織架構方面可能存在挑戰。如前文所述，Data Mesh 並不僅針對數據團隊，也不是數據團隊單獨就能做好的，它其實對應探討的是在企業的業務上下文裏面一種比較好的協作方式是什麼樣子的，需要幾個團隊承擔什麼職責才能做好這件事，並延伸到現有的團隊需要做什麼樣的調整，以及在這樣的調整下需要一套什麼樣的基礎設施或軟件來支持他們的工作。在白髮川看來，數據中臺、Data Mesh 都屬於所謂的 “CXO 工程”，Data Mesh 也需要企業自頂向下達成共識、形成決策並通過組織結構調整提供支持，否則可能也會遭遇類似於中臺戰略無法在企業順利落地的窘境。

Data Mesh 標誌着大規模數據分析架構和組織範式的轉變，但要加速 Data Mesh 的實現，在開源或商業工具上仍存在巨大的缺口。對比微服務有 K8s，Service Mesh 有 Istio、Linkerd，目前還沒有一款合適的工具可以幫助企業快速應用 Data Mesh。雖然使用現有技術作爲基本構建塊也是可行的，但在成熟的基礎設施工具出現之前，很多企業可能還是會選擇繼續觀望。

猜你喜歡