為什麼數據團隊在數據驗證方面苦苦掙扎（以及如何改變它）

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

你知道那句老話，“垃圾進，垃圾出”嗎？ 很有可能，您可能聽說過與數據衛生相關的短語。 但是你如何解決糟糕的數據管理和質量問題呢？ 好吧，這很棘手。 特別是如果您無法控制跟踪代碼的實施（許多數據團隊就是這種情況）。

然而，僅僅因為數據主管不擁有從數據設計到提交的管道並不意味著所有的希望都破滅了。 作為數據消費者（即產品經理、產品團隊和分析師）和數據生產者（工程師）之間的橋樑，您可以幫助開發和管理數據驗證，從而全面改善數據衛生。

在我們進入雜草之前，當我們說數據驗證時，我們指的是幫助數據團隊維護其數據質量的過程和技術。

現在，讓我們看看為什麼數據團隊會為這種驗證而苦苦掙扎，以及他們如何克服這些挑戰。

首先，為什麼數據團隊在數據驗證方面苦苦掙扎？

數據團隊在分析數據驗證方面苦苦掙扎的三個主要原因：

1. 他們通常不直接參與事件跟踪代碼的實施和故障排除，這使得數據團隊處於通常沒有圍繞分析數據驗證的標準化流程，這意味著測試受制於不一致的 QA 檢查。
2. 數據團隊和工程師依賴於反應式驗證技術而不是主動數據驗證方法，這並不能解決核心數據衛生問題。

這三個挑戰中的任何一個都足以讓最好的數據主管（以及支持他們的團隊）感到沮喪。 原因是有道理的：質量差的數據不僅代價高昂——根據 IBM 的數據，不良數據平均造成3 萬億美元的損失。 在整個組織中，它還削弱了對數據本身的信任，並導致數據團隊和工程師浪費數小時的工作時間來消除錯誤。

這個故事的寓意是？ 當數據驗證被擱置一旁時，沒有人會贏。

值得慶幸的是，這些挑戰可以通過良好的數據驗證實踐來克服。 讓我們更深入地了解每個痛點。

數據團隊通常無法控制數據收集本身

正如我們上面所說，數據團隊在數據驗證方面遇到困難的主要原因是他們不是執行相關事件跟踪工具的人（充其量，他們可以看到存在問題，但他們無法解決問題).

這讓數據分析師和產品經理，以及任何希望讓他們的決策更加受數據驅動的人，都背負著事後理清和清理數據的任務。 沒有人——我們是說沒有人——以消遣的方式享受數據處理。

對於大多數數據團隊來說，這個痛點特別難以克服，因為除了工程師之外，數據名冊上很少有人具備自己進行數據驗證的技術技能。 數據生產者和數據消費者之間的組織孤島使這個痛點更加敏感。 為了緩解這種情況，數據主管必須促進跨團隊協作以確保數據乾淨。

畢竟，數據是一項團隊運動，如果您的球員不能互相交談、一起訓練或集思廣益以獲得更好的結果，您將無法贏得任何比賽。

數據檢測和驗證沒有什麼不同。 您的數據消費者需要與數據生產者合作，在源頭實施和執行數據管理實踐，包括測試，以便在任何人在下游執行處理任務之前主動檢測數據問題。

這將我們帶到下一點。

數據團隊（及其組織）通常沒有圍繞分析的數據驗證設置流程

您的工程師知道測試代碼很重要。 每個人可能並不總是喜歡這樣做，但確保您的應用程序按預期運行是交付優質產品的核心部分。

事實證明，確保分析代碼按預期收集和交付事件數據也是構建和迭代優秀產品的關鍵。

那麼斷開連接在哪裡？ 測試分析數據的做法對於工程和數據團隊來說仍然相對較新。 很多時候，分析代碼被認為是功能的附加組件，而不是核心功能。 這一點，再加上乏善可陳的數據治理實踐，可能意味著它只是零星地全面實施（或根本沒有實施）。

簡而言之，這通常是因為數據團隊以外的人還不了解事件數據對他們日常工作的價值。 他們不知道乾淨的事件數據是他們後院的搖錢樹，他們所要做的就是定期澆水（驗證）以賺取資金。

