如何設計雲原生資料治理方案

來源：資料驅動智慧

一 背景

資料治理專案通常伴隨著監管壓力、高成本和不明確的投資回報。識別關鍵資料、管理後設資料、控制資料質量和確定資料來源的程式通常耗時較長且成本高昂。比如銀行業的相關年度成本很容易超過每年 1000 萬元，有時甚至超過 1 億元。執行過程既痛苦又緩慢，因為需要在數百個系統和應用程式中手動識別數千個資料元素，而這些系統和應用程式通常是在過去幾十年建立的。

也許其中最難以捉摸的是資料沿襲。一些供應商已經設法建立可以掃描系統和收集後設資料的工具，但它們通常無法連線到大多數現有系統環境。由於資料流通常沒有在整個企業中進行結構性和一致的記錄，因此主要依靠供應商知識和手動對映工作來編譯它們。當供應商紛紛離開時，這種知識就會離開企業，情況也會變得更加嚴重。

此外，即使業務和技術後設資料已被記錄為協調補救計劃的一部分，但由於後設資料捕獲和記錄不是自動化的，大多數後設資料很快就會過時。保持其最新需要持續的手動工作。

最後，組織將這些後設資料共享到企業的業務部門，以實現除資料治理本身之外的業務目的。許多大型組織都有資料戰略，以某種形式闡明資料管理基礎也應該為資料科學等業務目的提供支援，但很少有人在實踐中成功實現這一點。

基於雲的技術的出現帶來了可擴充套件性、彈性、更低的成本、快速部署和增強的資料技術相容性的承諾。在過去幾年中，我們與各種組織就其雲遷移和資料現代化計劃進行了合作，從設計的那一刻起就出現瞭如何智慧管理資料的模式。

例如，可以為 API 定義互操作標準，以便未來資料沿襲視覺化中的日誌記錄和治理實現自動化。資料質量控制可以基於一致的資料模型建立並直接嵌入到新的基礎設施中。轉換期間存在的知識不會丟失或降級，因為有關資料元素及其來源的關鍵資訊會輕鬆記錄在資料目錄中。

接下來將進一步詳細闡述資料治理設計的概念，並解釋如何透過資料資產、資料管理中心和 API 驅動架構等功能（透過稱為 Data Fabric 的資料層）實現資料治理。

二 框架

在基於服務的架構中，微服務連線組織的業務流程。在這樣的架構中，四個基礎元件可以共同實現資料管理和資料治理的設計。下面提供了一個示例：描述了一個擁有 5 個部門（風險與合規、財務、營銷、客戶管理和產品開發）的組織。每個部門建立並維護多個資料產品，其中一部分被歸類為“資料資產”，因為其他部門的消費者也使用它們。不同部門之間，各種API交換資料和資訊。所有這一切都是根據資料基礎結構精心策劃的，並由資料管理中心掃描並提供資料管理和服務。讓我們快速瀏覽一下這些元件。

資料資產——每個域或部門通常都會生成供其他域使用的資料或資訊。例如，客戶管理域可以透過入職和客戶關係管理流程收集客戶資料，以生成和維護包含客戶資訊的中央資料庫。營銷團隊可以使用該資料庫來執行銷售活動，風險部門可以使用該資料庫來確認是否遵守資料隱私法規。此類資料產品被賦予了不同的標籤，其中包括資料產品、資料資產、可信來源、權威資料來源和記錄系統。

API 驅動的架構——不同的團隊透過 API 作為首選或唯一的資料整合方法進行連線。保持 API 優先的理念可確保組織內部和外部的消費者都可以使用任何關鍵資料。

資料管理中心——在單獨配置的空間或環境中提供一組資料管理功能。這些功能包括後設資料管理、主資料和參考資料管理以及資料質量。不必在組織的每個區域內構建這些功能，而是可以從中央資料管理進行部署。

Data Fabric— 提供跨所有系統和應用程式連線的執行緒稱為 Data Fabric。它不是一個可以憑空例項化的魔法層；相反，它由一組支援功能和經過仔細考慮的治理協議組成，這些協議共同使整個企業的資料可發現、編目、分類、標記、質量控制，並可透過通用的互操作性標準和渠道進行訪問。

採用資料資產理念管理

什麼是資料資產

