隨著數字化時代的到來，近幾年數據領域的新技術概念不斷涌現，無論是數據湖、湖倉一體、流批一體、存算一體、數據編織抑或數據網格，很多還爬上了Gartner曲線，其中數據網格備受關注，數據網格從字面意思來看挺抽象的，會勸退很多人，但當你深入去理解這個概念時，才發現奧妙無窮。

一、數據平臺架構演進歷史

要理解數據網格，先得回顧下數據平臺的發展歷史，它們的典型代表分別是數據倉庫、數據湖及湖倉一體。

第一代：數據倉庫

1980年代中后期，為解決數據庫面對數據分析的不足，孕育出新一類產品數據倉庫。讓我們先來看下數據倉庫的定義，數據倉庫（Data Warehouse）是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策和信息的全局共享。

數據倉庫對于數據的處理可分為數據集成（裝載）、數據加工（ETL）、數據匯聚、數據展示及挖掘。數據經過這一過程，被抽取到數據倉庫中，并嚴格按照預先定義的模式被裝載進來，經過多層加工形成數據集市，并最終提供給終端應用或進一步供挖掘使用，主要場景包括編制報表、發布下游數據集市(Data Marts)，以及支持自助式商業智能等。

第二代：數據湖

隨著數據規模擴大，對數據承載能力（容量、算力）的要求也不斷增大，數倉架構的擴展能力面臨考驗，規模的擴展會面臨大量資源的投入，但硬件資源缺乏彈性，會導致高峰時資源不足，低谷時資源閑置浪費問題。針對數據類型，也不再局限于結構化數據，更多半結構化、非結構化數據需要被利用起來，傳統的數據倉庫架構面臨諸多的挑戰。

相比于數據倉庫，數據湖是一種不斷演進中、可擴展的大數據存儲、處理、分析的基礎設施。它就像一個大型倉庫，可以存儲任何形式（包括結構化和非結構化）和任何格式（包括文本、音頻、視頻和圖像）的原始數據，數據湖通常更大，存儲成本也更為廉價。結合先進的數據科學與機器學習技術，能提供預測分析、推薦模型等能力。

數據湖與數據倉庫核心區別在于：數據倉庫中，數據存儲的結構與其定義的schema是強匹配的，也就是先建模再使用，簡單點說，數據倉庫就像是一個大型圖書館，里面的數據需要按照規范放好，你可以按照類別找到想要的信息，存儲在倉庫中都是結構化數據，可以直接消費。

而數據湖存儲其中的數據不需要滿足特定的schema，數據湖也不會嘗試去將特定的schema施行其上，任何格式的數據都可以扔進數據湖。數據使用通常會在讀取數據的時候解析schema（schema-on-read），當處理相應的數據時，將轉換施加其上，也就是說，數據湖對于入湖的數據不做任何規范，只有在于使用時才定義存儲格式以便分析使用。

第三代：湖倉一體

可以看到，數據湖和數據倉庫都有各自的優勢和不足，但不難發現，二者在某些層面是非?；パa的，于是乎，2020年，大數據DataBricks公司首次提出了湖倉一體（Data Lakehouse）概念，希望將數據湖和數據倉庫技術合而為一，依據DataBricks公司對Lakehouse 的定義，湖倉一體是一種結合了數據湖和數據倉庫優勢的新范式，在用于數據湖的低成本存儲上，實現與數據倉庫中類似的數據結構和數據管理功能。

湖倉一體是一種更開放的新型架構，有人把它做了一個比喻，就類似于在湖邊搭建了很多小房子，有的負責數據分析，有的運轉機器學習，有的來檢索音視頻等，至于那些數據源流，都可以從數據湖里輕松獲取。

二、數據平臺遵循集中化的范式

但無論是數據倉庫，數據湖還是湖倉一體，它們都有一個共同的范式，就是以數據物理集中化為原則的、中心式，單體式的架構。

這種集中化的架構有三個特點，如下所示：

第一、統一采集企業的所有數據到一個數據平臺。

第二、統一對數據進行清洗、轉化、處理及分析。

第三、統一對外提供數據服務，包括數據集、API等等。

