獲得高質量數據的第一準則：停止加載低質量數據。其實就這么簡單。我看到很多公司都犯了這個錯誤，然后就納悶為什么他們的數據質量這么差。

數據快餐：捕獲所有數據！

“先攝入，后管理。” 這基本上是十年前大數據的口號。某種程度上，它甚至比快餐更糟糕，因為吃快餐至少你知道自己攝入了多少卡路里——即使你選擇忽略它。而這種策略，你根本不知道數據里有什么。

很多公司在數據計劃的起步階段，往往只是盡可能地收集數據，這很有道理，因為幾十年來他們一直缺乏數據。90年代和00年代的數據倉庫根本算不上大數據，只有少數人才能訪問，并決定誰如何使用這些數據。因此，當云計算和大數據技術出現時，最大限度地利用數據就顯得尤為重要。就像快餐一樣，這種方法能帶來即時的滿足感，您的第一個用例很快就會上線。

但負面影響隨后而來。大多數數據質量問題的根本原因是源系統在未經通知的情況下發生變化。它們的模式會變，底層技術會變，部署它們的基礎架構會變，安全設置會變，它們存在的整個目的也會變……無時無刻不在變化。每次中斷都需要幾個小時來排除故障、調試和修復。即使是每年只更改一次的穩定源也會導致大量中斷。數據部門提取 1,000 多個表的情況并不罕見。如果每個表平均每年更改一次，這意味著每年有 1,000 次更改，或者每天有 2-3 次更改。這導致數據團隊大部分時間都處于故障修復模式。

不要只治療癥狀！

一旦數據質量問題變得顯而易見，數據團隊通常會主動采取措施來解決問題。以下這些方法只能治標不治本：

模式演變：啊，數據源改變了嗎？不用擔心，我們會將所有變化反映到數據湖中?；蛘吒玫氖?，我們正在進行數據保管，這樣我們就可以添加更多衛星表來捕獲變化的數據。但這行不通，因為即使你設計的數據管道再智能，也無法應對未來的變化。貨幣列從“文本”更改為“十進制”，該cust列被重命名為customerid，該country字段被刪除，或者更糟的是，它被留空，或者整個表格憑空消失。 質量監控：雖然知道崩潰情況很棒，但這無法從一開始就阻止崩潰。數據質量監控固然有用，但它并不能解決數據質量問題，只能讓問題更加顯而易見。 安裝數據治理工具：你知道嗎，如果我們確定每個數據源的所有者、數據源中包含的內容，并要求他們記錄所有內容，那么他們就會更加負責！不，這會產生大量無人閱讀的文書工作。與數據質量監控一樣，數據治理工具也有其作用，但它并不能解決這個問題。 設立變更委員會：我們要修復這個流程！所有想要對生產環境進行變更的人都必須先在令人敬畏的CAB（變更咨詢委員會）上宣布，這樣我們才能與所有依賴您系統的人討論。我們每年都會發布4個重要版本，以確保可控。但這行不通，因為源系統通常不知道或者幾乎不知道他們的數據正在用于分析。這只是事后才想到的。即使數據團隊及時獲悉變更，并獲得了正確的新測試數據來準備遷移數據管道，仍然經常出錯。因為測試數據永遠無法與實際生產數據相符。而且您仍然需要加班加點地從中斷中恢復。 GenAI 將解決所有的問題：這其實不言而喻，但我還是要說，因為有些公司 100% 確信這就是解決之道：不，你無法用 GenAI 解決這個問題。我知道有些數據部門基本上停止了數據治理計劃，因為“現在你可以直接向聊天機器人詢問任何關于數據的問題，它都會回答?！?哦，你會得到答案。但答案基于什么呢？如果你的數據太亂，連人類專家都無法手動解決，那么 ChatGPT 也無法解答。

您需要一個與源系統的接口

軟件工程師們有一個使用了數十年的技巧，那就是 API。每當軟件團隊想要相互交互時，無論是在公司內部還是外部，你們都可以通過這些 API 進行通信。團隊在每個 API 背后做什么與你無關。他們可能會更改技術，可能會更改底層基礎設施或安全設置，甚至可能會更改架構。只要他們遵守 API 的約定，你就可以在應用中使用它們。

