讀資料工程之道：設計和構建健壯的資料系統03資料工程生命週期（上）

躺柒發表於2024-10-09

1. 資料工程生命週期

1.1. 資料領域正在經歷新資料技術和實踐的爆炸式增長，抽象程度和易用性不斷提高

1.2. 由於技術抽象程度的增加，資料工程師將越來越多地成為資料生命週期工程師，根據資料生命週期管理的原則來進行思考和操作

1.3. 資料工程生命週期包括將原始資料成分轉化為有用的最終產品的階段，可供分析師、資料科學家、機器學習工程師和其他人使用

1.4. 五個階段

  • 1.4.1. 生成

  • 1.4.2. 儲存

  • 1.4.3. 獲取

  • 1.4.4. 轉換

  • 1.4.5. 中間階段

  • 1.4.5.1. 可能會有點混亂

  • 1.4.6. 服務

  • 1.4.7. 生命週期的各個階段可能會以有趣和意想不到的方式重複、無序、重疊或交織在一起

1.5. 作為基石的是橫跨資料工程生命週期多階段的底層設計

  • 1.5.1. 安全

  • 1.5.2. 資料管理

  • 1.5.3. DataOps

  • 1.5.4. 資料架構

  • 1.5.5. 編排和軟體工程

  • 1.5.6. 沒有這些底層設計，資料工程生命週期的任何部分都無法充分發揮作用

2. 資料生命週期

2.1. 資料工程生命週期是完整資料生命週期的一個子集

2.2. 完整的資料生命週期涵蓋整個生命週期中的資料，而資料工程生命週期則側重於資料工程師控制的階段

3. 生成：源系統

3.1. 源系統是資料工程生命週期中使用的資料的來源

  • 3.1.1. IoT裝置

  • 3.1.2. 應用程式的訊息佇列

  • 3.1.3. 事務資料庫

3.2. 資料工程師需要對源系統的工作方式、它們生成資料的方式、資料的頻率和速度以及它們生成的資料的多樣性有一個工作上的理解

  • 3.2.1. 還需要與源系統所有者保持開放的溝通渠道，瞭解可能破壞管道和分析的更改

3.3. 資料工程的一個主要挑戰是工程師必須處理和理解令人眼花繚亂的資料來源陣列

3.4. 隨著軟體開發實踐的各種現代演變，應用程式+資料庫模式在今天仍然很流行

3.5. 源系統評估問題

  • 3.5.1. 資料來源的本質特徵是什麼？

  • 3.5.1.1. 它是一個應用程式，還是一個物聯網裝置叢集？

  • 3.5.2. 資料如何持久化在源系統中？

  • 3.5.2.1. 資料是長期儲存的，還是臨時的並被迅速刪除？

  • 3.5.3. 資料生成的速率是多少？

  • 3.5.3.1. 每秒有多少事件？

  • 3.5.3.2. 每小時有多少資料量？

  • 3.5.4. 從輸出資料中期望什麼程度的一致性？

  • 3.5.4.1. 如果你對輸出資料進行資料質量檢查，資料不一致（資料空值、糟糕的格式等）的發生頻率是多少？

  • 3.5.5. 錯誤發生的頻率如何？

  • 3.5.6. 資料會包含重複項嗎？

  • 3.5.7. 某些資料是否會延遲到達，是否會比同時生成的其他訊息晚很多？

  • 3.5.8. 獲取資料的模式是什麼？

  • 3.5.8.1. 是否需要跨多個表甚至多個系統進行連線才能獲得資料的全貌？

  • 3.5.9. 如果資料結構發生變化（例如，新增了一個新列）​，如何處理並傳達給下游利益相關者？

  • 3.5.10. 應該多久從源系統中提取一次資料？

  • 3.5.11. 資料是否以定期快照或變更資料捕獲(Change Data Capture，CDC)的更新事件提供？

  • 3.5.11.1. 執行更改的邏輯是什麼？

  • 3.5.11.2. 如何在源資料庫中跟蹤這些更改？

  • 3.5.12. 將為下游消費傳輸資料的資料提供者是誰/什麼？

  • 3.5.13. 從資料來源讀取會影響其效能嗎？

  • 3.5.14. 源系統是否有上游資料依賴？

  • 3.5.14.1. 上游系統的特點是什麼？

  • 3.5.15. 是否進行了檢查延遲或丟失的資料的質量檢查？

