如何從單一資料湖轉移到分散式資料網格

集中式且單一

在 30,000 英尺高空，資料平台架構如下圖 1 所示；一個集中式架構，其目標是

• 擷取資料來自企業的各個角落，範圍涵蓋營運和交易系統，以及執行業務的網域或擴充企業知識的外部資料供應商。例如，在媒體串流業務中，資料平台負責擷取各種資料：『媒體播放器效能』、『使用者如何與播放器互動』、『播放的歌曲』、『追蹤的藝人』，以及企業已納入的『標籤和藝人』、『與藝人的金融交易』，以及外部市場研究資料，例如『客戶人口統計』資訊。
• 清理、豐富和轉換原始資料，使其成為可信賴的資料，以滿足各種消費者的需求。在我們的範例中，其中一項轉換會將使用者互動的點擊串流轉換為有意義的會話，並豐富使用者詳細資料。這會嘗試將使用者的歷程和行為重建為彙總檢視。
• 提供資料集給具有各種需求的多樣消費者。這涵蓋從分析消費到探索資料尋找見解、基於機器學習的決策制定，到總結企業績效的商業智慧報告。在我們的媒體串流範例中，平台可透過 Kafka 等分散式日誌介面，提供全球媒體播放器的近乎即時的錯誤和品質資訊，或提供特定藝人播放記錄的靜態彙總檢視，以推動對藝人和唱片公司的財務付款計算。

圖 1：單一資料平台的 30,000 英呎視角

單一資料平台託管並擁有邏輯上屬於不同網域的資料，例如「播放事件」、「銷售關鍵績效指標」、「藝人」、「專輯」、「唱片公司」、「音訊」、「播客」、「音樂活動」等，這是公認的慣例；來自大量不同網域的資料。

雖然在過去十年中，我們已成功將網域驅動設計和受限網域應用到我們的營運系統，我們在很大程度上忽略了資料平台中的網域概念。我們已從網域導向資料擁有權轉移到集中式的網域不可知資料擁有權。我們以建立最大的單一體為傲，也就是大資料平台。

圖 2：沒有明確資料網域界線和網域導向資料擁有權的集中式資料平台

雖然這個集中式模型可以適用於網域較簡單、消費案例較少的組織，但對於網域豐富、來源眾多且消費者多元的企業來說，它會失敗。

集中式資料平台的架構和組織結構上有兩個壓力點，通常會導致其失敗

• 無所不在的資料與來源激增：隨著越來越多的資料無所不在，將所有資料集中在一個平台控制下並加以利用的能力也隨之降低。想像一下，僅在「客戶資訊」的領域中，組織內外就有越來越多來源提供有關現有和潛在客戶的資訊。假設我們需要將資料擷取並儲存在一個地方才能從各種來源獲得價值，這將限制我們回應資料來源激增的能力。我了解資料使用者（例如資料科學家和分析師）需要以低負擔處理各種資料集，以及需要將營運系統資料使用與用於分析目的的資料分開。但我認為現有的集中式解決方案並非擁有豐富網域且持續新增新來源的大型企業的最佳答案。
• 組織的創新議程和消費者激增：組織需要快速實驗，這會引入更多使用案例，以從平台消耗資料。這表示資料的轉換次數不斷增加，例如彙總、投影和切片，這些轉換可以滿足創新的測試和學習週期。長期的回應時間無法滿足資料使用者的需求，這在過去一直是組織摩擦的點，在現代資料平台架構中仍然如此。

雖然我還不想透露我的解決方案，但我需要澄清的是，我並不主張使用分散、孤立的網域導向資料，這些資料通常隱藏在營運系統的深處；孤立的網域資料難以發現、理解和使用。我並不主張使用多個分散的資料倉儲，這些資料倉儲是多年累積技術債務的結果。這是業界領導者表達過的疑慮。但我認為，對這些無法存取資料的意外孤立資料倉儲的回應，並非建立一個由集中式團隊擁有和管理所有網域資料的集中式資料平台。正如我們在上面學到並展示的那樣，這在組織上無法擴展。

耦合管線分解

傳統資料平台架構的第二個故障模式與我們如何分解架構有關。在將近 10,000 英尺的高度縮放至集中式資料平台時，我們發現架構分解圍繞著擷取、清理、彙總、提供服務等機械功能進行。組織中的架構師和技術領導者會根據平台的成長來分解架構。如前一節所述，需要加入新的來源或回應新的消費者，這表示平台需要成長。架構師需要找到一種方法，透過將系統分解為其架構量子來擴充系統。如 建立演化式架構 中所述，架構量子是一個獨立部署的元件，具有高度功能凝聚力，其中包含系統正常運作所需的所有結構元素。將系統分解為其架構量子的動機是建立獨立的團隊，每個團隊都可以建立並操作一個架構量子。讓這些團隊並行工作，以達到更高的操作擴充性和速度。

