資料網格原則和邏輯架構

資料的巨大鴻溝

我們真正指的是什麼資料？答案取決於您詢問的對象。當今的環境可分為營運資料和分析資料。營運資料位於微服務提供的業務功能後方的資料庫中，具有交易性質，保留目前狀態，並滿足執行業務的應用程式需求。分析資料是隨著時間推移對業務事實的暫時且彙總的檢視，通常建模為提供回顧性或前瞻性見解；它訓練機器學習模型或提供分析報告。

目前的技術、架構和組織設計狀態反映了這兩個資料平面分歧 - 兩個存在層級，既整合又分離。這種分歧導致架構脆弱。不斷失敗的 ETL（萃取、轉換、載入）作業和資料管線迷宮日益增長的複雜性，對於嘗試連接這兩個平面的許多人來說，是一個熟悉的光景，將資料從營運資料平面傳輸到分析平面，再傳輸回營運平面。

圖 1：資料的巨大鴻溝

分析資料平面本身已分歧為兩個主要的架構和技術堆疊：資料湖和資料倉儲；資料湖支援資料科學存取模式，而資料倉儲支援分析和商業智慧報告存取模式。對於這段對話，我暫且擱置這兩個技術堆疊之間的競爭：資料倉儲嘗試納入資料科學工作流程，而資料湖嘗試服務資料分析師和商業智慧。有關資料網格的原始撰寫探討了現有分析資料平面架構的挑戰。

圖 2：分析資料的進一步分歧 - 倉儲

圖 3：分析資料的進一步細分 - 湖泊

資料網格辨識並尊重這兩個平面之間的差異：資料的性質與拓撲、不同的使用案例、資料使用者的個別角色，以及最終他們多樣化的存取模式。然而，它嘗試在不同的結構下連接這兩個平面 - 一個以網域為基礎而非技術堆疊的反向模型和拓撲 - 重點放在分析資料平面上。管理這兩種資料原型所使用的現今技術的差異，不應導致從事這些資料的組織、團隊和人員分開。在我看來，營運和交易資料技術與拓撲相對成熟，而且主要由微服務架構驅動；資料隱藏在每個微服務的內部，透過微服務的 API 控制和存取。的確有創新的空間可以真正達成多雲原生營運資料庫解決方案，但從架構觀點來看，它符合業務需求。然而，管理和存取分析資料仍然是規模化的摩擦點。這是資料網格的重點所在。

我確實相信，在未來的某個時間點，我們的技術將演進以讓這兩個平面更緊密結合，但就目前而言，我建議我們將它們的考量分開。

網域擁有權

資料網格的核心建立在分散化和責任分配給最接近資料的人員，以支援持續變更和可擴充性。問題是，我們如何分解和分散資料生態系統的組成部分及其所有權。此處的組成部分由分析資料、其元資料，以及提供服務所需的運算組成。

資料網格遵循組織單位的接縫作為分解軸。我們今日的組織是根據其業務領域進行分解。這種分解在很大程度上將持續變更和演進的影響局限於領域的受限脈絡。因此，使業務領域的受限脈絡成為資料所有權分配的良好候選者。

在本文中，我將繼續使用與原始撰寫相同的用例，「數位媒體公司」。可以想像，媒體公司根據「播客」等領域將其營運（因此是支援營運的系統和團隊）進行區分，團隊和系統管理播客發布及其主機；「藝術家」，管理登入和付費藝術家的團隊和系統，依此類推。資料網格主張分析資料的所有權和提供應尊重這些領域。例如，管理「播客」的團隊在提供用於發布播客的 API 時，也應負責提供隨著時間推移表示「已發布播客」的歷史資料，以及其他事實，例如隨著時間推移的「收聽率」。如需深入了解此原則，請參閱面向領域的資料分解和所有權。

邏輯架構：以網域為導向的資料和運算

為了促進這種分解，我們需要建構一個根據領域排列分析資料的架構。在此架構中，領域與組織其他部分的介面不僅包括營運功能，還包括存取領域提供的分析資料。例如，「播客」領域提供用於「建立新的播客集數」的營運 API，但也提供用於擷取「過去 <n> 個月的所有播客集數資料」的分析資料終端點。這表示架構必須移除任何摩擦或耦合，讓領域提供其分析資料並發布計算資料的程式碼，獨立於其他領域。為了擴充，架構必須支援領域團隊在發布和部署其營運或分析資料系統方面的自主性。

以下範例說明了面向領域的資料所有權原則。這些圖表僅為邏輯表示和範例。它們並非旨在完整無缺。

每個領域可以公開一個或多個營運 API，以及一個或多個分析資料終端點

圖 4：符號：領域、其分析資料和營運功能

