資料網格中的架構和功能

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

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

本系列包含以下部分：

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

本系列文章所述的資料網格屬於機構內部。雖然可以擴充資料網格架構，向第三方提供資料產品，但這種擴充做法不在本文討論範圍內。擴充資料網格時，除了機構內的使用情況，還需要考慮其他因素。

架構

以下是定義本系列文章所述架構元件的關鍵字詞：

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

下圖概述在 Google Cloud上實作資料網格時的主要架構元件。

上圖顯示下列項目：

• 中央服務可建立及管理資料產品，包括影響資料網格參與者的機構政策、存取控制項 (透過身分與存取權管理群組)，以及基礎架構專屬構件。如要瞭解這類承諾和預訂的範例，以及有助於資料網格運作的基礎架構，請參閱「建立平台元件和解決方案」。
• 中央服務主要會為資料網格中的所有資料產品提供 Data Catalog，並為這些產品的潛在客戶提供探索機制。
• 資料網域會透過定義完善的資料使用介面，將資料子集公開為資料產品。這些資料產品可以是表格、檢視區塊、結構化檔案、主題或串流。在 BigQuery 中，這會是資料集；在 Cloud Storage 中，這會是資料夾或值區。可做為資料產品公開的介面類型有很多，介面範例：BigQuery 資料表上的 BigQuery 檢視區塊。在資料網格中建構資料產品一文，將討論最常用於分析目的的介面類型。

資料網格參考實作

如需這項架構的參考實作方式，請參閱data-mesh-demo存放區。參考實作中使用的 Terraform 指令碼會展示資料網格概念，不適用於實際工作環境。執行這些指令碼後，您將瞭解如何執行下列操作：

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

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

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

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

資料網格中的職務

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

資料網域與企業的業務單位 (BU) 或功能一致。常見的業務領域範例包括銀行中的抵押部門，或是企業的客戶、發行、財務或人資部門。從概念上來說，資料網格中有兩個與網域相關的函式：資料生產者團隊和資料消費者團隊。請務必瞭解，單一資料網域可能同時提供這兩項功能。資料網域團隊會製作自有資料的資料產品。該團隊也使用資料產品來取得業務洞察，並為其他領域製作衍生資料產品。

除了以網域為基礎的函式外，資料網格也有一組函式，由機構內的集中式團隊執行。這些中央團隊提供跨網域的監督、服務和管理，確保資料網格正常運作。可減輕資料網域在產生及使用資料產品時的作業負擔，並促進資料網格運作所需的跨網域關係。

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

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

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

您也可以考慮為資料網格設立卓越中心 (COE)。COE 的目的是管理資料網格。COE 也是指定的仲裁團隊，負責解決其他職能提出的任何衝突。這項函式有助於連結其他四項函式。

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

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

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

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

以資料網域為基礎的消費者團隊

在資料網格中，資料產品的消費者通常是資料使用者，他們不屬於資料產品網域。這些資料消費者會使用中央資料目錄，尋找符合需求的資料產品。因為可能有多個資料產品符合需求，資料消費者最終可能會訂閱多個資料產品。

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

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

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

中央資料管理團隊

資料管理團隊可讓資料生產者和消費者以自助式方式安全地分享、匯總及運算資料，同時避免機構面臨法規遵循風險。

為符合機構的法規遵循規定，資料治理團隊由多種資料實務人員角色組成，包括：

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

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

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

平台基礎架構應能輕鬆整合作業工具，以實現全球可觀測性、儀表化和法規遵循自動化。或者，基礎架構應促進這類整合，協助分散式團隊邁向成功。

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

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

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

如果初期目標是取得利益相關者的核准，以擴大資料網格，您可能需要在建構資料網格的初期階段限制自主性。不過，限制自主性可能會導致中央資料平台團隊出現瓶頸。這個瓶頸可能會阻礙資料網格擴展。因此，任何集中化決策都應謹慎做出。對資料生產者而言，從有限的可用選項中做出技術選擇，可能比自行評估和選擇無限的選項清單更合適。提升資料生產者的自主性，並不等於建立不受控管的技術環境。而是要適度兼顧選擇自由和標準化，以提高法規遵循率和平台採用率。

最後，優秀的資料平台團隊是公司其他部門的教育和最佳做法中心。我們建議中央資料平台團隊進行下列活動，以發揮最大影響力：

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

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

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

資料網格的其他注意事項

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

取得平台資金

如這篇網誌文章所述，「如要開始轉型，請先從財務著手」，這個平台永遠不會完成，而是會根據優先順序路線圖持續運作。因此，平台必須以產品的形式獲得資金，而非以有固定終點的專案形式。

資料網格的初期採用者須承擔相關費用。通常，成本會由建立第一個資料網域以啟動資料網格的商家，以及中央技術團隊 (通常是中央資料平台團隊的所在地) 分攤。

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

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

為協助您定義資料網格的最低可行平台，建議您先試用一或多個業務案例，然後反覆測試。在試用階段，請找出所需用途，以及有消費者願意採用產生的資料產品。用例應已獲得開發資料產品的資金，但需要技術團隊提供意見。

請確保負責導入試用版的團隊瞭解資料網格作業模式，如下所示：

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

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

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

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

許多想導入資料網格的機構可能已有現有資料平台，例如資料湖、資料倉儲，或兩者兼具。實作資料網格前，這些機構必須先規劃現有資料平台如何隨著資料網格成長而演進。

這些機構應考量下列因素：

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

後續步驟

• 如要進一步瞭解如何設計及運作雲端拓撲，請參閱 Google Cloud Well-Architected Framework。
• 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。