讀資料質量管理：資料可靠性與資料質量問題解決之道13資料沿襲

躺柒發表於2024-11-24

1. 資料沿襲

1.1. MyDoom的病毒

1.2. 現在，許多團隊甚至整個公司都在使用資料，這要求資料管理的方式要更便於合作，同時也更不容許發生錯誤

1.3. 從採用dbt和Apache Airflow等開源工具來實現資料轉換和編排，到使用Snowflake和Databricks等雲端資料倉儲和資料湖

1.4. 資料儀表板和報告獨立存在、只生成一次、很少被使用、從來不更新的日子已經一去不復返了

  • 1.4.1. 如今，資料要被全公司的終端使用者使用，所以必須把資料做成合格的產品，並且要進行合理的維護和管理，才能大規模地發揮其作用

1.5. 當你努力獲得更可靠的資料時，如果你不知道起點在哪裡，就很難找到目的地

  • 1.5.1. 資料沿襲就是能提供這些資訊的資料“地圖”​，無論資料管道的哪個階段受到了資料當機的影響，它都會告訴你

  • 1.5.2. 當自動化和端到端的覆蓋得以實現時​，沿襲會更加強大

1.6. 與檢測和警報相結合，資料沿襲就構成了真正的資料可靠性的基礎，並且是現代資料棧中越來越重要的組成部分

1.7. 可訪問性讓你能夠為使用者提供一定程度的“可控自由”​，將資料質量從散佈在幾個可見性資料表中的孤立實體轉變為可以在廣泛平臺上被真正實現的東西

2. 站點可靠性工程

2.1. 站點可靠性工程的目標是從保障可靠性出發，對軟體系統的維護和運營進行最佳化

2.2. SRE的主旨在於，用自動化手段解決邊際情況和“未知的未知”​（比如有bug的程式碼、伺服器故障、病毒等）帶來的困擾

2.3. 終極目標是建立一套方法，讓工程師可以用自動化手段代替人工，維護企業快速增加的程式碼庫，並且保證在系統發生問題時提供全方位的保障

2.4. SRE其實是一套思考和接近生產的方式

  • 2.4.1. 大多數開發系統的工程師也可以作為該系統的SRE

3. 端到端欄位級別的沿襲

3.1. 資料工程師對模式變更、空值、分佈錯誤等問題並不陌生，這些問題即便在最健康的資料系統中也會存在

  • 3.1.1. 儘管資料測試是預防這些問題的首要步驟，但資料沿襲正在成為資料管道根因分析和影響分析流程中的重要組成部分

  • 3.1.2. 資料沿襲也可以幫助資料工程和分析團隊看到在資料生命週期每個階段中資料的健康狀況

  • 3.1.3. 作為保障資料可靠性措施的一部分，資料沿襲是幫助理解故障資料的輸入和輸出的重要工具

3.2. 資料沿襲指的是資料集在其整個生命週期各個階段的地圖，從匯入資料倉儲或資料湖，一直到最終分析層的視覺化

  • 3.2.1. 資料沿襲就是資料從A點到B點的路線記錄

  • 3.2.2. 對於資料管道來說，資料沿襲追蹤上游資料來源系統（即資料倉儲和資料湖）和下游依賴關係（比如分析報告和資料儀表板）之間的關係，提供了資料演變的整體檢視

  • 3.2.3. 即便是最基本的SQL查詢也是非常複雜的，所以從零開始構建資料沿襲並不容易

  • 3.2.4. 沿襲圖是手動建立的，而這需要對全公司的資料環境以及所有元件之間的聯絡有著全面瞭解

3.3. 解析資料

  • 3.3.1. ANTLR是一種開源的查詢解析器的生成器，可以讀取、處理、執行和轉換結構化文字或二進位制檔案

  • 3.3.1.1. 使用該查詢解析器提取定義語法的列，你可以獲取更基本的SELECT子句用例的欄位級關係

  • 3.3.2. 你需要從種種複雜的關係和可能的互動所組成的蜘蛛網中抽象出來，以便實現為使用者提供真正強大的產品體驗這一願景

