讀資料質量管理：資料可靠性與資料質量問題解決之道11根因分析

1. 解決大規模資料質量問題

1.1. 為關鍵的資料管道制定一個事件管理計劃

1.2. 使用異常檢測作為大規模事件檢測方案的一部分

1.3. 在事件發生時，進行全面的根因分析與影響分析

1.4. 透過測試、持續整合/持續部署、資料可觀測性與更多的資料來積極主動地應對資料質量問題

1.5. 暫停資料管道、找到問題根源都只是恢復資料可靠性並繼續信任資料的冰山一角

2. 在軟體研發過程中解決資料質量問題

2.1. 無論是單獨的資料管道系統，還是大型的資料系統，此類“資料當機”問題的解決方案都已經存在

2.2. DevOps生命週期

• 2.2.1. 計劃

• 2.2.1.1. 研發團隊與產品和商業團隊協作，從而瞭解軟體的目標與SLA

• 2.2.2. 編碼

• 2.2.2.1. 編寫軟體的程式碼

• 2.2.3. 構建

• 2.2.3.1. 將軟體釋出到一個測試環境中

• 2.2.4. 測試

• 2.2.4.1. 對軟體進行測試

• 2.2.5. 釋出

• 2.2.5.1. 將軟體釋出為產品

• 2.2.6. 部署

• 2.2.6.1. 將軟體與現有應用程式共同整合和部署

• 2.2.7. 運維

• 2.2.7.1. 執行該軟體，並根據需要進行調整

• 2.2.8. 監控

• 2.2.8.1. 監控軟體的執行狀況，並對問題發出警報

• 2.2.9. 不斷迴圈往復的

2.3. DevOps生命週期的迴圈反饋流程

• 2.3.1. 幫助團隊可靠地實現大規模交付與業務目標相一致的功能

• 2.3.2. 我們往往傾向於被動地處理資料質量問題，因此在資料分析方面還沒有以有意義且可擴充套件的方式來推動應用這套反饋流程

2.4. 有效的事件管理是在軟體故障發生時減少混亂、儘快恢復正常業務執行的關鍵

• 2.4.1. 如果你沒有提前計劃好應對潛在事件的措施，那麼在面對複雜的真實問題時，套路化的事件解決方案可能根本不管用

2.5. 事件管理就是要對可能出現在日常工程流程中的問題進行鑑別、溯源、解決、分析和預防

3. 資料事件管理

3.1. 當資料系統越來越多地採用分散式架構，且企業攝取的資料規模越來越龐大時，出現錯誤（和事件）的機率也必然增加

3.2. 資料可靠性生命週期

• 3.2.1. 透過將資料可靠性生命週期應用於資料管道，資料工程師團隊可以把檢測、解決甚至提前預防資料質量問題的步驟更加無縫地銜接起來，從而確保資料質量問題不會影響到業務運營

3.3. 關鍵步驟

• 3.3.1. 事件檢測

• 3.3.2. 響應

• 3.3.3. 根因分析

• 3.3.4. 解決

• 3.3.5. （不做指責的）覆盤

4. 事件檢測

4.1. 將事件檢測和資料工程與分析的工作流程結合起來，從而確保當故障發生時，資料的擁有者與終端使用者都能透過合適的溝通渠道得到通知

4.2. 在資料進入生產環境之前就進行測試

4.3. 當資料管道被損壞或者資料儀表板崩潰時，你首先要做的就是進行事件檢測

4.4. 事件可以透過資料監控與警報被檢測到，這一過程可以手動實現，也可以透過設定閾值來自動實現

4.5. 事件檢測也可以作為異常檢測或者資料可觀測性解決方案的一部分，並根據歷史資料模式和定製化規則定期自動觸發

4.6. 事件檢測的一個重要部分就是異常檢測

• 4.6.1. 高質量的異常檢測系統應當能夠藉助演算法的微調來提高訊雜比並降低假陽性率，並且在精確率和召回率之間達到平衡

4.7. 資料團隊總是傾向於認為僅憑異常檢測就足以“解決”事件管理方面的問題

• 4.7.1. 事件管理問題從來不會被真正“解決”

• 4.7.2. 僅僅依靠異常檢測是一個單點故障

• 4.7.3. 事件檢測應當是一個多層面的過程，不僅包含檢測事件，還包括對事件的響應、解決和預防，並且要不斷迭代和重複這些步驟

4.8. 異常檢測是一種工具，而不是靈丹妙藥

• 4.8.1. 一個希望實現自動化運營的資料團隊，假如僅依賴異常檢測，而不借助測試、版本管理、可觀測性、沿襲等其他的技術工具，那麼等待著團隊的最好情況就是層出不窮的問題，而最差情況則是挫敗感和漫長的資料當機恢復時間

• 4.8.2. 不要僅僅依靠異常檢測本身來解決資料質量問題，因為“檢測到”有一個故障，並不意味著故障就能被立刻“解決”​

• 4.8.3. 僅憑異常檢測無法真正構建出可信任、可依靠、透明度高的資料系統，從而滿足洞察力驅動型企業的需求

4.9. 當異常檢測被端到端（例如跨資料倉儲、資料湖、ETL和商業智慧工具）實現，而並非僅僅在資料平臺的其中一兩層實現時，它對業務來說是極具價值的

5. 響應

5.1. 良好的事件響應機制的核心在於有效溝通，好在響應機制的大部分工作可以透過PagerDuty或者Slack等交流工具提前準備並自動完成

5.2. 據團隊應當提前為標準的資料事件響應流程編寫執行指令碼(runbook)和自動化運營手冊(playbook)