受到前幾代資料平台架構的影響，架構師會將資料平台分解為資料處理階段的管道。在非常高的層級上，管道會實作圍繞資料處理技術實作的功能凝聚力；例如擷取、準備、彙總、提供服務等功能。

圖 3：資料平台的架構分解

雖然這個模型提供了一些層級的擴充性，透過將團隊分配到管道的不同階段，但它有一個固有的限制，會減緩功能的傳遞。它在管道的階段之間具有高度耦合，才能傳遞獨立的功能或價值。它垂直於變更軸分解。

讓我們來看看我們的媒體串流範例。網路媒體串流平台會圍繞他們提供的媒體類型建立強大的網域建構。他們通常會以「歌曲」和「專輯」開始他們的服務，然後擴充到「音樂活動」、「播客」、「廣播節目」、「電影」等。啟用單一新功能（例如「播客播放率」的可見性）需要變更管道中的所有元件。團隊必須導入新的擷取服務、新的清理和準備，以及用於檢視播客播放率的彙總。這需要跨不同元件的實作進行同步，以及跨團隊的發行管理。許多資料平台提供通用且基於組態的擷取服務，可以輕易地應付擴充（例如新增新的來源或修改現有的來源），以將導入新來源的開銷降到最低。然而，這並未從消費者的觀點移除導入新資料集的端對端相依性管理。雖然在文件上，管道架構可能看起來像是我們已經達成管道階段的架構量子，但在實務上，整個管道（也就是單一平台）是必須變更以因應新功能的最小單位：解鎖新的資料集，並讓新的或現有的消費可以使用。這限制了我們因應新的資料消費者或來源而達成更高速度和擴充性的能力。

圖 4：在引入或增強功能時，架構分解與變更軸線正交，導致耦合和遞送速度變慢

孤立且高度專業化的擁有權

當今資料平台的第三種故障模式與我們如何架構建置和擁有平台的團隊有關。當我們拉近距離觀察建置和操作資料平台的人員的生活時，我們發現一群高度專業化的資料工程師與組織的營運部門隔離；資料的來源或使用和付諸行動以及決策制定的地方。資料平台工程師不僅在組織上被隔離，而且還根據其大數據工具的技術專業知識分組，通常缺乏業務和領域知識。

圖 5：隔離的高度專業化資料平台團隊

我個人不羨慕資料平台工程師的生活。他們需要從沒有提供有意義、真實和正確資料誘因的團隊中擷取資料。他們對產生資料的來源領域了解甚少，而且缺乏團隊的領域專業知識。他們需要為各種需求（營運或分析）提供資料，而沒有清楚了解資料的應用和存取使用領域專家的管道。

例如，在媒體串流領域，在來源端，我們有跨職能的「媒體播放器」團隊，提供有關使用者如何與他們提供的特定功能互動的訊號，例如「播放歌曲事件」、「購買事件」、「播放音訊品質」等；而在另一端則是跨職能的消費者團隊，例如「歌曲推薦」團隊、「銷售團隊」報告銷售關鍵績效指標、「藝術家付款團隊」根據播放事件計算和支付藝術家等。遺憾的是，資料平台團隊處於中間，透過不懈的努力為所有來源和使用提供合適的資料。

在現實中，我們發現來源團隊脫節、沮喪的消費者爭奪資料平台團隊積壓工作最優先順序，以及過度擴張的資料平台團隊。

我們已經建立了一個無法擴充且無法提供建立資料驅動組織的承諾價值的架構和組織結構。

以網域為導向的資料分解與擁有權

Eric Evans 的書 領域驅動設計 深刻影響了現代架構思維，進而影響了組織建模。它通過將系統分解為圍繞業務領域功能建立的分散式服務，影響了微服務架構。它從根本上改變了團隊的組成方式，以便團隊可以獨立自主地擁有領域功能。

雖然我們在實施營運功能時採用了面向領域的分解和所有權，但奇怪的是，我們在處理資料時忽視了業務領域的概念。DDD 在資料平台架構中的最接近應用是，來源營運系統發出其業務 領域事件，而單體資料平台則擷取它們。然而，在擷取點之外，不同團隊對領域和領域資料所有權的概念就消失了。

領域邊界脈絡是設計資料集所有權的強大工具。Ben Stopford 的 資料二分法 文章解開了透過串流共用領域資料集的概念。

為了分散單體資料平台，我們需要扭轉我們對資料、其區域性和所有權的思考方式。領域不應將資料流動到中央擁有的資料湖或平台中，而是需要以易於使用的管道主機和提供其領域資料集。

