作者：蔡芳芳
自 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 究竟。
從微服務的視角看資料架構
沒有一個概念是無緣無故憑空冒出來的，Data Mesh 的誕生也是基于對企業資料平台架構現狀和弊端的反思而提出來的。
企業資料平台的演進大緻可以分為三個重要階段：
- 第一階段，專有的企業資料倉庫和商業智能平台；
- 第二階段，以資料湖為代表的大資料生态系統；
- 第三階段，雲上資料平台，也是目前主流的混合實踐模式，包含實時資料流處理架構、整合批處理與流處理的架構，以及完全采用基于雲的存儲托管服務、資料流水線執行引擎和機器學習平台。
而這些資料平台架構存在一些共性的挑戰：
- 難以啟動：缺少用例支援，無法獲得業務支援；長時間的資料湖設計與技術評估；需要統一組織内多個業務或技術部門；
- 資料源難以規模化：缺少手段對錯綜複雜的源資料系統進行疏浚與管理；難以跟上不斷增長的資料源系統規模；
- 資料消費難以規模化：資料平台項目跟不上企業創新要求；用例過窄，難以滿足規模化需求；平台能力跟不上錯綜複雜的用例需求；
- 資料難以商業化：極高的開發和營運成本；難以将資料平台真正轉化為商業競争力；難以形成創新文化。
這背後的根本原因在于，從業務的視角來看，企業資料平台架構從第一到第三階段的演進其實一直延續着黑盒、集中式、單體架構的核心模式，由獨立且專業化的資料工程師團隊維護，業務方的可操控性非常弱，資料團隊很容易成為響應的瓶頸。
實際上，目前資料架構面臨的挑戰，與微服務架構之前的單體軟體所面臨的挑戰非常類似：
- 基礎設施無法響應業務彈性需求：單體資料架構下，基礎設施資源所有業務共享，進行集中式的管理和維護，無法基于業務需求靈活進行資源調整；
- 資料商業化成本高：加工資料以非産品思路對資料進⾏處理，是以⼤部分資料處理結果集無法以商品的形式度量其業務價值；
- 資料處理流水線複用成本高：每⼀個資料流水線為獨立的資料工作空間上下文，跨流水線的 資料結果或者中間結果需要進行複用時成本較高，難度較大；
- 資料處理成本較高：單體資料架構模式下，大部分的資料處理工作進行集中統⼀管理，在涉及更多業務場景支援、更多團隊協作下，資料處理的成本較高。
Data Mesh 試圖基于微服務的架構思想設計資料架構，來解決上述問題。
Data 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。
會改變資料團隊的工作嗎？
同為大資料領域近幾年誕生的新概念，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 其實是把資料團隊和業務團隊的職責邊界做了更清晰的劃分，使資料團隊的職責更加聚焦和精簡，從技術角度看對資料團隊目前的工作不會有特别大的影響。不過過程中可能會涉及到一些人員的調整，比如原來資料團隊中負責業務相關資料分析工作的人員會直接劃到業務團隊去，而關注業務無關的基礎設施的人員則繼續留在資料團隊中。
現在是采用 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。雖然使用現有技術作為基本建構塊也是可行的，但在成熟的基礎設施工具出現之前，很多企業可能還是會選擇繼續觀望。