你是否知道那個卡通比喻：堤壩上出現了漏水，卡通角色很快用手指堵住了它，卻發現又出現了一個需要堵住的漏水，以此類推，直到沒有更多的手指或整個大壩爆發?

數據工程師非常清楚這種感覺。

出現異常情況，并指派了一名數據團隊成員來解決它，但根本原因分析過程需要很長時間，以至于當一切都解決時，又出現了三個泄漏，并且沒有更多的尸體可以扔到問題。

簡而言之，根本原因分析和異常解決方案花費的時間太長。事實上，當我們對Wakefield Research 的 300 名數據專業人員進行數據質量狀況調查時，我們發現解決數據事件的平均時間為 9 小時!

受訪者還報告平均每月發生 61 起數據事件，這意味著數據團隊平均每個月要旋轉根本原因分析輪 549 小時。

與其在無休止的跑步機上運行修復損壞的管道和調查空值，不如數據工程師可以簡化這個過程呢?如果我們成功的秘訣就在我們眼前呢?

這是一個與時間一樣古老的故事(與幾年前一樣古老)。盡管如此，在我看來，最好的方法是讓數據團隊開始處理他們的關鍵數據資產，比如生產軟件，包括事件解決方案。

如何識別和分類數據異常

在我們進入根本原因分析最佳實踐之前，了解數據和管道中斷的方式非常重要。數據在這方面非常有創意，也是單元測試數據不足以檢測大多數事件的原因之一。

雖然幾乎有無數種方式或根本原因可以解釋為什么“這些數字看起來不正確”，但好消息是大多數異常可以分為四種類型。

1. 新鮮 度：數據新鮮度異常(有時稱為及時性)是指數據沒有及時更新。這通常是由業務需求決定的。高管可能需要每個季度的客戶流失數據，營銷人員可能需要每天早上 8:00 的新廣告數據，或者流媒體網站上的機器學習驅動的推薦引擎可能需要近乎實時的數據。

2. 分布 ：分布異常是指您的數據值超出可接受的范圍。在某些情況下，它可能是一個可接受的異常值，例如在會議期間訪問您的網站的訪問者激增，或者是在胡說八道的時候，例如報告從紐約到洛杉磯的貨物在幾秒鐘內發生。無論哪種方式，這表明您應該深入研究。

3. 容量 ：容量異常是指您的數據過多或過少，表明您的數據源的健康狀況可能存在問題。如果 2 億行突然變成 500 萬行，你應該知道。

4. 模式 ：當數據的組織發生變化時，模式異常就會發生。它可以像重命名、添加列或將字段類型從流更改為數字一樣簡單。當這些變化是意料之外的(而且它們往往不是)時，它們會破壞下游的流程。

數據團隊了解這些異常類別非常重要，這樣他們才能快速評估問題、標記問題并使用添加詞匯進行交流。

對異常進行分類的另一個原因是數據異常類型有時可以作為問題所在的線索 (從而加快解決問題的時間)。對于具有該特定平臺經驗的數據工程師來說尤其如此，他們會因過去的事件而傷痕累累。

例如，發生數據新鮮度異常的方式有很多種，但是當您看到其中的一種時，您應該做的第一件事是檢查您的 Airflow DAG以查看作業是否失敗。一旦數據消費者通過電子郵件發送了關于數據質量的討厭說明，這些檢查就可以手動完成。不過，更好的方法是實施自動數據監控，以便您的團隊第一個知道。

我們敢在破碎儀表板的陰暗墓地里唱歌，“準備好了嗎?”

主動數據監控不僅可以保持數據信任并加快檢測時間，還可以加快解決問題的時間。

盡管如此，因為有更快的認知跳躍和對因果關系的直觀理解 - 或者最近在導致問題的環境中可能發生了什么變化。

評估影響和分類

你還記得那些土狼追趕路行者如此匆忙的時候，當他低頭時，他發現他的腳下沒有地面?他行動迅速，但效率不高，結果一落千丈。

異常解決方法相同。數據團隊花費如此多時間的原因之一是他們發現自己以相同的努力追逐每一個異常，卻不知道何時或是否會從他們身下跌落。

換句話說，他們不知道異常的影響是否與響應成正比。例如，如果儀表板在 4 小時內沒有更新，這是一個問題嗎?有時是，有時不是。

避免 SPLAT 的一種方法是確定您最重要的數據資產并與業務利益相關者合作創建數據 SLA。與消費者一起編寫他們的期望和用例，為有效的事件分類提供必要的背景。

挑戰在于數據資產不斷增加，數據消費模式也在不斷變化。自動化數據沿襲可以幫助團隊在不斷發展的環境中有效地識別他們的關鍵表。

跨團隊主動溝通

溝通對于根本原因分析和異常解決方案至關重要。第一步是確保正確的數據工程師有正確的警報。

就像 Jack Skelington 在萬圣節比圣誕節表現得更好一樣，數據團隊的成員將更有效地解決他們自己領域或專業領域內的異常問題。發送警報和分配任務對于在避免倦怠的同時創建所有權和責任感至關重要。

為什么會倦怠?好吧，對于團隊來說，指派他們最有才華的工程師來幫助撲滅任何可能著火的地方是很誘人的，雖然這項任務很緊迫，但也可能很乏味。