自然地，每個領域可以依賴其他領域的營運和分析資料終端點。在以下範例中，「播客」領域使用「使用者」領域的「使用者更新」分析資料，以便它可以透過其「播客聽眾人口統計」資料集提供播客聽眾人口統計的圖像。

圖 5：範例：除了營運能力外，分析資料的領域導向所有權

注意：在範例中，我使用命令式語言存取營運資料或能力，例如「支付藝術家」。這只是為了強調存取營運資料與分析資料的用意之間的差異。我確實認知到，在實務上，營運 API 是透過更具宣告性的介面實作的，例如存取 RESTful 資源或 GraphQL 查詢。

資料作為產品

現有分析資料架構的挑戰之一是發現、理解、信任並最終使用品質資料的摩擦和成本很高。如果不解決這個問題，隨著提供資料（領域）的地點和團隊數量增加，這個問題只會隨著資料網格而惡化。這將會是我們第一個分散原則的後果。資料即產品原則旨在解決資料品質和長久以來的資料孤島問題；或者正如 Gartner 所稱的暗資料 -「組織在一般業務活動期間收集、處理和儲存的資訊資產，但通常無法用於其他用途」。領域提供的分析資料必須視為產品，而該資料的使用者應視為客戶 - 快樂且滿意的客戶。

原始文章列舉了一系列能力，包括可發現性、安全性、可探索性、可理解性、可信賴性等，資料網格實作應支援這些能力，才能將領域資料視為產品。它也詳細說明了組織必須引進的角色，例如領域資料產品負責人，負責確保資料以產品形式提供的客觀衡量標準。這些衡量標準包括資料品質、縮短資料使用時間，以及透過淨推薦值的資料使用者滿意度。領域資料產品負責人必須深入了解資料使用者是誰、他們如何使用資料，以及他們習慣使用資料的原生方法是什麼。對資料使用者的這種深入了解，會產生符合其需求的資料產品介面設計。實際上，對於網格上的大多數資料產品，有少數傳統角色具有其獨特的工具和期望，資料分析師和資料科學家。所有資料產品都可以開發標準化介面來支援他們。資料使用者和產品負責人之間的對話，是建立資料產品介面的必要部分。

每個領域都將包含資料產品開發人員角色，負責建立、維護和提供領域的資料產品。資料產品開發人員將與領域中的其他開發人員合作。每個領域團隊可以提供一個或多個資料產品。也可以組成新的團隊來提供資料產品，這些產品無法自然地融入現有的營運領域。

注意：與過去的範例相比，這是一個顛倒的責任模型。資料品質的責任轉移到上游，盡可能接近資料來源。

邏輯架構：資料產品的架構量子

在架構上，為了支援資料作為一個產品，讓網域可以自主提供或使用，資料網格引入了資料產品的概念，作為其架構量子。架構量子，正如演化式架構所定義的，是架構中最小的單位，可以獨立部署，具有高度的功能內聚性，並包含其功能所需的所有結構元素。

資料產品是網格中的節點，它封裝了其功能所需的三個結構組成部分，提供對網域分析資料的存取權，作為一個產品。

• 程式碼：它包括 (a) 負責使用、轉換和提供上游資料的資料管線程式碼 - 從網域作業系統或上游資料產品接收的資料；(b) 提供對資料、語意和語法架構、可觀察性指標和其他元資料的存取權的 API 程式碼；(c) 執行特徵的程式碼，例如存取控制政策、合規性、來源等。
• 資料和元資料：嗯，這就是我們都在這裡的原因，以多語形式存在的基礎分析和歷史資料。根據網域資料的性質及其使用模式，資料可以作為事件、批次檔案、關聯式表格、圖表等提供，同時保持相同的語意。為了讓資料可用，有一組相關的元資料，包括資料運算文件、語意和語法宣告、品質指標等；內含於資料中的元資料，例如其語意定義，以及傳達運算治理用於實作預期行為的特徵的元資料，例如存取控制政策。
• 基礎架構：基礎架構組成部分能夠建置、部署和執行資料產品的程式碼，以及儲存和存取大資料和元資料。

圖 6：資料產品組成部分作為一個架構量子

以下範例建立在前一節的基礎上，展示資料產品作為架構量子。此圖表僅包含範例內容，並非旨在完整或包含所有設計和實作細節。雖然這仍然是一個邏輯表示，但它正接近物理實作。

圖 7：符號：網域、其（分析）資料產品和作業系統

圖 8：提供面向網域的分析資料的資料產品

注意：資料網格模型不同於過去的範例，其中管線（程式碼）被管理為與其產生的資料分開的獨立元件；而且基礎架構（例如倉庫或湖泊儲存帳戶的執行個體）通常在許多資料集之間共用。資料產品是所有元件（程式碼、資料和基礎架構）的組合，其粒度為網域的邊界脈絡。

自助服務資料平台

