讀資料質量管理：資料可靠性與資料質量問題解決之道10資料平臺

躺柒發表於2024-11-21

1. 資料平臺

1.1. 讓你能夠從攝取資料到分析資料的整個過程中全面管理資料的技術組合

1.2. 資料平臺的要求隨著業務的變化而變化

1.3. 資料棧分為6層

  • 1.3.1. 資料攝取

  • 1.3.1.1. 從各種不同的來源中收集結構化資料和非結構化資料

  • 1.3.1.2. 正是ETL和ELT中的提取階段和載入階段

>  1.3.1.2.1.             大多數ETL工具都會從外部資料來源或內部系統中提取資料，在暫存區內將其轉換為儲存所能接受的（通常是關係型）格式，並將其載入到資料庫中

>  1.3.1.2.2.             更新穎的ELT整合架構，即從資料來源中提取原始資料，將其直接載入到資料倉儲中，並在流程結束時對其進行轉換

  • 1.3.1.3. 資料編排和工作流自動化通常被整合到攝取層來獲取孤立的資料，將它們與其他資料來源進行合併，並用於分析

  • 1.3.1.4. 在解決完儲存、處理和商業智慧層之後，資料編排能夠且應該被編織到平臺中

>  1.3.1.4.1.             資料編排需要一組有效的資料

  • 1.3.1.5. 在資料管道中的每一步都對資料進行測試並做出正確的斷言會非常棒，因為這種最佳實踐可以幫助我們具體化每個步驟的資料質量

  • 1.3.1.6. 在攝取時所測試的資料不一定在整個流程的演變過程中都一直可靠

  • 1.3.2. 資料儲存和處理

  • 1.3.2.1. 儲存層是資料棧的主力，它是你對剛攝取的資料進行儲存和處理的地方

  • 1.3.2.2. 資料倉儲是完全託管的解決方案，需要根據特定模式對資料進行結構化處理，所以一般從資料攝取的那一刻起就必須嚴格注意資料的整潔

  • 1.3.2.3. 資料湖通常是由資料團隊結合開源和現成技術來定製的，支援原始非結構化資料和解耦的分散式計算

  • 1.3.2.4. 湖倉一體則是一種新興的混合體，它為資料湖新增了SQL功能和模式等倉庫式特性，為傳統的資料倉儲提供了更大的靈活性

  • 1.3.3. 資料轉換和建模

  • 1.3.3.1. “資料轉換”和“資料建模”這兩個術語經常被混用，但它們其實是截然不同的過程

  • 1.3.3.2. 資料轉換包括準備用於分析和報告的原始資料

>  1.3.3.2.1.             探索性資料分析（剖析資料以瞭解其結構和特徵）​

>  1.3.3.2.2.             資料對映（定義各個欄位的格式來生成最終的輸出）​

>  1.3.3.2.3.             程式碼生成（根據定義的規則或後設資料生成可執行程式碼）​

>  1.3.3.2.4.             程式碼執行（應用生成的程式碼來生成所需的輸出）

>  1.3.3.2.5.             資料審查（確保轉換後的資料符合要求）​

  • 1.3.3.3. 資料建模是識別封裝業務邏輯的資料中的關鍵概念和關係的過程，然後用表的形式以及它們之間的關係對資料進行建模

  • 1.3.3.4. 資料轉換由專業的工程師使用Python、R或SQL等指令碼語言，經過耗時的工作週期來執行

>  1.3.3.4.1.             現代的自助式服務方法允許那些精通SQL且最常與資料打交道的業務使用者在設定需求方面更加可控，並縮短了實現可操作洞察所需的時間，而無程式碼或低程式碼方法讓這種轉換成為可能

