我工作過的許多公司，都把成為數(shù)據(jù)驅(qū)動型組織設定為它們的首要戰(zhàn)略目標之一。我的客戶深知AI賦能的益處：可以提供基于數(shù)據(jù)和超個性化（hyper-personalization）的最佳客戶體驗；同時通過數(shù)據(jù)驅(qū)動的優(yōu)化減少運營成本和時間；還可以為員工提供更強大的趨勢分析和BI能力。他們一直在大力投資數(shù)據(jù)和智能平臺等賦能引擎。遺憾的是，盡管這些企業(yè)在構建此類賦能平臺方面付出了更多的努力和投入，但結果往往不盡人意。

我理解企業(yè)在轉變成為數(shù)據(jù)驅(qū)動的組織的過程中面臨著多方面的難題。因為他們從數(shù)十年的遺留系統(tǒng)遷移而來的同時，也會被反對依賴數(shù)據(jù)的遺留文化影響，同時，競爭激烈的業(yè)務優(yōu)先級排序也阻礙了這種轉變。但是，我想分享一種導致數(shù)據(jù)平臺計劃失敗的架構視角。我將展示如何將過去十年在分布式架構中的學習成果應到數(shù)據(jù)領域中。我也會介紹一種新的企業(yè)數(shù)據(jù)架構，稱為數(shù)據(jù)網(wǎng)格(即Data Mesh)。

在閱讀之前，我的建議是暫時先放下“基于當前數(shù)據(jù)平臺體系構建范式”的假設和偏見；對從單體式和中心化數(shù)據(jù)湖轉變到數(shù)據(jù)網(wǎng)格架構的可能性持開放態(tài)度；擁抱數(shù)據(jù)永遠存在、無處不在、天然具有分布性特征的現(xiàn)實。

當前的企業(yè)數(shù)據(jù)平臺架構

它是中心式，單體式和領域不可知的，又被稱為數(shù)據(jù)湖。

幾乎每個與我合作的客戶都在計劃或正在構建他們的第三代數(shù)據(jù)和智能平臺，同時也承認過去幾代的失敗：

第一代：專有的企業(yè)數(shù)據(jù)倉庫和商業(yè)智能平臺；這些高價的解決方案使公司承擔了巨大的技術債務。這數(shù)千個無法維護的數(shù)據(jù)倉庫技術作業(yè)、表格和報告中的技術債務，卻只有一小部分專業(yè)人員能夠理解，這使得其對業(yè)務產(chǎn)生的積極影響被低估。

第二代：以數(shù)據(jù)湖為”特效藥“的大數(shù)據(jù)生態(tài)系統(tǒng)；在復雜的大數(shù)據(jù)生態(tài)系統(tǒng)中，超專業(yè)數(shù)據(jù)工程師團隊經(jīng)過長期運行，已經(jīng)創(chuàng)建了“數(shù)據(jù)湖怪獸”，這些龐然大物充其量可以實現(xiàn)大量的“研究與開發(fā)”分析，但是存在“承諾有余、實現(xiàn)不足”的情況。

第三代和當前的數(shù)據(jù)平臺或多或少與上一代相似，但在現(xiàn)代方向上轉變?nèi)缦?（a）通過Kappa等架構進行流傳輸以實現(xiàn)實時數(shù)據(jù)可用性，（b）使用Apache Beam等框架統(tǒng)一批處理和流處理以進行數(shù)據(jù)轉換，（c）全面采用基于云的托管服務，用于存儲，數(shù)據(jù)管道執(zhí)行引擎和機器學習平臺。

顯然，第三代數(shù)據(jù)平臺正在填補前幾代的空白，并在降低管理大數(shù)據(jù)基礎架構的成本，例如實時數(shù)據(jù)分析。但是，它同樣具有許多導致上一代失敗的潛在特征。

架構故障模式

為說明各代數(shù)據(jù)平臺所面臨的潛在限制，讓我們先看一下它們的體系結構和特征。在本文中，我以互聯(lián)網(wǎng)媒體流業(yè)務領域（例如Spotify，SoundCloud，Apple iTunes等）為例來闡明一些概念。

中心式和單體式

宏觀來看，數(shù)據(jù)平臺架構如下圖1所示。中心式架構，其目標是：

從企業(yè)的各個角落提取數(shù)據(jù)，這些數(shù)據(jù)的范圍包括企業(yè)的運營和交易系統(tǒng)以及經(jīng)營業(yè)務的領域，還有擴展企業(yè)知識的外部數(shù)據(jù)提供商。例如，在流媒體業(yè)務中，數(shù)據(jù)平臺負責攝取各種數(shù)據(jù)：“媒體播放器性能”，“用戶與播放器的交互方式”，“被演奏的歌曲”，“被關注的藝術家”以及作為企業(yè)已加入的“標簽和藝術家”，與藝術家的“經(jīng)濟往來”以及外部市場研究數(shù)據(jù)（例如“客戶人口統(tǒng)計”信息）。

平臺清理、豐富源數(shù)據(jù)并將其轉換為可滿足各種消費者需求的可信賴數(shù)據(jù)。在我們的示例中，其中一種轉換是將用戶交互的點擊流變成了帶有用戶詳細信息的數(shù)據(jù)。這試圖在聚合中重構用戶的行為。

平臺將數(shù)據(jù)集提供給具有各種需求的消費者，達到分析消費，探索數(shù)據(jù)以尋找洞見的目的，同時也可以實現(xiàn)基于機器學習的決策制定，撰寫總結業(yè)務績效的商業(yè)智能報告等。在我們的流媒體示例中，該平臺可以通過分布式日志界面（例如Kafka）提供有關全球媒體播放器的實時信息，或提供正在播放的特定藝術家靜態(tài)匯總視圖，以幫助財務理清給藝術家和唱片公司的付款。

