從工程視角看邁向資料網格架構的六大問題

一 為什麼需要資料網格

許多組織都構建了中央資料湖和資料團隊，希望基於資料來推動業務發展。然而，在最初的幾次快速勝利之後，他們注意到中央資料團隊經常成為瓶頸。團隊無法足夠快地處理管理層和產品負責人的所有分析問題。這是一個大問題，因為及時做出資料驅動的決策對於保持競爭力至關重要。例如：黑色週期間提供免費送貨是個好主意嗎?客戶是否接受更長但更可靠的運輸時間?產品設計更改如何影響結賬率和退貨率?

資料團隊希望快速回答所有這些問題。然而，在實踐中，他們遇到了困難，因為在運算元據庫發生更改後，他們需要花費太多時間來修復損壞的資料管道。在剩下的不多的時間裡，資料團隊必須發現並理解必要的業務域資料。對於每個問題，他們都需要學習業務知識才能提供有意義的見解。獲得所需的業務域專業知識是一項艱鉅的任務。

另一方面，組織還構建了領域驅動設計、自治領域團隊和去中心化微服務架構。這些領域團隊擁有並瞭解他們的領域，包括業務的資訊需求。他們自行設計、構建和執行Web應用程式和API。儘管瞭解領域和相關資訊需求，領域團隊仍必須聯絡超載的中央資料團隊以獲得必要的資料驅動見解。

隨著組織的最終發展，領域團隊和中央資料團隊的情況變得更糟。解決這個問題的一個方法是將資料的責任從中央資料團隊轉移到領域團隊。這就是資料網格概念背後的核心思想：分析資料的面向領域的去中心化。資料網格架構使領域團隊能夠自行執行跨域資料分析並互連資料，類似於微服務架構中的API。

二 什麼是資料網格

資料網格一詞由ZhamakDehghani創造2019年，它基於四個眾所周知的基本原則：

域所有權原則要求域團隊對其資料負責。根據這一原則，分析資料應該圍繞域組成，類似於與系統的有界上下文對齊的團隊邊界。遵循領域驅動的分散式架構，分析和運算元據所有權從中央資料團隊轉移到領域團隊。

資料作為產品原則將產品思維哲學投射到分析資料上。這個原則意味著域外的資料也有消費者。領域團隊負責透過提供高質量的資料來滿足其他領域的需求。基本上，域資料應該像任何其他公共API一樣對待。

自助資料基礎設施平臺背後的理念是將平臺思維應用於資料基礎設施。專門的資料平臺團隊提供與領域無關的功能、工具和系統，以便為所有領域構建、執行和維護可互操作的資料產品。藉助其平臺，資料平臺團隊使領域團隊能夠無縫地使用和建立資料產品。

聯邦治理原則透過標準化實現所有資料產品的互操作性，由治理組透過整個資料網格來推動。聯邦治理的主要目標是建立一個遵守組織規則和行業法規的資料生態系統。

三 如何設計資料網格

資料網格架構是一種分散的方法，使域團隊能夠自行執行跨域資料分析。其核心是具有負責團隊及其運營和分析資料的領域。領域團隊獲取運營資料並構建分析資料模型作為資料產品來執行自己的分析。它還可以選擇釋出帶有資料合約的資料產品來滿足其他領域的資料需求。

領域團隊在全域性策略上與其他人達成一致，例如聯合治理組中的互操作性、安全性和文件標準，以便領域團隊知道如何發現、理解和使用資料網格中可用的資料產品。資料平臺團隊提供的與領域無關的自助資料平臺使領域團隊能夠輕鬆構建自己的資料產品並有效地進行自己的分析。賦能團隊指導領域團隊如何對分析資料進行建模、使用資料平臺以及構建和維護可互操作的資料產品。

讓我們詳細瞭解資料網格架構的核心元件及其關係：

1.資料產品

資料產品是一個邏輯單元，包含用於處理和儲存分析或資料密集型用例的域資料的所有元件，並透過輸出埠將它們提供給其他團隊。您可以將其視為模組或微服務，但用於分析資料。

