讀資料工程之道：設計和構建健壯的資料系統23批次獲取的考慮因素

躺柒發表於2024-10-29

1. 批次獲取的考慮因素

1.1. 批次獲取，通常是獲取資料的一種便捷方式

  • 1.1.1. 透過從源系統中抽取一個資料子集，根據時間間隔或累積資料的大小來獲取資料

1.2. 基於時間間隔的批次獲取在傳統ETL的資料倉儲中很普遍

  • 1.2.1. 每天在非工作時間（也可以按其他頻率）處理一次資料，目的是提供每日的業務報表

1.3. 當資料從基於流的系統轉移到物件儲存時，基於資料量大小的批次獲取是很常見的

  • 1.3.1. 需要把資料分成離散的塊，以便後續在資料湖中進行處理

1.4. 常用的批次獲取資料模式

  • 1.4.1. 快照或差異資料提取

  • 1.4.1.1. 資料工程師必須選擇是捕獲源系統的全速快照還是捕獲差異（有時稱為增量）更新

  • 1.4.1.2. 使用全速快照，工程師在每次讀取更新時都會抓取源系統的整個當前狀態

>  1.4.1.2.1. 全速快照讀取由於其簡單性仍然非常普遍
  • 1.4.1.3. 使用差異更新模式，工程師可以只提取自上次從源系統讀取後的更新和變化
>  1.4.1.3.1. 差異更新是最小化網路流量和節省目標儲存空間的理想選擇

  • 1.4.2. 基於檔案的匯出和獲取

  • 1.4.2.1. 資料經常以檔案為介質在資料庫和其他系統之間移動

  • 1.4.2.2. 資料以可交換的格式序列化為檔案，然後這些檔案被提供給獲取系統

  • 1.4.2.3. 基於檔案的匯出是一種基於推送的獲取模式

>  1.4.2.3.1. 資料匯出和準備工作是在源系統一側完成的
  • 1.4.2.4. 出於安全原因，允許直接訪問後端系統往往是不可取的
>  1.4.2.4.1. 透過基於檔案的獲取，匯出過程在資料來源端執行，讓源系統工程師完全控制哪些資料被匯出以及資料如何被預處理

  • 1.4.2.5. 常見的檔案交換方法是物件儲存、安全檔案傳輸協議(Secure File Transfer Protocol，SFTP)、電子資料交換(Electronic Data Interchange，EDI)或安全複製(Secure Copy，SCP)

  • 1.4.3. ETL與ELT

  • 1.4.3.1. 提取意味著從一個源系統中獲取資料

  • 1.4.3.2. 提取通常是拉取資料，但它也可以是基於推送的

  • 1.4.3.3. 一旦資料被提取出來，就可以在其被載入到目標儲存之前對其進行轉換(ETL)，或者簡單地將資料載入到儲存中，以便將來進行轉換

  • 1.4.4. 插入、更新和批大小

  • 1.4.4.1. 當使用者試圖執行許多小批次的操作而不是數量較少的大操作時，批處理系統往往表現不佳

  • 1.4.5. 資料遷移

  • 1.4.5.1. 將資料遷移到一個新的資料庫或環境中通常不是一件簡單的事，資料需要被以批次的方式遷移

  • 1.4.5.2. 大多數資料系統在批次移動資料時效能表現得比以單行或單個事件移動資料更好

  • 1.4.5.3. 檔案或物件儲存通常是轉移資料的一個很好的中間介質

  • 1.4.5.4. 資料庫遷移的最大挑戰之一不是資料本身的移動，而是資料管道連線從舊系統到新系統的移動

2. 訊息和流獲取的考慮因素

2.1. 模式演進

  • 2.1.1. 模式演進在處理事件資料時是很常見的

  • 2.1.2. 模式演進可能會對你的資料管道和目標儲存產生意想不到的影響

  • 2.1.3. 如果你的事件處理框架有一個模式登錄檔​，使用它來對你的模式變化進行版本管理

  • 2.1.4. 一個死信佇列可以幫助你檢查那些沒有被正確處理的事件的問題

  • 2.1.5. 最簡單粗暴的方式（也是最有效的）是定期與上游利益相關者就潛在的模式變化進行溝通，並與引入這些變化的團隊一起主動解決模式變化，而不是隻在接收端對發生破壞性變化的資料作出反應

