引言——重新思考治理

當我聽到“治理”這個詞時，我會立即想象人們說“不！”，阻止訪問，要求批準，甚至可能有點.嚴厲。對我來說，治理更像是一種障礙，而不是一種推動因素。

說實話，我覺得這很無聊。我盡量避免任何看起來像安全或合規的東西。我跳過了安全相關的認證，因為深入研究訪問策略和審計日志感覺很枯燥。

我還記得職業生涯早期，我需要訪問一個項目的數據集。這花了好幾天時間，我輾轉于不同的團隊。等我終于拿到訪問權限時，項目方向已經發生了改變。

那一刻，我心里就形成了一個信念：治理妨礙了一切！許多人通過變通方法來應對這種摩擦：本地副本、非官方管道、未記錄的快捷方式。

我“有時”也會這么做，尤其是在研究型實驗中，治理并非迫切需要關注的問題。但在孤立實驗中行之有效的方法，在旨在擴展、協作或服務真實用戶的系統中卻行不通。

我花了不少時間，經歷了不少“意外事件”，才意識到治理并非“以后再處理”的事情。它不是阻礙，不是開銷，而是設計！本文是從另一個角度對這一認識進行結構化的思考。

治理不再是我回避的事情。它是我認真、系統地思考的事情，從第一天開始！

為了給這種思維轉變帶來架構性，我們可以看看DAMA 模型。我不會解釋整個模型；它非常廣泛，涵蓋的內容遠超我在這里所能觸及的范圍。相反，我會將自己的學習成果映射到其中選定的部分，并非作為抽象的理論，而是一種將實踐見解錨定在結構化且被廣泛認可的事物上的方法。可以說，我會在相關的時候參考 DAMA 模型，但這不是重點，而是一個有用的參考，以形成我對治理的思考。

? 治理不僅僅是訪問控制

長期以來，治理一直處于我的認知邊緣。作為一名數據科學家，我通常將其視為訪問控制的同義詞，即誰可以讀取什么，誰可以在何處寫入。考慮到我的工作性質，這很合理。

如果您是數據科學家或分析師，您可能有自己的看法，治理是您在請求訪問時偶爾遇到的背景事物。

但這只是整個情況的一部分。

當我擔任架構師的角色時，我與治理的關系發生了變化。

突然間，這不僅僅是關于“有人可以訪問這個表嗎？”的問題，而是關于信任、可追溯性和長期可維護性的問題。

我必須思考系統如何構建、團隊如何協作以及今天做出的決定明天如何被理解。就在那時，我意識到治理包括訪問控制，但并不由它來定義。

DAMA 框架幫助我實現了這一目標。通過它的術語，我發現我過去所說的“治理”實際上只涵蓋了數據安全領域的一小部分。

但是 DAMA 的數據治理領域向我介紹了我以前沒有太注意的概念，例如：管理和決策權。

乍一聽，這些術語似乎有些抽象。但仔細觀察后，我發現它們恰恰描述了我所遇到的差距。

???數據管理的本質在于：誰來管理這些數據？實際上，數據管理就是確保所有數據都記錄在案、定義保持一致、質量問題得到及時解決而不是被忽視的人。當有人問“這一列是什么意思？”時，數據管理人才是真正了解數據含義的人，或者知道該問誰！

是的，也許你會問：“管理權和所有權之間有什么區別？”我也有同樣的問題。

簡而言之：所有權關乎責任，管理權關乎任務。

即使您不親自處理數據，您也可能擁有數據，做出關鍵決策并對結果負責。相反，您可以管理數據，維護其質量和可用性，而不是在出現問題時承擔最終責任。例如，數據管理員（例如，BI 開發人員或業務分析師）說：“這個數字似乎不對，我認為它包含的收益有誤。” 數據所有者（例如，財務合伙人）說：“謝謝，我們現在就修復這個問題，確保不再發生。”