圖1：宏觀視角下整體數(shù)據(jù)平臺視圖

一般來說，整體數(shù)據(jù)平臺會托管邏輯上屬于不同領域的數(shù)據(jù)。例如“播放事件”，“銷售KPI”，“藝術家”，“專輯”，“標簽”，“音頻”，“播客”，“音樂事件”等；來自大量不同領域的數(shù)據(jù)。

在過去的十年中，盡管我們已成功將領域驅(qū)動的設計和有限的上下文應用于我們的操作系統(tǒng)，但我們在很大程度上忽略了數(shù)據(jù)平臺中的領域概念。我們已經(jīng)從面向領域的數(shù)據(jù)所有權轉移到中心式的不可知數(shù)據(jù)所有權的域。我們以創(chuàng)建最大的整體（即大數(shù)據(jù)平臺）而自豪。

圖2：領域數(shù)據(jù)界限和所有權不清的數(shù)據(jù)平臺

盡管此中心式模型可用于領域更簡單、消費案例數(shù)量較少的企業(yè)，但對于領域豐富，來源眾多且消費者多樣化的企業(yè)卻不適用。

中心式數(shù)據(jù)平臺的體系結構和組織結構上存在兩個壓力點，這些壓力點通常會導致失?。?/p>

無處不在的數(shù)據(jù)和源擴散：隨著越來越多的數(shù)據(jù)變得無處不在，在一個平臺的控制下，在一個地方使用所有數(shù)據(jù)并進行協(xié)調(diào)的能力將減弱。想象一下，僅在“客戶信息”領域，在企業(yè)內(nèi)外都有越來越多的提供有關現(xiàn)有和潛在客戶的信息來源。如果假設我們需要在一個地方攝取和存儲數(shù)據(jù)以從各種來源中獲取價值，我們對數(shù)據(jù)來源擴散的響應能力將被限制。我認為需要數(shù)據(jù)用戶（例如數(shù)據(jù)科學家和分析師）以低成本來處理各種數(shù)據(jù)集，并且需要將操作系統(tǒng)數(shù)據(jù)使用的數(shù)據(jù)與用于分析目的的數(shù)據(jù)區(qū)分開來。但是我認為，如果企業(yè)是具有豐富領域和不斷添加新資源的大型組織，現(xiàn)有的中心式解決方案不是最佳解決方案。

組織的創(chuàng)新計劃和消費者激增：組織對快速試驗的需求引入了大量用例來消費平臺中的數(shù)據(jù)。這意味著數(shù)據(jù)轉換（可以滿足創(chuàng)新的測試和學習周期的聚合，投影和切片）的數(shù)量正在不斷增長。滿足數(shù)據(jù)消費者需求的響應時間過長一直是企業(yè)面臨的一個問題，而在現(xiàn)代數(shù)據(jù)平臺體系結構中仍然如此。

盡管我現(xiàn)在還不想放棄我的解決方案，但我需要澄清的是，我倡導的領域數(shù)據(jù)不是隱藏在操作系統(tǒng)中的，分散的，孤立的，也不是難以發(fā)現(xiàn)，理解和使用的。我不支持技術債務中形成的分散數(shù)據(jù)倉庫。這是行業(yè)領導者的關注點。但是我認為，解決這些問題的方法并不是建立一個中心式的數(shù)據(jù)平臺，而是由一個中心團隊組成來管理。正如我們在上面論證的那樣，它沒有組織化的規(guī)模。

耦合流水線分解

傳統(tǒng)數(shù)據(jù)平臺體系結構的第二種故障模式與我們?nèi)绾畏纸怏w系結構有關。放大中心式數(shù)據(jù)平臺后，我們發(fā)現(xiàn)一個圍繞攝取，清理，聚合，服務等機械功能的架構分解。企業(yè)中的架構師和技術領導者會根據(jù)平臺的增長來分解架構。如上一節(jié)所述，引入新資源或應對新消費者的需求要求平臺不斷發(fā)展。架構師需要找到一種方法，通過將其分解為體系結構量子來擴展系統(tǒng)。如《設計可進化架構》中所述，架構量子是具有高功能凝聚力的、可獨立部署的組件，其中包括系統(tǒng)正常運行所需的所有結構要素。將系統(tǒng)分解成架構量子是為了創(chuàng)建獨立的團隊，團隊里每個人都可以構建和操作架構量子。這些團隊之間的并行工作可提高的運營可擴展性和速度。

鑒于前幾代數(shù)據(jù)平臺體系結構的影響，架構師將數(shù)據(jù)平臺分解為一系列數(shù)據(jù)處理階段。這邪惡管道在高水平處理數(shù)據(jù)并實現(xiàn)攝取，準備，匯總，服務等功能的凝聚。

圖3：數(shù)據(jù)平臺的體系結構分解

盡管此模型通過將團隊分配到流水線的不同階段擴大了規(guī)模，但它具有一個固有的局限性，那就是使功能交付速度變慢。它在流水線的各個階段之間具有很高的耦合度，以提供獨立的功能或價值。它與變化軸正交分解。

