資料網格的架構和功能

Last reviewed 2024-09-03 UTC

資料網格是一種架構和組織架構，將資料視為產品 (在本文中稱為「資料產品」)。在這個架構中，資料產品是由最瞭解該資料的團隊開發，並遵循全組織的資料治理標準。將資料產品部署至資料網格後，組織中的分散式團隊就能更快速、更有效率地探索及存取符合需求的資料。如要建構完善的資料網格，您必須先建立本文所述的高階架構元件和組織角色。

本文件是一系列文章的一部分，說明如何在 Google Cloud上實作資料網格。本指南假設您已閱讀並熟悉「使用 Google Cloud建構現代化分散式資料網格」一文所述的概念。

本系列包含下列部分：

• 資料網格的架構與功能 (本文件)
• 為資料網格設計自助式資料平台
• 在資料網格中建構資料產品
• 在資料網格中探索及使用資料產品

在本系列中，所述的資料網格是組織內部。雖然可以擴充資料網格架構，向第三方提供資料產品，但這種擴充方法不在本文討論範圍內。擴充資料網格時，除了組織內的使用情形外，還需要考量其他因素。

架構

下列重要詞彙用於定義本系列文章所述的架構元件：

• 資料產品：資料產品是邏輯容器，或一或多項相關資料資源的分組。
• 資料資源：資料資源是儲存系統中的實體資產，用於保存結構化資料，或儲存會產生結構化資料的查詢。
• 資料屬性：資料屬性是資料資源的欄位或元素。

下圖概略說明在 Google Cloud上實作的資料網格中，有哪些重要架構元件。

上圖顯示下列內容：

• 中央服務可建立及管理資料產品，包括影響資料網格參與者的組織政策、存取控管 (透過 Identity and Access Management 群組)，以及基礎架構專屬構件。如需這類承諾和預留項目的範例，以及有助於資料網格運作的基礎架構，請參閱「建立平台元件和解決方案」。
• 中央服務會使用 Knowledge Catalog，為資料網格中的所有資料產品提供 Data Catalog，並為這些產品的潛在消費者提供探索機制。
• 資料網域會透過定義明確的資料使用介面，將資料子集公開為資料產品。這些資料產品可以是資料表、檢視表、結構化檔案、主題或串流。在 BigQuery 中，這會是資料集；在 Cloud Storage 中，這會是資料夾或 bucket。可做為資料產品公開的介面有不同類型。介面的例子包括 BigQuery 資料表上的 BigQuery 檢視表。如要瞭解最常用於分析用途的介面類型，請參閱「在資料網格中建構資料產品」。

資料網格參考導入

您可以在 data-mesh-demo 存放區中找到這個架構的參考實作。參考實作中使用的 Terraform 指令碼會示範資料網格概念，不適用於正式環境。執行這些指令碼後，您將瞭解如何執行下列操作：

• 將產品定義與基礎資料分開。
• 建立 Data Catalog 範本，用於描述產品介面。
• 使用這些範本標記產品介面。
• 將權限授予產品用戶。

對於產品介面，參考實作會建立並使用下列介面類型：

• BigQuery 資料表的授權檢視表。
• 以 Pub/Sub 主題為基礎的資料串流。

詳情請參閱存放區中的 README 檔案。

資料網格中的函式

如要讓資料網格順利運作，您必須為在資料網格中執行工作的人員定義明確的角色。擁有權會指派給團隊原型或職能。這些函式包含資料網格工作人員的核心使用者歷程。為了清楚描述使用者歷程，我們已將其指派給使用者角色。這些使用者角色可以根據各企業的情況進行拆分和組合。您不需要直接將角色對應至組織中的員工或團隊。

資料網域與企業內的業務單位 (BU) 或職能部門一致。常見的業務領域包括銀行的房貸部門，或是企業的客戶、配銷、財務或人力資源部門。從概念上來說，資料網格中有兩個與網域相關的函式：資料產生者團隊和資料消費者團隊。請務必瞭解，單一資料網域可能同時提供這兩種功能。資料領域團隊會根據擁有的資料產生資料產品。該團隊也會使用資料產品取得業務洞察，並產生衍生資料產品供其他網域使用。

除了網域型功能外，資料網格也有一組由組織內集中式團隊執行的功能。這些中央團隊提供跨網域監督、服務和管理，讓資料網格得以運作。這些團隊可減輕資料網域在產生及使用資料產品時的營運負擔，並促進資料網格運作所需的跨網域關係。

