接續上篇

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

Implment

設計原型

跟一般的軟體開發一樣，先從最關鍵的點開始做 POC，確認商業邏輯和資料是可行的再做後續開發。
如果是簡單的 SQL Aggregation，就先確認 SQL 語法和邏輯沒有問題；如果是比較複雜的流程（例如多個 ETL 轉換），就要先確認每次 SQL 的結果與運算是沒有問題的。等流程確認好之後再著手開發正式的 ETL Job。
一般來說大部分的 ETL Job 流程會很雷同，所以在設計上需要反覆將雷同的部分精煉成共同的元件，這樣 Job 之間只要最小幅度的改動商業邏輯或變項就能快速開發新的 ETL Job。

變數設置

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

database 和 table 的名稱

對於 ETL 來說， database 和 table 的名稱很容易根據部署的環境和階段來改變，透過變數來管理會比較方便。

連線方式

呈上，連線路徑、帳號密碼也是獨立於商務邏輯會根據狀況改變的部分，所以這部分也需要透過變數來管理。
如果有些 Adhoc Query 只有每次搜尋條件不一樣的話，也可以將 where condition 做成變數，這樣就可以很簡單的下類似的查詢。

設計模式標準化

ELT 通常會有相似的模式，身為開發者當然希望能盡量減少重複，所以需要思考怎麼讓 ETL 的過程變得標準化，減少開發時間。更有人認為資料工程師不應該寫 Airlfow DAG，而是要開發能夠產生 DAG 的工具。

Data Engineers Shouldn’t Write Airflow Dags — Part 1

測試

通常測試會有幾個階段

Unit Test

如果你有自己些處理資料小工具的話，會針對這個小工作來做 Unit Test，例如測試能不能順利讀取檔案、將清除不合法的資料，再將資料存到 DB 去等等。這邊通常會用 Mock 或是小量的資料來做 Unit Test。

整合測試

每個 ETL Job 是由多個小的 Task 組合再一起，這邊主要是測試流程和商務邏輯。

Staging 環境測試

Staging 環境理論上資料會近似生產環境，這邊主要是測試 ETL Job 能不能負荷生產環境的資料的量，包括能不能在預定的時間內將結果產出、運算資源是否足夠等。

Deployment

一般程式部署流程就是分 Staging 和生產環境，但是如前面文章說的，資料很的不確定性很高，為了怕資料在意外的情況下污染到正式環境的資料，就會使用「兩階段轉換」。將處理完的結果，先放到別的地方，等資料驗證沒有問題後，再進入正式的 DB。

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

從測試到正式環境

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

• 測試資料 => 測試資料處理程式 => 測試 DB（先確認資料處理程式正確）

• 測試資料 => 正式資料處理程式 => 測試 DB

• 正式資料 => 正式資料處理程式 => 測試 DB （確認資料處理程式能應付正式資料）

• 正式資料 => 正式資料處理程式 => 正式 DB

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

正式資料 => 正式資料處理程式 => 暫存區 => 確認資料品質 => 正式DB
其他變形應用

當然除了放到暫存區之外，也可以直接在程式裡確認程式品質，放在同一個處理程式中：
正式資料 => 「正式資料處理程式 => 暫存區（in memory） => 確認資料品質」 => 正式DB

當然當資料量大，或是需要累積多一點資料一起驗證時，還是會先落地在檢查。
正式資料 => 正式資料處理程式 => 暫存區（in db 或其他persistance storage） => 確認資料品質 => 正式DB

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

Evaluation

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

資料面

基本的包括每天原始資料量、處理後的資料量、以及處理過程中有沒有錯誤的狀況。比較進階的話還會監測幾個關鍵的統計值，確保資料有沒有異常。

資源面

包括運算資源以及儲存資源的監控。當 ETL Job 越來越多的時候，就要觀察運算環境的資源夠不夠，不然不同排程的運算相互衝突時，會造成運算失敗或是沒有在預計的時間內完成。

除此之外，儲存資源的監控也是非常必要，有時候運算單元會在 local 存放暫存檔案，當硬碟爆滿將會造成任務失敗；另外生產環境中的儲存空間也是要持續監控，不管是前端收資料的 Kafka、或是存放最終資料的 DB，一但沒有注意到將會造成資料永久的損失。

Iteration

加工資料如同原始資料可以分為一次性的以及會持續產生的。需要注意的問題也跟原始資料一樣，如果要更改持續產生的加工資料，需要特別注意不要影響到現有的資料管線，非常推薦使用二階段驗證的方式來做迭代，以確保資料品質穩定。