讓我們看一下我們的流媒體示例。 網(wǎng)絡流媒體平臺有一個強大的媒體類型領域構造。他們通常從“歌曲”和“專輯”等服務開始，然后擴展到“音樂事件”，“播客”，“廣播節(jié)目”，“電影”等。啟用單個新功能，例如“播客播放率”的可見性，則需要更改管道中的所有組件。團隊必須引入新的攝取服務，新的清理和準備工作以及用于查看播客播放率的合集。這需要在組件之間進行同步，并在團隊之間進行發(fā)布管理。許多數(shù)據(jù)平臺提供的提取服務可以應資源添加擴展問題，以最大程度地減少開銷。但是，這并沒有從消費者角度解決端到端依賴性問題。我們看似已經(jīng)達到了流水線階段的架構，但實際上整個流水線（即單體式平臺）是必須改成適應新功能的最小單元：解鎖新數(shù)據(jù)集并將其用于新的或現(xiàn)有的消費。這限制了我們響應新的使用者或數(shù)據(jù)源以實現(xiàn)更高速度和更大規(guī)模的能力。

圖4：引入或增強功能時，架構分解與更改軸正交，從而導致耦合和交付速度降低

孤立和超專業(yè)的所有權

當今數(shù)據(jù)平臺的第三種失敗模式與我們?nèi)绾谓M織構建平臺的團隊有關。當我們實地觀察數(shù)據(jù)平臺的人員的生活時，我們發(fā)現(xiàn)他們是一群與組織運營部門隔離的超專業(yè)數(shù)據(jù)工程師；對于數(shù)據(jù)源自何處或在何處使用并付諸行動和決策制定并不知情。數(shù)據(jù)平臺工程師不僅在組織上處于孤立狀態(tài)，而且根據(jù)他們在大數(shù)據(jù)工具方面的技術專長（通常缺乏業(yè)務和領域知識）分類使得他們通常缺乏業(yè)務和領域知識。

圖5：孤立的超專業(yè)數(shù)據(jù)平臺團隊

我并不羨慕數(shù)據(jù)平臺工程師的生活。他們需要消費來自團隊的數(shù)據(jù)，這個團隊通常不能提供有意義的、真實的和正確的數(shù)據(jù)。他們對生成數(shù)據(jù)的源域了解甚少，并且團隊中缺乏領域?qū)I(yè)知識。他們需要針對各種操作或分析的需求提供數(shù)據(jù)，但卻不了解數(shù)據(jù)的應用，也無需與使用領域?qū)＜衣?lián)系。

在媒體流領域，比如在源端，我們有跨職能的“媒體播放器”團隊，可提供有關用戶如何與他們提供的特定功能進行交互的信號，例如“播放歌曲事件”，“購買事件”，“播放音頻質(zhì)量”等；另一端是消費者跨職能團隊，例如“歌曲推薦”團隊，報告銷售KPI的“銷售團隊”，根據(jù)演出計算和付款給藝人的“藝人支付團隊”等。不幸的是，位于中間的數(shù)據(jù)平臺團隊則拼命為所有來源和消費提供合適的數(shù)據(jù)。

實際上，我們還發(fā)現(xiàn)有的源團隊彼此沒有聯(lián)系，有的互相爭奪，導致過度拉伸。

我們創(chuàng)建的架構和組織結構無法擴展，并且無法實現(xiàn)創(chuàng)建數(shù)據(jù)驅(qū)動型組織所承諾的價值。

下一代企業(yè)數(shù)據(jù)平臺架構

它通過分布式數(shù)據(jù)網(wǎng)格包含了無處不在的數(shù)據(jù)。

那么，我們上面討論的故障模式和特征的答案是什么？我認為有必要進行范式轉換，以期在大規(guī)模構建現(xiàn)代分布式體系結構中發(fā)揮作用。整個技術行業(yè)都采用了這些技術，并取得了成功。

我建議下一代企業(yè)數(shù)據(jù)平臺架構是分布式領域驅(qū)動架構、自助式平臺設計以及產(chǎn)品思維與數(shù)據(jù)的融合。

圖6：融合：構建下一個數(shù)據(jù)平臺的模式轉變

盡管這聽起來像是一句空話，但是這些技術確實在現(xiàn)代化操作系統(tǒng)的技術基礎方面產(chǎn)生了具體的、令人難以置信的積極影響。讓我們來深入研究一下如何將這些方法應用于數(shù)據(jù)世界，以擺脫當前的舊范式。

數(shù)據(jù)和分布式領域驅(qū)動的架構融合

面向領域的數(shù)據(jù)分解和所有權

埃里克·埃文斯（Eric Evans）的著作《領域驅(qū)動設計》（Domain-Driven Design）對現(xiàn)代架構思想以及組織建模產(chǎn)生了深遠的影響。它通過將系統(tǒng)分解為圍繞業(yè)務領域功能構建的分布式服務來影響微服務體系結構。它從根本上改變了團隊的組成方式，從而使團隊可以獨立自主地擁有領域能力。

盡管在實現(xiàn)運營功能時我們采用了定向領域分解和所有權，但奇怪的是，在涉及數(shù)據(jù)時，我們卻忽略了業(yè)務領域的概念。 DDD在數(shù)據(jù)平臺體系結構中最接近的應用是用于源操作系統(tǒng)發(fā)出其業(yè)務領域事件，并用于整體數(shù)據(jù)平臺來接收它們。但是，超出攝取點的范圍，就失去了領域的概念以及不同團隊對領域數(shù)據(jù)的所有權。

領域綁定上下文是一種功能強大的工具，可用于設計數(shù)據(jù)集的所有權。 Ben Stopford的Data Dichotomy文章介紹了通過流共享領域數(shù)據(jù)集的概念。
為了使單體式數(shù)據(jù)平臺分散化，我們需要顛覆我們對數(shù)據(jù)本地性和所有權的看法。與其將數(shù)據(jù)從領域中流到中央擁有的數(shù)據(jù)湖或平臺中，不如說領域需要以易于使用的方式托管和服務于其領域數(shù)據(jù)集。