資料資產是一組準備好的資料（一般不是原始資料），可供更廣泛的消費者使用。它受到管理、貼上標籤、質量受控且易於訪問。它是可發現和描述的，以便為整個企業的消費者啟用自助服務。資料資產通常在整個企業中重複使用，並在給定的資料或業務域內擁有。

為什麼被高度關注

鑑於資料資產被大量消費者使用，因此這是實施資料質量和治理控制的非常合乎邏輯的位置。在該受管資產中，內容被標記，資料質量受到嚴格控制，因此不必在整個企業中識別和測量這些資料，這通常會導致不一致的“事實版本”，而是有一個可信的分發點給定的資料集。例如，美國十大銀行已經啟動了一些計劃來識別這些關鍵資料來源並對其進行管理。通常，大約 20 到 100 個資料資產將使組織能夠控制其所有關鍵資料，這比嘗試在 1000 個單獨系統中定義資料質量要有效得多。

資料資產採用

建立和定義資料資產還不夠。一個必要且同樣重要的步驟是管理它們的使用，因為如果消費者不使用它們，他們就無法從集中控制的資料質量中受益。因此，許多組織已經啟動了各種版本的資料資產採用計劃。通常，一方面包括共享流通，加強培育對資料資產及其使用好處的認識，另一方面包括合規標準和機制，要求只能從資料資產而不是任何地方使用別的資料。

業務使用者和影響

對於資料組織來說，除了難以衡量的價值（例如避免監管罰款）之外，闡明它們為企業增加的價值一直是一場歷史性的鬥爭。資料資產在這裡改變了遊戲規則。僅當存在下游關鍵消耗時，資料來源才能成為資料資產，因此建議記錄這些消費者及其用例。

構建資料資產和依賴於它們的用例的簡單概述可以清楚地闡明這些資產產生的影響。透過收集資料的下游需求並評估如何在受信任的分發點內控制和增強資料，也可以更有效地執行影響評估。例如，一家領先的保險公司能夠相對精確地衡量一組增強的客戶資料如何使他們能夠更輕鬆地執行和提高銷售活動的有效性。

如果沒有資料資產的識別和主動管理，結果通常是難以理解的資料流“蜘蛛網”，存在資料重複和不一致的情況。戰略性地使用資料資產，可以識別使用獨特的可重複使用的精選的資料來源用例組。

三 資料資產治理

需要一個治理模型來將資料資產嵌入到 Data Fabric 中，以確保它不會被“壞”資料淹沒，其中“資料網格”是如何將此治理嵌入到組織中的主要方法。

資料網格

一個相對較新的術語是“資料網格”，它是一種使業務領域能夠在捕獲和維護資料的點管理其關鍵資料的方法，並由中央自助服務資料支援基礎設施。這與過去的努力形成鮮明對比，過去的組織試圖將其關鍵資料集中在資料湖和資料倉儲中。這種集中化工作通常會受到對中央資料團隊的過度期望的困擾，這些團隊沒有特定於業務的上下文來理解資料，因此無法跟上消費者所需的步伐。“髒”資料湖是一種常見症狀。

治理模式

某些業務或功能域可能已準備好立即管理其關鍵資料資產，但其他域可能還沒有。以銀行業為例，通常相對成熟的領域包括風險和金融，因為它們在遵守監管資料治理準則方面擁有多年的經驗。

允許域所有者生成資料資產供其他人使用有幾個要求。首先，支援領域必須在資料管理和工程方面具備最低水平的所需技能和經驗。其次，域所有者必須在團隊內部或外部擁有所需的資源，或委派部分職責的預算。維護資料資產通常不是一項全職工作，但同時它確實意味著重大責任。

基於這些考慮，企業可以選擇適合的治理模式，每種治理模式都有各自的優點和缺點。組織可以先選擇一種模式，但隨著時間的推移，可以發展到另一種模式。

治理建議

以下建議可以標準化任何模式的實施並降低其風險：

• 將資料資產的概念嵌入到企業變革方法中

• 制定並遵守一系列設計原則，其中包括資料資產的治理

• 堅持資料資產必須直接源自經確認的權威來源的設計原則

• 定義具有清晰描述的領域的權威企業資料模型

• 維護資料資產的中央目錄

• 堅持使用最少的所需後設資料集，包括分類和其他與安全相關的後設資料，以實現基於角色的訪問