2.2. 遲到資料

  • 2.2.1. 事件可能會遲到

  • 2.2.2. 為了處理遲到的資料，你需要設定一個截止時間，即遲到的資料將不再被處理

2.3. 順序和重複傳送

  • 2.3.1. 流平臺通常是由分散式系統構建的，這會導致一些複雜的問題

  • 2.3.2. 訊息可能不按預想的順序傳輸，而且相同的訊息可能被傳輸多次

2.4. 重放

  • 2.4.1. 重放允許訊息的使用者從歷史資料中請求一系列的訊息，允許你將事件倒退到一個過去的特定時間點

  • 2.4.2. 重放是許多流式獲取平臺的關鍵功能，當你需要重新獲取和處理特定時間範圍的資料時，它非常有用

  • 2.4.3. RabbitMQ通常會在所有訂閱者消費完訊息後將其刪除

  • 2.4.4. Kafka、Kinesis和Pub/Sub都支援事件保留和重放

2.5. 生存時間

  • 2.5.1. 最大訊息保留時間，也被稱為生存時間

  • 2.5.1.1. 生存時間是你希望事件在被確認和獲取之前儲存多長時間的設定

  • 2.5.2. 任何在生存時間過期後沒有被獲取的未確認事件都會自動消失

  • 2.5.2.1. 有助於減少事件獲取管道中的背壓和非必要的事件量

  • 2.5.3. 要找到生存時間對我們資料管道影響的正確平衡點

  • 2.5.3.1. 一個極短的生存時間（幾毫秒或幾秒）可能會導致大多數訊息在處理前就消失

  • 2.5.3.2. 一個很長的生存時間（幾周或幾個月）會造成許多未處理訊息的積壓，從而導致很長的等待時間

  • 2.5.4. Google Cloud Pub/Sub支援最長7天的保留期

  • 2.5.5. Amazon Kinesis Data Stream的保留期可以到365天

  • 2.5.6. Kafka可以被配置為無限期保留，僅受限於可用的磁碟空間

  • 2.5.6.1. Kafka還支援將舊訊息寫入雲物件儲存的選項，解鎖幾乎無限的儲存空間和保留期

2.6. 訊息大小

  • 2.6.1. 必須確保你的流框架能夠處理你預期內最大的訊息

2.7. 錯誤處理和死信佇列

  • 2.7.1. 因為訊息大小超標，或者已經過了生存時間，所以事件可能被髮送到一個不存在的主題或訊息佇列

  • 2.7.2. 不能被獲取的事件需要被重新路由並儲存在一個單獨的位置，稱為死信佇列

  • 2.7.3. 死信佇列將有問題的事件和消費者可以正確獲取的事件分開

  • 2.7.4. 資料工程師可以使用死信佇列來診斷為什麼會發生獲取錯誤，並解決資料管道問題

  • 2.7.4.1. 在找到錯誤的根本原因並解決後，就可以重新處理佇列中的訊息了

2.8. 消費者的推送和拉取

  • 2.8.1. Kafka和Kinesis只支援拉取式訂閱

  • 2.8.2. Pub/Sub和RabbitMQ還支援推送式訂閱，允許這些服務將訊息寫到監聽器上

  • 2.8.3. 拉取式訂閱是大多數資料工程應用程式的預設選擇

  • 2.8.4. 如果你新增一個額外的層來處理這個問題，純拉取式的訊息獲取系統仍然可以推送

2.9. 位置

  • 2.9.1. 為了增強冗餘度，我們會整合來自不同位置的資料流並在靠近資料生成的位置消費資料

  • 2.9.2. 你的獲取點越靠近資料生成的位置，你的頻寬和延遲就越好

  • 2.9.3. 需要平衡位置與在區域之間移動資料以在組合資料集上執行分析的成本

相關文章