• 5.2.1. 執行指令碼為你提供了關於如何使用不同服務及其遇到的常見問題的說明

• 5.2.1.1. 要把故障發生時的角色提前分配好

• 5.2.2. 自動化運營手冊則會提供處理事件的分步流程

5.3. 除了“事件響應人”外，通常還會有一名“事件指揮官”來負責分配工作、整合資訊，而事件響應人和其他利益相關方則會一起解決問題

5.4. 在具體的業務情況中，後設資料可以作為一種強大的工具來有效判斷哪些團隊會受到某一資料當機事件的影響

6. 根因分析

6.1. 根因分析(Root Cause Aanlysis，RCA)

6.2. 資料事件可能悄無聲息地出現在整個資料管道中，並影響數十甚至上百張資料表

6.3. 低資料質量的一個常見原因是新鮮度問題

• 6.3.1. 資料的版本異常老舊

• 6.3.2. 背後的原因多種多樣

• 6.3.2.1. 某個程式的作業卡在了計算佇列裡

• 6.3.2.2. 計算系統超時

• 6.3.2.3. 某個合作伙伴沒有及時上傳資料

• 6.3.2.4. 軟體錯誤

• 6.3.2.5. 意外的日程安排變更導致你的程式作業從有向無環圖(D A G)裡被移除

6.4. 大多數資料問題的根源

• 6.4.1. 進入程式作業、資料管道或系統的資料發生某種意外的變更

• 6.4.2. 轉換資料的邏輯（ETL、SQL、Spark作業等）發生了變更

• 6.4.3. 某種事務型故障

• 6.4.3.1. 計算超時錯誤

• 6.4.3.2. 授權問題

• 6.4.3.3. 資料基礎設施故障

• 6.4.3.4. 日程變更

• 6.4.4. 快速診斷故障原因需要的不僅僅是合適的工具，更需要對這三類問題為什麼以及是如何發生的有全域性認知

6.5. 事件的發生往往不是由於單一因素，反而經常是多種因素的共同作用

• 6.5.1. 要把這些多因素綜合的故障當作可貴的學習機會，用於流程最佳化和技術微調

• 6.5.2. 在軟體（和資料）系統變得越來越複雜的今天，精確診斷某次故障或事件的單一確切原因或根源正變得越發艱

• 6.5.3. 系統崩潰的原因很少是唯一的

6.6. Amazon的五步法框架

• 6.6.1. 發現問題

• 6.6.2. 思考這個問題為什麼會發生，並記錄其原因

• 6.6.3. 判別該原因是不是問題的根源

• 6.6.3.1. 該原因能否被預防？

• 6.6.3.2. 該原因能否在其發生前提前被檢測出來？

• 6.6.3.3. 如果該原因是人為失誤，那麼為什麼會發生這樣的情況？

• 6.6.4. 繼續重複這些步驟，把上面的“原因”迭代成“問題”

• 6.6.5. 當你確信已經找到問題的根源時，就可以停止了

6.7. 隨著資料工程師努力減少手動作業量，他們研發出很多智慧流程、測試方法、資料新鮮度檢查方法以及其他解決方案用以診斷資料事件，避免它們傳播到下游

6.8. 對資料管道進行根因分析的五個步驟

• 6.8.1. 檢視資料沿襲

• 6.8.1.1. 追溯到系統中出現問題的最上游節點，而那裡就是故障最開始發生的地方，你也要去那裡尋找答案

• 6.8.1.2. 最上游節點的資料儀表板就可以提供所有的答案，幫你迅速診斷出問題的根源

• 6.8.1.3. 要確保參與資料事件解決的所有人（資料工程師、資料分析師、分析工程師、資料科學家等）都能獲取最新版本的資料沿襲

• 6.8.1.4. 資料沿襲應當包含商業智慧報告、機器學習模型、反向ETL池等資料產品

• 6.8.1.5. 自動化欄位級別的沿襲常常是資料工程團隊的高回報投資選項，因為它能幫助我們簡單快速地瞭解哪些資料資源是損壞的，以及這些損壞的部分是如何影響下游的資料產品和資料儀表板的

• 6.8.2. 檢視程式碼

• 6.8.3. 檢視資料

• 6.8.3.1. 檢視有異常欄位的資料表中的其他欄位或許能為你判斷資料異常的根源提供線索，這種方法一般比較有用

• 6.8.3.2. 要確保所有參與解決資料故障的人員都能方便地對資料進行切割和分塊，這樣才能便捷地分析資料事故與不同的資料段、時間段以及其他資料分段的相關性

• 6.8.4. 檢視執行環境

• 6.8.4.1. 許多資料事故的直接誘因是執行ETL/ELT資料轉換工作的執行環境

• 6.8.4.2. dbt是處理這些程式執行問題的一個有效的開源工具

• 6.8.5. 藉助你同伴的幫助

• 6.8.5.1. 你的團隊夥伴可以提供有價值的知識或見解，幫你診斷資料中的問題

• 6.8.5.2. 要確保所有參與解決資料故障的人員都能獲取關於資料所有權和使用情況的後設資料，這樣他們就能知道出了問題可以去向誰提問

• 6.8.5.3. 保留一份資料事件的歷史記錄，並記載相關的文件，這也很有幫助

• 6.8.6. 可以把根因分析從令人焦慮的深夜緊急電話轉變成在整個組織中規模化可持續的通用標準流程

6.9. 根因分析在（接近）實時地解決甚至預防資料質量問題上是一個強有力的工具，但是要記得，資料管道的崩潰常常不是某個單一問題導致的