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

躺柒發表於2024-10-10

1. 獲取

1.1. 在瞭解資料來源、所用源系統的特徵以及資料的儲存方式之後，你需要收集資料

1.2. 資料工程生命週期的下一階段是從源系統中獲取資料

  • 1.2.1. 源系統和獲取代表了資料工程生命週期中最重要的瓶頸

  • 1.2.2. 源系統通常不在你的直接控制範圍內，可能會隨機變得無響應或提供質量差的資料

  • 1.2.3. 你的資料獲取服務可能出於多種原因神秘地停止工作

  • 1.2.4. 不可靠的源和獲取系統會在整個資料工程生命週期中產生連鎖反應

1.3. 主要問題

  • 1.3.1. 正在獲取的資料的用例有哪些？

  • 1.3.1.1. 可以重用這些資料而不是建立同一資料集的多個版本嗎？

  • 1.3.2. 系統是否可靠地生成和獲取這些資料，這些資料是否在我需要時可用？

  • 1.3.3. 獲取後的資料目的地是什麼？

  • 1.3.4. 需要多久訪問一次資料？

  • 1.3.5. 資料通常以多大的體積到達？

  • 1.3.6. 資料的格式是什麼？

  • 1.3.6.1. 下游儲存和轉換系統可以處理這種格式嗎？

  • 1.3.7. 源資料是否處於良好狀態以供直接下游使用？

  • 1.3.7.1. 如果是這樣，持續多長時間，什麼可能導致它無法使用？

  • 1.3.8. 如果資料來自流媒體源，是否需要在到達目的地之前進行轉換？

  • 1.3.8.1. 在資料流本身內轉換資料的情況下，進行中的轉換是否合適？

1.4. 批處理與流處理

  • 1.4.1. 處理的所有資料本質上都是流式傳輸的

  • 1.4.2. 資料幾乎總是在其源頭不斷地產生和更新

  • 1.4.3. 批次獲取只是一種專門且方便的大塊處理資料流的方法

  • 1.4.4. 流式獲取使我們能夠以連續、實時的方式向下遊系統提供資料

  • 1.4.4.1. 實時（或接近實時）意味著資料在生成後的很短的時間內（例如，不到1秒後）就可以供下游系統使用

  • 1.4.4.2. 符合實時性要求的延遲因領域和要求而異

  • 1.4.4.3. 流處理似乎是個好主意，但它並不總是直截了當的；額外的成本和複雜性必然會發生

  • 1.4.5. 批次資料在預定的時間間隔或當資料達到預設大小閾值時被獲取

  • 1.4.5.1. 批次獲取是一扇單向門：一旦資料被分成批次，下游消費者的延遲就會受到固有的限制

  • 1.4.6. 批處理長期以來一直是獲取資料的預設方式

  • 1.4.6.1. 批處理仍然是為下游消費提取資料的一種非常流行的方式，特別是在分析和ML中

  • 1.4.7. 許多系統中儲存和計算的分離以及事件流和處理平臺的普遍存在，使得資料流的連續處理更容易獲得並且越來越受歡迎

  • 1.4.7.1. 選擇在很大程度上取決於使用情況和對資料實時性的期望

  • 1.4.8. 關鍵考慮因素

  • 1.4.8.1. 如果我實時獲取資料，下游儲存系統能否處理資料流的速率？

  • 1.4.8.2. 需要毫秒級的實時資料獲取嗎？

>  1.4.8.2.1. 或者採用微批處理方法，例如每分鐘收集和獲取資料？
  • 1.4.8.3. 流式獲取的用例有哪些？
>  1.4.8.3.1. 透過實施流處理，我有哪些具體優勢？

>  1.4.8.3.2. 如果我實時獲取資料，我可以對這些資料採取什麼行動來改進批處理？

  • 1.4.8.4. 流處理方法在時間、金錢、維護、停機時間和機會成本方面是否會比簡單地進行批處理花費更多？

  • 1.4.8.5. 如果基礎設施出現故障，我的流處理管道和系統是否可靠且冗餘？

  • 1.4.8.6. 哪些工具最適合用例？

  • 1.4.8.7. 如果我正在部署ML模型，線上預測和可能的持續訓練對我有什麼好處？

  • 1.4.8.8. 我是從實時生產例項獲取資料嗎？

>  1.4.8.8.1. 如果是這樣，我的獲取過程對此源系統有何影響？

  • 1.4.9. 許多出色的獲取框架確實可以處理批處理和微批處理獲取方式

  • 1.4.9.1. 批處理是許多常見用例的絕佳方法，例如模型訓練和每週報告

  • 1.4.9.2. 只有在確定了可以權衡使用批處理的業務用例之後，才能採用真正的實時流

