2019年我與ThoughtWorks的Zhamak Dehghani合作，提出一個分佈式數據平臺架構Data Mesh的架構思想和設計，並在真實客戶企業中參與實施，本文是對這一思想和設計的總結，參考自《How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh》和實踐中的深入思考。

傳統數據平臺改造、治理、基礎設施、數據能力的構建方式可能需要基於一個完全不同於以往的邏輯，即企業數據平臺（Data Platform）正在進入一個範例變革（Paradigm Shift）的階段。

傳統企業數據平臺的演進

傳統企業數據平臺的演進主要有三個重要階段：

• 第一階段，基於企業級數據倉庫的BI能力；
• 第二階段，以數據湖為代表的大數據生態系統；
• 第三階段，基於雲的數據平臺，亦為當前主流的混合實踐模式，包含實時數據流處理架構、整合批量與流處理的框架、以及結合雲端存儲、流水線、以及機器學習能力。

企業數據平臺的失敗

NewVantage Partners公司從2012年起，面向財富1000企業管理層調研大數據和AI在其企業內的實施情況，該報告2019年揭示了整個企業數據平臺領域的窘迫——儘管在大數據和AI領域投入超過5億美元的公司較上一年增長了66%，在65家受訪企業裡回應「未能或尚早體現可量化業務結果」的企業增加了41%。

在研究企業數據平臺項目失敗案例中我們發現如下四個核心原因：

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

如果我們把企業數據平臺的成功要素集中在：在錯綜複雜的企業技術環境中快速啟動；規模化地引入高價值的新數據源和使用場景；儘早實現數據對整個企業商業系統的價值（對內或對外）。

那麼，我們需要怎樣一種技術架構思想？

反思單體架構的模式

企業數據平臺從第一到第三個階段的演進過程中，無一例外地延續著一個單體架構（Monolithic Architecture）的核心模式，只是這個架構的表現形式從一個嚴格劃分的數據倉庫、變成被專業化和神秘化數據湖、最終轉化成一個多種實踐模式的混合。

在數據的產出與消費之間，總有一個龐然大物——

1. 在分佈在企業無數角落，在各種上下文中收集數據；
2. 對數據進行清洗、擴充、和轉換；
3. 為數據的消費方，例如報表、分析、以及機器學習平臺提供實時或批量的數據集。

這種單體式的架構思想在應用在構建企業數據平臺時，自然出現了上文所述的巨大挑戰——難以啟動、難以規模化、以及難以商業化。最終結果，是大多企業數據平臺項目在經歷了三到五年的巨大投入後，難以獲得預期收益。

在企業應用架構領域，微服務（Microservices）架構的出現可以被認為是對單體架構的反思，以微服務為代表的分佈式架構擁有優勢：

1. 超大規模應用的持續構建和交付能力；
2. 高業務複雜度業務上下文中更高細粒度的業務擴展；
3. 獨立部署帶來的更高可用性；
4. 可演進的技術棧。

單體式架構優勢在於結構簡單、數據一致性高、持續部署難度低，這一構架自然弱化了團隊對頻繁部署、團隊靈活性、持續交付、以及技術債管理的需要。

在企業應用架構的上下文中，技術團隊在選擇微服務架構或單體式架構時所考慮的，是：

1. 應用是否擁有一個龐大的代碼體系同時又需要持續交付；
2. 業務邏輯是否可能頻繁出現更細粒度的擴展；
3. 業務擴展是否對應用的可用性有極高需求；
4. 技術債是否需要更激進的管理；
5. 技術選型是否需要演進。

這些問題的答案如果都是「是」，那麼團隊就有理由轉向分佈式架構。

如果我們回到企業數據平臺的上下文中來反思這五個問題：

1. 目前企業廣泛使用單體式架構，數據的沉澱、處理、和使用基本存在於錯綜複雜的源系統（Source Systems）中，其代碼體系一定是龐大的；
2. 數據創新的本質就是更細粒度業務的發現、實現、和規模化，數據使用場景一定發生頻繁的細粒度擴展；
3. 由於商業和法規環境的不同，數據場景的使用有極高的獨立性，在地業務需要數據平臺根據需求提供穩定且獨特的數據服務；
4. 數據平臺面向的往往就是一個龐大的技術債，數據平臺必須和技術債管理集中在一起考慮；
5. 在雲平臺和開源數據工具蓬勃演進的今天，企業需要更快地引進新的數據工具和基礎設施，其技術棧需要更快的演進。