雖然為了適應業務靈活分析的需要會產生各種數據集市，但這些數據集市的數據都是基于集中化的數據平臺打造的，本質上仍然是集中化架構的延續。

為什么數據一定要集中到一起呢？

因為大家對于數據分析有一個根深蒂固的認知，即數據具有網絡效應，多維度的數據只有融合分析才能產生發揮出數據的最大價值，而要實現融合分析的前提是數據要進行集中化的管理，如果數據以物理隔離的形式存在，以現有的技術手段不足以實現數據的融合分析，打破數據孤島也是數據治理領域最為重要的課題。

三、集中化數據平臺面臨的挑戰

數字化時代的使得使得集中化數據平臺面臨體系架構、技術架構、組織架構等多方面的巨大挑戰。

第一、無處不在的數據使得集中化數據平臺對各類數據進行采集的響應能力變弱，企業擁有越多來源的數據，集中化管理的壓力就越大，比如某些企業大數據平臺建設了很久，但新增的數據寥寥無幾，并不是說沒有新數據，主要在于根本沒有能力去實時感知數據源和數據的變化。

第二、集中化的數據平臺意味著要進行大量的數據搬遷，傳統的批處理方式很容易造成數據延遲、不一致的現象，這影響到了下游應用的準確性。

第三、數據應用需求的大幅增加使得集中化平臺對各類數據進行處理和分析的響應速度變慢，大量的領域需求被耽擱或拒絕，各個領域想盡辦法另起爐灶。

第四、數據工程師原來以創建最大的整體（即大數據平臺）而自豪，現在卻處于業務孤立的境地，因為企業將面向領域的數據所有權轉移到了集中化平臺上的數據工程師，集中化平臺上的數據工程師對各領域的來源數據缺乏了解，也缺乏領域專業知識，越來越難以滿足各領域的數據消費需求。

四、領域驅動設計的啟示

OLTP領域總是變革的先行者，Devops首先在OLTP大行其道，然后敏捷的春風刮到OLAP領域，導致了DataOps的出現，同樣的情形估計又要發生一遍。

埃里克·埃文斯（Eric Evans）的著作《領域驅動設計》（Domain-Driven Design）對現代架構思想以及組織建模產生了深遠的影響。它通過將系統分解為圍繞業務領域功能構建的分布式服務來影響微服務體系結構，從根本上改變了團隊的組成方式，從而使團隊可以獨立自主地擁有領域能力。盡管在OLTP引入了定向領域分解和所有權，但在OLAP卻忽略了領域的概念，DDD提倡的領域綁定上下文是一種強大的工具，實際可以用來設計數據集的所有權。

設想一下阿里這個龐大的數據帝國的推薦引擎設計，如果在優酷上需要基于淘寶商品的交易數據進行推薦，與其將淘寶、優酷的數據統一采集到中央數據中臺然后打造推薦模型以供優酷調用，還不如淘寶這邊提供交易數據的服務接口由優酷來統一調用來得方便，當然物理存儲啥的肯定可以采用諸如阿里云之類的中心式架構，我不知道阿里具體是怎么干的，但在業務規模和數據規模巨大的企業，領域驅動的數據服務實踐也許早就存在，因為沒有一個數據團隊能同時搞定多個領域的業務。

下面這張圖是個示例，對于“推薦領域”圖數據集來說，如果還有其它領域（例如“新藝術家發現領域”）對其有用，則可以選擇提取和訪問該領域，這要求我們從傳統ETL模式轉移到跨所有域的服務調用。

五、數據網格的定義和原則

針對傳統集中化數據平臺的困境，Zhamak Dehghani 于 2019 年 5 月撰寫了一篇論文，提出了數據網格的概念。在這篇文章中，Thoughtworks 顧問描述了集中式、單體式和與域無關的數據平臺的局限性。

這些平臺通常采用專有企業數據倉庫的形式或復雜的數據湖，其中包含“數千個無法維護的 ETL 作業、表格和報告，只有一小部分專業人員才能理解，從而導致對業務的積極影響未充分實現”，根據 Dehghani 的說法，這些數據“由一個由超專業數據工程師組成的中央團隊運營，這些工程師充其量只能支持一些研發分析”。數據網格旨在通過專注于領域驅動的設計來解決這些問題，并引導領導者走向“現代數據堆棧”，以實現元數據和數據管理的集中化和分散化之間的平衡。