在我們的示例中，與其想象來自媒體播放器的數(shù)據(jù)流到某個集中位置以供一個集中的團隊接收，不如想象我們有一個擁有并服務其數(shù)據(jù)集的播放器領域以滿足團隊下游使用的任何目的。數(shù)據(jù)集實際駐留的物理位置及其流動方式是“播放器領域”的技術實現(xiàn)。物理存儲肯定可以是諸如Amazon S3存儲桶之類的中心式架構，但播放器數(shù)據(jù)集的內(nèi)容和所有權仍保留在生成它們的領中。類似地，在我們的示例中，“推薦”領域以適合其應用的格式創(chuàng)建數(shù)據(jù)集，例如圖形數(shù)據(jù)庫，同時消化了播放器數(shù)據(jù)集。如果還有其他領域（例如“新藝術家發(fā)現(xiàn)領域”）對“推薦領域”圖數(shù)據(jù)集有用，則可以選擇提取和訪問該領域。

這意味著當我們將數(shù)據(jù)轉換為適合該特定領域的形狀時，我們可能會在不同領域中復制數(shù)據(jù)。例如，與藝術家相關的時間序列播放事件的圖表。

這就要求我們將思維方式從傳統(tǒng)上通過ETL、當前通過事件流的推入和獲取模型轉移到跨所有域的服務和提取模型。

面向領域的數(shù)據(jù)平臺中的體系結構范圍是一個領域，而不是流水線階段。

圖7：根據(jù)域（源域，使用者域和新創(chuàng)建的共享域）分解擁有數(shù)據(jù)的架構和團隊

面向源的領域數(shù)據(jù)

一些領域自然地與數(shù)據(jù)起源的源一致。源域數(shù)據(jù)集代表業(yè)務的現(xiàn)實情況。源域數(shù)據(jù)集捕獲與其操作系統(tǒng)的來源和現(xiàn)實關聯(lián)非常緊密的數(shù)據(jù)。在我們的示例中，諸如“用戶如何與服務進行交互”或“入職標簽流程”之類的業(yè)務事實導致領域數(shù)據(jù)集的創(chuàng)建，例如“用戶點擊流”，“音頻播放質(zhì)量流”和“內(nèi)置標簽”。這些事實是眾所周知的，并且是由起源處的操作系統(tǒng)生成的。例如，媒體播放器系統(tǒng)最了解“用戶點擊流”。

在理想的情況下，操作系統(tǒng)及其團隊或組織單位不僅負責提供業(yè)務功能，而且還負責提供其業(yè)務領域的真實情況作為源域數(shù)據(jù)集。在企業(yè)規(guī)模上，領域概念和源系統(tǒng)之間從來沒有一對一的映射。通常，有許多系統(tǒng)可以服務屬于某個領域的部分數(shù)據(jù)，其中一些是舊式的，而某些則易于更改。因此，可能會有許多源對齊的數(shù)據(jù)集（也稱為現(xiàn)實數(shù)據(jù)集），最終需要將它們匯總到一個內(nèi)聚的領域?qū)R的數(shù)據(jù)集中。

商業(yè)事實最好以商業(yè)領域事件的形式呈現(xiàn)，可以將其存儲并作為帶有時間標記的事件的分布式日志，以供任何授權消費者訪問。

除了定時事件外，源數(shù)據(jù)域還應提供易于使用的源域數(shù)據(jù)集的歷史快照，這些密切反映其領域的更改間隔的記錄在一定時間范圍內(nèi)匯總。例如，在向流媒體業(yè)務提供音樂的藝術家的“內(nèi)嵌標簽”源域中，每月匯總通過入職標簽生成的事件的內(nèi)嵌標簽是一種合理的視圖。

請注意，源對齊領域數(shù)據(jù)集必須與內(nèi)部源系統(tǒng)的數(shù)據(jù)集分開。領域數(shù)據(jù)集的性質(zhì)與操作系統(tǒng)用來完成其工作的內(nèi)部數(shù)據(jù)有很大不同。與它們的系統(tǒng)相比，它們具有更大的體積，代表著不變的定時事實，并且變化的頻率更低。因此，實際的基礎存儲必須適合大數(shù)據(jù)，并且必須與現(xiàn)有的操作數(shù)據(jù)庫分開。數(shù)據(jù)和自助平臺設計融合部分將介紹如何創(chuàng)建大數(shù)據(jù)存儲和服務基礎架構。

源域數(shù)據(jù)集是最基礎的數(shù)據(jù)集，由于業(yè)務事實并不經(jīng)常更改，所以更改頻率較低。預計這些領域數(shù)據(jù)集將被永久儲存使用，以便隨著企業(yè)發(fā)展其數(shù)據(jù)驅(qū)動和情報服務，他們始終可以返回到業(yè)務事實，并創(chuàng)建新的匯總或預測。

請注意，源域數(shù)據(jù)集在創(chuàng)建時幾乎代表原始數(shù)據(jù)，并且未針對特定使用者進行擬合或建模。

面向消費者的共享領域數(shù)據(jù)

