[Data] Data Pipeline 101（六） — 二階段轉換

一階段搞不好，就用兩階段啊

沒什麼圖可以用，只好直接口述了。反正概念很簡單。

目的

這邊的轉換就是在說 ETL 從處理原始資料，到進入目標 DB 的過程，這樣的過程稱之為一階段。但是在於處理資料時，就算先前都沒有問題，也不代表以後不會因為資料來源的錯誤而發生問題。

為了避免處理後的壞資料進入正式環境的 DB，就會使用「兩階段轉換」。將處理完的結果，先放到別的地方，等資料驗證沒有問題後，再進入正式的 DB。

然而二階段轉換並不是說單純把資料放到 Staging 環境而已，以下就來說明開發 Data Pipeline 通常的做法，以及環境的區分。

從測試到正式環境

由於 ETL 的正確性涵蓋了兩部分：1. 原始資料的正確 以及 2. 商務邏輯的正確，所以一般來說，比較嚴謹的開發流程會是這樣子：

1. 測試資料 => 測試資料處理程式 => 測試 DB（先確認資料處理程式正確）
2. 測試資料 => 正式資料處理程式 => 測試 DB
3. 正式資料 => 正式資料處理程式 => 測試 DB （確認資料處理程式能應付正式資料）
4. 正式資料 => 正式資料處理程式 => 正式 DB

這邊用的方式其實都只算是一階段的轉換，加入二階段轉換後最終會像這樣。

• 正式資料 => 正式資料處理程式 => 暫存區 => 確認資料品質 => 正式DB

其他變形應用

當然除了放到暫存區之外，也可以直接在程式裡確認程式品質，放在同一個處理程式中：

• 正式資料 => 「正式資料處理程式 => 暫存區（in memory） => 確認資料品質」 => 正式DB

當然當資料量大，或是需要累積多一點資料一起驗證時，還是會先落地在檢查。

• 正式資料 => 正式資料處理程式 => 暫存區（in db 或其他persistance storage） => 確認資料品質 => 正式DB

當資料流是同時結合 mini-batch 一邊收資料和轉換資料，但是只需要 batch 近 DB 時，就很適合使用上面這種方式。例如每十分鐘從 server 那邊收一次 log 資料，但再轉存到正式環境之前，只需要每天確認當天的總數有沒有太大的差異，或是需要合併檢查資料範圍有沒有特別的偏差值就好。這時候中間的暫存區可能就會先放在一個暫存的表格中，當作中繼資料來處理和檢查。