3.6. 資料來源產生的資料供下游系統消費，包括人工生成的電子表格、物聯網感測器以及網路和移動應用程式

  • 3.6.1. 每個來源都有其獨特的資料生成量和節奏

  • 3.6.2. 資料工程師應該知道來源如何生成資料，包括相關的怪癖或細微差別

3.7. 源資料最具挑戰性的細微差別之一是模式

  • 3.7.1. 無模式

  • 3.7.1.1. 無模式並不意味著沒有模式

  • 3.7.1.2. 意味著應用程式在寫入資料時定義模式，無論是寫入訊息佇列、平面檔案、blob還是文件資料庫（如MongoDB）​

  • 3.7.2. 固定模式

  • 3.7.2.1. 建立在關聯式資料庫儲存之上的更傳統的模型使用資料庫中強制執行的固定模式，應用程式寫入必須符合該模式

3.8. 模式隨時間變化

  • 3.8.1. 事實上，在軟體開發的敏捷方法中鼓勵模式演變

3.9. 在源系統模式中獲取原始資料輸入，並將其轉換為有價值的分析輸出

4. 儲存

4.1. 選擇儲存解決方案是在資料生命週期其餘部分取得成功的關鍵，而且出於各種原因，它也是資料生命週期中最複雜的階段之一

  • 4.1.1. 雲上的資料架構通常利用多種儲存解決方案

  • 4.1.2. 很少有資料儲存解決方案純粹用作儲存，許多支援複雜的轉換查詢，甚至物件儲存解決方案也可能支援強大的查詢功能

  • 4.1.3. 雖然儲存是資料工程生命週期的一個階段，但它經常涉及其他階段，例如獲取、轉換和服務

4.2. 資料的儲存方式會影響資料在資料工程生命週期的所有階段中的使用方式

4.3. Apache Kafka和Pulsar等流式框架可以同時作為訊息的獲取、儲存和查詢系統，物件儲存是資料傳輸的標準層

4.4. 評估儲存系統

  • 4.4.1. 該儲存解決方案是否與架構所需的寫入和讀取速度相容？

  • 4.4.2. 儲存是否會給下游流程造成瓶頸？

  • 4.4.3. 瞭解這種儲存技術的工作原理嗎？

  • 4.4.3.1. 你是在最佳地利用儲存系統還是在做出不自然的行為？

  • 4.4.3.2. 你是否在物件儲存系統中應用了高速率的隨機訪問更新

  • 4.4.4. 該儲存系統能否處理預期的未來規模？

  • 4.4.5. 下游使用者和程序是否能夠在所需的服務等級協定(Service Level Agreement，SLA)中檢索資料？

  • 4.4.6. 你是否正在捕獲有關模式演變、資料流、資料血緣等的後設資料？

  • 4.4.7. 這是一個純儲存解決方案（物件儲存）​，還是支援複雜的查詢模式（即雲資料倉儲）​？

  • 4.4.8. 儲存系統是模式不可知的（物件儲存）嗎？

  • 4.4.8.1. 靈活的模式(Cassandra)嗎？

  • 4.4.8.2. 是強制模式（雲資料倉儲）嗎？

  • 4.4.9. 如何跟蹤主資料、黃金記錄資料質量和資料血緣以進行資料治理？

  • 4.4.10. 何處理法規遵從性和資料主權？

  • 4.4.10.1. 能否將資料儲存在某些地理位置而不是其他位置？

4.5. 資料訪問頻率

  • 4.5.1. 並非所有資料都以相同的方式訪問

  • 4.5.2. 檢索模式將因儲存和查詢的資料不同而有很大差異

  • 4.5.3. 資料訪問頻率將決定資料的溫度

  • 4.5.3.1. 訪問頻率最高的資料稱為熱資料

>  4.5.3.1.1. 熱資料通常每天被檢索多次，甚至每秒可能被檢索幾次

  • 4.5.3.2. 不冷不熱的資料可能會每隔一段時間訪問一次

  • 4.5.3.3. 冷資料很少被查詢，適合儲存在歸檔系統中

>  4.5.3.3.1. 出於合規目的或在另一個系統發生災難性故障的情況下，通常會保留冷資料

>  4.5.3.3.2. 在“過去”​，冷資料將儲存在磁帶上並運送到遠端檔案設施

>  4.5.3.3.3. 在雲環境中，供應商提供專門的儲存層，每月儲存成本非常低廉，但資料檢索的價格很高

相關文章