>  1.3.3.4.2.             轉換在很大程度上仍然是資料工程師所負責的過程，它合併了Python和除SQL之外的其他語言

  • 1.3.3.5. 資料轉換可以用批處理或實時流處理的方式進行，而後者是一種很有前景且越來越常見的實時對轉換和建模進行處理的方法，在獲取新鮮的資料比確保資料的準確性更重要時會非常適用

  • 1.3.4. 商業智慧和分析

  • 1.3.4.1. 高度可見的資料棧層稱為商業智慧和分析層

  • 1.3.4.2. 商業智慧層讓資料具有可操作性，如果沒有它，你的資料就會缺乏意義

  • 1.3.4.3. 分析工具透過儀表板和資料視覺化來檢索、分析和顯示資料，使使用者能夠利用資料獲得可操作的洞察

  • 1.3.4.4. 透過視覺化來體驗資料，可以增強資料敘事的能力，即以人類可以理解的敘事方式來表達資料，從而讓人採取行動

  • 1.3.4.5. 資料敘事透過交流資料變化的前後背景並分享資料趨勢背後的原因則更進了一步

>  1.3.4.5.1.             資料敘事的原則必須經過長時間的實踐和磨鍊，但如果沒有自助式的商業智慧和分析工具，團隊就無法開始培養這些技能

  • 1.3.5. 資料可觀測性

  • 1.3.5.1. 透過正確的流程和文化建立對資料的信任

>  1.3.5.1.1.             除非你所使用的資料可以被信任並且能為你的業務提供可靠的見解，否則即便是世界上最先進的資料棧也是沒用的

  • 1.3.5.2. 第一步是要了解資料在當前狀態下的健康狀況

  • 1.3.5.3. 現代資料棧的第6層本身並不是最後一步，而是貫穿整個資料生命週期的一種互連手段，我們稱之為資料可觀測性

  • 1.3.5.4. 資料可觀測性是指組織在生命週期的各個階段充分了解其系統中資料健康狀況的能力

  • 1.3.5.5. 端到端的資料可觀測性對於確保資料質量來說至關重要

>  1.3.5.5.1.             有效的可觀測性工具將連線到現有的資料棧，提供端到端的沿襲，使你能夠發現下游依賴關係並在靜止狀態下自動監控資料，而不會從資料儲存中提取資料，並冒著安全或合規的風險

  • 1.3.6. 資料發現和治理

  • 1.3.6.1. 資料團隊需要一種可擴充套件的方式來記錄和理解關鍵資料資產

>  1.3.6.1.1.             透過資料目錄來實現的

  >   1.3.6.1.1.1.              資料目錄充當後設資料清單，並提供資料可訪問性、健康狀況和儲存位置等資訊

  >   1.3.6.1.1.2.              資料目錄可以很容易地跟蹤個人身份資訊的儲存位置，以及組織中的哪些人有權跨管道來訪問這些資訊，從而讓這些人成為資料治理和法規合規性的組成部分

  • 1.3.6.2. 現代資料團隊還是會遇到傳統資料目錄的侷限性

  • 1.3.6.3. 資料發現是一種越來越多地應用於資料編目的新方法，它根據一組特定消費者如何攝取、儲存、聚合和使用資料，提供了資料在特定領域的動態解讀

  • 1.3.6.4. 透過資料發現，治理標準應當是跨領域聯合的

  • 1.3.6.5. 資料發現可以實時瞭解資料的當前狀態，而不是其理想或“編目”狀態

  • 1.3.6.6. 資料發現使資料團隊能夠相信其對資料的假設與現實相匹配，從而能在資料基礎設施中增強動態發現並實現高度可靠性

1.4. 流的資料團隊會對每一層都進行投資，有時會利用相同的工具或技術一次解決2～3層

  • 1.4.1. 層數也將根據資料團隊的需求而增加

2. 建立對資料的信任

2.1. 評估資料質量的投資回報率

  • 2.1.1. 不可靠的資料會導致時間浪費、收入損失、合規風險和客戶信任的削弱

  • 2.1.2. 在提升資料質量之前，你需要對低資料質量的影響進行評估並弄清哪些資料集對你的組織來說是最重要的

  • 2.1.3. 不是所有的資料都同等重要，而瞭解業務中關鍵資產的資料當機成本將會是和利益相關方溝通資料質量影響的基礎

