讀資料質量管理：資料可靠性與資料質量問題解決之道06資料測試

躺柒發表於2024-11-17

1. 執行分析型資料轉換

1.1. 確保ETL期間的資料質量

  • 1.1.1. ETL即“提取-轉換-載入”​

  • 1.1.2. 步驟

  • 1.1.2.1. 在提取步驟中，原始資料從一些上游資料來源中匯出，並將其移動到暫存區

>  1.1.2.1.1. MySQL

>  1.1.2.1.2. NoSQL伺服器

>  1.1.2.1.3. CRM系統

>  1.1.2.1.4. 資料湖中的原始檔案

  • 1.1.2.2. 暫存區中的資料按照資料工程師的要求規範進行組合和處理

  • 1.1.2.3. 在載入步驟中，我們將轉換後的資料移出暫存區並移至其目的地，該目的地通常是資料倉儲中的一個特定表

1.2. 確保轉換期間的資料質量

  • 1.2.1. ETL是指先將資料載入到暫存伺服器，然後再載入到目標系統的過程

  • 1.2.1.1. ETL為資料工程師提供了在資料投入生產前對其進行驗證的機會

  • 1.2.2. ELT要求將資料直接載入到目標系統中

  • 1.2.2.1. ELT則加快了處理速度，但如果沒有恰當地進行測試和監控，就會降低資料質量

  • 1.2.3. 轉換源資料的原因

  • 1.2.3.1. 只是對欄位進行重新命名，以匹配目標位置的模式需求

  • 1.2.3.2. 透過篩選、聚合、彙總、去重等方式對源資料進行清洗和整合

  • 1.2.3.3. 同時進行型別轉換和單位轉換

  • 1.2.3.4. 為了滿足行業規定或法規，你可以在此步驟對敏感資料欄位進行加密

  • 1.2.3.5. 進行資料治理審計或資料質量檢查

2. 警報和測試

2.1. dbt（資料構建工具）​、WhereScape或Informatica等ETL系統也容易出現故障

  • 2.1.1. 需要一個強大的測試和警報系統以便在大批次資料生產環境中執行這些程式

2.2. 資料測試是在生產之前或期間驗證組織對資料假設的過程

  • 2.2.1. 空值

  • 2.2.1.1. 是否有任何值是未知的（為空值）​？

  • 2.2.2. 容量

  • 2.2.2.1. 有沒有收到任何的資料？

  • 2.2.2.2. 收到的資料是太多了還是太少了？

  • 2.2.3. 分佈

  • 2.2.3.1. 資料是否在可接受的範圍內？

  • 2.2.3.2. 值是否在給定列的範圍內？

  • 2.2.4. 獨特性

  • 2.2.4.1. 獨特性

  • 2.2.5. 已知的不變數

  • 2.2.5.1. 兩個物件是否從根本上不同

2.3. 資料測試的兩個最佳工具分別是dbt測試和Great Expectation

  • 2.3.1. Great Expectations更為通用

  • 2.3.2. dbt本身並不是一個測試解決方案

  • 2.3.2.1. 如果你已經在使用該框架對資料進行建模和轉換了，那麼其開箱即用的測試效果非常好

2.4. 要執行資料質量測試

  • 2.4.1. 將轉換後的資料載入到臨時的暫存表/資料集中

  • 2.4.2. 執行測試以確保暫存表中的資料落在生產所需的閾值範圍內

2.5. 如果資料質量測試失敗了，則會向負責該資料資產的資料工程師或分析師傳送警報，而資料管道也不會執行

  • 2.5.1. 資料工程師能夠在影響終端使用者或系統之前發現意料之外的資料質量問題

  • 2.5.2. 資料測試可以在轉換過程的任何步驟之前或之後進行

  • 2.5.3. 測試是資料質量工作流中的一個重要組成部分，但它並不是團隊在解決資料質量問題時應該採取的唯一主動措施

2.6. dbt單元測試

  • 2.6.1. 現代ELT最受歡迎的選擇之一

  • 2.6.2. 工具擴充套件了向被轉換的表新增單元測試的能力

  • 2.6.3. dbt模型是獨立的SQL語句，它們接收輸入資料，對其進行轉換，並將轉換的一些結果載入到目標表中

  • 2.6.4. 單項測試

  • 2.6.4.1. 可以在不同模型上重複使用的“模板化”測試

  • 2.6.4.2. 採用引數化的SQL查詢形式，因此可以接收引數

  • 2.6.4.3. unique測試的是在特定列中的值是不是唯一的

  • 2.6.4.4. not_null測試的是特定列中的值是否為空值

  • 2.6.4.5. accepted_values確保一列中的所有值都是有限集中的一個

  • 2.6.4.6. relationships檢查了表之間的“引用完整性”​