但是重大變更怎么辦？嗯，他們有專門的流程，叫做“棄用 API”。這還是挺煩人的。但變更確實會發生，而且有些變更是重大的。當你使用v1任何 API 時，他們可以發布一個版本，v2并給你 6 個月到 1 年的時間，等你準備好了再遷移到 v2。這完美嗎？不完美。但確實有效。

這是否意味著我們現在都需要在數據世界中開始托管 API？完全不是。但我們可以開始與源系統就接口達成一致。這意味著他們準備一組能夠很好地表示其系統中數據的表，而無需暴露每個內部表。源團隊決定格式。他們可以將該模式在自己的數據庫中提供，也可以將數據推送到整個公司用于分析的通用數據庫/Lakehouse。如果他們有任何重大更改，他們可以v2以不同的模式發布其中一個表，同時仍然可以v1并行發布。一旦所有消費者都遷移到v2，就可以終止該v1接口。

如果你做得好，你的界面設計就能讓數據使用起來更便捷。操作系統通常以規范化格式存儲數據。因此，你需要進行 300 次異質連接才能獲得任何洞察。你可以發布 4 個寬表來準備數據使用，而不是發布數百個小表。這能讓你的界面保持簡潔易懂。

障礙：為什么這還不普遍？

幾乎所有數據部門的人都覺得這個想法很棒。而且它在軟件領域已經有過明顯的成功先例。那么，為什么我們沒有一直這樣做呢？有幾個障礙：

這給運營源系統的團隊帶來了額外的工作和責任。他們有不同的預算、不同的待辦事項、不同的部門……他們為什么要投資于此？他們實際上并沒有動力讓其他人使用他們的數據。如果他們想自己做分析，他們是最了解自己數據的人，所以他們可以直接連接到數據并運行一些查詢。 設置起來比僅僅復制源數據更困難：沒有什么比一個 JDBC 連接和一個SELECT *每晚運行的命令更簡單的了。如果你足夠幸運，甚至不需要和另一端的工程師溝通。你可以隨時隨地以你最喜歡的格式復制所有你想要的數據。你會感覺效率極高。有些公司甚至有關于有多少數據源已經被錄入數據湖的指標。 這些想法相對較新：雖然在軟件領域很常見，但在數據領域卻相對較新。數據網格的概念僅在幾年前才被提出。數據產品思維仍然是一個年輕的概念。數據契約主要存在于博客和領英帖子中，在生產環境中并不常見。

如何開始對源數據采用數據產品思維？

先到先得

如果你還沒有在生產環境中實現商業價值的數據用例，那就先實現它。除非你能夠證明對組織有重大價值，否則你不會獲得更多預算，也不會說服任何外部團隊為你做事。所以，先把第一個用例拼湊起來。直接從源頭提取數據。忘掉我上面寫的一切。創造價值。至于如何做到這一點，那是另一篇文章的主題。

處理業務關鍵用例

殘酷的事實是，企業通常不會改變，除非它們有真正的理由去改變。你可能用幾個簡單的 Tableau 儀表板創造了巨大的價值，而且每個月都需要更新。恭喜你，這是一個不錯的選擇。這可能意味著你只有幾個重要的數據源，而且它們偶爾會出問題。不用擔心，你下周就能修復。一旦你開始根據你采集的數據進行主動交易，或者你使用來自運營系統的數據構建一個面向客戶的人工智能機器人，數據質量問題就可能開始帶來巨大的經濟損失、聲譽損失，甚至兩者兼而有之。相信我，現在你已經得到了組織高層領導的傾聽，這很棒，因為你的下一步需要它。

獲得領導層的支持

杰夫·貝佐斯曾給亞馬遜全體員工發了一封著名的電子郵件，大意是要求使用API進行相互溝通。你的領導層很可能不如杰夫·貝佐斯精通技術。不過，現在是時候向他們尋求幫助了。因為，還記得第一個障礙嗎？這會給運營團隊帶來工作。他們需要預算來做這件事。除了預算之外，他們還需要明白這一點。如果你已經完成了第一步和第二步，那么就很容易讓他們相信你所做工作的價值。但即便如此，也會有部門渴望加入，也會有部門抵制任何改變。不要試圖一下子改變整個組織。讓你最忠實的追隨者獲得成功。如果其他業務領導者看到這一點，他們很快也會轉變。而對于那些不可避免地落后的少數人，公司領導層可以輕易地否決他們。順序在這里很重要。不要一開始就充當數據警察，強迫每個人在價值實現之前為你工作。你有責任讓他們相信你所帶來的價值。