決策權處理的是一個經常被忽視的問題：誰來對這些數據做出決策？誰來決定重命名字段、更改數據類型或重新定義指標？在許多團隊中，變更是臨時發生的，由需要的人推動。良好的治理會為這些決策引入清晰的流程，確保變更經過深思熟慮，其后果也易于理解。

作為一名架構師，通過更廣闊的視角看待治理讓我意識到，治理不是事后修補的，而是需要盡早進行設計！

② DAMA治理架構一瞥

說到這兒，你可能會想：DAMA 模型到底是什么？它包含哪些內容？我還有什么沒注意到的？

我也有類似的疑慮。尤其是因為人們經常會列出一些熟悉的概念，比如數據質量、訪問控制、元數據，然后隨意地加上“等等”，仿佛其他一切都只是事后才想到的模糊概念。

這或許是一句無關緊要的玩笑話，但在技術對話中，“等等”通常表示我們已經理解到極限了。說實話，我在上面的比喻圖中也提到了這一點（冰山一角，我提到了“……等等”）。

具體來說，DAMA 框架列出了 11 個不同的數據管理領域。它不是一份清單或分步指南，更像是一張地圖。地圖很有用，尤其是對架構師來說。

輪子的中心是數據治理。你可能會注意到，它不僅僅是眾多框架中的一個，而是將所有內容整合在一起的協調層。

圍繞它的領域包括數據架構、元數據管理、數據安全、數據質量以及“更多”領域，但這些領域定義明確，具有實際意義。

不過，情況并非如此：如果你是一名數據架構師，那么這些領域中只有一個，也就是數據架構，字面上的標題里有“架構”這個詞。但在實踐中，你幾乎會被所有領域吸引。

您將做出依賴于元數據良好管理的設計決策。

您將繼承沒有明確管理的系統，并被要求“使其具有可擴展性”。

您將構建假設數據是可信且受管理的管道。

您需要對質量進行建模，跨孤島集成，并在執行過程中“確保安全”。

所以，架構師并非擁有整個 DAMA 體系。但如果你不了解它的組成部分，最終可能會不小心圍繞它們進行設計，甚至更糟的是，你會忽略它們，直到它們在生產中出現故障。

③ 利用元數據和血統構建信任

一旦我開始將治理視為設計而不是限制，我就無法停止注意到系統中信任破裂的所有細微、安靜的方式。

它并不總是戲劇性的。它不是數據泄露或系統故障。它比這更微妙：有人在使用數據集之前猶豫不決，因為他們不確定它是否是最新的。儀表板被廢棄，因為沒人記得某個數字是如何計算的。初級分析師從頭開始重新創建報告，因為他們找不到或無法信任現有的報告。

這些情況很少出現在事件日志中，但它們卻是治理缺失的真正代價。它們拖慢了團隊的進度，造成了冗余，并削弱了信心。

那時我才意識到：治理不僅僅關乎誰有權訪問，還關乎人們能否信任他們訪問后看到的內容。

這種信任并非來自儀表板或文檔。它來自元數據和血緣！

元數據：系統自己的內存

元數據不僅僅是一個描述或一個標簽。它是系統的記憶！

它使數據集能夠自我解釋。它使人們能夠無需猜測地應對復雜情況。它能夠提高可發現性，減少誤解，并使團隊擺脫對部落知識的依賴。

在現代數據系統中，元數據并非事后才填充的內容，而是設計時就已考慮到的。元數據為原本雜亂無章的表格和文件提供了結構。

我之所以這么說，是因為我曾經經歷過類似的情況。我是一名數據科學家，打開一個沒有描述、沒有所有者、甚至不知道一半列含義的表。我和很多人一樣，會猜測，或者忽略那些我不理解的列。有時我很幸運，有時則不然。

元數據涵蓋數據集所有權、字段定義、分類、對象間關系、使用模式以及訪問上下文等內容。捕捉所有這些信息不僅僅是文檔，更是設計。

因為好的元數據不會放在 wiki 的一邊；它會影響您的系統如何被理解、使用和擴展。

