讀資料質量管理：資料可靠性與資料質量問題解決之道07異常檢測

躺柒發表於2024-11-18

1. 監控和異常檢測

1.1. 在資料方面，所有明面上的測試和資料質量檢查都不能完全保護你免受資料當機的影響

  • 1.1.1. 當機可能由於各種原因而出現在管道內部和外部的各個階段

  • 1.1.2. 這些原因通常與資料本身無關

1.2. 要了解資料何時中斷，最好的做法是依靠資料監控，特別是異常檢測技術

  • 1.2.1. 在容量、新鮮度、分佈和其他值沒有達到預期閾值時被及時識別

1.3. 在知道有一個好的分類（或者說分類模型）之前，你需要知道什麼是好的分類

2. 異常檢測

2.1. 指的是識別出偏離常態的事件或觀察結果

2.2. 對於許多資料團隊來說，異常檢測都被認為是一種“有則更好”而不是“必須要有”的東西

2.3. 團隊必須同時採取主動方式和被動方式來解決資料質量問題

2.4. 監控併發出關於資料可觀測性支柱（新鮮度、容量、分佈和模式）的警報

2.5. 要明白對於任何異常檢測問題來說都沒有完美的分類器

3. 已知的未知和未知的未知

3.1. 你可以預測的（已知的未知）和你無法預測的（未知的未知）

  • 3.1.1. 測試和斷路器可以處理許多已知的未知

  • 3.1.2. 在涉及未知的未知時，監控和異常檢測可以作為處理的基礎

3.2. 已知的未知是你可以輕鬆預測的問題

  • 3.2.1. 空值

  • 3.2.2. 特有的新鮮度問題

  • 3.2.3. 由定期更新的系統觸發的模式變更

  • 3.2.4. 可以在它們導致下游出現問題前把它們解決

3.3. 未知的未知指的是即使透過最全面的測試也無法解決的資料當機

  • 3.3.1. 是整個資料管道中出現的問題

  • 3.3.2. 不僅僅是特定測試所涵蓋的部分

  • 3.3.3. 關鍵欄位中的分佈異常導致Tableau儀表板出現故障

  • 3.3.4. 其他團隊進行的JSON模式變更

  • 3.3.5. 對ETL（或反向ETL）的意外更改導致測試無法執行而不良資料未被發現

  • 3.3.6. 直到幾周後才被注意到的不完整或陳舊資料，影響了關鍵營銷指標

  • 3.3.7. 程式碼變更導致API停止收集為重要新產品提供的資料

  • 3.3.8. 隨時間推移產生的資料漂移

  • 3.3.8.1. ETL作業通常不考慮給定表中已經存在的資料

3.4. 利用監控和異常檢測來識別並警告偏離給定資料管道歷史預期的資料行為。透過了解“好”資料的樣子，就會更容易主動識別出“壞”資料

4. 構建異常檢測的演算法

4.1. 語言和工具

  • 4.1.1. SQLite和SQL

  • 4.1.2. Jupyter Notebooks

  • 4.1.3. Python

4.2. 新鮮度監控

  • 4.2.1. 可以為我們提供一個強有力的指標來說明關鍵資料資產上次更新的時間

  • 4.2.2. 如果一份按小時定期更新的報告突然看起來很陳舊，這類異常應該給我們提供了一個強烈的訊號，表明某些地方是不準確的或者可能是錯誤的

  • 4.2.3. SQL不儲存後設資料，所以為了在這種追溯環境中對新鮮度進行視覺化，我們需要自己跟蹤這些資訊

  • 4.2.3.1. 到底多少天未更新資料就算太久沒更新了呢？