本文僅說明具有資料網格專屬角色的函式。無論平台採用何種架構，任何企業都需要其他幾個角色。不過，這些其他角色不在本文討論範圍內。

資料網格的四項主要功能如下：

• 以資料領域為基礎的產品團隊： 建立及維護資料產品的生命週期。這些團隊通常稱為「資料產生者」。
• 資料網域型消費者團隊：探索資料產品，並用於各種數據分析應用程式。這些團隊可能會使用資料產品來建立新的資料產品。這些團隊通常稱為「資料消費者」。
• 中央資料治理團隊：定義並強制執行資料產生者的資料治理政策，確保資料品質和資料可信度。這個團隊通常稱為資料治理團隊。
• 中央自助式資料基礎架構平台團隊：為資料產生者提供自助式資料平台。這個團隊也提供工具，用於集中探索資料和觀測資料產品，供資料消費者和資料產生者使用。這個團隊通常稱為資料平台團隊。

另一個可考慮的額外功能是資料網格的卓越中心 (COE)。COE 的目的是管理資料網格。COE 也是指定的仲裁團隊，負責解決其他職能部門提出的任何衝突。這項功能有助於連結其他四項功能。

以資料網域為基礎的產品團隊

資料產品通常建構在實體資料存放區 (單一或多個資料倉儲、資料湖泊或串流) 之上。組織需要傳統資料平台角色，才能建立及維護這些實體存放區。不過，這些傳統資料平台角色通常不是建立資料產品的人員。

如要從這些實體存放區建立資料產品，組織需要資料工程師和資料架構師等資料從業人員。下表列出資料產生者團隊中所需的所有網域專屬使用者角色。

角色	責任	必備技能	理想結果
資料產品擁有者	擔任資料產品的主要業務聯絡窗口。 負責定義、政策、業務決策，以及將業務規則套用至以產品形式公開的資料。 負責解答業務問題。因此，擁有者在與資料消費者團隊或集中式團隊 (資料治理和資料基礎架構平台) 會面時，代表資料網域。	資料分析 資料架構 產品管理	資料產品為消費者帶來價值。資料產品的生命週期管理機制相當完善，包括決定何時停用產品或發布新版本。 通用資料元素與其他資料網域之間有協調機制。
資料產品技術主管	擔任產品的主要技術聯絡窗口。 負責實作及發布產品介面。 技術問題的聯絡窗口。因此，負責人與資料消費者團隊或集中式團隊 (資料治理和資料基礎架構平台) 會面時，代表資料網域。 與資料治理團隊合作，在組織中定義及實作資料網格標準。 與資料平台團隊合作，根據資料產生和使用過程中的技術需求，協助開發平台。	資料工程 資料架構 軟體工程	資料產品符合業務需求，並遵循資料網格技術標準。 資料取用端團隊會使用資料產品，且該產品會顯示在資料產品探索體驗產生的結果中。 可分析資料產品的使用情形 (例如每日查詢次數)。
資料產品支援	擔任正式環境支援的聯絡窗口。 負責維護產品服務水準協議 (SLA)。	軟體工程 網站可靠性工程 (SRE)	資料產品符合規定的服務水準協議。 資料消費者對資料產品使用方式的疑問，都能獲得解答和解決。
資料領域的主題內容專家 (SME)	與其他資料網域的中小企業會面時，代表資料網域，建立整個組織通用的資料元素定義和界線。 協助網域內的新資料產生者定義產品範圍。	資料分析 資料架構	與其他資料領域的中小企業合作，建立並維護對組織資料和所用資料模型的全面瞭解。 有助於建立可互通的資料產品，符合組織的整體資料模型。 資料產品建立和生命週期管理有明確標準。 資料網域中的資料產品可提供業務價值。
資料擁有者	負責某個內容領域。 負責確保資料品質和準確性。 核准存取要求。 協助撰寫資料產品說明文件。	任何技能，但必須充分瞭解業務功能。 任何技能，但必須充分瞭解資料的意義和相關業務規則。 任何技能，但必須能判斷資料品質問題的最佳解決方案。	跨職能領域使用的資料準確無誤。 利害關係人瞭解資料。 資料使用方式符合使用政策。

以資料網域為基礎的使用者團隊

