有效的數據治理是指通過設計嵌入到數據流程中的數據質量、完整性和安全控制等的應用。這與傳統數據治理模式形成鮮明對比，傳統數據治理工作在實施后花費了大量精力來發現數據系統、構建數據沿襲以及實施數據質量和完整性控制。在實踐中如何運作呢？

一個簡單的例子

讓我們舉一個我在實踐中多次看到的簡單例子：

有一個客戶創建流程，其中收集并創建某些客戶數據以創建新的客戶檔案。該數據被發送到存儲客戶數據的系統中。基于該中央系統中的數據，存在三個使用該數據的下游系統。首先，有一個產品開放系統，客戶開始消費所提供的一些產品和服務。其次，有一個營銷系統來宣傳新的、額外的產品和服務。第三，有一個客戶管理系統，如果客戶致電提出疑問或問題，呼叫中心的代理可以訪問客戶信息。

傳統的數據治理方法

在傳統方法中，將這些數據系統和流程納入治理可能是一項艱巨的任務。我們必須確定流程和關鍵數據，定義需求，然后開始設計控制措施以確保數據確實得到充分管理。

對于示例中的 5 個過程中的每一個，我們都可以識別所涉及的關鍵數據。然后我們可以識別它們之間的數據流并創建數據沿襲。數據沿襲的一種常見方法是從下游的數據開始，明確數據流，返回上游。然后，我們從中央數據平臺獲取數據，將其提取到數據質量工具中，并測量數據質量。我們還從消費流程中獲取數據，再次測量數據質量，并將其與集中存儲的客戶數據進行比較以確保一致性。

這種方法面臨許多挑戰。眾所周知，記錄數據沿襲非常困難且耗時。將數據質量納入數據質量工具的成本非常高，因為這相當于有效地復制數據。衡量系統之間和跨系統的一致性很困難，因為系統可能來自不同的技術和供應商，具有不同的預構建模式和元數據實踐，并且可能是相隔數年構建的。需要理解數據轉換并將其嵌入到數據質量規則中。

適當的數據訪問和使用很難證明，因為數據流沒有集中跟蹤，并且它們使用不同的模式。通過大量的手動工作，相應的系統和應用程序所有者（如果存在）可能可以解釋數據訪問過程，但這取決于他們的個人理解和本地保存（并且很少維護）的文檔，因此這種數據治理模式具有很大的挑戰性。

那么我們怎樣才能做得更好——更加智能、可擴展且面向未來

（1）數據采集控制

讓我們從數據捕獲開始，自上而下地處理所述的流程。對于客戶創建流程，定義收集和創建的關鍵數據元素，并花時間明確記錄每個數據元素的要求。現在掌握了要求，返回創建功能并實施控制措施，以防止首先創建不準確和不完整的數據。此步驟極其關鍵 — 預防數據問題的成本效益至少比稍后在下游修復問題的成本效益高 10 倍。

有許多簡單但功能強大的選項來實現數據捕獲控件。可以嵌入控件以確保進度停止，直到完成必填字段。下拉菜單非常適合郵政編碼或國家/地區等標準化字段。如果給定數據元素沒有有限的有效值集，請考慮在接受格式之前如何檢查格式。有效性或一致性規則可以掃描非法字符、不可能的重復字符或意外的數據長度。人工智能也可以發揮作用，例如將數據與公共和第三方數據或從掃描圖像檢索的數據進行比較。無需完全停止該過程，而是可以向創建功能模塊發送彈出窗口以確認數據的準確性，如果需要，可以覆蓋該彈出窗口。

一些數據捕獲控制可以是基于流程的，而不是由技術驅動的。以一家健康診所為例，我們發現多達 40% 的患者電話號碼不準確。審查并澄清了數據采集職責，并實施了簡單的流程變更。當創建患者病例時，前臺人員現在會要求他們驗證電話號碼，這實際上消除了數據質量問題。

（2）源頭數據質量

客戶數據幾乎對任何組織都至關重要。在我們的示例中，我們定義了 3 個消費系統，但在現實生活中通常有數十個使用該數據的系統。因此，客戶數據的存儲應作為“數據產品”在戰略位置進行管理。無論此數據產品是通過 CRM、MDM、CDP 還是其他類型的解決方案啟用，都建議在源頭控制數據質量。

也就是說，無論數據存儲在何處，都應將其質量作為標準、持續的實踐進行衡量和發布。該解決方案應該內置數據質量控制。按照冷凍食品存儲控制的類比，您想知道在任何時間存儲了哪些食物以及存儲溫度。如果溫度升高超過某個閾值，您會想立即知道- 而不是想等待每月更新的儀表板。冰箱至少應該配備集成溫度控制裝置，可以顯示溫度并在超出閾值時發出警報。如果可以避免的話，您不想在事后手動構建這些東西。

根據所涉及的解決方案技術，可以考慮許多選項。所有領先的數據平臺都允許應用標準和規則。適用于數據捕獲點的類似規則和要求（例如，與郵政編碼格式的有效性相關）也可以在數據源處強制執行。許多平臺可以根據可用元數據自動計算表中包含的數據的數據質量指標。同樣，數據質量檢查可以輕松嵌入到現有的攝取和整合作業中，以便過濾掉、拒絕、修復和/或安排數據管理員審查包含可能不正確數據的記錄。