>  2.6.4.6.1. 確保如id在內的關鍵欄位是一一對應的

  • 2.6.5. dbt測試通常是很好的測試標準

  • 2.6.6. dbt測試是由你組織中的開發人員以程式碼形式手動維護的

  • 2.6.6.1. 複雜的測試可以確保獲得高質量的資料

  • 2.6.6.2. 會浪費工程資源的時間消耗，所花費的時間也接近於開發模型本身所需的時間

  • 2.6.7. 測試失敗必須有意義才能有效

  • 2.6.8. 測試失敗仍然是表明出現錯誤的良好訊號，儘管它並不能提供快速修復

  • 2.6.8.1. 需要深入研究棧來消除錯誤，因為你的ELT測試方案不是正確的端到端測試

2.7. Great Expectations單元測試

  • 2.7.1. 一個開源工具，它以單元測試的形式提供了另一種從資料中“斷言你所期望”的方法

  • 2.7.2. 比dbt測試更具可擴充套件性

  • 2.7.2.1. 用Python編寫的，它可以被用於各種ETL/ELT解決方案

  • 2.7.3. 允許單元測試在一系列不同的資料量上執行，從單個小批次資料到完整的資料轉換

  • 2.7.4. 作為Python包釋出，擴充套件了有用的命令列介面，並使用Jupyter等工具進行資料驗證

  • 2.7.5. Slack整合

  • 2.7.5.1. 設定高度可配置的Slack警報

  • 2.7.6. 僅限於Python

  • 2.7.6.1. 是一個Python工具

  • 2.7.7. 一個完全獨立的工具，具有不同的學習曲線

2.8. Deequ單元測試

  • 2.8.1. 一個由AWS構建的開源庫，用於執行資料單元測試

  • 2.8.2. 構建在Apache Spark上，因此在格式方面具有很大的靈活性

  • 2.8.3. Deequ的工作方式是斷言測試條件並返回失敗的資料行或批資料

  • 2.8.4. Deequ測試套件的入口點是VerificationSuite類

  • 2.8.5. 優點

  • 2.8.5.1. 與AWS整合

>  2.8.5.1.1. 很容易與AWS Glue進行整合，並且在技術部落格中進行了詳細的線上記錄
  • 2.8.5.2. 高可擴充套件性
>  2.8.5.2.1. 可以利用Scala作業編排和並行的優勢，使其更加高效

>  2.8.5.2.2. 資料儲存在Scala的資料框架中，這是針對大資料生態系統及其挑戰而專門構建的
  • 2.8.5.3. 有狀態計算
>  2.8.5.3.1. 可以計算指標的後設資料，將所述後設資料儲存在適當的位置，然後在接收更多資料時重新計算關鍵指標
  • 2.8.5.4. 內建的異常檢測
>  2.8.5.4.1. 允許對執行指標的平均值和偏差進行檢測

  • 2.8.6. 缺點

  • 2.8.6.1. 對於資料工程領域以外的人來說，Scala並不是一種友好的語言

  • 2.8.6.2. 對整合測試的適用性有限

>  2.8.6.2.1. 與dbt測試按模型執行並自然地跨ELT管道整合了測試斷言所不同，Deequ可以靈活地執行在你所提供的任何一批資料上
  • 2.8.6.3. 缺乏直觀的使用者介面
>  2.8.6.3.1. 軟體非常簡單且功能十分強大

2.9. Deequ單元測試

  • 2.9.1. 一個由AWS構建的開源庫，用於執行資料單元測試

  • 2.9.2. 構建在Apache Spark上，因此在格式方面具有很大的靈活性

  • 2.9.3. Deequ的工作方式是斷言測試條件並返回失敗的資料行或批資料

  • 2.9.4. Deequ測試套件的入口點是VerificationSuite類

  • 2.9.5. 優點

  • 2.9.5.1. 與AWS整合

>  2.9.5.1.1. 很容易與AWS Glue進行整合，並且在技術部落格中進行了詳細的線上記錄
  • 2.9.5.2. 高可擴充套件性
>  2.9.5.2.1. 可以利用Scala作業編排和並行的優勢，使其更加高效

>  2.9.5.2.2. 資料儲存在Scala的資料框架中，這是針對大資料生態系統及其挑戰而專門構建的
  • 2.9.5.3. 有狀態計算
>  2.9.5.3.1. 可以計算指標的後設資料，將所述後設資料儲存在適當的位置，然後在接收更多資料時重新計算關鍵指標
  • 2.9.5.4. 內建的異常檢測