一些領域與消費密切相關。消費者領域數(shù)據(jù)集和擁有它們的團隊的目的是滿足一組密切相關的用例。例如，“社交推薦領域”側重于根據(jù)用戶彼此之間的社交聯(lián)系提供推薦，創(chuàng)建適合此特定需求的領域數(shù)據(jù)集；也可以通過“用戶社交網(wǎng)絡的圖形”表示。此數(shù)據(jù)集對于推薦用例很有用，也許對于“聽眾通知”領域也有用，該領域提供給不同聽眾發(fā)送通知的數(shù)據(jù)，比如其社交網(wǎng)絡中的人正在聽的內(nèi)容。因此，“用戶社交網(wǎng)絡”有可能成為共享的和新定義的領域數(shù)據(jù)集，供多個消費者使用。 “用戶社交網(wǎng)絡”領域團隊專注于提供“用戶社交網(wǎng)絡”的最新視圖。

消費者對齊的領域數(shù)據(jù)集與源域數(shù)據(jù)集相比具有不同的性質(zhì)。它們在結構上經(jīng)歷了更多的變化，并且將源域事件轉換為聚合適合特定訪問模型的視圖和結構，例如我們在上面看到的圖形示例。面向領域的數(shù)據(jù)平臺應該能夠輕松地從源頭重新生成這些消費者數(shù)據(jù)集。

分布式管道作為領域內(nèi)部實現(xiàn)

盡管將數(shù)據(jù)集所有權從中央平臺委托給領域，但是仍然需要清理，準備，聚合和提供數(shù)據(jù)，數(shù)據(jù)管道的使用也是如此。在這種體系結構中，數(shù)據(jù)管道只是內(nèi)部復雜性和數(shù)據(jù)域的實現(xiàn)，并在域內(nèi)部進行處理。結果，我們將看到數(shù)據(jù)管道階段分布到每個領域中。
例如，源域需要包括對其領域事件的清除，重復數(shù)據(jù)刪除，擴展它們的領域以便其他領域可以使用它們，而無需復制清除。每個領域數(shù)據(jù)集都必須為其提供的數(shù)據(jù)質(zhì)量、及時性，錯誤率等建立服務水平目標：。例如，我們提供音頻“播放點擊流”的媒體播放器領域可以包括清理和標準化其領域中的數(shù)據(jù)管道，這樣就可以提供“播放音頻點擊事件”的實時數(shù)據(jù)流。

同樣，我們將看到從中心式管道的聚合階段進入了消費領域的細節(jié)的實現(xiàn)。

圖8：將管道分配到領域中作為第二類關注點，以及領域的內(nèi)部實現(xiàn)細節(jié)

有人可能會爭辯說，該模型可能會導致每個領域在創(chuàng)建自己的數(shù)據(jù)處理管道實現(xiàn)，技術堆棧和工具方面做出重復的努力。我將在談論數(shù)據(jù)和以自助共享數(shù)據(jù)基礎架構為平臺的思維融合時，很快解決這個問題。

數(shù)據(jù)和產(chǎn)品思維融合

將數(shù)據(jù)所有權和數(shù)據(jù)管道實施分配到業(yè)務領域中這件事引起了人們對分布式數(shù)據(jù)集的關注可行性，可用性和協(xié)調(diào)性。在這里，學習應用產(chǎn)品思維和數(shù)據(jù)資產(chǎn)所有權非常方便。

領域數(shù)據(jù)作為產(chǎn)品

在過去的十年中，運營領域已經(jīng)將產(chǎn)品思想融入了他們?yōu)榻M織其他部門提供的能力中。領域團隊將這些能力作為API（應用程序接口）提供給組織中其他開發(fā)人員以作為創(chuàng)建更高價值和功能的基礎。這些團隊致力于為他們的領域API（應用程序接口）創(chuàng)建最佳的開發(fā)人員體驗；包括可發(fā)現(xiàn)且易于理解的API文檔，API測試箱，同時密切跟蹤質(zhì)量和應用的關鍵績效指標。

為了使分布式數(shù)據(jù)平臺獲得成功，領域數(shù)據(jù)團隊必須以相似的嚴格度將產(chǎn)品思維應用于他們提供的數(shù)據(jù)集。將其數(shù)據(jù)資產(chǎn)視為產(chǎn)品，并將組織里的其余數(shù)據(jù)科學家，機器學習和數(shù)據(jù)工程師視為客戶。

圖9：領域數(shù)據(jù)集作為產(chǎn)品的特征

回顧我們的示例，互聯(lián)網(wǎng)媒體流業(yè)務。它的關鍵領域之一是“播放事件”，即誰，何時，何地播放了哪些歌曲。這個關鍵的領域在組織中擁有不同的使用者；例如，近實時消費者會對用戶體驗以及可能的錯誤感興趣，因此在客戶體驗下降或客戶支持電話打入的情況下可以快速響應以恢復錯誤。還有一些消費者更喜歡每日或每月歌曲播放事件聚合的歷史記錄。

在這種情況下，我們的“播放的歌曲”領域為組織的其他部分提供了兩個不同的數(shù)據(jù)集作為產(chǎn)品。在事件流上公開的實時播放事件，以及在對象存儲中作為序列化文件公開的聚合播放事件。

任何技術產(chǎn)品（這里說的是領域數(shù)據(jù)產(chǎn)品）的一項重要素質(zhì)就是使它們的消費者滿意。（這里指的是數(shù)據(jù)工程師，機器學習工程師或數(shù)據(jù)科學家。）為了向消費者提供最佳的用戶體驗，領域數(shù)據(jù)產(chǎn)品需要具有以下基本素質(zhì)：

可發(fā)現(xiàn)的