在資料網格中，使用資料產品的人員通常是資料產品網域以外的資料使用者。這些資料消費者會使用中央 Data Catalog，尋找符合需求的資料產品。由於可能有多項資料產品符合需求，資料消費者最終可能會訂閱多項資料產品。

如果資料消費者找不到符合用途的資料產品，則有責任直接諮詢資料網格 COE。在諮詢期間，資料消費者可以提出資料需求，並尋求建議，瞭解如何透過一或多個網域滿足這些需求。

資料消費者尋找資料產品時，會尋找能協助他們達成各種用途的資料，例如永久分析資訊主頁和報表、個別成效報表，以及其他業務成效指標。或者，資料消費者可能正在尋找可用於人工智慧 (AI) 和機器學習 (ML) 用途的資料產品。為實現這些不同的用途，資料消費者需要結合多種資料從業人員角色，如下所示：

角色	責任	必備技能	理想結果
資料分析師	搜尋、識別、評估及訂閱單一網域或跨網域資料產品，為商業智慧架構的運作奠定基礎。	數據分析工程 商業數據分析	提供乾淨、經過整理和匯總的資料集，供資料視覺化專家使用。 制定資料產品使用最佳做法。 匯總及整理跨網域資料集，滿足網域的分析需求。
應用程式開發人員	開發應用程式架構，用於取用網域內外一或多項資料產品的資料。	應用程式開發 資料工程	建立、提供及維護應用程式，這些應用程式會使用一或多項資料產品的資料。 建立資料應用程式供使用者使用。
資料視覺化專家	將資料工程和資料分析術語，轉譯為業務利害關係人能理解的資訊。 定義從資料產品填入業務報表的程序。 建立及監控說明策略性業務目標的報表。 與組織內的工程師合作，設計從已使用的資料產品匯總而成的資料集。 導入報表解決方案。 將高階業務需求轉化為技術需求。	需求分析 資料視覺化	為使用者提供有效、準確的資料集和報表。 透過開發的資訊主頁和報表，滿足業務需求。
資料科學家	搜尋、識別、評估及訂閱資料科學用途的資料產品。 從多個資料網域擷取資料產品和中繼資料。 訓練預測模型並部署，以最佳化領域業務程序。 針對多個資料領域，提供可能適用的資料管理和資料註解技術意見回饋。	機器學習工程 數據分析工程	建立預測性和規範性模型，將業務程序最佳化。 及時完成模型訓練和部署。

中央資料治理團隊

資料治理團隊可讓資料產生者和消費者以自助方式安全地共用、匯總及運算資料，不會為組織帶來法規遵循風險。

為符合組織的法規遵循要求，資料治理團隊由多種資料從業人員角色組成，如下所示：

角色	責任	必備技能	理想結果
資料治理專員	提供監督機制，並協調法規遵循的單一檢視畫面。 建議在整個網格中實施資料收集、資料保護和資料保留的隱私權政策。 確保資料監管員瞭解政策並能存取政策。 視需要提供最新資料隱私權法規的資訊和諮詢服務。 視需要提供安全性問題的相關資訊和諮詢。 執行內部稽核，並定期分享風險和控管計畫報告。	法律領域專家 資安領域專家 資料隱私領域專家	政策中的隱私權法規為最新版本。 資料產生者會及時收到政策異動通知。 管理階層會定期收到及時報告，瞭解所有已發布資料產品的政策遵循情況。
資料管理員 (位於各網域內)	將資料治理專家制定的政策編碼。 定義及更新組織使用的分類，以便使用探索和隱私權相關中繼資料，為資料產品、資料資源和資料屬性加上註解。 與各自領域內外的各種利害關係人協調。 確保其網域中的資料產品符合組織的中繼資料標準和隱私權政策。 指導資料治理工程師如何設計資料平台功能，以及排定優先順序。	資料架構 資料監管	已為網域中的所有資料產品建立必要的中繼資料，且網域的資料產品說明準確。 自助式資料基礎架構平台團隊正在建構合適的工具，自動為資料產品加上中繼資料註解、建立及驗證政策。
資料治理工程師	開發可自動產生資料註解的工具，並可供所有資料網域使用，然後使用這些註解強制執行政策。 實作監控機制，檢查註解的一致性，並在發現問題時發出警示。 透過快訊、報表和資訊主頁，確保組織員工瞭解資料產品的狀態。	軟體工程	系統會自動驗證資料治理註解。 資料產品符合資料治理政策。 及時偵測資料產品違規情形。