從這五個反思我們可以大膽的提出，單體式企業數據平臺必然需要向具有微服務特性的分佈式數據平臺演進。

什麼是分佈式數據平臺Data Mesh？

一個分佈式數據平臺的核心是一組用面向域的數據或ML產品、用自服務的方式使用數據技術設施提供的數據流水線（清洗、組合、豐富等）或合規（數據鑑權、隱私、安全等）的公共服務、並接受數據產品思維的設計和管理，以及和企業交付基礎設施深度集成。

其目的，是幫助企業：

1. 在合規的基礎上獲得規模化的數據能力交付；
2. 將規模化的數據能力引入到不同業務場景；
3. 保持數據的質量、合規、以及安全性；
4. 保持技術棧的多樣性，吸引數據領域新的技術框架和數據人才。

一個具有分佈式特點的企業數據平臺，應該具備以下四個特點：

面向域的數據架構

面向域（Domain-oriented）的數據或ML產品是分佈式數據平臺最小的「業務單元」，它們相互合作承擔了絕大部分平臺可見的價值。一個典型的數據或ML產品的架構包含以下四個組件：

1. 一組Polyglot數據接口（導入或導出）；
2. 一個具有領域特點的邊界；
3. 一組內置的數據流水線；
4. 一組連接基礎設施控制接口（如日誌）。

每一個數據或ML產品都具有獨立的靈活技術棧選擇、可發現、可尋址、自解釋、合規、安全、可管理、可擴展、以及相互運營性。任何一個面向域的數據或ML產品都有以下特點：

1. 支持一個端到端的用例（Use Case）；
2. 連接數據生產（Production）和消費（Consumption）兩端；
3. 在生產和消費兩端是一系列能力組成的價值鏈，並具有規模化的特性；
4. 數據生產和消費方式是不斷變化的；
5. 關於如何使用這些產品，需要改變現有數據生產和消費的方式；
6. 有可能根據需要裂變或重新組合；

這種分佈式架構保證企業在更復雜多變的業務場景中獲得最大靈活度且可擴展的數據能力。

自服務的平臺基礎設施

數據能力的構建是一項複雜的工程實踐，分佈式數據平臺的另一個重要特性是將最具普遍代表性的基礎設施使用行為進行自動化、中心化、和規模化。我們選取以下七項最重要的數據基礎設施能力作為企業的優選：

1. 數據快照Data Snapshotting；
2. 源數據描述Self-describing Library;
3. 原始副本Raw Copy；
4. 數據產品模板Data Product Template；
5. 數據格式轉換Data Format Conversion；
6. 數據流水線模板Data Pipeline Templates；
7. 日誌和追蹤Logging & Traceability。

隨著平臺的逐漸成熟，不同行業選擇什麼樣的基礎設施，如何實現，都可能發生變化，企業需要根據自身情況選擇最具有規模性和價值的能力進行投資。這些能力基於數據基礎設施自服務平臺、通過控制接口供給給獨立的數據或ML產品，最終實現基礎設施能力的自動化和規模化。

數據產品思維

數據或ML產品支持一個端到端的用例，且擁有生產和消費兩端，這樣的特性和應用領域的產品實踐類似，數據產品思維提出了一個「數據產品經理」的概念，其職責包括：

1. 管理用例，不斷髮現那些規模化的使用場景，修正現有用例，連接數據生產和消費兩端；
2. 管理價值鏈，決定數據產品所需要的核心能力，和技術架構師設計解決方案；
3. 在企業洞察數據生產和消費的行為，鼓勵正向行為（例如鼓勵數據發現Data Discovery），修正那些不符合數據平臺思想的行為，不斷提高使用率（Adoption Rate）；
4. 演進數據產品的設計。

同時，還有三個方向的產品思維需要思考.