數(shù)據(jù)產(chǎn)品必須易于發(fā)現(xiàn)。常見的實現(xiàn)方式是對所有可用的數(shù)據(jù)產(chǎn)品及其元信息（例如其所有者，來源，樣本數(shù)據(jù)集等）編寫目錄。此中心式可發(fā)現(xiàn)性服務使組織里的數(shù)據(jù)消費者，工程師和科學家能夠輕松找到他們需要的數(shù)據(jù)集。每個領域數(shù)據(jù)產(chǎn)品都必須在此中心式數(shù)據(jù)目錄中注冊以方便查詢。

請注意，這里的觀點轉變是從單一平臺提取數(shù)據(jù)，到以可發(fā)現(xiàn)的方式將其數(shù)據(jù)作為產(chǎn)品提供到每個領域。

可尋址的

數(shù)據(jù)產(chǎn)品一經(jīng)發(fā)現(xiàn)，便應該遵循國際慣例，有一個唯一地址，以幫助其用戶以編程方式訪問它。根據(jù)數(shù)據(jù)的基礎存儲和格式，組織可以為數(shù)據(jù)采用不同的命名約定?？紤]到易用性，在分散式體系結構中，有必要制定通用的約定。不同的領域存儲和提供數(shù)據(jù)集的格式不同，事件可能通過諸如Kafka主題之類的流進行存儲和訪問，而柱狀數(shù)據(jù)集可能使用CSV文件或序列化Parquet文件的AWSS3存儲桶。多種語言環(huán)境中的數(shù)據(jù)集可尋址性標準消除了查找和訪問信息時的摩擦。

可信賴且真實的

沒有人會使用他們不信任的產(chǎn)品。在傳統(tǒng)的數(shù)據(jù)平臺中，存在數(shù)據(jù)有誤、不能反映業(yè)務真相或者根本無法信任的情況。在這里，中心式數(shù)據(jù)管道的大部分工作都集中在此，在提取數(shù)據(jù)后清理數(shù)據(jù)。

如果要達到根本性的轉變，數(shù)據(jù)產(chǎn)品的所有者要圍繞數(shù)據(jù)的真實性提供可接受的服務，以及提供它與事件發(fā)生的真實性的接近程度。在創(chuàng)建數(shù)據(jù)產(chǎn)品時應該應用數(shù)據(jù)清理和自動數(shù)據(jù)完整性測試。提供數(shù)據(jù)源和數(shù)據(jù)沿襲作為與每個數(shù)據(jù)產(chǎn)品相關聯(lián)的元數(shù)據(jù)有助于增加消費者對產(chǎn)品及其適用性方面的信任。

數(shù)據(jù)完整性（質(zhì)量）指標的目標值或范圍在領域數(shù)據(jù)產(chǎn)品之間有所不同。例如，“播放事件”領域可以提供兩種不同的數(shù)據(jù)產(chǎn)品，一種接近實時，準確性較低，包括丟失或重復的事件，而另一種則具有較長的延遲和較高的事件準確性。每個數(shù)據(jù)產(chǎn)品定義并保證其作為一組SLO的完整性和真實性。

自描述的語義和語法

優(yōu)質(zhì)的產(chǎn)品不需要消費者手持即可使用：它們可以被查詢，理解和消費。將數(shù)據(jù)集構建為具有最小單元的產(chǎn)品，以供數(shù)據(jù)工程師和數(shù)據(jù)科學家使用，這需要對語義和語法對數(shù)據(jù)進行充分描述，理想情況下將樣本數(shù)據(jù)集作為示例。數(shù)據(jù)模式是提供自助數(shù)據(jù)資產(chǎn)的起點。

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

分布式領域數(shù)據(jù)體系結構中的主要問題之一是關聯(lián)跨領域數(shù)據(jù)并將其有機縫合、連接，過濾，聚合的能力。跨領域有效關聯(lián)數(shù)據(jù)的關鍵是遵循某些標準和統(tǒng)一規(guī)則。這樣的標準化應該用于全球治理，以實現(xiàn)多語言領域數(shù)據(jù)集之間的互操作性。這種標準化工作的共同關注點是字段類型格式化，跨不同領域識別多義詞，數(shù)據(jù)集地址約定，通用元數(shù)據(jù)字段，事件格式（例如CloudEvents）等。

例如，在媒體流業(yè)務中，“藝術家”可能出現(xiàn)在不同的領域中，并且在每個領域中具有不同的屬性和標識符。 “播放事件流”域?qū)λ囆g家的識別可能與負責開發(fā)票和付款的“藝術家支付”領域的識別不同。但是，為了能夠在不同領域的數(shù)據(jù)產(chǎn)品之間關聯(lián)藝術家的數(shù)據(jù)，我們需要就如何將藝術家識別為多義詞達成共識。一種方法是考慮具有聯(lián)合實體的“藝術家”和“藝術家”的唯一全局聯(lián)合實體標識符，這與管理聯(lián)合身份的方式類似。

受全球管轄的通信的互操作性和標準化是構建分布式系統(tǒng)的基礎支柱之一。

安全并受全局訪問控制

無論架構是否中心化，都必須安全地訪問產(chǎn)品數(shù)據(jù)集。在分散的面向領域的數(shù)據(jù)產(chǎn)品的世界中，對每個領域數(shù)據(jù)產(chǎn)品都被以更小的單元應用訪問控制。與操作領域類似，訪問控制策略可以被集中定義，但是也可以應用到每個單獨的數(shù)據(jù)集產(chǎn)品上。使用企業(yè)身份管理系統(tǒng)（SSO）和基于角色的訪問控制策略定義是實現(xiàn)產(chǎn)品數(shù)據(jù)集訪問控制的便捷方法。