安裝正確的工具來監控進度并進行治理

如果您想賦予域更多職責，則需要落實一些措施。但以下是一些常見的做法：

數據質量工具：是的，您確實需要它們。因為即使出于良好的意圖，您仍然會創建質量低劣的數據。您需要盡早發現這些問題，并理想情況下阻止質量低劣的數據向下游蔓延。 數據契約：API 之于軟件世界，數據契約之于數據世界。您需要就哪些數據可供下游使用達成一致。數據契約可以是一個簡單的文檔頁面。但如果它是一種能夠主動執行這些契約的解決方案，那就更好了，這樣您就不會意外違反自己的契約。 數據目錄：如果您至少在數據目錄中記錄您的接口，這也很有幫助，這樣人們就可以了解每個數據集的含義以及誰擁有它。 數據產品市場：如果您采用去中心化的方式工作，多個團隊將共同創建數據產品。數據倉庫類似于集中式共產主義生產，而數據產品則相當于一個自由市場。您希望團隊能夠發布他們的數據產品，記錄其用途、內容和所有者。您希望其他團隊能夠以受管控的方式使用數據產品。您希望了解您的數據在組織中的使用情況，并形成一個高層次的沿襲。

為團隊做好跑腿工作

別忘了他們需要幫助——即使他們懷有最好的意圖。我們采取的一個有效方法是，讓數據部門負責最重要的數據源。這意味著核心數據團隊負責創建與數據源一致的數據產品。在這種情況下，讓來自源領域的某個人成為數據產品負責人至關重要。即使這僅僅意味著每周與團隊開一次會，也必須確保發布數據的業務所有權掌握在真正了解這些數據的人手中。令人驚訝的是，這幾乎從來都不是數據團隊的。我們通常不知道我們正在獲取的數據意味著什么。我們也不應該知道，我們無法將十幾個不同部門的數據都塞進我們的腦子里。

逐步將更多責任下放到部門

如果每個部門不各自負責數據，就無法真正擴大組織的數據應用規模。我遇到過一些團隊，他們試圖將所有工作集中化，結果不可避免地遇到了瓶頸。我遇到過一位天才數據分析師——我們姑且叫他德塔吧。德塔是我見過的最聰明的人之一。他在公司的數據部門工作了十多年，對數據倉庫的數據了如指掌。他勤于記錄自己的發現，最終形成了數百頁的數據描述。在會議上，他能在5分鐘內回答初級分析師需要3個月才能解答的問題。 “啊，你想要這個見解？那么你需要將數據庫 X 中的表 A 與大型機中的表 B 和 C 連接起來。小心忽略該custid列。我知道它仍然在那里，但自從 4 年前換了新系統后，如果你嘗試執行你想做的事情，該字段可能會不準確。最好custid從數據庫 Y 中獲取。但我的記憶有點生疏；我得再查一遍文檔才能確切地知道該怎么做?！薄巴?，謝謝德塔，沒有你我們永遠也搞不定這個問題。一百萬年也搞不定。”問題是，我知道只有少數組織有德塔。即使是有的組織，德塔也需要休假。而且德塔可能快退休了。此外，盡管德塔是個天才，但他不可能把公司的所有數據都記在腦子里。德塔通常是第一個承認這一點的人。

所以，責任遲早應該轉移到各個部門。對于渴望權力的數據領導者來說，這可能是一個難以下咽的苦果。因為你的直接控制權減少了。你需要問自己一個問題：我在這里是為了實現所有的數據用例嗎？答案是否定的。你的公司也沒有專門負責發送所有電子郵件的電子郵件部門。你的職責是幫助組織最大限度地利用數據。這項支持工作應該由數據團隊集中完成。你越能將單個用例推送到各個部門，你就能創造更大的影響力?？梢赃@樣想：你現在擁有的不再是一個由 30 人組成的集中數據團隊，而是一個由 300 人組成的分布式數據團隊。最棒的是，雖然他們都在努力從數據中創造價值，但只有 10% 的人在你的預算范圍內工作。

小結

解決數據質量問題不能僅靠工具來實現。它需要組織變革。以下是成功的途徑：

價值至上 處理業務關鍵用例 獲得領導層的支持 安裝正確的工具來監控進度并進行治理 為團隊做跑腿工作 逐步將更多責任壓實到部門