在我們的範例中，與想像資料從媒體播放器流動到某個中央位置供中央團隊接收，何不想像播放器領域擁有並提供其資料集，供任何團隊在任何目的下在下游存取。資料集實際上駐留的實體位置以及其流動方式，是「播放器領域」的技術實作。實體儲存當然可以是集中式基礎設施，例如 Amazon S3 儲存區，但播放器資料集內容和所有權仍屬於產生它們的領域。同樣地在我們的範例中，「推薦」領域會建立適合其應用程式的格式的資料集，例如圖形資料庫，同時使用播放器資料集。如果還有其他領域（例如「新藝人探索領域」）發現「推薦領域」圖形資料集有用，他們可以選擇擷取並存取該資料集。

這表示我們在將資料轉換為適合特定網域的形狀時，可能會在不同的網域中複製資料，例如時間序列播放事件到相關藝術家圖表。

這需要我們將思考方式從傳統上透過 ETL，最近則透過事件串流的「推入和攝取」轉變為跨所有網域的「提供服務和提取」模式。

在網域導向資料平台中，架構量子是「網域」，而不是管線階段。

圖 7：根據網域分解架構和擁有資料的團隊 - 來源、消費者和新建立的共用網域

以來源為導向的網域資料

有些網域自然會與資料的來源對齊。來源網域資料集代表業務的「事實和現實」。來源網域資料集擷取與其來源的作業系統（現實系統）所產生的資料非常接近。在我們的範例中，業務事實，例如「使用者如何與服務互動」或「標籤加入流程」，會導致建立網域資料集，例如「使用者點擊串流」、「音訊播放品質串流」和「已加入標籤」。這些事實最為人所知，而且是由位於來源點的作業系統所產生。例如，媒體播放器系統最了解「使用者點擊串流」。

在成熟且理想的情況下，作業系統及其團隊或組織單位不僅負責提供業務功能，也負責提供來源網域資料集作為「其業務網域的真實性」。在企業規模中，網域概念和來源系統之間永遠不會是一對一的對應。通常有許多系統可以提供屬於網域的資料部分，有些是舊系統，有些則容易變更。因此，可能會有許多「來源對齊資料集」，又稱為「現實資料集」，最終需要彙總成一個一致的網域對齊資料集。

業務事實最適合以業務網域事件呈現，可以儲存在分散式時間戳記事件記錄中，並提供給任何授權的消費者存取。

除了計時事件外，來源資料網域還應該提供來源網域資料集的易於使用的歷史快照，並根據與其網域變更間隔密切相關的時間間隔進行彙總。例如，在顯示提供音樂給串流業務的藝術家標籤的「已加入標籤」來源網域中，按月彙總已加入的標籤是除了透過加入標籤的流程所產生的事件外，可以提供的合理檢視方式。

請注意，來源對齊網域資料集必須與內部來源系統的資料集分開。網域資料集的性質與作業系統用來執行其工作的內部資料非常不同。它們的容量大得多，代表不可變的計時事實，而且變更頻率低於其系統。因此，實際的底層儲存必須適合大資料，而且與現有的作業資料庫分開。第資料和自助服務平台設計趨同節說明如何建立大資料儲存和提供服務的基礎架構。

來源網域資料集是基礎最紮實的資料集，而且變動頻率較低，因為業務事實不會那麼頻繁地變動。預期這些網域資料集會被永久擷取並提供，讓組織在發展其資料驅動和智慧服務時，隨時都能回歸業務事實，並建立新的聚合或預測。

請注意，來源網域資料集在建立時，會緊密代表原始資料，而且不會針對特定消費者進行調整或建模。

以消費者為導向且共用的網域資料

有些網域會與消費緊密結合。消費者網域資料集和擁有這些資料集的團隊，旨在滿足一組密切相關的使用案例。例如，專注於根據使用者之間的社交連結提供建議的「社交建議網域」，會建立符合此特定需求的網域資料集；或許透過「使用者的社交網路圖形表示」。儘管此圖形資料集對建議使用案例很有用，但它也可能對「聽眾通知」網域很有用，此網域提供有關傳送給聽眾的不同類型通知的資料，包括其社交網路中的人員正在聽什麼。因此，有可能「使用者社交網路」可以成為多個消費者使用的共用且新實體化的網域資料集。「使用者社交網路」網域團隊專注於提供「使用者社交網路」始終經過整理且最新的檢視。

與來源網域資料集相比，消費者對齊的網域資料集性質不同。它們在結構上會經歷更多變動，而且會轉換來源網域事件，以聚合檢視和結構，以符合特定存取模式，例如我們在上面看到的圖形範例。以網域為導向的資料平台應該能夠輕鬆地從來源重新產生這些消費者資料集。

分散式管線作為網域內部實作