• 定義並執行可發現性和互操作標準

四 API 驅動的架構和互操作性標準

採用 API 優先的理念以及明確定義的互操作性標準是確保未來資料流的治理和控制以及驅動自動資料沿襲捕獲、避免未來大量手動對映工作的關鍵。

API驅動架構

在 API 優先的基礎架構中，不同的團隊透過 API 作為首選或唯一的資料整合方法進行連線。保持 API 優先的理念可確保組織內部和外部的消費者都可以使用任何關鍵資料。如果做得正確，還應該推動對開放銀行標準等全球標準的遵守，從而為與戰略合作伙伴合作提供機會。

互操作標準

互操作標準由一組規則和協議組成，用於驅動不同系統和應用程式之間的互動和資料交換。如果我們用電來類比，您可以購買任何型別的電器，從冰箱到電燈或手機充電器，並且通常期望您可以將其連線到家中的插座。資料也類似——希望確保資料透過標準插座以商定的質量和數量提供，這些插座可供任何有權訪問房屋內不同房間的人使用。對於企業來說，就需要就介面型別以及向其提供資料的渠道達成一致。

沒有一套互操作標準適合每個組織，但有幾個維度或元件至關重要：

• 遵守資料模型以確保資料的使用和解釋的一致性，至少對於最小的一組關鍵資料而言如此

• 標準訊息傳遞和有效負載格式

• 與系統和應用程式一起以標準化格式識別、維護和提供的最低業務和技術後設資料

• 一組已確定的相容技術

互操作工具集

擁有一套一致的互操作標準應該推動任何型別的相容技術能夠與基礎設施交換資料。出於採用目的，建議確定至少 1 種也可能是幾種資料工程師可用於各自目的的 API 技術。

選擇哪種技術取決於組織、目標業務成果以及現有的技術堆疊和相應的專業知識。比如，一家區域零售組織決定採用 MuleSoft 作為其數字組織構建的首選 API 平臺，而一家大型領先製造商則選擇建立自己的內部構建的 API 功能。

透過 API 實現資料沿襲工業化

對於組織而言，存在巨大的機會來確保透過採用 API 優先的思維方式將資料管理納入未來基礎設施的設計中：

1. 可以定義 API 模式來滿足未來對資料和資訊流的需求。示例模式包括非同步、同步、編排和資料處理以及事件驅動模式。

2. 在各種模式中，對齊與 API 一起提供的後設資料指令碼或檔案。這些指令碼應該標準化，幷包含最少的業務和技術後設資料集，例如源、目的地、提要頻率、包含的關鍵資料元素以及一系列指標（例如分類、PII 指標）。最佳實踐是，每次更新 API 時，這些後設資料檔案都會更新（如果可能，自動更新），並在 API 目錄中維護。

3. 確保將 API 後設資料檔案推送或拉入後設資料管理中。工具到位特別是資料目錄，以便可以建立譜系圖。

將驅動 API 作為系統間資料交換的主要手段與堅持最低標準相結合，推動“資料沿襲設計”。

注意：不要使後設資料檔案過於複雜。較小的關鍵後設資料集優於業務價值不明確的詳盡集。除了例外之外，預設情況下不需要包含詳細的資料元素級採購和轉換邏輯。

五 資料管理中心

與實施後手動執行的治理活動相比，集中配置但本地採用的資料管理功能以更低的成本增強了資料的一致定義、治理和保護。

資料管理中心的重要性

為了透過設計推動資料管理，建立並提供一個單獨配置的管理中心並使其包含最低限度所需的資料功能至關重要。管理中心包含資料管理，應作為未來任何雲原生業務或功能流程構建的一部分來引用和嵌入的功能。他們應該能夠從資料中自助服務這些功能，而不是讓每個轉換計劃或業務功能區域在如何確保正確使用主資料、管理後設資料和監控資料質量方面重新構建功能和標準。

資料管理需要設計

歷史上，絕大多數傳統資料管理投資都是在“事後”（即實施後）花費的。發現業務流程，識別資料元素，推斷業務需求，並根據現有基礎設施實施來衡量資料質量，這需要大量的人工工作和持續的紀律。

在這裡的方法中，這些資料管理注意事項嵌入在設計和實施階段之前和期間。此外，稍後手動執行的治理步驟將作為功能、非功能和技術需求整合為設計的一部分。隨著解決方案的實施，資料管理是“按設計”構建的。