Thoughtworks認為，數據網格是一種面向分析和機器學習的技術方法，以去中心化的組織和技術方式分享、訪問和管理數據。數據網格希望創建一種社會技術方法，旨在規?；墨@取數據中的價值。從本質上講，它創建了一個可靠的數據共享模式，與組織同步發展并持續擁抱變化。

認為，數據網格是一種去中心化的數據體系結構，按特定業務領域（例如營銷、銷售、客戶服務等）來組織數據，為給定數據集的生產者提供更多所有權。?生產者對領域數據的理解使他們能夠設定專注于文檔、質量和訪問的數據治理策略。反過來，這可以在整個組織中實現自助服務。雖然這種聯合方法消除了與集中式單體系統相關的許多操作瓶頸，但并不一定意味著您不能使用傳統的存儲系統，如數據湖或數據倉庫。這只是意味著它們的使用已經從單一的集中式數據平臺轉變為多個去中心化的數據存儲庫。

為了實現數據網格的目標，Dehghani提出了數據網格的四個原則，包括按領域對數據的所有權和架構去中心化、數據即產品、自助式數據基礎設施及聯邦式計算治理。

1、按領域對數據的所有權和架構去中心化

數據網格的核心是去中心化的，并將權力下放，將其分配給最接近數據的人，從而能夠支持持續的變更和擴張，它比數據湖具有更好的擴展性，因為新的數據源或新的數據消費者只意味著添加一個新的域（數據產品），而不是重新訪問整個數據湖。

為了實現這個目標，我們需要構建一個按域劃分的數據架構。在此架構中，領域與組織其他部分的接口不僅包括交易操作能力，還包括對域所服務的分析數據的訪問。以下示例演示了面向領域的數據所有權原則，每個域可以公開一個或多個操作型 API，以及一個或多個數據API：

這種去中心化的組織架構有點像華為數據之道中提到的業務負責制的數據管理責任體系，華為按分層分級原則任命數據Owner，在公司層面設置公司數據Owner，在各業務領域設置領域數據Owner，這樣既能確保公司數據工作統籌規劃，也能同時兼顧各業務領域靈活多變的特征。

各領域數據Owner在公司數據Owner的統籌下負責所轄領域的數據管理體系的建設和優化。各業務部門是執行規則、保證數據質量，進而推動規則優化的關鍵環節。通過主管結構正式任命各數據主題域和業務對象的數據Owner和數據管理，數據Owner的職責包括數據管理體系建設、信息架構建設、數據質量管理、數據入湖和數據服務建設等等。

大家肯定很困惑，領域擁有數據的所有權似乎是天然的，怎么能說是進步的理念呢？現在數據集中化的目的不就是為了剝奪這種權力以便讓其它領域也可以訪問到領域的數據嗎？

問題的關鍵在于原來的領域雖然擁有數據的權力，但并沒有承擔分享的義務，這引發了數據集中化管理的變革，但傳統集中化的數據平臺做過了頭，在各領域數據支撐上力不從心，數據網格希望采用分布式的架構來解決集約化和靈活性的矛盾，讓數據所有權回歸領域，但需要承擔對外數據服務的義務。

2、數據即產品

傳統對集中化數據的訪問通常需要先進行多次溝通，提交工單等待批準，數據網格希望減少生產者交付高質量數據的阻力，同時使消費者能快速地探索、理解和使用數據。

在過去的十年中，OLTP致力于用產品思維提升對外服務能力，包括打造豐富的 API（應用程序接口）體系、提供優秀的開發體驗（可發現且易于理解的 API 文檔，API 測試箱及密切跟蹤質量的關鍵績效指標）等等。

為了使分布式數據平臺獲得成功，領域數據團隊也必須將產品思維應用于他們提供的數據集，將數據視為獨立的產品，承擔起提升數據質量的責任，包括準確性、一致性等，確保數據可供發現、檢索、理解、值得信賴并有安全性的保障，領域數據產品需要具有以下基本特征：