中央自助式資料基礎架構平台團隊

自助式資料基礎架構平台團隊 (或資料平台團隊) 負責建立一組資料基礎架構元件。分散式資料網域團隊會使用這些元件，建構及部署資料產品。資料平台團隊也會推廣最佳做法，並介紹工具和方法，協助分散式團隊在採用新技術時，減輕認知負荷。

平台基礎架構應能輕鬆與作業工具整合，以便進行全球觀測、檢測和法規遵循自動化。或者，基礎架構應能促進這類整合，讓分散式團隊順利運作。

資料平台團隊與分散式網域團隊和基礎架構團隊，採用共同責任模式。這個模型會顯示平台使用者應承擔的責任，以及資料平台團隊支援的平台元件。

由於資料平台本身是內部產品，因此不支援所有用途。而是根據優先順序藍圖，持續發布新服務和功能。

資料平台團隊可能已有一組標準組合元件，且正在開發中。不過，如果團隊的需求與資料平台提供的需求不一致，資料網域團隊可能會選擇使用不同的專屬元件。如果資料網域團隊選擇其他方法，則必須確保建構及維護的任何平台基礎架構，都符合全組織的安全性和資料治理政策與防護措施。對於中央資料平台團隊以外開發的資料平台基礎架構，資料平台團隊可以選擇共同投資，或將自己的工程師嵌入網域團隊。資料平台團隊是否選擇共同投資或嵌入工程師，可能取決於資料網域平台基礎架構對組織的策略重要性。組織只要持續參與資料領域團隊的基礎架構開發作業，就能提供必要的協調和技術專業知識，重新封裝開發中的任何新平台基礎架構元件，以便日後重複使用。

如果您的初始目標是取得利害關係人的核准，以便擴充資料網格，則在建構資料網格的早期階段，可能需要限制自主權。不過，限制自主權可能會導致中央資料平台團隊成為瓶頸。這個瓶頸可能會阻礙資料網格擴充。因此，任何集中化決策都應謹慎考量。對資料產生者來說，從有限的可用選項中做出技術選擇，可能比自行評估並從無限的選項清單中選擇更合適。提升資料產生者的自主性，並不等於建立不受控管的技術環境。而是要在選擇自由和標準化之間取得適當平衡，藉此提高法規遵循和平台採用率。

最後，優秀的資料平台團隊是公司其他部門的主要教育和最佳做法來源。建議核心資料平台團隊採取的幾項最有效活動如下：

• 定期審查新功能專案的架構設計，並向開發團隊提出通用的開發方式。
• 分享知識和經驗，並共同定義最佳做法和架構指南。
• 確保工程師有合適的工具，可驗證及檢查常見問題，例如程式碼問題、錯誤和效能降低。
• 舉辦內部黑客松，讓開發團隊提出內部工具需求。

中央資料平台團隊的角色和職責範例可能包括：

