[Data] Data Pipeline 101（三）—ETL
Published in
4 min readMar 22, 2020
老梗但必要
ETL 不管是以前還是在過去都是一件不太被重視也不討喜的工作。但這的確是 Data Pipeline 的核心。
資料在使用之前都必須被處理過。
ETL 真的沒啥好介紹的，概念真的太簡單好懂。
- Extract: 把資料從某個地方拿出來。
- Transform: 將資料作轉換。
- Load: 湊數的一步，把轉換完的資料丟到某個地方。
ETL 之所以必要在於，原始資料通常不適合拿來直接使用的。原因在於：
- 原始資料量太大：通常前端在收資料的時候，都會使用比較鬆散的事件格式，像是 JSON，也通常不會做壓縮。這樣在計算時需要消耗較多的資源，也會影響計算速度。所以通常在使用之前會做最基本的壓縮和格式最佳化。
- 資料不乾淨：通常資料前端收進來的時候，如果沒有處理好，會遇到很多奇怪的狀況，「Garbage in、garbase out」所以確保資料的品質非常重要。比較基本的像是格式、數值範圍，更複雜的一點包括欄位統計值甚至邏輯等等。
- 比較複雜的 Aggregation：資料是隨著事件進來，但是使用上可能會以每小時、每天為單位來進行分析或計算。如果每次畫報表都必須從最原始的資料開始算，會消耗大量計算資源，而且 SQL 或計算也會非常複雜，所以一般來說都會先將原始資料聚合成一些時間粒度稍微「粗」一點的資料，才會來做後續應用。
以下從網路上找幾個應用範例：
標準的清理資料流程
一般來說，資料在進入 Data Warehouse 前，都必須經過這幾個階段，才能供後續業務報表或是視覺化使用。算是基本起手式吧。
在不同層（Layer）的資料之間作轉換
資料傳送到後端後，會經過 ETL 放到 Staging 環境、再透過 ETL 放到 DW、再透過 ETL 整理到了 Data Mart 給 End User 使用。當原始資料越複雜、資料量越多，中間就更需要多層次的處理來確保資料品質以及使用上的效能。
Streaming ETL
當然除了 Batch ETL 外，Streaming ETL 也是有的。可以根據事件、或是 mini batch 的方式來處理原始資料，配合 Batch Process 來處理累積的資料。
總之 ETL 是個很廣泛的領域，不僅僅是「資料處理」四個字而已。還需要考量到軟硬體架構、商務邏輯、後續的使用才能設計最適合的 ETL 流程。