正如您所想像的，要建立、部署、執行、監控和存取一個不起眼的六邊形（資料產品），需要配置和執行相當多的基礎架構；配置此基礎架構所需的技能是專業的，而且難以在每個網域中複製。最重要的是，團隊可以自主擁有其資料產品的唯一方法是存取基礎架構的高階抽象，這可以消除配置和管理資料產品生命週期的複雜性和摩擦。這需要一個新的原則，自助服務資料基礎架構作為實現網域自主性的平台。

資料平台可以被視為已經存在的傳遞平台的延伸，用於執行和監控服務。然而，用於操作資料產品的底層技術堆疊，在今天看來與服務的傳遞平台非常不同。這只是因為大資料技術堆疊與營運平台的分歧。例如，網域團隊可能會將其服務部署為 Docker 容器，而傳遞平台使用 Kubernetes 進行其編排；然而，鄰近的資料產品可能會在其 Databricks 集群上以 Spark 工作執行其管線程式碼。這需要配置和連接兩組截然不同的基礎架構，在資料網格之前，不需要這種程度的互操作性和互連性。我個人希望我們開始看到營運和資料基礎架構的融合，這是有道理的。例如，也許在同一個編排系統上執行 Spark，例如 Kubernetes。

實際上，為了讓一般開發人員（網域現有的開發人員類型）可以存取分析資料產品開發，自助服務平台除了簡化配置之外，還需要提供一種類別的新工具和介面。自助服務資料平台必須建立支援網域資料產品開發人員工作流程的工具，以便使用現有技術假設的較少專業知識來建立、維護和執行資料產品；自助服務基礎架構必須包含降低建立資料產品所需的目前成本和專業知識的功能。原始撰寫內容包含一份 功能清單，由自助服務資料平台提供，包括存取可擴充多語言資料儲存、資料產品架構、資料管線宣告和編排、資料產品譜系、運算和資料區域性等。

邏輯架構：多平面的資料平台

自助服務平台功能屬於模型中稱為平面的多個類別或層面。注意：平面代表存在層級，整合但獨立。類似於物理和意識平面，或網路中的控制和資料平面。平面既不是層，也不表示強階層存取模型。

圖 9：符號：一個平台平面，透過自服務介面提供許多相關功能

一個自服務平台可以有多個平面，每個平面服務不同的使用者輪廓。在以下範例中，列出三個不同的資料平台平面

• 資料基礎架構提供平面：支援提供執行資料產品元件和產品網格所需的基礎架構。這包括提供分散式檔案儲存、儲存帳戶、存取控制管理系統、執行資料產品內部程式碼的協調、在資料產品圖表上提供分散式查詢引擎等。我預期其他資料平台平面或只有進階資料產品開發人員會直接使用這個介面。這是一個相當低階的資料基礎架構生命週期管理平面。
• 資料產品開發人員體驗平面：這是典型資料產品開發人員使用的主要介面。這個介面抽象化許多複雜性，這些複雜性會影響資料產品開發人員的工作流程。它提供比「提供平面」更高級別的抽象化。它使用簡單的宣告式介面來管理資料產品的生命週期。它自動實作被定義為一組標準和全球慣例的跨領域考量，套用於所有資料產品及其介面。
• 資料網格監督平面：有一組功能最適合在網格層級提供，也就是連接資料產品的圖表，而且是全球性的。雖然每個介面的實作可能會依賴於個別資料產品功能，但在網格層級提供這些功能會更方便。例如，針對特定使用案例發現資料產品的能力，最適合透過搜尋或瀏覽資料產品網格來提供；或者將多個資料產品關聯起來以建立更高階見解，最適合透過執行資料語意查詢來提供，而資料語意查詢可以在網格上的多個資料產品中執行。

以下模型僅為範例，並非意圖要完整。雖然平面的階層結構是理想的，但以下並未暗示嚴格的分層。

圖 10：自助式資料平台的多個平面 *DP 代表資料產品

聯邦運算治理

如您所見，資料網格遵循分散式系統架構；獨立資料產品的集合，具有獨立的生命週期，由可能獨立的團隊建置和部署。然而，對於大多數使用案例，若要以高階資料集、見解或機器智慧的形式獲得價值，這些獨立資料產品需要進行互操作；能夠關聯它們、建立聯集、找出交集，或對它們執行其他圖形或集合運算。為了讓這些運算成為可能，資料網格實作需要一個治理模型，該模型包含分散化和網域自我主權、透過全球標準化進行互操作、動態拓撲，最重要的是平台自動執行決策。我稱這為聯邦運算治理。由網域資料產品所有者和資料平台產品所有者組成的聯盟領導的決策制定模型，具有自主權和網域內部決策制定權，同時建立和遵守一組全球規則（套用於所有資料產品及其介面）以確保一個健全且可互操作的生態系統。該小組有一項艱難的工作：在集中化和分散化之間維持平衡；哪些決策需要針對每個網域進行在地化，哪些決策應針對所有網域進行全球制定。最終，全球決策有一個目的，透過資料產品的發現和組成，建立互操作性和複利網路效應。