3.4. 構建使用者介面

  • 3.4.1. 重點顯示哪些連線可能與特定的用例或問題相關

  • 3.4.2. 資料團隊一般最關心最下游層（在Looker或Tableau等工具中的商業智慧物件）或最上游層（儲存在資料倉儲或資料湖中的來源表或欄位，它們通常是資料事件的根因）​

  • 3.4.2.1. 最下游層的商業智慧報告和儀表板是資料使用者用於日常工作的最終產品

  • 3.4.2.2. 最重要的上游層（也就是資料倉儲或資料湖中的來源表）是使用者需要利用的物件，它可以幫助使用者逐層追蹤沿襲，並找到表格或欄位存在資料質量問題的那個上游層

  • 3.4.2.3. 一旦使用者找到問題所在，就可以在該表格或欄位中進行修復，從而解決問題

  • 3.4.3. 視覺化框架

  • 3.4.3.1. Apache Preset

  • 3.4.3.2. React Virtuoso

3.5. 欄位關係

  • 3.5.1. SELECT語句沿襲

  • 3.5.1.1. 由SQL的SELECT語句定義的欄位關係

  • 3.5.1.2. 欄位之間的關係，上游欄位的一個更改會直接影響到下游欄位

  • 3.5.2. 非SELECT語句沿襲

  • 3.5.2.1. 由所有其他的SQL語句定義的欄位關係

  • 3.5.2.2. 欄位和表之間關係，下游欄位通常是由上游欄位經篩選或排序邏輯生成的

3.6. 聽取團隊成員的意見並參考每個人的建議

3.7. 致力於原型開發

  • 3.7.1. 客戶就是我們的指路明燈

3.8. 釋出並迭代

  • 3.8.1. 時間是至關重要的，當我們優先考慮一個專案時，必須確保參與該專案的所有人的時間效率都是最高的

  • 3.8.2. 建功能特性、向客戶展示、請求反饋，然後根據需要進行最佳化或修改

  • 3.8.3. 越來越多的資料團隊將開始採用自動化沿襲和其他知識圖譜來識別資料質量問題的來源

4. 資料沿襲的基本要求

4.1. 各行業的資料團隊一直使用資料表級別的沿襲來生成上下游之間的依賴關係，從而最佳化資料可靠性工作流

4.2. 資料表級別的沿襲在宏觀層面上非常有用，但它不能提供足夠的細節來幫助資料團隊瞭解資料管道究竟為什麼以及是怎樣發生故障的

4.3. 第一步都應該是理解使用者的需求，並據此研究出在合理的時間內能夠做出怎樣的成果

4.4. 重要功能

  • 4.4.1. 快速產生價值

  • 4.4.1.1. 快速瞭解程式碼、執行和資料的變動對下游資料欄位和報表的影響

  • 4.4.1.2. 提煉出資料物件間在欄位級別的關係，資料表級別對於快速解決問題來說太過粗糙了

  • 4.4.2. 安全的架構

  • 4.4.2.1. 不希望沿襲直接調取使用者資料或個人可識別資訊

  • 4.4.2.2. 採用調取後設資料、記錄文件、查詢記錄等資訊的方式，而把使用者資料留在客戶的環境中

  • 4.4.3. 自動化

  • 4.4.3.1. 採用自動化的工具，根據資料生命週期的更改來更新資料資產

  • 4.4.4. 與流行的資料工具整合

  • 4.4.4.1. 一個可以生成整個資料管道中所有節點的知識圖譜，從資料倉儲或資料湖的攝取開始，一直到商業智慧或分析層

  • 4.4.4.2. 資料轉換工具

>  4.4.4.2.1. Snowflake

>  4.4.4.2.2. Redshift

>  4.4.4.2.3. Databricks

>  4.4.4.2.4. Apache Sparks

>  4.4.4.2.5. dbt

>  4.4.4.2.6. Apache Airflow

>  4.4.4.2.7. Perfect
  • 4.4.4.3. 商業智慧工具