從命名約定到所有權模型，從分類到譜系，這些選擇都會影響架構。它們不僅僅是描述性的，更是結構性的。

設計時考慮治理意味著您不僅僅會問“這應該放在哪里？”

你還會問，“六個月后，當我不在身邊時，人們如何找到它、理解它，更重要的是信任它？”

Lineage：建立信心的足跡

如果元數據是記憶，那么血緣就是故事！

血緣可以告訴你數據集是如何形成的，哪些源系統輸入了它，應用了哪些轉換，以及哪些儀表板或模型依賴于它。它能將不可見的邏輯轉化為可見的流程！

當出現問題或看起來不對勁時，沿襲通常是唯一可以放心調試的方法。

我在實踐中見過這種情況。儀表板上的數字看起來很可疑，而且沒有血緣關系，你只能打開標簽頁、追蹤管道并進行猜測。

但是有了血統？你順著線索走。你看到了引入空值的那個連接。你注意到了上游悄悄棄用的字段。你調試的是“系統”，而不僅僅是“癥狀”。

但血統不僅僅適用于緊急情況。即使一切正常，它也能建立信心。它幫助分析師提出更好的問題。它幫助新團隊成員更快地上手。它幫助利益相關者信任他們看到的數字。

這就是為什么所有設計都應該考慮到血統意識。

④ 注重質量的設計

數據質量是一個很難反駁的流行詞。每個人都在談論它，每個人都說自己關心它。但當它涉及到實際系統時，人們的做法往往是被動的：事后測量，報告問題，然后指望下游有人能修復這些問題。

它被視為技術問題：測試、驗證、檢查。但如果你仔細觀察，就會發現質量是治理的實際行動。它關乎設定期望，并將這些期望融入系統結構，而非錯誤日志。

DAMA 模型使這種區別更加清晰。數據質量是一個獨立的領域，但它與數據集成并存。因為真正的質量問題不僅僅是無效值，還包括不匹配的連接、未記錄的假設、靜默截斷以及一個團隊做出的對另一個團隊影響的決策。

航空史上有一個故事讓我印象深刻。二戰期間，英國制造了一架非凡的飛機：德·哈維蘭蚊式轟炸機。與當時的大多數飛機不同，這架飛機主要由木材制成，以便節省金屬用于其他戰爭用途。它輕巧、快速、高效，被認為是工程學上的一項成就。

但后來事情開始變得糟糕。飛機開始在空中解體。起初，故障被歸咎于敵方襲擊。但經過調查，原因遠沒有那么引人注目，反而更加明顯：其中一家工廠用于粘合木質部件的膠水混合不當！

它并沒有立即出現故障跡象。但隨著時間的推移，在壓力和濕度的作用下，它最終崩潰了。飛機通過了檢查，執行了任務。但飛機內部卻已經開始解體。

這個故事總是提醒我，一個系統可以在表面上“運作”，但其內部卻在悄悄地退化。

在數據系統中，這就是缺失的質量控制。管道運行，儀表板加載。但這些數字建立在無聲的假設之上：缺少字段、默認值、未知的連接。就像蚊子一樣，系統會一直保持，直到它失效！

這就是為什么質量必須在設計中融入，而不是在檢查中融入。設計始于期望。

模式強制執行是最明顯的例子之一。它常常被視為限制性的，阻礙了靈活性。但實際上，它意味著清晰度。它就像系統在說：“這就是我期望的。”

當強制執行某種類型、聲明必需字段、拒絕未知列時，這不僅僅是一個技術特性，而是一個治理視角。你聲明有效數據是什么樣的，系統會維護這個定義。

但期望并不止于結構。它們延伸到集成：鍵是否對齊？關系是否合理？維度是否對齊？這個數據集能否安全地與那個數據集連接，還是會引入“靜默”重復？這些問題完全屬于數據集成領域，而且往往是質量問題最嚴重的隱患。