“設計”功能示例

資料目錄 -正如上面針對 API 所概述的，但應用更廣泛，就應用程式及其之間的資料流而言的系統全面的發現、文件和視覺化可以自動化。

資料質量——監控和確保資料質量和完整性的控制可以透過兩種主要方式嵌入。首先，可以在資料建立、捕獲和傳輸時應用特定的控制和限制。比如對接受或有效值的限制以及資料流中的協調檢查。其次，在資料資產等戰略位置，可以對靜態資料實施質量控制，以衡量完整性、準確性和及時性。

主資料和參考資料——資料資產的非常具體的示例，主資料和參考資料是非常強大的槓桿，可以推動在事務級別重複使用的資料的一致使用。比如MDM以確保在整個企業中，在入職、交易、客戶聯絡、營銷和關係管理等流程中使用正確的客戶資料元素。同樣，提供易於訪問的參考資料（例如郵政地址標準）將推動其採用。

六 Data Fabric 作為系統之間的雲原生粘合劑

提供跨所有系統和應用程式連線的執行緒稱為資料結構。它不是一個可以憑空例項化的魔法層；相反，它由一組支援功能和經過仔細考慮的治理協議組成，這些協議共同使整個企業的資訊可發現、編目、分類、標記、質量控制，並可透過通用的互操作性標準和渠道進行訪問。

在很大程度上，該結構是由前面描述的資料資產、API 和資料管理中心元件啟用的。如果正確並充分地使用，它們應該形成資料結構的主要架構。但是，即使不是最低要求，也有一些互補的資料功能：

資料管道、攝取、準備、傳輸、供應和儲存——在 API 無法完成工作的情況下，替代或補充的資料交付和整合選項可以確保根據業務或業務來收集、攝取、轉換、管理和提供資料。功能要求。需要配置儲存來儲存資料。

資料編排——根據目標用例和業務流程，可以應用資料編排來從各種來源獲取資料，組合和整合資料，並將其提供給資料分析工具。資料編排可以在 IaaS 或 PaaS 級別執行，也可以使用抽象基礎設施級別活動的技術（例如 Apache Airflow、Prefect 和 Snowflake）來執行。

資料安全和保護——監控和確保敏感資料不丟失、不被濫用或被未經授權的使用者訪問的過程，並啟用主動保護資料資產的功能。政策和標準應規定如何保護資料以及如何共享資料。身份和訪問管理 (IAM) 可以促進基於角色的訪問，各種網路和身份驗證保護措施可以保護資料免遭未經授權的訪問和操縱。

報告、分析和資料科學——可以建立一個或多個資料平臺來滿足報告或分析用例。具有資料資產、API 和資料管理。資料管理中心到位後，這將成為一項簡單的工作，因為資料可用、易於理解且易於獲取，並且在雲原生環境中，可以按需啟用相應的報告或資料科學工具，而無需大量的前期投資。

七 成功因素

讓我們以一些關於成功因素的想法來結束本文。取得成功的組織通常首先關注幾個選定的領域，從一開始就吸引業務利益相關者，確保將遵守法規和政策方面的好處與業務成果一起考慮，並堅持雲優先的設計原則。

1. 從小規模開始——從組織相對良好的領域中的 1 或 2 個資料資產開始，其中物料、客戶和產品資料通常是強有力的候選者。在較小的規模上取得成功並利用聚集的動力來推動其他領域吸取的經驗教訓的實施會更容易。

2. 業務參與——從一開始就包括業務代表。價值創造取決於它們的採用和消費，這就是為什麼確保將相關要求納入資料資產和資料結構中至關重要，包括需要什麼資料以及如何訪問資料。

3. 效益整合——擁有強大成功案例的組織通常能夠將歷史資料治理職責與更具前瞻性的資料科學相關用例結合起來，清楚地闡明強大的資料基礎將如何為整個企業的利益相關者服務。如果資料管理，投資回報更有說服力。透過設計推動法規遵從性以及以業務為導向、洞察力驅動的用例。

4. 雲優先——堅持雲原生設計可以防止供應商壁壘，並允許進行無風險、無缺失的實驗，避免高額前期投資，並能夠“快速修復”，在出現問題時進行擴充套件成功。