（1）可發現的

數據產品必須易于發現。常見的實現方式是對所有可用的數據產品及其元信息（例如其所有者，來源，樣本數據集等）編寫目錄。此中心式可發現性服務使組織里的數據消費者，工程師和科學家能夠輕松找到他們需要的數據集。每個領域數據產品都必須在此中心式數據目錄中注冊以方便查詢。請注意，這里的觀點轉變是從單一平臺提取數據，到以可發現的方式將其數據作為產品提供到每個領域。

（2）可尋址的

在分布式體系架構中要制定通用的標準，確保數據產品有一個唯一的訪問地址，不同領域存儲和提供數據集的格式不同，事件可通過 Kafka 進行存儲和訪問，而數據集可使用 CSV 文件或序列化 Parquet 文件的 AWS S3 進行存儲和訪問。

（3）可信賴且真實的

沒有人會使用他們不信任的產品。在傳統集中化數據平臺中，采集的原始數據質量往往參差不齊，需要花費大量時間進行清洗和轉化。為了實現根本性的提升，領域數據產品的所有者要從源頭解決數據質量問題，并通過元數據服務（比如血緣分析）來提升信任度和使用體驗。

（4）自描述的語義和語法

優質的產品往往所見即所得。為了降低數據工程師和數據科學家使用數據集產品的門檻，需要對數據集的含義進行充分描述，最好以樣本數據集作為示例，數據schemas 即域元數據是提供自助服務的起點。

（5）可互操作并受全球標準約束

分布式領域數據體系結構需要具備對跨領域的數據進行連接、過濾、整合的能力，其中的關鍵是遵循統一的標準和規則，這種標準化工作的共同關注點包括字段類型格式化，跨不同領域識別多義詞，數據集地址約定，通用元數據字段，事件格式（例如 CloudEvents）等，互操作性和標準化是構建分布式系統的基礎支柱之一。

（6）安全并受全局訪問控制

無論架構是否中心化都必須確保產品數據集的安全性。在分布式的面向領域的數據產品中，對每個領域數據產品都要進行精細的訪問控制，訪問控制策略可以被集中定義但也可以應用到每個單獨的數據集產品上。使用企業身份管理系統（SSO）和基于角色的訪問控制策略是實現產品數據集訪問控制的便捷方法。

（7）領域數據跨職能團隊

領域需要增加數據產品經理和數據工程師。數據產品經理要圍繞數據產品的愿景和路線圖做出決策，要關注消費者的滿意度，不斷衡量和改進其領域擁有和生產的數據的質量和豐富性，要負責域數據集的生命周期管理，在域數據消費者的需求之間取得平衡，要為數據產品成功定義關鍵績效指標 (KPI)，比如數據產品實現周期。

為了對域內數據進行優化改造，領域必須擁有數據工程師，從而與軟件工程師形成互補，數據工程師雖然擁有數據開發和建模技能，但在構建數據資產時缺乏軟件工程標準實踐，比如持續交付和自動化測試，同樣，軟件工程師通常也沒有使用數據工程工具集的經驗，消除技能孤島有助于創建更大的數據工程技能庫。在這方面，我們已經觀察到DevOps運動產生的授粉效應，比如SRE新型工程師的產生。

數據產品涉及數據、代碼資產（包括生成它的代碼和交付它的代碼）、元數據和相關策略。數據產品可以作為 API、報表、表或數據集在數據湖中傳遞，數據產品應由相同的組件構成，具體包括：

（1）數據

不同數據庫、數倉以及數據湖內的運營、分析和交互數據，按照產品所有者各自負責的域進行組織。

（2）數據事件

定義和描述與數據產品相關的所有狀態變化、命令或數據傳輸；這類事件可能由多種來源觸發，包括數據產品 API（每個請求都可以是一個事件），數據變更捕獲（數據中的每個變化都是一個事件），以及數據目錄變更（元數據的變更事件只會向訂閱者發布）。

（3）數據產品 API

