流行的分析數據驗證技術以及您需要它們的原因

編者按：本文最初發表於 2020 年 12 月 14 日的 Iteratively 博客。

歸根結底，您的數據分析需要像任何其他代碼一樣進行測試。 如果您不驗證此代碼及其生成的數據，其成本可能很高（根據 Gartner 的數據，每年的成本高達 970 萬美元）。

為避免這種命運，公司及其工程師可以利用多種主動和被動數據驗證技術。 我們強烈推薦前者，我們將在下面解釋。 主動的數據驗證方法將幫助公司確保他們擁有的數據是乾淨的並且可以使用。

反應式與主動式數據驗證技術：在數據問題成為問題之前解決它們

“一盎司的預防勝過一磅的治療。” 這句老話幾乎在任何情況下都是正確的，包括用於分析的數據驗證技術。 另一種說法是，積極主動比被動被動更好。

任何數據驗證的目的都是確定數據可能不准確、不一致、不完整甚至缺失的地方。

根據定義，反應式數據驗證發生在事後，並使用異常檢測來識別您的數據可能存在的任何問題，並幫助緩解不良數據的症狀。 雖然這些方法聊勝於無，但它們並沒有從一開始就解決導致不良數據的核心問題。

相反，我們認為團隊應該嘗試為他們的分析採用主動的數據驗證技術，例如類型安全和模式化，以確保他們獲得的數據準確、完整且符合預期的結構（並且未來的團隊成員沒有與糟糕的分析代碼作鬥爭）。

雖然選擇更全面的驗證方法似乎很明顯，但許多團隊最終還是使用了反應式數據驗證。 這可能有多種原因。 通常，分析代碼是許多非數據團隊的事後想法，因此未經測試。

不幸的是，未經任何驗證就處理數據也很常見。 此外，糟糕的分析代碼只有在非常糟糕時才會被注意到，通常是在幾週後有人注意到報告嚴重錯誤甚至缺失時。

反應式數據驗證技術可能看起來像使用 dbt 或 Dataform 等工具轉換倉庫中的數據。

雖然所有這些方法都可以幫助您解決數據問題（並且通常使用客觀上很棒的工具），但它們仍然無法幫助您解決不良數據的核心原因（例如，在項目中實施的零碎數據治理或分析 -沒有跨團隊溝通的項目基礎），讓你每次都回到他們身邊。

僅僅反應性數據驗證是不夠的； 您需要採用主動數據驗證技術才能真正有效並避免前面提到的代價高昂的問題。 原因如下：

• 數據是一項團隊運動。 確保您的數據乾淨不僅僅取決於一個部門或一個人。 它需要每個人共同努力，以確保高質量的數據並在問題發生之前解決問題。
• 數據驗證應該是軟件開發生命週期 (SDLC) 的一部分。 當您將它集成到您​​的 SDLC 中並與您現有的測試驅動開發和自動化 QA 流程並行時（而不是事後添加它），您可以通過預防數據問題而不是稍後解決問題來節省時間。
• 主動數據驗證可以集成到您現有的工具和 CI/CD 管道中。 這對您的開發團隊來說很容易，因為他們已經投資於測試自動化，現在可以快速擴展它以增加分析的覆蓋範圍。
• 主動數據驗證測試是快速移動的團隊高效運作的最佳方式之一。 它確保他們可以快速迭代並避免數據漂移和其他下游問題。
• 主動數據驗證讓您有信心根據需要更改和更新代碼，同時最大限度地減少以後必須解決的錯誤數量。 此主動流程可確保您和您的團隊僅更改與您關注的數據直接相關的代碼。

既然我們已經確定了主動數據驗證的重要性，下一個問題是：您如何做到這一點？ 團隊使用哪些工具和方法來確保他們的數據在問題出現之前是好的？

讓我們開始吧。

數據驗證方法

數據驗證不僅僅是在特定點發生的一個步驟。 它可能發生在數據生命週期的多個點——客戶端、服務器、管道或數據倉庫本身。

它實際上在很多方面非常類似於軟件測試。 但是，有一個關鍵區別。 您不是在單獨測試輸出； 您還確認您的數據輸入是正確的。

讓我們看一下每個位置的數據驗證情況，檢查哪些是被動的，哪些是主動的。

客戶端中的數據驗證技術

您可以使用 Amplitude Data 等工具來利用類型安全、單元測試和 linting（靜態代碼分析）進行客戶端數據驗證。

現在，這是一個很好的起點，但重要的是要了解這種工具使您能夠在這一層進行什麼樣的測試。 這是一個細分：