4.3. 分佈

  • 4.3.1. 評估資料的欄位級分佈健康狀況

  • 4.3.2. 分佈會告訴我們資料的所有期望值，以及每個值出現的頻率

  • 4.3.3. 在許多情況下，一定程度的資料不完整是可以接受的，但如果10%的空值率變成了90%，那我們就必須要知道到底發生了什麼

  • 4.3.4. 假設觀測值資料集來自符合數學規則的基準分佈

  • 4.3.4.1. 樣本分佈

  • 4.3.4.2. 真實分佈

  • 4.3.5. 中心極限定理

  • 4.3.5.1. 隨著樣本數量的增加，獨立生成的隨機樣本的分佈會接近於某個分佈

  • 4.3.5.2. 如果在一個均值為μ、標準差為σ的給定資料集中有一個足夠隨機的樣本，則樣本均值的分佈將近似正態分佈

  • 4.3.5.3. 正態分佈或高斯分佈是統計課中大家都很熟悉的著名鐘形曲線

>  4.3.5.3.1. 應用高斯分佈可能會得到一種進行異常檢測的初始方法

>  4.3.5.3.2. 中心極限定理陳述了許多人都會忽略的一個資料生成過程中的關鍵特徵：獨立、隨機的觀測值在極限情況下產生正態分佈

>  4.3.5.3.3. 在商業智慧資料中，觀測值結果往往具有高度的相關性，並與其他變數相混淆
  • 4.3.5.4. “異常”和“有趣”的觀測值之間是有區別的，這不能完全用純粹的統計思維來理解
>  4.3.5.4.1. 時間序列包含重要的前後背景資訊

  >   4.3.5.4.1.1. 季節性是指時間序列在一定時間間隔內觀察到可預測的波動趨勢

>  4.3.5.4.2. 並非所有的異常觀測值都是有趣的，它們並不能幫助我們識別並糾正資料當機

  • 4.3.6. 如果空值率的“峰值”代表著比之前平均值的增加，則更應令人擔憂

  • 4.3.6.1. 當空值率突然下降時，可能不值得進行監控，而檢測空值率是否增加的價值是顯而易見的

4.4. 良好的異常檢測肯定是資料可觀測性難題的一部分，但這並不是全部

  • 4.4.1. 同樣重要的還有前後的背景資訊

5. 構建監控器

5.1. 模式變更和沿襲的異常檢測

  • 5.1.1. 跟蹤模式變更和沿襲可以讓你前所未有地瞭解資料的健康狀況和使用模式，提供有關何人、何事、何地、何因以及如何使用你資料的關鍵前後上下文資訊

  • 5.1.2. 其實在理解資料當機對下游（通常也是現實世界）的影響時，模式和沿襲是兩個最重要的資料可觀測性支柱

5.2. 當對資料結構進行更改時，就會發生模式變更

  • 5.2.1. 模式變更可以指關於資料的任何事

  • 5.2.1.1. 新增新的API端點

  • 5.2.1.2. 假定已棄用的欄位尚未被棄用

  • 5.2.1.3. 增加或減少列、行或整個表

  • 5.2.2. 有版本歷史

  • 5.2.2.1. 模式變更很容易悄悄地突然降臨到我們身上

  • 5.2.3. 識別發出表明管道健康的訊號的有用後設資料

  • 5.2.3.1. 跟蹤它，同時構建檢測器來提醒我們潛在的問題

  • 5.2.3.2. 提供額外的表是跟蹤模式的一種方法，但還有許多其他不同的方法

5.3. 對沿襲進行視覺化

  • 5.3.1. 沿襲是資料可觀測性5個支柱中最全面的一個

  • 5.3.2. 沿襲透過告訴我們哪些下游來源可能受到影響以及哪些上游來源可能是根本原因這兩件事來貫穿整個事件

  • 5.3.3. 沿襲資訊可以幫助我們確定事件的根本原因並更快地解決它們

5.4. 調查資料異常

  • 5.4.1. 解釋僅使用發生了資料異常的事實

  • 5.4.2. 解釋使用了沿襲，根據表和欄位之間的依賴關係，將事件置於整個前後上下文中並確定了問題的根本原因

相關文章