資料產品連線到源(例如作業系統或其他資料產品)並執行資料轉換。資料產品在一個或多個輸出埠提供資料集。輸出埠通常是由資料合約定義的結構化資料集。下面是一些例子：

• 包含多個相關表的BigQuery資料集

• AWSS3儲存桶中的Parquet檔案

• AzureDataLakeStorageGen2中的增量檔案

• Kafka主題中的訊息

資料產品由領域團隊擁有。團隊負責資料產品整個生命週期的運營。團隊需要持續監控並確保資料質量、可用性和成本。

下面是資料產品設計示例：

2.資料合約

資料合約是定義資料提供者與其消費者之間交換資料的結構、格式、語義、質量和使用條款的文件。它涵蓋：

• 資料產品提供者，包括所有者和訪問的輸出埠

• 資料使用條款和條件

• 提供的資料屬性的架構和語義

• 質量屬性，例如新鮮度和行數

• 服務級別目標，例如可用性和支援時間

• 使用資料的賬單詳細資訊

雖然資料合約代表了介面規範，但提供資料的實際實現是資料產品的輸出埠。

當不同團隊或組織單位之間交換資料時，資料合約就會發揮作用。首先，也是最重要的，資料合約是一種溝通工具，用於表達對如何構建和解釋資料的共同理解。它們使語義和質量期望變得明確。在後期的開發和生產中，它們還充當程式碼生成、測試、模式驗證、質量檢查、監控、訪問控制和計算治理策略的基礎。資料合約還可用於消費者驅動的契約測試的輸入埠，以驗證資料是否按指定提供。

資料合約規範定義了YAML格式來描述所提供資料集的使用條款和屬性。

3.聯邦治理

聯合治理組通常組織為一個行會，由參與資料網格的所有團隊的代表組成。他們就全球政策達成一致，這是資料網格中的遊戲規則。這些規則定義了領域團隊如何構建他們的資料產品。

互操作性政策是起點。它們允許其他領域團隊以一致的方式使用資料產品。例如，全域性策略可以定義提供資料的標準方式是作為AWSS3上相應域團隊擁有的儲存桶中的CSV檔案。

接下來，必須有某種形式的文件來發現和理解可用的資料產品。一個簡單的策略可以是帶有一組預定義後設資料的wiki頁面，例如資料產品的所有者、位置URL和CSV欄位的描述。

以安全的方式訪問實際資料產品的統一方法可以是在AWSIAM中使用由域團隊管理的基於角色的訪問。

隱私和合規性等全球政策也很常見。考慮保護個人身份資訊(PII)或特定行業的法律要求。

4.資料抽取

領域團隊如何將其運營資料提取到資料平臺中?根據領域驅動設計原則設計的軟體系統包含作為可變實體/聚合和不可變領域事件的資料。

領域事件非常適合納入資料平臺，因為它們代表相關的業務事實。如果存在訊息傳遞系統，則可以透過附加額外的訊息使用者將域事件轉發到資料平臺。資料可以實時採集、處理並轉發到資料平臺。透過這種流式攝取，資料在到達時會小批次傳送，因此可以立即用於分析。由於域事件已經被明確定義，因此除了PII資料的重複資料刪除和匿名化之外，在清理和預處理方面幾乎沒有什麼可做的。有時，還建議定義和攝取包含僅與分析用例相關的資訊的內部分析事件，以便不必修改域事件。