資料網格中治理的優先事項不同於傳統分析資料管理系統的治理。雖然它們最終都設定為從資料中獲取價值，但傳統資料治理嘗試透過決策制定集中化，並建立資料的全球正規表示，且最少支援變更。相比之下，資料網格的聯邦運算治理接受變更和多重詮釋脈絡。

將系統置於不變的束縛衣中可能會導致脆弱性演變。

-- 生態學家 C.S. Holling

邏輯架構：嵌入在網格中的運算政策

聯邦治理模型需要一個支持性的組織結構、誘因模型和架構才能運作：在尊重在地網域的自主權，並有效實施全球政策的同時，達成互操作性的全球決策和標準。

圖 11：符號：聯邦運算治理模型

如前所述，在平台針對所有網域及其資料產品標準化、實施和強制執行的內容，以及留給網域決定的內容之間取得平衡是一門藝術。例如，網域資料模型是一個應在地化到最熟悉它的網域的考量。例如，'podcast 收聽率' 資料模型的語意和語法如何定義，必須留給 'podcast 網域' 團隊決定。然而，關於如何識別 'podcast 聽眾' 的決策是一個全球性的考量。podcast 聽眾是 '使用者' 族群的成員，其上游界定脈絡，可以跨越網域的界線，並在其他網域中找到，例如 '使用者播放串流'。統一識別允許關聯關於 '使用者'（同時是 'podcast 聽眾' 和 '串流聽眾'）的資訊。

以下是資料網格治理模型中所涉及元素的範例。這不是一個全面的範例，僅說明與全球層級相關的考量。

圖 12：聯邦運算治理元素範例：團隊、誘因、自動化實作，以及資料網格的全球標準化面向

許多預先資料網格治理的實務，作為集中式功能，不再適用於資料網格範例。例如，過去強調認證黃金資料集（已通過集中式品質控制和認證流程並標記為可信賴的資料集）作為治理的集中式功能，已不再相關。這是源於在先前的資料管理範例中，資料（無論品質和格式為何）會從作業網域的資料庫中擷取，並集中儲存在現在需要集中式團隊套用清理、協調和加密流程的倉庫或資料湖中；通常在集中式治理群組的監護下。資料網格完全分散了此疑慮。網域資料集只有在網域內部，根據預期的資料產品品質指標和全球標準化規則，經過品質保證流程後，才會成為資料產品。網域資料產品所有者最能決定如何衡量其網域的資料品質，因為他們最了解產生資料的網域作業詳細資訊。儘管有這種在地化決策和自主權，他們仍需要遵守由全球聯合治理團隊定義，並由平台自動化的品質建模和服務水準目標 (SLO) 規格，並根據全球標準制定。

下表顯示資料治理的集中式（資料湖、資料倉庫）模型與資料網格之間的對比。

預先資料網格治理面向	資料網格治理面向
集中式團隊	聯合團隊
負責資料品質	負責定義如何建模構成品質的內容
負責資料安全性	負責定義資料安全面向，例如平台要內建並自動監控的資料敏感度層級
負責遵守法規	負責定義平台要內建並自動監控的法規要求
資料的集中式監護	網域的資料聯合監護
負責全球正規資料建模	負責建模多義詞，也就是跨越多個網域邊界的資料元素
團隊獨立於網域	團隊由網域代表組成
目標為建立明確定義的靜態資料結構	目標為啟用有效的網格運作，涵蓋網格持續變動且動態的拓撲
單體式資料湖/資料倉儲所使用的集中式技術	各網域所使用的自助式平台技術
根據受控資料（表格）的數量或容量衡量成功	根據網路效應衡量成功，即網格上資料消耗所代表的連線
有人為介入的手動程序	平台所實作的自動化程序
防止錯誤	偵測錯誤並透過平台的自動化處理進行復原

原則摘要和高階邏輯架構

讓我們將所有內容彙整在一起，我們討論了資料網格的四個基本原則

這些原則會驅動一個邏輯架構模型，同時將分析資料和運作資料在同一個網域下更緊密地結合在一起，並尊重其技術差異。這些差異包括分析資料可能寄存的位置、處理運作服務與分析服務的不同運算技術、查詢和存取資料的不同方式等。

圖 13：資料網格方法的邏輯架構

我希望在這個時候，我們已經建立了一種共同語言和一個邏輯心智模型，我們可以共同使用它來詳細說明網格組成的藍圖，例如資料產品、平台和必要的標準化。