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

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

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

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

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

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

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

第二代：以數(shù)據(jù)湖為”特效藥“的大數(shù)據(jù)生態(tài)系統(tǒng)；在復(fù)雜的大數(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)代方向上轉(zhuǎn)變?nèi)缦?（a）通過Kappa等架構(gòu)進行流傳輸以實現(xiàn)實時數(shù)據(jù)可用性，（b）使用Apache Beam等框架統(tǒng)一批處理和流處理以進行數(shù)據(jù)轉(zhuǎn)換，（c）全面采用基于云的托管服務(wù)，用于存儲，數(shù)據(jù)管道執(zhí)行引擎和機器學(xué)習(xí)平臺。

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

架構(gòu)故障模式

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

中心式和單體式

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

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

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

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

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

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

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

圖2：領(lǐng)域數(shù)據(jù)界限和所有權(quán)不清的數(shù)據(jù)平臺

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

中心式數(shù)據(jù)平臺的體系結(jié)構(gòu)和組織結(jié)構(gòu)上存在兩個壓力點，這些壓力點通常會導(dǎo)致失敗：

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

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

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

耦合流水線分解

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

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

圖3：數(shù)據(jù)平臺的體系結(jié)構(gòu)分解

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)和分布式領(lǐng)域驅(qū)動的架構(gòu)融合

面向領(lǐng)域的數(shù)據(jù)分解和所有權(quán)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

任何技術(shù)產(chǎn)品（這里說的是領(lǐng)域數(shù)據(jù)產(chǎn)品）的一項重要素質(zhì)就是使它們的消費者滿意。（這里指的是數(shù)據(jù)工程師，機器學(xué)習(xí)工程師或數(shù)據(jù)科學(xué)家。）為了向消費者提供最佳的用戶體驗，領(lǐng)域數(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)性服務(wù)使組織里的數(shù)據(jù)消費者，工程師和科學(xué)家能夠輕松找到他們需要的數(shù)據(jù)集。每個領(lǐng)域數(shù)據(jù)產(chǎn)品都必須在此中心式數(shù)據(jù)目錄中注冊以方便查詢。

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

可尋址的

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

可信賴且真實的

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

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

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

自描述的語義和語法

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

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

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

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

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

安全并受全局訪問控制

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

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

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

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

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

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

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

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

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

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

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

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

圖11：提取和收集與領(lǐng)域無關(guān)的數(shù)據(jù)管道基礎(chǔ)架構(gòu)，并將工具構(gòu)建到作為平臺的獨立數(shù)據(jù)基礎(chǔ)架構(gòu)中

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

服務(wù)而不是提取

發(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