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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

盡管如此，因?yàn)橛懈斓恼J(rèn)知跳躍和對(duì)因果關(guān)系的直觀理解 - 或者最近在導(dǎo)致問題的環(huán)境中可能發(fā)生了什么變化。

評(píng)估影響和分類

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

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

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

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

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

跨團(tuán)隊(duì)主動(dòng)溝通

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

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

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

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

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

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

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

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

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

確定上游依賴項(xiàng)

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

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

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

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

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

每種異常類型的根本原因幾乎是無(wú)限的，但它們都源于數(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ù)的工具引入錯(cuò)誤時(shí)，系統(tǒng)或操作問題被發(fā)現(xiàn)。這方面的一個(gè)示例可能是運(yùn)行時(shí)間過長(zhǎng)的 Airflow 檢查，從而導(dǎo)致數(shù)據(jù)新鮮度異常。另一個(gè)示例可能是依賴于訪問 Snowflake 中的特定模式的作業(yè)，但它沒有訪問該模式的正確權(quán)限。

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

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

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

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

整合事件解決流程

由于數(shù)據(jù)異常可能源自管道的每個(gè)組件以及數(shù)據(jù)本身，因此事件解決方案會(huì)變得混亂。

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

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

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

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

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