數(shù)據(jù)和自助服務平臺設計的融合部分描述了這一共享的基礎結構，該基礎結構可輕松、自動地為每個數(shù)據(jù)產(chǎn)品啟用上述功能。

領域數(shù)據(jù)跨職能團隊

將數(shù)據(jù)作為產(chǎn)品提供的領域；需要增加新的技能：（a）數(shù)據(jù)產(chǎn)品所有者和（b）數(shù)據(jù)工程師。

數(shù)據(jù)產(chǎn)品所有者根據(jù)數(shù)據(jù)產(chǎn)品的愿景和路線圖做出決策，更多關注消費者的滿意度，并不斷衡量和提高其領域擁有和生產(chǎn)的數(shù)據(jù)的質(zhì)量和豐富性。她負責領域數(shù)據(jù)集的生命周期，以及何時更改，修訂和淘汰數(shù)據(jù)和架構。她在領域數(shù)據(jù)使用者的競爭需求之間取得了平衡。

數(shù)據(jù)產(chǎn)品所有者必須定義成功標準和與業(yè)務相關的關鍵績效指標（KPI）。例如，數(shù)據(jù)產(chǎn)品的消費者成功發(fā)現(xiàn)和使用數(shù)據(jù)產(chǎn)品的交付時間是可衡量的成功標準。

為了構建和運行領域的內(nèi)部數(shù)據(jù)管道，團隊必須擁有數(shù)據(jù)工程師。這種跨職能團隊的一個奇妙的副作用是跨團隊技能互補。我目前的行業(yè)觀察是，一些數(shù)據(jù)工程師雖然能夠使用其交易工具，但在構建數(shù)據(jù)資產(chǎn)時缺乏軟件工程標準實踐，例如在連續(xù)交付和自動化測試方面。同樣，構建操作系統(tǒng)的軟件工程師通常也沒有使用數(shù)據(jù)工程工具集的經(jīng)驗。消除技能孤島有助于創(chuàng)建更大的數(shù)據(jù)工程技能庫。我們已經(jīng)觀察到與DevOps運動相同的跨團隊技能互補，以及諸如SRE之類的新型工程師的誕生。

必須將數(shù)據(jù)視為任何軟件生態(tài)系統(tǒng)的基礎，因此軟件工程師和軟件通才必須將數(shù)據(jù)產(chǎn)品開發(fā)的經(jīng)驗和知識添加到他們的工具帶中。同樣，基礎架構工程師需要增加管理數(shù)據(jù)基礎架構的知識和經(jīng)驗。企業(yè)必須提供從通才到數(shù)據(jù)工程師的職業(yè)發(fā)展途徑。由于缺少數(shù)據(jù)工程的技術從而導致了之前「孤立和超專業(yè)的所有權」那節(jié)中的中心化的數(shù)據(jù)工程團的過度局部優(yōu)化的問題。

圖10：具有明確數(shù)據(jù)產(chǎn)品所有權的跨功能領域數(shù)據(jù)團隊

數(shù)據(jù)和自助平臺設計融合

將數(shù)據(jù)所有權分配給領域的主要問題之一是可能存在重復工作。幸運的是，將通用基礎架構構建為平臺已經(jīng)是眾所周知的問題，并且已經(jīng)得到解決。

將領域不可知的基礎架構功能收集和提取到數(shù)據(jù)基礎架構平臺中，解決了重復設置數(shù)據(jù)管道引擎，存儲和流基礎架構的工作的問題。數(shù)據(jù)基礎架構團隊可以擁有并提供域發(fā)現(xiàn)，處理，存儲和服務其數(shù)據(jù)產(chǎn)品所需的必要技術。

圖11：提取和收集與領域無關的數(shù)據(jù)管道基礎架構，并將工具構建到作為平臺的獨立數(shù)據(jù)基礎架構中

將數(shù)據(jù)基礎架構構建為平臺的關鍵是（a）不包含任何特定于領域的概念或業(yè)務邏輯，使其保持領域不可知性；以及（b）確保平臺隱藏了所有潛在的復雜性和提供了數(shù)據(jù)基礎架構組件自助服務的方式。自助數(shù)據(jù)基礎架構作為平臺向用戶（領域的數(shù)據(jù)工程師）提供的功能種類繁多。這里有幾個：

可擴展的多語言大數(shù)據(jù)存儲

加密靜態(tài)和動態(tài)數(shù)據(jù)

數(shù)據(jù)產(chǎn)品版本控制

數(shù)據(jù)產(chǎn)品架構

數(shù)據(jù)產(chǎn)品去識別

統(tǒng)一的數(shù)據(jù)訪問控制和記錄

數(shù)據(jù)管道的實現(xiàn)和編排

數(shù)據(jù)產(chǎn)品發(fā)現(xiàn)，目錄注冊和發(fā)布

數(shù)據(jù)治理與標準化

數(shù)據(jù)產(chǎn)品沿襲

數(shù)據(jù)產(chǎn)品監(jiān)控/報警/日志

數(shù)據(jù)產(chǎn)品質(zhì)量指標（收集和共享）

內(nèi)存中數(shù)據(jù)緩存

聯(lián)合身份管理

計算和數(shù)據(jù)局部性

自助數(shù)據(jù)基礎架構的成功標準是減少“創(chuàng)建新數(shù)據(jù)產(chǎn)品的時間”。這將引導“數(shù)據(jù)產(chǎn)品”功能所需的自動化，這在“將領域數(shù)據(jù)作為產(chǎn)品”部分中進行了介紹。例如，通過配置和腳本自動執(zhí)行數(shù)據(jù)提取，將腳手架放置在適當位置的數(shù)據(jù)產(chǎn)品創(chuàng)建腳本，在目錄中自動注冊數(shù)據(jù)產(chǎn)品等。