2.2. 計算資料當機成本

  • 2.2.1. 從DevOps從業者那裡借鑑到的TTD和TTR這兩個指標將為解決這一問題提供良好的開端

  • 2.2.2. TTD描述了資料團隊發現任何型別的資料質量問題所需的時間，無論是新鮮度異常還是導致整個管道被破壞的模式變更

  • 2.2.3. TTD以天、周甚至月為單位，因為在大多數情況下，資料當機會在儀表板或報告“不正常”時首先被下游使用者檢測到

  • 2.2.4. 時間越長，透過重新處理或回填源資料來恢復資料就越困難

  • 2.2.5. TTR描述了團隊在收到警報後能夠以多快的速度來解決資料事件

  • 2.2.6. TTR指標讓你能夠了解資料問題的嚴重程度，並跟蹤解決問題所需的時間

  • 2.2.7. （TTD小時數+TTR小時數）×當機每小時成本=資料當機成本

  • 2.2.7.1. 當機每小時成本是一個通用指標，用於表示當機每小時花費的工程時間，以及資料當機對資料消費者和業務決策的影響

  • 2.2.7.2. 花費的工程時間可以計算為當機時間的一個因素

  • 2.2.7.3. 隨著時間的推移和技術債務的累積，當機成本只會不斷增加

  • 2.2.7.4. 根據當機時間對業務的潛在影響不同，該成本會有非常大的差異

  • 2.2.8. 資料質量和可靠性的影響通常會被忽視，當這些問題被發現時，往往為時已晚

2.3. 更新資料當機成本以反映外部因素

  • 2.3.1. 每年因資料損壞而產生的成本可以透過解決問題所需的工程或資源來進行估算

  • 2.3.2. 勞動力成本+合規風險+機會成本=不良資料的年度成本

3. 為資料設定SLA、SLO和SLI

3.1. 站點可靠性工程師使用SLA、SLI和SLO等框架來減少應用程式當機並確保其可靠性

  • 3.1.1. 使用SLO來定義並度量內部團隊或供應商將要交付的給定產品的SLA，以及如果不滿足這些SLA則可能採取的補救措施

  • 3.1.2. 軟體團隊開發了內部的SLO，以幫助工程、產品和業務團隊在其應用程式最重要的事情上保持一致，並對傳入的請求進行優先順序排序

3.2. 如果不能容忍最小的當機時間，就沒有創新的空間

3.3. 有了可靠的SLA，一旦出現問題，工程師就確切地知道應該如何以及何時進行干預

3.4. SLA可以幫助資料團隊及其消費者在整個生命週期中定義、評估並跟蹤資料可靠性

  • 3.4.1. 設定資料可靠性的SLA可以在資料、資料團隊和下游消費者之間建立信任

3.5. 如果沒有一致認可的SLI，消費者可能會對資料的可靠性做出不準確的假設或者尋找有關資料可靠性的軼事證據

3.6. 有了SLO，組織就可以成為更好的“資料驅動型”組織

3.7. 透過對溝通和優先順序流程進行規範化，資料可靠性SLA將有助於資料團隊更清晰地掌握業務優先順序，並更容易在事件發生時快速響應

3.8. 步驟

  • 3.8.1. 透過SLA定義資料可靠性

  • 3.8.1.1. 資料團隊還應該從消費者那裡收集反饋，瞭解他們對可靠性的看法

  • 3.8.2. 透過SLI度量資料可靠性

  • 3.8.3. 透過SLO跟蹤資料可靠性

  • 3.8.3.1. 在確定SLI後，你可以為資料設定目標或設定可接受的當機範圍

3.9. 為資料設定SLA、SLO和SLI只是難題的第一步

  • 3.9.1. 請務必記住，設定SLO和度量SLI本身並不能改善任何事情

  • 3.9.2. 成功的關鍵在於他的團隊評估了什麼是最重要的，設定了SLI來度量它，並設定了SLO來判斷進度，然後能夠正確地確定優先順序，並評估所執行專案的成功程度，以改進這些度量指標

  • 3.9.3. 資料團隊經常忙於設定指標，但沒有為實際執行這些指標而提供適當的價值，也沒有確定環境中的哪些負面特徵會導致缺失SLO的情況

相關文章