許多業務物件作為實體和聚合儲存在SQL或NoSQL資料庫中。它們的狀態隨著時間的推移而變化，最新的狀態僅保留在資料庫中。具有狀態的實體的有力候選者是物品、價格、客戶資料或運輸狀態。對於分析用例，通常需要擁有最新狀態和一段時間內的狀態歷史記錄。有多種方法可以攝取實體。一種方法是每次實體更改時生成併發布具有當前狀態的onCreate/onUpdate/onDelete事件或實體監聽器。然後可以使用流式攝取來攝取資料，如上所述。當無法更改操作軟體時，可以使用變更資料捕獲(CDC)直接監聽資料庫更改並將其流式傳輸到資料平臺。最後，可以設定傳統的計劃ELT或ETL作業，將資料匯出到檔案並將其載入到平臺中，其缺點是沒有實時資料，匯出之間沒有所有階段更改，並且需要一些合併匯出資料的工作再次。然而，它們對於大型機等遺留系統來說是一個可行的選擇。

5.資料轉換

深入研究資料產品中的資料組織，我們可以看到流經不同階段的不同型別的資料。運算元據通常作為某種原始和非結構化資料被攝取。

在預處理步驟中，原始資料被清理並結構化為事件和實體。事件較小、不可變且高度面向領域，例如OrderPurchased或ShipmentDelivered。實體代表業務物件，例如狀態隨時間變化的貨物或物品。這就是為什麼實體通常表示為快照列表、歷史記錄，最新快照是當前狀態。

在實踐中，我們經常看到手動輸入或匯入的資料。例如，透過電子郵件以CSV檔案形式傳送的預測資料或業務程式碼的文字描述。

來自其他團隊的資料被整合為外部資料。當使用來自其他管理良好的團隊的資料產品時，這種整合可能會以非常輕量級的方式實現。在從遺留系統匯入資料的情況下，外部區域充當輔助加強層。

聚合資料來回答分析問題。領域資料可以透過定義資料合約釋出給其他團隊。資料合約通常由一個檢視實現，即使底層資料模型發生變化，該檢視也是穩定的。

6.資料清潔

乾淨的資料是有效資料分析的基礎。透過資料網格，領域團隊負責執行資料清理。他們瞭解自己的領域，並且可以確定需要處理其領域資料的原因和方式。

引入資料平臺的資料通常以其原始的原始和非結構化格式匯入。使用列式資料庫時，這可能是每個事件的一行包含CLOB事件負載欄位，可以是JSON格式。現在可以對其進行預處理以使資料乾淨：

• 結構化：將非結構化和半結構化資料轉換為分析資料模型，例如，透過將JSON欄位提取到列中。

• 減輕結構變化：當資料結構發生變化時，可以減輕結構變化，例如用合理的預設值填充空值。

• 重複資料刪除：由於大多數分析儲存系統都是僅附加的，因此無法更新實體和事件。刪除所有重複條目。

• 完整性：確保資料包含商定的時間段，即使在攝取過程中出現技術問題也是如此。

• 修復異常值：識別並糾正可能因錯誤而出現的無效資料。

從實現的角度來看，這些預處理步驟可以實現為投影原始資料的簡單SQL檢視。可以透過公共表表示式來組織查詢(CTE)並可以透過使用者定義的函式進行增強(UDF)，例如用於JSON處理。作為替代方案，清理步驟可以實現為對主題進行操作的lambda函式。可以使用dbt等框架構建更復雜的管道，但也需要掌握更多技能。

7.資料分析

為了獲得洞察力，領域團隊查詢、處理和聚合他們的分析資料以及來自其他領域的相關資料產品。

SQL是大多數分析查詢的基礎。它提供了強大的功能來連線和調查資料。資料平臺應該有效地執行連線操作，即使對於大型資料集也是如此。聚合用於對資料進行分組，視窗函式有助於跨多行執行計算。筆記本有助於構建和記錄探索性發現。

當人類透過視覺感知資料、趨勢和異常時，會更容易理解它們。有許多出色的資料視覺化工具可以構建漂亮的圖表、關鍵績效指標概述、儀表板和報告。它們提供易於使用的UI來深入、過濾和聚合資料。例如：Looker、Tableau、Metabase、Redash。

為了獲得更高階的見解，可以應用資料科學和機器學習方法。這些支援相關性分析、預測模型和其他高階用例。需要特殊的方法、統計和技術技能。例如：scikit-learn、PyTorch、TensorFlow。