值得慶幸的是，現代架構為我們提供了無需依賴人工記憶就能確保質量的方法。我們可以將約束直接編碼到模型中。我們可以創建僅允許經過驗證的數據通過的層。我們可以定義合約，即數據生產者和消費者之間的明確協議，例如：“這是我們承諾交付的內容，如果我們未能交付，您將通過合約得知。”

這些不僅僅是實踐，更是設計原則。如果正確實施，它們將改變治理的本質：從被動應對轉變為主動預防。

⑤ 安全、分類和策略作為設計工具

2018年，全世界目睹了一項悄無聲息的決策演變成一場全球丑聞。一款看似無害的性格測試應用竟然收集了個人信息，不僅來自其用戶，還來自數千萬好友，這都歸功于Facebook的系統設計方式！

沒有黑客攻擊，也沒有防火墻被攻破。問題不在于未經授權的訪問，而在于系統從一開始就沒有將這些數據標記為敏感數據！沒有明確的分類，也沒有對哪些數據可以收集、共享和重新利用進行任何劃分。

架構允許這樣做。因此數據流動，遠遠超出了用戶的理解或預期。

后果是巨大的。調查、國會聽證會、數十億美元的罰款，以及歷史性的信任喪失。這一切都是因為沒有一個機制來規定“這些數據不應該被泄露”。

長期以來，我都把安全視為邊界防護。防火墻、訪問控制，如果情況嚴重，或許還會用到加密。我沒有意識到，在系統內部，治理方式已經受到我們如何標記、控制和定義數據行為的影響。

對我來說，“分類”這個詞一直屬于機器學習！我把分類器看作是算法。但進入架構行業后，我發現了一種不同的分類器，它能夠悄無聲息地決定一列或一個數據集的整個生命周期。它不是通過預測，而是通過意圖。

一旦表達了這種意圖，設計就變得至關重要。標記為可識別個人身份的列不僅在視覺上被隱藏，還會觸發系統層面的屏蔽。訪問規則不僅僅是用戶角色，更是目的、責任和暴露風險在架構上的體現。

對于用戶來說，這些可能看起來像是令人沮喪的政策、缺失的值、被阻止的報告、被屏蔽的字段，但實際上系統正在執行其設計的功能！

這改變了我的觀點。安全和分類并非附加控制，而是根植于架構之中。在舊系統中，策略是文檔。如今，它們是設計決策。系統的行為反映了這些決策。標記上游的字段會在整個流程中攜帶該標記。

DAMA 模型所稱的數據安全和數據治理并非孤立的領域。它們緊密交織。一方提供規則，另一方則將規則構建到系統中。

如果在設計時嵌入分類和策略，您無需手動強制執行信任。系統會為您執行信任。而且，它會安靜、精確且一致地執行。

因此，我們不再問誰能看到某些數據，而是開始問一個不同的問題：這些數據代表什么？它應該如何表現？以及，將它從一個地方移動到另一個地方會產生什么影響？

從控制訪問到編碼含義的這種轉變才是治理優先架構的真正面貌。

⑥ 機器學習治理

如果你翻閱DAMA的車輪圖尋找“機器學習治理”，你不會找到明確的答案。DAMA并非為機器學習系統設計。然而，你在模型構建、跟蹤、解釋和調試上花費的時間越多，你就越能發現DAMA模型仍然適用。

只是我們還沒有更新我們的思維模式來趕上。

傳統的數據治理側重于數據集、轉換、沿襲和訪問。但機器學習系統并不止于數據。它們會生成行為，而這些行為是由輸入、訓練過程、超參數以及可能已不復存在的歷史數據快照所塑造的。

機器學習領域的治理帶來了一些新挑戰，這些挑戰既熟悉又陌生，只是更加混亂。曾經的表格現在變成了模型制品。曾經的字段現在變成了特征。曾經的轉換步驟現在變成了訓練流程。

但核心治理問題依然存在。我們能信任它嗎？我們能追蹤它嗎？誰應該為此負責？究竟發生了什么變化？