使數據產品內的數據可以按照統一、一致、符合行業標準規范的約定進行訪問，比如 OpenAPI 或 GraphQL、MQQT、gRPC 等機制。

（4）數據產品目錄

描述位于數據產品中的數據，同時提供用戶界面和 API 接口，方便用戶和機器消費數據產品；數據產品目錄整合在企業數據目錄中，對所有數據產品提供統一的企業視圖。

（5）數據產品變更捕獲

捕獲數據產品中所有的數據變化，并將這些變化通知訂閱用戶，從而簡化數據產品元素在組織內和更大范圍間的傳播，例如公司內需要保證分析和運營數據庫的一致、例如，“賬戶”域就有可能觸發對單個“客戶”域內的數據變更。

（6）數據產品變更/審計日志

跟蹤和記錄數據產品的所有變化，以支持聯邦治理和審計要求。

3、作為平臺的自助數據基礎設施

將數據所有權分配給領域的主要問題之一是可能存在重復工作。幸運的是，將通用基礎架構構建為平臺已經是眾所周知的問題，將領域不可知的基礎架構功能收集和提取到數據基礎架構平臺中，使數據域能夠自行生成其數據產品。他們需要能夠使用與用戶相關的工具和流程來定義其數據產品，而無需對中央平臺或中心平臺團隊具有很強的依賴性。

在數據網格中，你擁有自主團隊開發和管理自治產品，你不能有需要專業知識才能操作的專用工具是基于網格的平臺的核心基礎。自助數據基礎架構的成功標準是減少“創建新數據產品的時間”，這將引導“數據產品”功能所需的自動化。

將數據基礎架構構建為平臺的關鍵是（a）不包含任何特定于領域的概念或業務邏輯，使其保持領域不可知性（b）確保平臺隱藏了所有潛在的復雜性和提供了數據基礎架構組件自助服務的方式。自助數據基礎架構作為平臺向用戶（領域的數據工程師）提供的功能種類繁多，比如： 可擴展的多語言大數據存儲 加密靜態和動態數據 數據產品版本控制 數據產品架構 統一的數據訪問控制和記錄 數據管道的實現和編排 數據產品發現，目錄注冊和發布 數據治理與標準化 數據產品監控/報警/日志 數據產品質量指標（收集和共享） 內存中數據緩存 聯合身份管理

4、聯邦式計算治理

如前所述，數據網格遵循分布式系統架構，包括一組具有獨立生命周期的獨立數據產品，由可能的獨立團隊構建和部署。然而，對于大多數用例而言，為了以高階數據集、洞察力或機器智能的形式獲得價值，這些獨立的數據產品需要互操作，能夠關聯它們、創建聯合及查找交點等等。

為了使任何這些操作成為可能，數據網格實現需要一個治理模型，該模型包含去中心化和域自主權、全局標準化的互操作性、基于動態拓撲的平臺自動執行決策。由域數據產品所有者和數據平臺產品所有者聯合領導的決策模型，具有自治和域本地決策權，同時創建并遵守一組全局規則——適用于所有數據產品及其接口的規則——以確保健康和可互操作的生態系統。

這是一項艱巨的工作，要思考如何保持中心化和去中心化之間的平衡，哪些決策需要本地化到每個域，哪些決策應該針對所有域全局進行，最終，全局決策只有一個目的，即通過數據產品的發現和組合創造互操作性和復合網絡效應。

六、總結

數據網格是一種架構和組織范式，它挑戰了我們的傳統觀念 , 即必須將大量的可分析數據集中起來才能使用，將數據放在一起或讓專門的數據團隊來維護。數據網格認為，為了推動大數據創新，領域必須是數據的所有者并將數據作為產品以提供服務（在自助數據平臺的支持下，抽象數據產品服務所涉及的技術復雜性），還必須通過自動化的方式實現一種新的聯合治理形式，以支持面向領域的數據產品間的互操作性、去中心化、互操作性以及數據消費者體驗，這是數據創新民主化的關鍵。

如果組織擁有大量的領域，包括大量產生數據的系統和團隊，或者多種數據驅動的用戶場景和訪問模式，那么數據網格也許是一種很好的選擇。