8.資料平臺

每個組織的資料平臺可能有所不同。資料網格是一個新領域，供應商開始在其現有產品中新增資料網格功能。

從所需的能力來看，可以區分分析能力和資料產品能力：分析能力使領域團隊能夠構建分析資料模型並執行資料驅動決策的分析。資料平臺需要以自助服務的形式獲取、儲存、查詢和視覺化資料的功能。典型的資料倉儲和資料湖解決方案，無論是本地還是雲提供商，都已經存在。主要區別在於每個領域團隊都有自己的隔離區域。

更先進的資料網格資料平臺還提供額外的與領域無關的資料產品功能，用於建立、監控、發現和訪問資料產品。自助資料平臺應該支援領域團隊，以便他們能夠快速構建資料產品並在其隔離區域的生產中執行它。該平臺應該支援領域團隊釋出他們的資料產品，以便其他團隊可以發現它們。這一發現需要所有去中心化資料產品的中心入口點。資料目錄可以透過不同的方式實現：作為wiki、git儲存庫，甚至已經有基於雲的資料目錄的供應商解決方案，例如SelectStar、Google資料目錄或AWSGlue資料目錄。然而，資料產品的實際使用需要領域團隊訪問、整合和查詢其他領域的資料產品。平臺應支援、監控和記錄資料產品的跨域訪問和使用。

更先進的資料平臺支援策略自動化。這意味著，不是強迫域團隊手動確保不違反全域性策略，而是透過平臺自動執行策略。例如，所有資料產品在資料目錄中具有相同的後設資料結構，或者在資料攝取期間自動刪除PII資料。

有效地組合來自多個域的資料產品，即在幾秒鐘內進行大型跨域連線操作，確保了開發人員的接受度和滿意度。這就是為什麼查詢引擎對資料平臺的架構有很大的影響。具有單一查詢語言並支援獨立區域的共享平臺是一個很好的起點，因為一切都高度整合。這可能是GoogleBigQuery，其中包含多個專案中的表，可透過GoogleDataCatalog發現這些表。在更加分散和分散式的資料網格中，諸如Presto之類的分散式查詢引擎仍然可以在不匯入資料的情況下執行跨域聯接，但它們有其自身的侷限性，例如有限的下推要求需要傳輸所有底層列資料。

四 資料網格示例

當團隊使用其他領域的資料產品時，就會出現網格。使用來自上游域的資料可以簡化資料引用和查詢(例如獲取文章的價格)，而來自下游域的資料可以分析效果，例如A/B測試(例如轉化率的變化)。來自多個其他領域的資料可以聚合以構建全面的報告和新的資料產品。

讓我們看一個簡化的電子商務示例：

域可以根據資料特徵和資料產品用途進行分類。我們採用ZhamakDehghani的分類：

1.源對齊

在此示例中，線上商店沿著客戶旅程細分為多個域，從產品搜尋到結賬再到支付。在資料網格中，這些域將其資料作為資料產品釋出，以便其他人可以訪問它們。工程師對自己的資料進行分析，以改進他們的作業系統並驗證新功能的商業價值。他們使用域鄰居的資料來簡化查詢並深入瞭解下游域的影響。這些領域資料可以稱為源對齊的，因為它們釋出的大多數資料產品與其作業系統中生成的領域事件和實體密切對應。

2.聚合的

對於複雜的子系統，團隊只專注於交付由其他領域的各種資料產品聚合而成的資料產品，這可能是高效的。一個典型的例子是360°客戶檢視，其中包括來自多個領域的相關資料，例如帳戶資料、訂單、發貨、發票、退貨、帳戶餘額和內部評級。對於不同的有界上下文，全面的360°客戶檢視很難構建，但它可能對許多其他領域有用。複雜子系統的另一個例子是構建需要增強資料科學技能的複雜機器學習模型。明智的做法是，資料科學家團隊使用結賬資料和360°客戶檢視來開發和訓練推薦模型，而另一個團隊則使用該模型並專注於在線上商店或促銷電子郵件中呈現計算出的推薦。

