[Data] Data Pipeline 101（八） — ETL Job 開發流程

從開發到放棄

介紹一下一般開發 ETL 的流程。每隻 ETL 都可以看作是獨立的程式，有獨立的開發流程。

設計原型

跟一般的軟體開發一樣，先從最關鍵的點開始做 POC，確認商業邏輯和資料是可行的再做後續開發。

如果是簡單的 SQL Aggregation，就先確認 SQL 語法和邏輯沒有問題；如果是比較複雜的流程（例如多個 ETL 轉換），就要先確認每次 SQL 的結果與運算是沒有問題的。等流程確認好之後再著手開發正式的 ETL Job。

一般來說大部分的 ETL Job 流程會很雷同，所以在設計上需要反覆將雷同的部分精煉成共同的元件，這樣 Job 之間只要最小幅度的改動商業邏輯或變項就能快速開發新的 ETL Job。

變數設置

為了減少程式的變動，一些常用容易變化的部分建議抽出來做成變項，同長幾個比較固定的變項會包括：

1. database 和 table 的名稱：對於 ETL 來說， database 和 table 的名稱很容易根據部署的環境和階段來改變，透過變數來管理會比較方便。
2. 連線方式：呈上，連線路徑、帳號密碼也是獨立於商務邏輯會根據狀況改變的部分，所以這部分也需要透過變數來管理。
3. 如果有些 Adhoc Query 只有每次搜尋條件不一樣的話，也可以將 where condition 做成變數，這樣就可以很簡單的下類似的查詢。

測試

通常測試會有幾個階段

1. Unit Test：如果你有自己些處理資料小工具的話，會針對這個小工作來做 Unit Test，例如測試能不能順利讀取檔案、將清除不合法的資料，再將資料存到 DB 去等等。這邊通常會用 Mock 或是小量的資料來做 Unit Test。
2. 整合測試：每個 ETL Job 是由多個小的 Task 組合再一起，這邊主要是測試流程和商務邏輯。
3. Staging 環境測試：Staging 環境理論上資料會近似生產環境，這邊主要是測試 ETL Job 能不能負荷生產環境的資料的量，包括能不能在預定的時間內將結果產出、運算資源是否足夠等。

部署流程

一般程式部署流程就是分 Staging 和生產環境，但是如前面文章說的，資料很的不確定性很高，為了怕資料在意外的情況下污染到正式環境的資料，所以理想上的部署流程上可以分為這幾個階段：

1. 資料來源：Staging；ETL 後的產物：Staging
2. 資料來源：Production；ETL 後的產物：Staging
3. 資料來源：Production；ETL 後的產物：Production

上線後的監測和告警

正式上線後，還是要注意資料品質和 ETL 運行狀況，通常可以分為資料和資源兩個面向來做監測：

• 資料面：基本的包括每天原始資料量、處理後的資料量、以及處理過程中有沒有錯誤的狀況。比較進階的話還會監測幾個關鍵的統計值，確保資料有沒有異常。
• 資源面：包括運算資源以及儲存資源的監控。當 ETL Job 越來越多的時候，就要觀察運算環境的資源夠不夠，不然不同排程的運算相互衝突時，會造成運算失敗或是沒有在預計的時間內完成。
  除此之外，儲存資源的監控也是非常必要，有時候運算單元會在 local 存放暫存檔案，當硬碟爆滿將會造成任務失敗；另外生產環境中的儲存空間也是要持續監控，不管是前端收資料的 Kafka、或是存放最終資料的 DB，一但沒有注意到將會造成資料永久的損失。