儘管資料集的所有權已從中央平台委派給網域，但對資料的清理、準備、聚合和服務的需求仍然存在，資料管線的使用也是如此。在此架構中，資料管線只是資料網域的內部複雜性和實作，而且在網域內部內部處理。因此，我們將看到資料管線階段分佈到每個網域。

例如，來源網域需要包含其網域事件的清理、去重和豐富，以便其他網域可以消耗它們，而不會重複清理。每個網域資料集都必須為其提供的資料品質建立服務等級目標：即時性、錯誤率等。例如，我們的媒體播放器網域提供音訊「播放點擊串流」，可以在其網域中包含清理和標準化資料管道，提供符合組織事件編碼標準的去重近乎即時「播放音訊點擊事件」串流。

同樣地，我們將看到集中式管道的匯總階段移入消耗網域的實作細節中。

圖 8：將管道分佈到網域中作為次要考量和網域的內部實作細節

有人可能會辯稱，此模型可能會導致每個網域在建立自己的資料處理管道實作、技術堆疊和工具時重複工作。我將在我們討論資料和自服務平台設計收斂與自服務共用資料基礎架構作為平台時，簡要說明此問題。

網域資料作為一種產品

在過去十年中，營運網域已將產品思維建置到他們提供給組織其他部分的功能中。網域團隊將這些功能作為 API 提供給組織中的其他開發人員，作為建立更高階價值和功能的建構區塊。這些團隊致力於為其網域 API 建立最佳開發人員體驗；包括可發現且易於理解的 API 文件、API 測試沙盒，以及嚴密追蹤的品質和採用 KPI。

為了讓分散式資料平台成功，網域資料團隊必須對他們提供的資料集應用同樣嚴謹的產品思維；將其資料資產視為其產品，並將組織其他部分的資料科學家、機器學習和資料工程師視為其客戶。

圖 9：網域資料集作為產品的特徵

考慮我們的範例，網路媒體串流業務。其關鍵網域之一是「播放事件」，即由誰、何時何地播放了哪些歌曲。此關鍵網域在組織中具有不同的消費者；例如，有興趣於使用者體驗和可能錯誤的近乎即時消費者，因此在客戶體驗下降或有客戶支援電話進來時，可以快速回應以修復錯誤。還有一些消費者會偏好每日或每月的歌曲播放事件匯總的歷史快照。

在這種情況下，我們的「播放歌曲」網域提供兩個不同的資料集作為其產品給組織中的其他人；即時播放事件顯示在事件串流中，以及匯總的播放事件顯示為物件儲存空間中的序列化檔案。

任何技術產品，在這種情況下是網域資料產品，一個重要的品質是讓其消費者感到滿意；在這種情況下是資料工程師、機器學習工程師或資料科學家。為了提供消費者最佳的使用者體驗，網域資料產品需要具備以下基本品質

區段資料和自助服務平台設計趨同說明了共用基礎架構，讓上述功能可以輕鬆且自動地針對每個資料產品啟用。

網域資料跨職能團隊

提供資料作為產品的網域需要擴充新的技能組：(a) 資料產品擁有者和 (b) 資料工程師。

資料產品擁有者會針對資料產品的願景和路線圖做出決策，關注其消費者的滿意度，並持續衡量和改善其網域擁有和產生的資料的品質和豐富度。她負責網域資料集的生命週期，包括何時變更、修改和停用資料和架構。她在網域資料消費者相互競爭的需求之間取得平衡。

資料產品擁有者必須定義成功準則和與業務相符的關鍵績效指標 (KPI) 給他們的資料產品。例如，資料產品的消費者發現和成功使用資料產品的提前時間，是一個可衡量的成功準則。

為了建置和營運網域的內部資料管線，團隊必須包含資料工程師。這種跨職能團隊的一個絕佳附加效果是不同技能的交叉授粉。我目前對產業的觀察是，一些資料工程師雖然有能力使用其專業工具，但在建置資料資產時卻缺乏軟體工程的標準實務，例如持續傳遞和自動化測試。類似地，建置運作系統的軟體工程師通常沒有使用資料工程工具組的經驗。消除技能組的隔閡將導致組織可以使用更多且更深入的資料工程技能組。我們在 DevOps 運動中觀察到相同的跨技能授粉，以及新類型工程師的誕生，例如SRE。

資料必須視為任何軟體生態系統的基礎部分，因此軟體工程師和軟體通才必須將資料產品開發的經驗和知識加入他們的工具包。同樣地，基礎架構工程師需要加入管理資料基礎架構的知識和經驗。組織必須提供從通才到資料工程師的職業發展途徑。資料工程技能的缺乏導致了局部最佳化，即形成集中式資料工程團隊，如封閉且高度專業化的所有權一節中所述。

圖 10：具有明確資料產品所有權的跨職能領域資料團隊