1.5. 推送與拉取

  • 1.5.1. 在資料獲取的推送模型中，源系統將資料寫入目標系統，無論是資料庫、物件儲存還是檔案系統

  • 1.5.2. 在拉取模型中，資料是在源系統中檢索

  • 1.5.3. 推送和拉取正規化之間的界限可能非常模糊

  • 1.5.4. 資料在資料管道的各個階段工作時，經常會被推送和拉取

  • 1.5.5. 在傳統的ETL中，獲取系統按固定的時間表查詢當前源錶快照

  • 1.5.6. 連續CDC

  • 1.5.6.1. 每當源資料庫中的一行發生更改時，一種常用方法都會觸發一條訊息

  • 1.5.6.2. 這條訊息被推送到一個佇列中，獲取系統在佇列中獲取它

  • 1.5.6.3. CDC方法使用二進位制日誌，它記錄對資料庫的每次提交

>  1.5.6.3.1. 獲取系統讀取日誌但不直接與資料庫互動

>  1.5.6.3.2. 這幾乎不會對源資料庫增加額外負載
  • 1.5.6.4. 某些版本的批處理CDC使用拉取模式
>  1.5.6.4.1. 在基於時間戳的CDC中，獲取系統查詢源資料庫並提取上次更新以來已更改的行

1.6. 透過流式獲取，資料繞過後端資料庫並直接推送到終端，通常由事件流平臺緩衝資料

  • 1.6.1. 此模式對於發射感測器資料的IoT感測器佇列很有用

  • 1.6.2. 我們不是依靠資料庫來維護當前狀態，而是簡單地將每個記錄的讀數視為一個事件

  • 1.6.3. 簡化了實時處理，允許應用程式開發人員為下游分析定製訊息，並極大地簡化了資料工程師的工作

2. 轉換

2.1. 資料工程生命週期的下一個階段是轉換，這意味著資料需要從其原始形式轉變為對下游用例有用的形式

  • 2.1.1. 如果沒有適當的轉換，資料將處於惰性狀態，並且不會以對報告、分析或ML有用的形式出現

  • 2.1.2. 轉換階段是資料開始為下游使用者消費創造價值的階段

2.2. 在獲取後，基本轉換立即將資料對映到正確的型別​，將記錄放入標準格式，並刪除錯誤的記錄

  • 2.2.1. 轉換的後期階段可能會轉換資料模式並應用規範化

  • 2.2.2. 在下游，我們可以應用大規模聚合來報告或對ML過程的資料進行特徵化

2.3. 主要考慮因素

  • 2.3.1. 轉換的成本和投資回報率(Return On Investment，ROI)是多少？

  • 2.3.1.1. 相關的商業價值是什麼？

  • 2.3.2. 轉換是否儘可能簡單和自我隔離？

  • 2.3.3. 轉換支援哪些業務規則？

2.4. 可以批次轉換資料，也可以在傳輸過程中進行流式轉換

  • 2.4.1. 幾乎所有資料都以連續流的形式開始，批處理只是處理資料流的一種特殊方式

  • 2.4.2. 批處理轉換非常受歡迎，但鑑於流處理解決方案的日益普及和流資料量的普遍增加，預計流式轉換的受歡迎程度將繼續增長，也許很快就會在某些領域完全取代批處理

2.5. 轉換視為資料工程生命週期的一個獨立領域，但生命週期的實際情況在實踐中可能要複雜得多

2.6. ML的資料特徵化是另一個資料轉換過程

  • 2.6.1. 特徵化旨在提取和增強對訓練ML模型有用的資料特徵

  • 2.6.2. 特徵化可能是一門暗黑藝術，它結合了領域專業知識（以確定哪些特徵可能對預測很重要）與資料科學方面的豐富經驗

3. 服務

3.1. 資料工程生命週期的最後階段

  • 3.1.1. 現在資料已被獲取、儲存並轉換為連貫且有用的結構，是時候從你的資料中獲取價值了

  • 3.1.2. 從資料中“獲取價值”對不同的使用者意味著不同的事情

  • 3.1.3. 資料服務可能是資料工程生命週期中最令人興奮的部分

3.2. 當資料用於實際目的時，它才有價值

  • 3.2.1. 未使用或未查詢的資料只是惰性的

3.3. 資料虛榮專案是公司的一個主要風險

  • 3.3.1. 在資料湖中收集大量資料集，這些資料集從未以任何有用的方式使用過