3.消費者導向

在公司中，還有一些業務部門需要來自整個價值流的資料來做出明智的決策，這些部門的人員是業務專家，但不是工程師或技術專家。管理和控制需要來自所有領域的詳細報告和KPI來識別優勢和偏差。營銷人員使用自己的最佳化工具(例如GoogleAnalytics或AdobeAnalytics)對客戶旅程中的所有步驟進行漏斗和網路分析。在這些領域中，資料模型針對特定部門的需求進行了最佳化，因此可以被描述為消費者一致的。與消費者保持一致的報告通常是中央資料團隊的主要任務之一。透過資料網格，面向消費者的領域團隊專注於滿足某一特定業務領域的資料需求，使他們能夠獲得深入的領域知識並不斷開發更好的分析結果。透過構建整合的領域團隊或透過工程團隊為業務提供領域資料即服務(例如支援C級或控制)，業務和IT的聯絡更加緊密。他們的資料通常用於分析和報告，但不需要作為其他領域的資料產品進行釋出和管理。

五 域團隊的建設過程

正如資料團隊還有一段旅程要繼續一樣，每個領域團隊也必須繼續一段旅程，成為資料網格的貢獻者。每個團隊都可以在準備好時按照自己的節奏開始他們的旅程。好處已經在旅途中顯現出來。團隊將很快從第一個資料驅動的決策中獲益，開始大量使用更多、更好的資料來獲得更深入的見解。資料網格隨著每個將資料作為產品共享的團隊而發展，從而實現資料驅動的創新。

為了使這一過程取得成功，團隊需要三件事：高層管理人員清晰的資料網格願景，讓每個人都朝著同一個方向前進;支援性環境，包括易於使用的自助資料平臺，讓工程團隊能夠繼續工作資料分析的學習路徑，以及以自己的方式和步調行走旅程的高度信任環境。

1.0級沒有資料分析

您的團隊負責一個領域並構建和運營獨立的系統包括必要的基礎設施。構建這些系統需要付出相當大的努力，而且高度關注卓越的交付。這些作業系統現在生成域資料。

資料分析根本不相關。

2.1級運算元據庫查詢

在生產中，您可能必須調查事件並需要分析有多少客戶受到影響。此外，一些利益相關者可能對您的資料有疑問，例如“哪些庫存商品在過去六個月內尚未售出?”或“上一個黑色週期間的運輸時間是多少?”要回答所有這些問題，您可以向運算元據庫傳送分析查詢。隨著時間的推移，您還可以進行一些初步的探索性分析，以更深入地瞭解系統的行為。

這會增加生產資料庫的負載，並且您可能會想要更改生產資料庫以更好地支援分析查詢，例如建立其他索引。您可以將額外的負載解除安裝到只讀副本。但分析查詢的編寫仍然緩慢且繁瑣。

3.2級分析自己的資料

考慮到分析查詢緩慢且難以編寫的痛苦，您嘗試了資料平臺團隊正在推廣的自助資料平臺。例如，您現在可以訪問GoogleBigQuery。在此平臺上，您的團隊開始透過從Kafka獲取訊息來構建分析資料模型。這是您的第一個資料產品。該資料平臺允許您透過可維護且快速的查詢來分析覆蓋您自己系統的資料，同時保持運算元據庫的架構不變。您將學習如何構建、預處理、清理、分析和視覺化分析資料，儘管其中大部分是您已經熟悉的SQL，但需要學習的內容還有很多。

由於現在可以快速回答有關您自己的資料的問題，您和您的產品負責人現在進入了制定資料驅動決策的週期：定義假設並用資料進行驗證。

4.3級分析跨域資料