使用云基礎架構作為基礎可以減少運營成本和工作量，但是，它并沒有完全消除需要在業(yè)務環(huán)境中放置的更高的抽象。無論云提供商如何，數(shù)據(jù)基礎架構團隊都可以使用一組豐富且不斷增長的數(shù)據(jù)基礎結構服務。

向數(shù)據(jù)網(wǎng)格轉移的范式

讀了這么久了，讓我們總結一下。我們研究了當前數(shù)據(jù)平臺的一些基本特征：中心式，單體式，高度耦合的管道架構，由超專業(yè)數(shù)據(jù)工程師的獨立操作。我們介紹了作為平臺的無處不在的數(shù)據(jù)網(wǎng)格的構建模塊；面向領域的分布式數(shù)據(jù)產(chǎn)品，由獨立的跨職能團隊擁有，這些團隊具有嵌入式數(shù)據(jù)工程師和數(shù)據(jù)產(chǎn)品所有者，使用通用數(shù)據(jù)基礎結構作為承載，準備和服務其數(shù)據(jù)資產(chǎn)的平臺。

數(shù)據(jù)網(wǎng)格平臺是經(jīng)過精心設計的分布式數(shù)據(jù)體系結構，在集中管理和標準化下實現(xiàn)了互操作性，并通過共享和統(tǒng)一的自助式數(shù)據(jù)基礎結構實現(xiàn)了此功能。我希望，它與無法訪問的數(shù)據(jù)零散孤島的景象不同。

圖12：俯視數(shù)據(jù)網(wǎng)格架構

那么，數(shù)據(jù)湖或數(shù)據(jù)倉庫在此體系結構中適合什么位置？它們只是網(wǎng)格上的節(jié)點。我們很有可能不需要數(shù)據(jù)湖，因為保存原始數(shù)據(jù)的分布式日志和存儲是可用與從作為產(chǎn)品的不同的、可尋址的、不可變的數(shù)據(jù)集中作為產(chǎn)品中進行探索。但是，如果我們確實需要更改數(shù)據(jù)的原始格式以進行進一步的探索（例如標記），則有此需求的領域可能會創(chuàng)建自己的湖泊或數(shù)據(jù)中心。

因此，數(shù)據(jù)湖不再是整個體系結構的核心。我們將繼續(xù)應用一些數(shù)據(jù)湖的原理，例如使不變的數(shù)據(jù)可用于勘探和分析用途。我們將繼續(xù)使用數(shù)據(jù)湖工具，但是將其用于數(shù)據(jù)產(chǎn)品的內(nèi)部實施或作為共享數(shù)據(jù)基礎結構的一部分。

實際上，這使我們回到了一切的起點：2010年，James Dixon打算將一個數(shù)據(jù)湖用于單個領域，而多個數(shù)據(jù)域?qū)⑿纬梢粋€“水上花園”。

主要轉變是將領域數(shù)據(jù)產(chǎn)品視為第一類關注點，而將數(shù)據(jù)湖工具和管道視為第二類關注點-即實現(xiàn)細節(jié)。這將當前的思維模型從中心化式數(shù)據(jù)湖轉變?yōu)榭梢院芎玫貐f(xié)同工作的數(shù)據(jù)產(chǎn)品生態(tài)系統(tǒng)，即數(shù)據(jù)網(wǎng)格

相同的原則適用于用于業(yè)務報告和可視化的數(shù)據(jù)倉庫。它只是網(wǎng)格上的一個節(jié)點，并且可能位于網(wǎng)格的面向消費者的邊緣上。

我承認，盡管我看到數(shù)據(jù)網(wǎng)格實踐已在我的客戶中應用，但企業(yè)規(guī)模的采用仍然有很長的路要走。我不認為技術是這里的局限性，我們今天使用的所有工具都可以容納多個團隊的分配和所有權。尤其是向批處理和流傳輸以及諸如Apache Beam或Google Cloud Dataflow之類的工具統(tǒng)一的轉變，可以處理多種類型的數(shù)據(jù)集。

諸如Google Cloud Data Catalog之類的數(shù)據(jù)目錄平臺提供了中心化的可發(fā)現(xiàn)性，訪問控制和分布式領域數(shù)據(jù)集的治理。多種云數(shù)據(jù)存儲選項使領域數(shù)據(jù)產(chǎn)品可以選擇適合用途的多語言存儲。

需求是真實的，工具已經(jīng)準備就緒。這需要組織的工程師和領導者來認識到，僅使用新的基于云的工具，現(xiàn)有的大數(shù)據(jù)范例和一個真正的大數(shù)據(jù)平臺或數(shù)據(jù)湖就只會重復過去的失敗。

這種范式轉換需要一套新的管理原則以及一種新的語言：

服務而不是提取

發(fā)現(xiàn)和使用而不是提取和載入

發(fā)布事件流而不是利用中心化的管道來管理數(shù)據(jù)

數(shù)據(jù)產(chǎn)品生態(tài)而不是中心化數(shù)據(jù)平臺

讓我們將大數(shù)據(jù)單體分解為一個統(tǒng)一，協(xié)作和分布式的數(shù)據(jù)網(wǎng)格生態(tài)系統(tǒng)。

來源：https://insights.thoughtworks.cn/data-monolith-to-mesh/

編輯：fqj