作為 Red Ventures 的(數據)產品管理總監，Brandon Beidel 表示，不良數據可能“……觸發工程師進行 2 到 3 小時的考察，以追查問題的根源。不幸的是，最擅長發現這些問題的工程師隨后被這些類型的問題所淹沒。我們需要找到一條出路，擺脫這種享樂主義的跑步機和無休止的時間循環，從高效的人身上奪走時間。”

第二步是通知您的數據消費者存在問題，因此他們不會對不良數據采取行動或傳播不良數據。我們認識的一位數據工程負責人描述了一種將表格用于執行報告的情況。

他們發現了數量異常，并迅速通過電子郵件發送給他們的矩陣合作伙伴或業務利益相關者，他們擁有該報告只是說：“我們現在遇到問題，但我們正在努力解決。請不要發送您的每日報告。”

業務利益相關者非常欣賞他們的積極主動性。這是矩陣合作伙伴知道數據工程團隊支持他們的時刻。突然之間，數據團隊從解決問題轉變為提供服務。

最后，重要的是不僅要在數據工程團隊內部進行溝通，還要在可能是問題根源的其他團隊之間進行溝通。

例如，該模式是否會更改一次性異常，還是會由于軟件工程團隊推出的一項新功能而改變您正在攝取的產品遙測數據的輸出?您的 IT 團隊可能知道。

確定上游依賴項

一旦確定了異常類型并評估了影響，數據團隊需要確定受影響最大的“上游”表。換句話說，不良數據首先從哪里進入您的環境?

這很關鍵，主要有兩個原因。首先是上游表將為根本原因分析提供關鍵上下文。 如果異常是最上游的表之一，則可能是數據源的系統問題。如果問題起源于數據消費者附近的下游，則可能是代碼問題或 dbt 模型是罪魁禍首。

第二個是，如果你不是……好吧，在它的根源上，你就無法解決根本原因。 否則，無論您多頻繁地將正確數據回填到表中，不良數據將繼續從其來源處級聯。

自動化數據沿襲可以幫助團隊避免通過 SQL 查詢來手動跟蹤和重新跟蹤表依賴關系的卡通化過程，在無盡的迷宮中找到異常的起源點。如果您手動執行此操作，您會發現“您應該在阿爾伯克基左轉”。

分析引入異常的三個基礎設施層

每種異常類型的根本原因幾乎是無限的，但它們都源于數據基礎架構三層的問題。

了解這些層以及它們如何產生數據異常可以為您的事件解決過程提供結構。

系統根本原因： 當系統或客戶在提取、加載和轉換過程中應用于數據的工具引入錯誤時，系統或操作問題被發現。這方面的一個示例可能是運行時間過長的 Airflow 檢查，從而導致數據新鮮度異常。另一個示例可能是依賴于訪問 Snowflake 中的特定模式的作業，但它沒有訪問該模式的正確權限。

代碼根本原因 ：第二種數據事件根本原因與代碼有關。例如，您的 SQL 或工程代碼有什么問題嗎?不正確的 JOIN 語句可能會導致不需要或未過濾的行?還是 dbt 模型意外添加了一個非常嚴格的 WHERE 子句，導致輸出數據行數減少而觸發卷異常?如果您能找到一個在引入異常的大致時間前后修改過的查詢或 dbt 模型，那么這是一個很有希望的跡象，表明您已經找到了根本原因。這個過程可以通過整個堆棧的數據監控和日志分析來加速。

自動化數據監控和日志分析的示例。

數據根源： 系統和代碼問題在軟件工程中也很典型，但在數據工程的精彩世界中，數據本身也可能出現問題，使其成為更具動態性的變量。例如，它可能是一個消費者應用程序，其中客戶的輸入很古怪。假設您是一家在線寵物零售商，有人輸入他們的狗重 500 磅而不是 50 磅，這會導致現場健康異常。雖然您可以手動運行多個查詢以通過重復 Bart Simpson 在被拘留的黑板上寫下他的臺詞來分割數據，但這也是一個可以自動化的過程。有多種數據質量解決方案，包括數據可觀察性平臺，可以快速可視化破壞用戶定義的業務邏輯的“壞行”，以幫助查明問題所在。

快速查看異常行分布有助于查明數據級事件。

整合事件解決流程

由于數據異常可能源自管道的每個組件以及數據本身，因此事件解決方案會變得混亂。

數據團隊可能會為 Fivetran、Databricks、Snowflake、Airflow 和 dbt 打開選項卡，同時查看其 ETL 引擎中的日志和錯誤跟蹤，并運行多個查詢來分割數據。

數據可觀察性可以幫助您在單一窗格中查看對 SQL 代碼、dbt 模型和 Airflow 問題的任何更改，只需單擊一下即可查看完整的數據沿襲。這減少了上下文切換，從而實現更快的分辨率。

借助數據可觀察性，您可以在單個窗格中立即查看事件的關聯 SQL 查詢、dbt 模型等。

您的團隊需要更快地解決數據問題以減輕負面影響，以便將更多時間花在為業務增加價值的任務上。

否則，每一次數據事件都會讓人感覺就像有人把鋼琴掉在了你的頭上。