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

數(shù)據(jù)工程師非常清楚這種感覺。

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

簡而言之，根本原因分析和異常解決方案花費的時間太長。事實上，當(dāng)我們對Wakefield Research 的 300 名數(shù)據(jù)專業(yè)人員進(jìn)行數(shù)據(jù)質(zhì)量狀況調(diào)查時，我們發(fā)現(xiàn)解決數(shù)據(jù)事件的平均時間為 9 小時!

受訪者還報告平均每月發(fā)生 61 起數(shù)據(jù)事件，這意味著數(shù)據(jù)團(tuán)隊平均每個月要旋轉(zhuǎn)根本原因分析輪 549 小時。

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

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

如何識別和分類數(shù)據(jù)異常

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

雖然幾乎有無數(shù)種方式或根本原因可以解釋為什么“這些數(shù)字看起來不正確”，但好消息是大多數(shù)異?？梢苑譃樗姆N類型。

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

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

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

4. 模式 ：當(dāng)數(shù)據(jù)的組織發(fā)生變化時，模式異常就會發(fā)生。它可以像重命名、添加列或?qū)⒆侄晤愋蛷牧鞲臑閿?shù)字一樣簡單。當(dāng)這些變化是意料之外的(而且它們往往不是)時，它們會破壞下游的流程。

數(shù)據(jù)團(tuán)隊了解這些異常類別非常重要，這樣他們才能快速評估問題、標(biāo)記問題并使用添加詞匯進(jìn)行交流。

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

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

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

主動數(shù)據(jù)監(jiān)控不僅可以保持?jǐn)?shù)據(jù)信任并加快檢測時間，還可以加快解決問題的時間。

盡管如此，因為有更快的認(rèn)知跳躍和對因果關(guān)系的直觀理解 - 或者最近在導(dǎo)致問題的環(huán)境中可能發(fā)生了什么變化。

評估影響和分類

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

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

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

避免 SPLAT 的一種方法是確定您最重要的數(shù)據(jù)資產(chǎn)并與業(yè)務(wù)利益相關(guān)者合作創(chuàng)建數(shù)據(jù) SLA。與消費者一起編寫他們的期望和用例，為有效的事件分類提供必要的背景。

挑戰(zhàn)在于數(shù)據(jù)資產(chǎn)不斷增加，數(shù)據(jù)消費模式也在不斷變化。自動化數(shù)據(jù)沿襲可以幫助團(tuán)隊在不斷發(fā)展的環(huán)境中有效地識別他們的關(guān)鍵表。

跨團(tuán)隊主動溝通

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

就像 Jack Skelington 在萬圣節(jié)比圣誕節(jié)表現(xiàn)得更好一樣，數(shù)據(jù)團(tuán)隊的成員將更有效地解決他們自己領(lǐng)域或?qū)I(yè)領(lǐng)域內(nèi)的異常問題。發(fā)送警報和分配任務(wù)對于在避免倦怠的同時創(chuàng)建所有權(quán)和責(zé)任感至關(guān)重要。

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

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

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

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

業(yè)務(wù)利益相關(guān)者非常欣賞他們的積極主動性。這是矩陣合作伙伴知道數(shù)據(jù)工程團(tuán)隊支持他們的時刻。突然之間，數(shù)據(jù)團(tuán)隊從解決問題轉(zhuǎn)變?yōu)樘峁┓?wù)。

最后，重要的是不僅要在數(shù)據(jù)工程團(tuán)隊內(nèi)部進(jìn)行溝通，還要在可能是問題根源的其他團(tuán)隊之間進(jìn)行溝通。

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

確定上游依賴項

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

這很關(guān)鍵，主要有兩個原因。首先是上游表將為根本原因分析提供關(guān)鍵上下文。 如果異常是最上游的表之一，則可能是數(shù)據(jù)源的系統(tǒng)問題。如果問題起源于數(shù)據(jù)消費者附近的下游，則可能是代碼問題或 dbt 模型是罪魁禍?zhǔn)住?/p>

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

自動化數(shù)據(jù)沿襲可以幫助團(tuán)隊避免通過 SQL 查詢來手動跟蹤和重新跟蹤表依賴關(guān)系的卡通化過程，在無盡的迷宮中找到異常的起源點。如果您手動執(zhí)行此操作，您會發(fā)現(xiàn)“您應(yīng)該在阿爾伯克基左轉(zhuǎn)”。

分析引入異常的三個基礎(chǔ)設(shè)施層

每種異常類型的根本原因幾乎是無限的，但它們都源于數(shù)據(jù)基礎(chǔ)架構(gòu)三層的問題。

了解這些層以及它們?nèi)绾萎a(chǎn)生數(shù)據(jù)異常可以為您的事件解決過程提供結(jié)構(gòu)。

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

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

自動化數(shù)據(jù)監(jiān)控和日志分析的示例。

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

快速查看異常行分布有助于查明數(shù)據(jù)級事件。

整合事件解決流程

由于數(shù)據(jù)異?？赡茉醋怨艿赖拿總€組件以及數(shù)據(jù)本身，因此事件解決方案會變得混亂。

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

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

借助數(shù)據(jù)可觀察性，您可以在單個窗格中立即查看事件的關(guān)聯(lián) SQL 查詢、dbt 模型等。

您的團(tuán)隊需要更快地解決數(shù)據(jù)問題以減輕負(fù)面影響，以便將更多時間花在為業(yè)務(wù)增加價值的任務(wù)上。

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