>  4.4.4.3.1. Looker

>  4.4.4.3.2. Tableau

>  4.4.4.3.3. Mode

  • 4.4.4.4. 要考慮資料系統中所有資料表之間可能出現的連線和關係

  • 4.4.5. 提取列級別的資訊

  • 4.4.5.1. 許多表級別的沿襲解決方案主要基於解析查詢日誌，但這無法提取解析後的列資訊，其中的後設資料是幫助使用者理解資料異常和其他問題所必需的內容

  • 4.4.5.2. 在最基本的情況下，欄位級別的資料沿襲可以大大減少檢測和解決資料質量問題所需的時間，其目的是減少資料團隊對其資料管道進行溯源所需的總時間

  • 4.4.6. 審查營收報告中的可疑數字

  • 4.4.7. 減少資料債務

  • 4.4.8. 管理個人可識別資訊

4.5. 資料沿襲的設計

  • 4.5.1. 三個元素

  • 4.5.1.1. 目標表格，儲存在下游報告中

  • 4.5.1.2. 目標欄位，儲存在目標表格中

  • 4.5.1.3. 來源表格，儲存在資料倉儲中

  • 4.5.2. 非選定欄位對從來源表中提取的行產生影響，但它們不會對結果表中的欄位值產生影響

5. 案例分析

5.1. 並非每個組織都知道如何實現這些資料的全部價值

  • 5.1.1. 資料經常被困在資訊孤島中，關於資料的服務請求堆積在工單佇列中，而這些請求永遠無法到達超負荷地為整個組織提供服務的資料工程師和分析師那裡

5.2. 隨著分散式架構逐漸成為資料驅動型組織的全新黃金標準，自助式的行動方式對於許多資料領導者來說將會讓他們夢想成真

5.3. “可控自由”原則

  • 5.3.1. controlled freedom

  • 5.3.2. 集中式資料團隊僅僅控制少數的關鍵方面：如何攝取資料，如何保障資料安全，如何以最佳格式最佳化資料，然後將其釋出到標準的高管報告中

  • 5.3.3. 團隊能夠保證資料來源值得信賴，資料本身是安全的，且公司在高層報告中使用一致的指標和定義時，資料使用者就有信心在這個框架內能夠自由訪問並利用資料

5.4. 去中心化資料團隊

  • 5.4.1. 5個團隊負責資料管理：資料標記與收集、資料工程、資料分析、資料科學和資料架構

  • 5.4.2. 分析師和工程師之間有明確的界限

  • 5.4.2.1. 分析師靠近業務部門，瞭解痛點，並努力尋找和驗證新的資料來源

  • 5.4.3. STM（Source to Target Mapping，從來源到目標的對映）

  • 5.4.3.1. 本質在於允許工程師根據定義明確的執行手冊來進行操作，從而構建支援業務資料需求所需的資料管道和架構

  • 5.4.4. 透過給工程師提供要解決的問題而不是讓他們整合分析策略，團隊中的實踐者可以保持專注，並致力於那些為業務目標提供支援的專案

  • 5.4.5. 去中心化方法並不適用於每一個組織

  • 5.4.5.1. 團隊結構的需求將根據公司為資料設定的SLA而有所不同

5.5. 避免追逐閃亮的新科技，而應該選擇解決問題的技術

  • 5.5.1. 資料領導者不應盲目追求技術的新潮

  • 5.5.2. 實現自助式分析

  • 5.5.2.1. 包括批次的、微批次的、流式的、結構化的和非結構化的

  • 5.5.2.2. 排序、切片和切塊

5.6. 建立資料信任

  • 5.6.1. 要讓這種自助式分析的模式發揮作用，組織需要相信資料的準確性、可靠性和可信度

  • 5.6.2. 當你放棄透明度或開始隱藏東西時，人們就會失去信任，而重新獲得信任會非常困難

  • 5.6.3. 透過保證開放的溝通並對資料健康問題保持透明，團隊贏得了足夠的信任，得以建立一個自助式的資料平臺，全天候地為決策賦能

相關文章