版本控制、可解釋性、可重復性和可審計性不再只是學術上的機器學習難題！它們是真正的治理問題，并且正在引起現實世界的關注。

各國政府正開始行動。《歐盟人工智能法案》以及全球圍繞人工智能倫理和透明度的努力，正在規范化良好治理的模式。這些不僅僅是法律辯論，更是系統解釋能力的轉變。

現代平臺也在迎頭趕上。許多平臺現在將模型視為數據生態系統中的“一等公民”。您可以將預測追溯到模型版本，模型版本追溯到訓練運行，訓練運行追溯到數據快照和代碼。

這是模型的血統！是的，它看起來很像我們已經對數據集所做的！

作為一名架構師，你或許需要開始將模型視為不斷發展、受管控的對象，而非輸出。你不僅要監控它們的性能，還要審查它們的構建過程、依賴關系以及審批者。

這就是為什么諸如受管控的特征存儲、感知沿襲的 ML 注冊表以及部署審批工作流等模式不僅僅是MLOps技巧。它們是治理實踐，即使它們尚未進入 DAMA 框架。

也許他們應該這么做。

因為模型成為生產系統的一部分后，就承擔了重要的責任：決策、風險和后果。這意味著它們應該遵循我們應用于其他一切事物的相同設計準則。它不是事后諸葛亮，也不是例外。它只是治理的延伸！

治理優先設計清單

在結束這篇文章之前，我想沒有比分享一份清單更好的方法了。

這是一種表達“是的，治理在這個架構中是完整的”的方式。它們是設計時的反思。如果你能仔細檢查這份清單，并真誠地回答“是”，那么你很可能不僅僅是在構建一個有效的系統，而是在構建一個持久的系統。對我來說，這才是治理優先設計的真正樣子。

這還不是一個全面或標準化的清單，但這是一個開始。而且不知何故，它已經帶來了巨大的改變。

訪問和保護

? 系統是否根據目的和敏感度（而不僅僅是用戶角色）實施訪問控制？

? 訪問決策是否被記錄并可審計，包括覆蓋的理由？

元數據和可發現性

? 作為管道的一部分，數據集、模型和儀表板是否包含豐富的描述、所有權和標簽？

? 新團隊成員是否可以在不詢問任何人的情況下理解數據集是什么、它來自哪里以及如何使用它？

? 在 wiki 中，元數據是否被視為第一類對象，而不是事后才想到的東西？

分類與策略意識

? 分類是否嵌入在設計中，例如機密、內部或 PII 等標簽；并在整個數據流中受到尊重？

? 這些分類是否會動態觸發治理行為，例如屏蔽、訪問限制或保留限制？

? 政策是否已編纂、可追溯并且直接與分類級別相關？

傳承與變革意識

? 每個儀表板或模型都可以追溯到產生它的數據和邏輯嗎？

? 系統是否顯示了在轉換過程中發生了哪些變化、何時發生了變化以及為什么發生了變化？

? 當源數據集發生變化時，是否能立即清楚下游會受到什么影響？

質量與期望

? 數據預期和驗證規則是否在設計時聲明和執行，而不是后來作為測試添加？

? 模式演變是否通過有意的審查而不是默默的漂移來處理？

? 數據缺失、重復或過時等質量問題是否明顯地被提出并發送給正確的所有者？

AI 和 ML 治理

? 模型預測是否可以追溯到所使用的模型版本、訓練數據和代碼？

? 模型批準、部署和審查是否受結構化工作流程的管理，而不僅僅是代碼筆記本？

? 可解釋性、偏見和性能監控從一開始就是模型生命周期的一部分嗎？

架構連貫性

? 治理原則是否反映在架構圖中，而不是僅僅埋藏在文檔或幻燈片中？

? 命名約定、領域邊界和職責是否反映所有權和目的的明確性？

? 如果六個月后你不在了，其他人還能滿懷信心地信任、使用和擴展這個系統嗎？