為了讓每個人都明白他們需要關心事件數據這棵搖錢樹，數據團隊需要宣傳在整個組織中可以使用經過充分驗證的數據的所有方式。 雖然數據團隊可能在其組織內受到限制和孤立，但最終還是要由這些數據擁護者來打破他們與其他利益相關者之間的壁壘，以確保採用正確的流程和工具來提高數據質量。

為了克服數據管理的這種狂野西部並確保適當的數據治理，數據團隊必須建立流程，明確說明何時、何地以及如何主動測試數據。 這聽起來可能令人生畏，但實際上，數據測試可以無縫地融入現有的軟件開發生命週期 (SDLC)、工具和 CI/CD 管道。

為設計數據策略的數據團隊以及實施和測試代碼的工程團隊提供清晰的流程和說明，將幫助每個人理解他們應該期望看到的輸出和輸入。

數據團隊和工程師依賴於被動而非主動的數據測試技術

在生活的幾乎每個方面，積極主動總比被動被動好。 這也適用於分析的數據驗證。

但是許多數據團隊和他們的工程師感到被困在反應性數據驗證技術中。 如果沒有使主動測試變得容易的可靠數據治理、工具和流程，事件跟踪通常必須快速實施和交付以包含在版本中（或在一次交付後追溯添加）。 這些迫使數據主管及其團隊在事後使用異常檢測或數據轉換等技術。

這種方法不僅不能解決壞數據的根本問題，而且會花費數據工程師數小時的時間來消除錯誤。 它還會花費分析師數小時的時間來清理不良數據，並使企業因數據更好時可能發生的所有產品改進而損失收入。

數據主管必須幫助塑造數據管理流程，而不是處於持續的數據追趕狀態，其中包括早期主動測試和具有護欄功能的工具（例如類型安全），以提高數據質量並減少下游返工。

那麼，什麼是主動數據驗證措施？ 讓我們來看看。

數據驗證方法和技術

主動數據驗證意味著在數據管道的每個階段採用正確的工具和測試流程：

• 在客戶端中使用 Amplitude 等工具來利用類型安全、單元測試和 A/B 測試。
• 在管道中使用諸如 Amplitude、Segment Protocols 和用於模式驗證的 Snowplow 開源模式回購 Iglu 等工具，以及用於集成和組件測試、新鮮度測試和分佈式測試的其他工具。
• 在倉庫中使用 dbt、Dataform 和 Great Expectations 等工具來利用模式化、安全測試、關係測試、新鮮度和分佈測試以及範圍和類型檢查。

當數據團隊積極維護和執行主動數據驗證措施時，他們可以確保收集的數據有用、清晰和乾淨，並且所有數據持有者都了解如何保持這種狀態。

此外，圍繞數據收集、處理和測試技術的挑戰可能難以單獨克服，因此領導打破數據團隊和工程團隊之間的組織孤島非常重要。

如何更好地更改數據驗證以進行分析

邁向分析的功能性數據驗證實踐的第一步是認識到數據是一項團隊運動，需要來自各個級別的數據股東的投資，無論是您作為數據負責人，還是您的個人工程師實施跟踪代碼行。

從客戶到倉庫，組織中的每個人都受益於良好的數據收集和數據驗證。

要推動這一點，您需要三件事：

1. 來自數據主管和公司領導層的自上而下的指導，建立在整個企業中維護和使用數據的流程
2. 在公司的各個層面傳播數據，以便每個團隊了解數據如何幫助他們更好地完成工作，以及定期測試如何支持這一點
3. 用於很好地管理數據的工作流和工具，無論是內部工具，混合工具（如 Segment Protocols 或 Snowplow 和 dbt），還是更好的內置分析平台（如 Amplitude）。 在所有這些步驟中，同樣重要的是，數據領導者要儘早和經常地分享勝利並朝著偉大的數據邁進。 這種透明度不僅可以幫助數據消費者了解他們如何更好地使用數據，還可以幫助數據生產者（例如，您的工程師進行測試）看到他們的勞動成果。 這是雙贏的。

克服數據驗證難題

數據驗證對數據團隊來說很困難，因為數據消費者無法控制實施，數據生產者不理解為什麼實施很重要，零敲碎打的驗證技術讓每個人都對不良數據做出反應，而不是阻止它。 但它不一定是那樣的。

數據團隊（以及支持他們的工程師）可以通過共同努力克服數據質量問題，利用好數據的跨職能優勢，並利用現有的強大工具來簡化數據管理和測試。