• 類型安全是指編譯器在源代碼中驗證數據類型和實現指令，防止由於拼寫錯誤或意外變量而導致的下游錯誤。
• 單元測試是指您單獨測試特定選擇的代碼。 不幸的是，大多數團隊在驗證他們的分析時並沒有將分析集成到他們的單元測試中。
• A/B 測試是指您針對黃金狀態數據集（您認為完美的分析版本）或生產數據副本測試分析流程。 這可以幫助您確定您所做的更改是否有效以及對現有情況的改進。

管道中的數據驗證技術

管道中的數據驗證就是確保客戶端發送的數據與您倉庫中的數據格式相匹配。 如果兩者不在同一頁面上，您的數據消費者（產品經理、數據分析師等）將無法從另一端獲得有用的信息。

管道中的數據驗證方法可能如下所示：

• 模式驗證以確保您的事件跟踪與模式註冊表中定義的內容相匹配。
• 在 dbt 等工具中通過關係、唯一和代理鍵實用程序測試進行集成和組件測試，以確保平台之間的跟踪正常運行。
• 通過 dbt 之類的工具進行新鮮度測試，以確定您的源數據有多“新鮮”（也就是它的最新和健康程度）。
• 使用 Great Expectations 等工具進行分佈式測試，以便在數據集或樣本與預期輸入不匹配時收到警報，並確保對跟踪所做的更改不會弄亂現有數據流。

倉庫中的數據驗證技術

您可以使用 dbt 測試、Dataform 測試和 Great Expectations 來確保發送到您的倉庫的數據符合您期望和需要的約定。 您還可以在此層進行轉換，包括在這些轉換中進行類型檢查和類型安全，但我們不建議將此方法作為您的主要驗證技術，因為它是被動的。

此時，團隊可用的驗證方法包括驗證數據是否符合某些約定，然後對其進行轉換以匹配它們。 團隊還可以使用 dbt 進行關係和新鮮度測試，以及使用 Great Expectations 進行價值/範圍測試。

所有這些工具的功能都歸結為這一層的一些關鍵數據驗證技術：

• 確保CRUD數據和轉換符合既定約定的模式化。
• 安全測試以確保數據符合 GDPR 等安全要求。
• 在 dbt 等工具中進行關係測試，以確保一個模型中的字段映射到給定表中的字段（也稱為參照完整性）。
• 新鮮度和分佈測試（正如我們在管道部分中提到的）。
• 範圍和類型檢查，確認從客戶端發送的數據在倉庫的預期範圍或格式內。

通過深入研究 Lyft 的發現和元數據引擎 Amundsen，可以找到其中許多測試的一個很好的例子。 該工具允許公司的數據消費者搜索用戶元數據，以提高其可用性和安全性。 Lyft 確保數據質量和可用性的主要方法是通過圖形清理 Airflow 任務進行版本控制，當新數據添加到他們的倉庫時，該任務會刪除舊的重複數據。

為什麼現在是採用更好的數據驗證技術的時候了

過去，數據團隊在數據驗證方面苦苦掙扎，因為他們的組織沒有意識到數據衛生和治理的重要性。 那不是我們生活的世界了。

公司已經意識到數據質量至關重要。 僅僅以一種被動的方式清理壞數據是不夠的。 僱傭數據工程師團隊通過轉換或編寫無休止的 SQL 查詢來清理數據是一種不必要且低效的時間和金錢使用。

過去，80% 的數據準確度是可以接受的（取捨取決於用例），而留有 20% 的誤差範圍。 這對於簡單的分析可能沒問題，但對於驅動產品推薦引擎、檢測異常或製定關鍵業務或產品決策來說還不夠好。

公司聘請工程師來創造產品並完成出色的工作。 如果他們不得不花時間處理不良數據，那麼他們就沒有充分利用時間。 但是數據驗證讓他們有時間重新專注於他們最擅長的事情：為組織創造價值。

好消息是高質量的數據觸手可及。 為實現這一目標，公司需要打破數據生產者和數據消費者之間的孤島，幫助每個人了解其價值。 然後，公司應該扔掉電子表格並在他們的分析中應用更好的工程實踐，例如版本控制和模式化。 最後，他們應該確保整個組織都遵循數據最佳實踐，並製定跟踪和數據治理計劃。

投資於主動分析驗證以獲得數據紅利

在當今世界，反應式、隱式數據驗證工具和方法已經遠遠不夠了。 它們會耗費您的時間、金錢，也許最重要的是信任。

為了避免這種命運，擁抱積極主動的哲學。 通過從開始和整個軟件開發生命週期驗證您的分析數據，在問題成為代價高昂的問題之前識別問題。