并不總是需要創建數據質量規則并執行它們。如果嵌入了數據質量控制來保證數據以給定格式到達并且之后不會被損壞（例如，因為值必須繼續匹配一組參考數據），那么數據質量指標可能會變得多余。這一切都是為了確保數據完整性，但如何做到這一點取決于您。

（3）數據訪問控制

客戶數據應受到保護，以確保只有具有適當權限的人員和流程才能訪問它。與基于角色的訪問控制相關的最佳實踐是眾所周知的并且已記錄在案，因此無需深入研究。

然而，從數據治理的角度來看，僅僅引用訪問控制是不夠的。特別是對于云原生應用程序，建議實現不可變的、自動生成的訪問和審核日志。每當訪問數據時，都會在日志中創建一個條目，該條目指定誰或什么獲得了訪問權限以及基于什么憑據。這些日志可以存儲在相對冷的倉庫中，以最大限度地降低成本。

在源頭，可以對數據進行屏蔽或模糊處理，以確保通過適當配置的數據訪問流程，人員和流程只能根據他們擁有的權限訪問他們真正需要的數據。

上述所有控件的共同點是它們都是內置的、可擴展的且靈活的。當建立系統、應用程序和集成時，它們非常容易實現。之后，如果數據量或使用量激增，或者添加新角色，也不會影響控制的有效性。

（4）可發現的數據流

為了創建和實現數據流，無論數據流的技術或性質、大小和頻率如何，都需要定義一些事情：數據來自哪里，在傳輸過程中對數據做了什么，以及它被發送到哪里。任何經驗豐富的數據治理專家都知道為已經存在一段時間的系統和應用程序構建數據沿襲的恐怖故事。然而，在創建時，當數據工程師仍在設計他們的管道時，通過稍微調整它們來確保這些流可以通過設計發現是相對簡單的工作。

跨數據流模式，為與流本身一起提供的元數據腳本或文件定義模板。這些腳本應該標準化，并包含最少的業務和技術元數據集，例如源、目的地、頻率、包含的關鍵數據元素以及一系列指標（例如分類、PII 指標）。最佳實踐是每次更新數據流時都會更新這些元數據文件（如果可能的話，自動更新）并在目錄中維護。然后，確保將這些元數據文件推送或拉入元數據管理工具（例如數據目錄）、譜系圖可以自動創建。

遵循上述準則并堅持互操作性標準，可以推動“通過設計實現數據沿襲”。

（5）數據變更控制

我們示例中的下游系統 - 產品開放、營銷和呼叫中心客戶管理，全部使用來自中央客戶數據存儲平臺的數據。我們需要確保實際上使用了正確、準確的數據。我們不需要重新衡量數據質量，唯一需要控制的是數據與我們的權威來源一致。如果那里的數據不準確或丟失，那么應該在那里檢測并解決問題——而不是下游。那么我們如何保證這種一致性呢？

一種簡單的方法是在客戶數據平臺中構建直接接口。例如對于呼叫中心運營來說，這是非常可行的。如果代理需要審查或編輯客戶數據，則可以直接與源連接來完成此操作，從而保證數據質量在傳輸過程中不會受到損壞。

出于營銷目的，例如推動向特定目標客戶的郵政地址發送定制信件的活動，這可能不可行。在這種情況下，數據協調檢查是首選解決方案。數據協調是描述數據傳輸期間驗證階段的術語，其中將目標數據與原始源數據進行比較，以確保數據已正確傳輸。

我并不是說要提出任何新的建議——對賬控制已經存在了幾十年。我的意思是，應該將特定的數據標準嵌入到變更方法中，該方法要求實施控制以確保關鍵數據與源同步，以便在處于設計階段時自動且強制地考慮這一點將創建或更改數據流的任何類型的轉換。確保將其直接嵌入到數據流中，而不是痛苦地創建全新的腳本來提取數據并將其與原始源數據進行比較。

很久以前，我負責一家銀行抵押貸款信用風險模型的回測過程。我的一個腳本每月運行一次，以檢查信用風險模型的性能。這是一個復雜的腳本——要收集所有客戶及其金融產品的數據，以及長達 48 個月的交易數據，超過 2500 行代碼用于連接到源系統，將交易映射到產品，將產品映射到客戶，并構建各種統計模型來計算違約概率、違約風險和違約損失。當腳本啟動時，需要一個小時才能完成（當時還沒有進入可擴展的云處理時代），因此在此過程中停下來檢查中間結果并不容易。

我內置了各種類型的對帳檢查，如果出現問題，它們會向我發出警報。例如，在代碼中的不同點，我會添加一行代碼來計算給定子集的客戶或交易數量，并將其直接與相同的總和進行比較，通過不同的邏輯，我可以直接從源數據重新計算。大多數情況下，警報不會響起。但有一天，盡管腳本的執行看似沒有錯誤，但對賬檢查顯示有幾條記錄存在差異。隨后的分析表明，一些新客戶端的記錄在傳輸中被丟棄，因為我正在使用的處理引擎無法讀取某些“非法”字符，因此丟棄了這些記錄。在這種情況下，一些自定義代碼解決了該問題，但更可持續，從源頭開始，數據質量控制將確保這些非法字符不會再次出現在新客戶端中。

小結

上述兩種方法都可以得出結論：數據確實得到了適當的管理，但只有源頭治理、過程治理的方法具有可擴展性、成本效益和創造價值。