首先，數據平臺中兩個基礎設施（數據基礎設施和ML基礎設施）的建設需要通過產品管理的方式進行構建，原因有如下幾點：

1. 基礎設施的建設範圍和順序，由其支持的數據或ML產品是否有規模化的使用需要決定；
2. 對基礎設施的使用方式也並非永恆不變，一方面來自於使用者（數據或ML產品）本身的需求變化，另外一方面則來自於工具集本身的快速演進（來自於開源社區或雲），平臺需要不斷尋找更好的方式滿足不斷變化的需求；
3. 使用新的基礎設施工具同時產生新的行為和流程。

以上幾點原因決定了數據或ML基礎設施方向的產品經理以下職責：

1. 決定所轄基礎設施建設的路線圖；
2. 瞭解使用者的需求變化、緊跟開源社區或雲端工具的變化，按照需要演進技術棧；
3. 對新的流程和工具在組織內進行導入, 提高基礎設施的使用率。

其次，分佈式數據平臺的構建必然挑戰現有圍繞在單體式架構系統的IT組織架構——數據的生產、存儲、處理、和使用都被固化在每個單體系統中，其組織模式也一定是分散在每個系統中的。這意味著平臺級的組織轉型，需要在數據平臺的基礎上定義一個平臺級的產品負責人，其職責包括：

1. 洞察域以及邊界，平衡多個域上下文的衝突問題，用高抽象的語言向不同域的數據生產者和消費者解釋；
2. 不斷向業務部門和管理層描述數據平臺的業務價值；
3. 面對一個高內聚、低耦合的平臺，建立必要的標準、工作方式、溝通原則等；
4. 設定數據平臺產品經理（數據/ML產品方向或基礎設施方向）級的KPI，負責其成長。

最後，在我們的實踐中發現，分佈式數據平臺的方式將挑戰許多現有部門的工作方式，特別是信息安全、企業基礎設施支持、合規、第三方數據提供商等。我們需一個組織級別協調者的存在，其職責包括：

1. 協調其他部門，必要時抽調人員互相駐場以解決摩擦的問題；
2. 在不同部門中宣傳分佈式數據平臺對於企業向數據轉型的價值；
3. 對第三方數據提供商提出新的要求，可能涉及第三方的平臺使用場景。

我們認為，這四類產品管理類崗位，是企業通過分佈式數據平臺進行企業數據戰略轉型的基礎。

基於持續集成的交付基礎設施

分佈式數據平臺的最終目的是在企業真正形成具備靈活性、規模化、以及演進性的數據能力平臺，這就需要和企業現有的持續集成基礎設施進行整合，整合場景包含：

1. 分佈在每個數據或ML產品中數據流水線的構建質量可以有統一的交付基礎設施進行管理以及可視化；
2. 所有自服務數據基礎設施上的能力可以通過企業現有持續集成平臺進行質量控制；
3. 具體數據或ML產品提供能力可以通過現有持續集成平臺進行質量保證。

到此，我們介紹了分佈式數據平臺的四個重要組成部分，它們分別是：

1. 具有領域特徵的數據或ML產品；
2. 自服務的數據基礎設施；
3. 具有產品思維特性的管理方式和角色；
4. 基於持續集成的交付基礎設施。

寫在最後

企業數據平臺的演進經歷了從數據倉庫、到數據湖、再到雲的過程，在過去的五年裡，耗費巨資建設的數據平臺難以獲得預期收益，我們認為，以微服務（Microservices）為代表的分佈式架構（Distributed Architrecture）思想，正在取代一體式架構（Monolithic Architecture）在數據領域正在引發一次範式變革。

互聯網革新正在成為常態，企業正在向下一代、即數據企業進行演進，我們需要新的架構思想、技術實現、和組織結構。在這個背景下，我們提出了一個分佈式數據平臺Data Mesh的概念、架構設計、以及治理方式，它的目標是幫助企業獲得與時俱進的、靈活且規模化的、面向業務領域的廣泛數據能力，幫助企業實現數據轉型。

原文：https://insights.thoughtworks.cn/distributed-data-platform-data-mesh/

更多精彩商業洞見，請關注微信公眾號：ThoughtWorks商業洞見