分析您自己的領域資料是一個很好的開始，但將其與其他領域的資料相結合才是神奇的開始。儘管資料分散，但它可以讓您獲得全面的檢視。例如，針對UI更改對轉化率的影響進行A/B測試，或者構建用於欺詐檢測的機器學習模型，其中包括之前的購買歷史記錄和當前的點選流行為。這要求其他團隊以您的團隊可以發現、訪問和使用的方式共享他們的資料產品。這是網格開始自行形成的時候。

當團隊成為資料網格的消費成員時，它開始對資料網格的互操作性和治理產生興趣。理想情況下，團隊將向資料網格治理小組派遣一名代表。

如果您是第一個團隊，您可能必須暫時跳過此步驟並進入第4級併成為第一個為其他人提供資料的人。

5.4級釋出資料合約

根據其他團隊的需求，您可以透過釋出資料合約的方式與其他團隊共享您的資料。例如，您提供已確認、已拒絕和已中止的訂單，以便其他人可以將其事件與轉化率相關聯。您不再只是資料產品的消費者，而是資料產品的釋出者。您為其他團隊創造價值。但同時，從長遠來看，它會增加您的責任和運營職責。

釋出的資料產品必須符合聯合治理組定義的全域性策略。你必須瞭解並理解當前的全球政策。現在，您最遲需要參與聯邦治理小組併為其做出貢獻。

六 資料團隊的建設過程

資料網格主要是一種組織結構，並且完全符合團隊拓撲的原則。它將資料的職責轉移給由資料平臺團隊和資料支援團隊支援的領域團隊。所有團隊的代表聚集在一個聯合治理小組中來定義共同標準。

如今，在許多組織中，中央資料團隊負責廣泛的分析任務，從資料工程和管理資料基礎設施到建立C級報告。這樣的中央資料團隊會遭受認知超載，包括領域、技術和系統知識。資料網格緩解了這一點。

資料網格為中央資料團隊成員提供了新的視角，因為他們的分析和資料工程技能仍然非常必要。例如，它們非常適合為喜歡在基礎設施上工作的人們建立資料平臺。他們中的一些人可以組建一個資料支援團隊作為內部顧問，幫助領域團隊完成他們的旅程。無論他們的新角色如何，他們中的許多人都將在資料網格聯合治理組中再次聚會，共同塑造資料網格的未來。

然而，真正的思維轉變發生在建立新的以資料為中心的領域時，如上圖所示。讓我們看一下大型中央資料團隊通常基於整體資料倉儲或資料湖生成的典型管理報告。透過資料網格，建立這些管理報告的資料工程師與專門的產品負責人一起構建了一個新的領域團隊。作為新領域團隊的工程師，他們現在可以專注於新領域和消費者。這使他們能夠隨著時間的推移獲得深入的領域知識，從而產生更好的報告和持續最佳化。此外，他們從使用單一資料倉儲轉向使用其他領域的資料產品。這種轉變是由資料產品需求驅動的漸進過程，加速了資料網格的形成。產品負責人與其他領域團隊就所需的資料產品進行協商，並確保新領域團隊將來構建的報告和其他產品能夠滿足業務需求。

隨著現有領域團隊在其旅程中進行越來越多的資料分析，中央資料團隊成員的另一個觀點是加入其中一個團隊。憑藉現有知識，他們可以向團隊中的其他人傳播和教授他們的知識和技能，從而加速領域團隊邁向資料網格的旅程。重要的是，他們要成為團隊的正式成員，而不是在領域團隊內建立資料子團隊。除了他們的知識和技能之外，資料工程師還可以將中央資料團隊的職責和工件帶到他們的領域團隊中。例如，以前由中央資料團隊完成的客戶分析將由推薦領域團隊負責。

資料科學家通常也是集中組織的。這就是為什麼他們的未來在組織方面與中央資料團隊的未來非常相似。他們關注的資料網格中的資料產品是機器學習功能和模型。當加入現有的領域團隊時，這樣的機器學習模型可能會完全整合到微服務中。因此，資料網格能夠實現此類基於機器學習的服務，因為所需的MLOps功能可以方便地構建在資料網格之上。