3.4. 分析

  • 3.4.1. 是大多數資料工作的核心

  • 3.4.2. 一旦你的資料被儲存和轉換，你就可以生成報告或儀表板並對資料進行臨時分析

  • 3.4.3. 商業智慧

  • 3.4.3.1. BI透過收集資料來描述企業的過去和當前狀態

  • 3.4.3.2. BI需要使用業務邏輯來處理原始資料

  • 3.4.3.3. 用於分析的資料服務是資料工程生命週期各個階段可能會糾纏在一起的另一個領域

  • 3.4.3.4. 業務邏輯通常在資料工程生命週期的轉換階段應用於資料，但讀取邏輯方法越來越流行

>  3.4.3.4.1. 資料以乾淨但相當原始的形式儲存，具有最少的後處理業務邏輯
  • 3.4.3.5. BI系統維護一個業務邏輯和定義的儲存庫
>  3.4.3.5.1. 此業務邏輯用於查詢資料倉儲，以使報告和儀表板與業務定義保持一致

  • 3.4.4. 資料質量差、組織孤島和缺乏足夠的資料技能通常會阻礙分析技術的廣泛使用

  • 3.4.5. 運營分析

  • 3.4.5.1. 運營分析側重於運營的精細細節，促進報告使用者可以立即採取行動

  • 3.4.5.2. 運營分析側重於運營的精細細節，促進報告使用者可以立即採取行動

  • 3.4.5.3. 資料是實時消費的，直接來自源系統或流資料管道

  • 3.4.5.4. 運營分析中的洞察型別與傳統BI不同，因為運營分析側重於當前，不一定關注歷史趨勢

  • 3.4.6. 嵌入式分析

  • 3.4.6.1. 在SaaS平臺上提供給客戶的分析帶有一組單獨的要求和複雜性

  • 3.4.6.2. 內部BI面向的受眾有限，一般呈現的統一檢視數量有限

  • 3.4.6.3. 訪問控制很關鍵，但並不特別複雜

  • 3.4.6.4. 使用少數角色和訪問層來管理訪問

  • 3.4.6.5. 每個客戶都必須看到他們的資料，而且只能看到他們的資料

3.5. 多租戶

  • 3.5.1. 資料工程師可能會選擇將許多客戶的資料存放在公用表中，以便為內部分析和機器學習提供統一的檢視

  • 3.5.2. 該資料透過具有適當定義的控制元件和過濾器的邏輯檢視在外部呈現給各個客戶

  • 3.5.3. 資料工程師有責任瞭解他們部署的系統中多租戶的細節，以確保絕對的資料安全和資料隔離

3.6. 機器學習

  • 3.6.1. 一旦組織達到高水平的資料成熟度，他們就可以開始識別適合機器學習的問題並開始圍繞它組織實踐

  • 3.6.2. 資料工程師的職責在分析和機器學習方面有很大的重疊，而且資料工程、機器學習工程和分析工程之間的界限可能很模糊

  • 3.6.3. 特徵儲存是最近開發的一種結合了資料工程和機器學習工程的工具

  • 3.6.3.1. 在實踐中，資料工程師是支援機器學習工程的特徵儲存的核心支援團隊的一部分

  • 3.6.4. 注意事項

  • 3.6.4.1. 資料質量是否足以執行可靠的特徵工程？

>  3.6.4.1.1. 質量要求和評估是與使用資料的團隊密切合作制定的
  • 3.6.4.2. 資料是否可發現？
>  3.6.4.2.1. 資料科學家和機器學習工程師能否輕鬆找到有價值的資料？

  • 3.6.4.3. 資料工程和機器學習工程之間的技術和組織邊界在哪裡？

  • 3.6.4.4. 資料集是否正確代表了基本事實？

>  3.6.4.4.1. 是否存在偏見

  • 3.6.5. 在將大量資源投入機器學習之前，請花時間建立堅實的資料基礎

  • 3.6.5.1. 意味著在資料工程和機器學習生命週期中建立最佳系統和架構

  • 3.6.5.2. 通常最好在轉向機器學習之前先培養分析能力

  • 3.6.5.3. 許多公司已經因為在沒有適當基礎的情況下采取舉措而破滅了機器學習夢想

3.7. 反向ETL

  • 3.7.1. 向ETL長期以來一直是資料中的一個實際現實，被視為一種我們不喜歡談論或用名字來表示的反模式

  • 3.7.2. 反向ETL從資料工程生命週期的輸出端獲取經過處理的資料，並將其反饋回源系統

  • 3.7.3. 隨著企業越來越依賴SaaS和外部平臺，反向ETL變得尤為重要

  • 3.7.3.1. 廣告平臺是一個日常用例

相關文章