角色	責任	必備技能	理想結果
資料平台產品擁有者	建立資料基礎架構和解決方案的生態系統，讓分散式團隊能建構資料產品。降低技術門檻、確保治理機制內建，並盡可能減少資料基礎架構的集體技術債。 與領導階層、資料網域擁有者、資料治理團隊和技術平台擁有者合作，制定資料平台的策略和藍圖。	資料策略與作業 產品管理 利害關係人管理	建立成功的資料產品生態系統。 正式環境中有大量資料產品。 縮短資料產品發布的最簡可行產品時間和正式版時間。 提供一般基礎架構和元件組合，可滿足資料產生者和資料取用者最常見的需求。 資料產生者和資料消費者對這項服務的滿意度很高。
資料平台工程師	透過範本、可部署的架構藍圖、開發人員指南和其他說明文件，建立可重複使用且自助式的資料基礎架構和解決方案，用於資料擷取、儲存、處理和使用。此外，也會建立 Terraform 範本、資料管道範本、容器範本和自動化調度管理工具。 開發及維護中央資料服務和架構，將跨功能問題的程序標準化，例如資料共用、管道自動化調度管理、記錄和監控、資料治理、持續整合和持續部署 (CI/CD) (內建防護機制)、安全性和法規遵循報告，以及 FinOps 報告。	資料工程 軟體工程	資料產生者可使用標準化、可重複使用的基礎架構元件和解決方案，進行資料擷取、儲存、處理、管理和共用，並提供必要說明文件。 元件、解決方案和使用者說明文件的發布時程，都與藍圖一致。 使用者回報顧客滿意度很高。 資料網格中的所有函式都有強大的共用服務。 共用服務的正常運作時間很長。 支援團隊的回覆時間很短。
平台和資安工程師 (中央 IT 團隊 (例如網路和資安團隊) 的代表，隸屬於資料平台團隊)	確保資料平台抽象化與企業級技術架構和決策一致。 在核心團隊中建構資料平台交付所需的技術解決方案和服務，支援工程活動。	基礎架構工程 軟體工程	平台基礎架構元件是專為資料平台開發。 元件、解決方案和使用者說明文件的發布時程，都與藍圖一致。 中央資料平台工程師回報的顧客滿意度很高。 資料平台使用的元件 (例如記錄) 可提升基礎架構平台的健康狀態。 基礎技術元件的運作時間長。 資料平台工程師遇到問題時，支援團隊會快速回覆。
企業架構師	根據企業級技術和資料策略，調整資料網格和資料平台架構。 提供資料平台和資料產品架構的諮詢、設計授權和保證，確保符合企業級策略和最佳做法。	資料架構 解決方案疊代和問題解決 建立共識	建立成功的生態系統，其中包含大量資料產品，可縮短建立最簡可行產品及將這些產品發布至正式環境的時間。 已為重要資料歷程建立架構標準，例如建立中繼資料管理和資料共用架構的通用標準。

資料網格的其他注意事項

數據分析資料平台有多種架構選項，每個選項都有不同的必要條件。如要啟用各個資料網格架構，建議貴組織遵循本節所述的最佳做法。

取得平台資金

如網誌文章「If you want to transform start with finance」(如要轉型，請從財務開始) 所述，平台永遠不會完成：平台一律會根據優先順序藍圖運作。因此，平台必須以產品的形式獲得資金，而不是以具有固定端點的專案形式。

資料網格的第一個採用者須承擔費用。通常，費用會由建立第一個資料網域來啟動資料網格的業務部門，以及中央技術團隊 (通常是中央資料平台團隊) 共同分擔。

如要說服財務團隊核准中央平台的資金，建議您提出商業提案，說明集中式平台隨著時間推移實現的價值。這項價值來自在個別交付團隊中重新實作相同元件。

定義資料網格的最小可行平台

為協助您定義資料網格的最低可行平台，建議您使用一或多個商業提案進行試行和疊代。在試行階段，請找出必要用途，以及準備好採用資料產品的消費者。這些用途應已獲得開發資料產品的資金，但仍需要技術團隊的投入。

請確保實施前測的團隊瞭解資料網格作業模式，如下所示：

• 業務 (即資料產生者團隊) 擁有待處理項目、支援和維護。
• 中央團隊會定義自助模式，並協助業務部門建構資料產品，但在完成後，會將資料產品交給業務部門執行及擁有。
• 主要目標是驗證業務營運模式 (網域產生、網域使用)。次要目標是驗證技術營運模式 (由中央團隊開發的自助模式)。
• 由於平台團隊資源有限，請使用主幹和分支團隊模式匯集知識，但仍允許開發專門的平台服務和產品。

此外，建議您採取下列做法：

• 規劃藍圖，而非任由服務和功能自然發展。
• 定義最低可行平台功能，涵蓋擷取、儲存、處理、分析和機器學習。
• 將資料治理融入每個步驟，而非視為獨立的工作流程。
• 在管理、平台、價值流和變更管理方面，建立最低限度的能力。最低功能是指能滿足 80% 商業提案的功能。

規劃資料網格與現有資料平台共存

許多想導入資料網格的組織，可能已有現成的資料平台，例如資料湖泊、資料倉儲，或兩者兼具。在導入資料網格之前，這些組織必須制定計畫，瞭解現有資料平台如何隨著資料網格成長而演進。

這類組織應考量下列因素：

• 在資料網格上最有效的資料資源。
• 必須保留在現有資料平台中的資產。
• 資產是否必須移動，或是否可以保留在現有平台上，並仍參與資料網格。

後續步驟

• 如要進一步瞭解如何設計及操作雲端拓撲，請參閱「Google Cloud Well-Architected Framework」。
• 如要查看更多參考架構、圖表和最佳做法，請瀏覽 Cloud Architecture Center。