>  2.9.5.4.1. 允許對執行指標的平均值和偏差進行檢測

  • 2.9.6. 缺點

  • 2.9.6.1. 對於資料工程領域以外的人來說，Scala並不是一種友好的語言

  • 2.9.6.2. 對整合測試的適用性有限

>  2.9.6.2.1. 與dbt測試按模型執行並自然地跨ELT管道整合了測試斷言所不同，Deequ可以靈活地執行在你所提供的任何一批資料上
  • 2.9.6.3. 缺乏直觀的使用者介面
>  2.9.6.3.1. 軟體非常簡單且功能十分強大

3. Apache Airflow

3.1. Apache Airflow、Luigi、Matillion和Stitch等工具讓團隊能夠更好地管理編排層的資料質量，該層以程式設計方式編寫、排程和監控資料管道中的工作流

3.2. “檢查點”

  • 3.2.1. ​通常被稱為有向無環圖(Directed Acylic Graph，DAG)

3.3. Apache Airflow（和其他編排工具）有向無環圖最常見的資料當機型別是質量變低的查詢和錯誤的Python程式碼

3.4. 滿是錯誤的程式碼可能是人為錯誤（例如令人討厭的縮排錯誤）引起的，而當Apache Airflow作業執行所花費的時間比預期更長時，查詢的質量會降低

3.5. 排程程式的SLA

  • 3.5.1. 在編排層防止資料事故的另一種流行方法是將“斷路器”方法用於資料管道的執行

  • 3.5.2. 斷路意味著當資料不符合一組質量閾值時，資料管道將停止執行

  • 3.5.3. 斷路器是CI/CD工作流程中的常見做法，也是一種防止系統因新軟體部署而發生中斷的手段，許多相同的概念都可以應用於資料管道

  • 3.5.4. 團隊可以在測試和CI/CD流程中的其他步驟（如版本控制）之上整合斷路器

  • 3.5.5. 可以在指標更新完成後實施一個有用的斷路器，在允許任何下游作業執行前先執行完整性測試

  • 3.5.6. 如果發現輸送到管道中的上游資料不準確，則暫停管道中間的資料工作流

  • 3.5.7. 斷路器可以防止資料產品將高質量和低質量的資料混合，從而確保可用資料的可靠性

  • 3.5.7.1. 線路閉合：資料正在流經管道

  • 3.5.7.2. 線路開啟：資料沒有流經管道

  • 3.5.8. 核心解決方案

  • 3.5.8.1. 資料沿襲

  • 3.5.8.2. 跨管道的資料分析

  • 3.5.8.3. 能夠透過分析發現的問題來自動觸發線路

  • 3.5.9. 斷路器被用於防止豎井式資料管道的新鮮度、容量和分佈問題，但類似的原理也可以應用於大規模自動化

3.6. 為Apache Airflow DAG安裝斷路器是防止資料質量問題的一種更為積極主動的方法，如果資料不滿足新鮮度、容量和模式閾值的要求，則可以在編排層停止資料管道

3.7. 斷路是一種有價值且節省成本的工具，但它通常僅用於最關鍵的資料當機事件

  • 3.7.1. 斷路不僅可以防止不良資料破壞原本完美的管道，而且還可以確保在執行具有（難以發現的）資料質量問題的DAG時不會產生回填成本

3.8. SQL檢查運算子

  • 3.8.1. 可驗證給定DAG的內容是否與多個關鍵元素（包括值、間隔和閾值）的預期相一致

  • 3.8.2. 將允許你執行自定義的SQL檢查運算子，這些運算子從給定的SQL查詢中返回單行，以檢查該行中的任何返回值是否為False

3.9. 如果沒有戰略化地審慎實施，斷路器和SQL檢查運算子可能會阻止整個資料管道執行那些與問題無關且高質量的作業，從而阻止分析型資料流向下遊系統

4. 要點

4.1. 解決資料當機不只是在下游儀表板中出現空值時對相關方做出回應，或者當你在收到CEO發來關於“丟失資料”的瘋狂電子郵件時重新訪問你的Snowflake查詢

4.2. 資料當機應該能夠透過在資料管道的各個階段整合資料質量檢查來進行主動預防

  • 4.2.1. 從最初的資料倉儲或資料湖中接收資料，到最終在商業智慧層中的實際應用

4.3. 雖然資料質量問題不能單靠技術來解決，但收集、清洗、接收、處理和編排資料時考慮資料可靠性一定會對資料質量的提高有所幫助

4.4. 即使有最嚴格的SQL檢查，那些“未知的未知”也可能會被遺漏

4.5. 資料永遠不會完全可靠，而我們最好可以儘早接受這一事實

相關文章