介紹一下一般開發 ETL 的流程。每隻 ETL 都可以看作是獨立的程式，有獨立的開發流程。但是不同的 ETL 程式又可以使用類似的系統或架構來幫助開發和管理。

Initiate & Design

資料面

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

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

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

系統面

以下就提幾點在設計 Data Pipeline 系統時，通常需要考量的點：

• 資料延遲性
  這邊的延遲性是只說從收到資料到處理資料需要多久時間、可以容忍多久的延遲？這會影響到資料需要做即時處理還是批次處理？例如硬體系統的監控資料、或是線上使用者人數可能需要即時，或至少五分鐘內的資料。如果像是每天看的 BI 報表，需要等前一天的資料都收完才能計算的，處理頻次就是每天一次，相對來說也可以容忍比較大的延遲。

• 資料精準性
  在計算資料時，需要到多精準？例如銀行的金額就沒有容許誤差的可能；但是像是線上即時使用者數、或是推文數就多少有誤差的空間。那另外像處理即時資料時，要求是「最少一次」還是「僅此一次」？對於資料先後順序有沒有特別要求？如果使用者每天需要 Aggregate 一次資料，那原始資料中每條資料的先後順序或許就沒有太大影響。

• 系統的高可用性
  一般來說越接近資料源的「資料收集」系統，越注重高可用性。因為最源頭的資料一但掉了就ＧＧ了。必須讓原始資料儘早落地，才能安心做後續資料清洗或計算等開發。

• 其他維運面考量
  系統能不能支援版本回滾？
  資料處理邏輯有時候難免會更新，如果錯的話能不能快速回滾的之前的版本重跑資料？

• 紀錄任務進行時間
  能不能量測每次的時間，如果有天處理時間異常增加能不能發送告警？

• 防止錯誤資料進入正式環境
  資料處理有件有趣的事情是，即便程式邏輯正確，也不代表商業邏輯正確。通常一個新上線或是新修改後的資料處理程式，不會馬上將結果導入正式環境中以免污染當前的資料。如何透過環境設定切割來做到這件事，後面會有專文討論。

• 資源監控
  能否簡單監控甚至預測所需資源？

• 易於開發/部署
  開發 Data Pipeline 系統的人，和之後使用 Data Pipeline 建立任務的人可能是不同的兩群人（例如系統架構師開發系統、之後交由資料工程師建立任務）。那這套系統使用的語言能不能符合之後使用者主要的開發語言？或能不能允許其他語言來使用（例如 Python 或 Shell Script）

• 自動化的維運工具
  Data Pipeline 系統和其他任何軟體系統一樣都需要維運，越自動的維運機制以及越完整的自我修復功能，都能大大降低未來的負擔。

Implement

變數設置

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

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

• 連線方式
  呈上，連線路徑、帳號密碼也是獨立於商務邏輯會根據狀況改變的部分，所以這部分也需要透過變數來管理。

如果有些 Adhoc Query 只有每次搜尋條件不一樣的話，也可以將 where condition 做成變數，這樣就可以很簡單的下類似的查詢。

測試

通常測試會有幾個階段

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

• 整合測試：每個 ETL Job 是由多個小的 Task 組合再一起，這邊主要是測試流程和商務邏輯。
  Staging 環境測試：Staging 環境理論上資料會近似生產環境，這邊主要是測試 ETL Job 能不能負荷生產環境的資料的量，包括能不能在預定的時間內將結果產出、運算資源是否足夠等。

Deployment

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

• 資料來源：Staging；ETL 後的產物：Staging
• 資料來源：Production；ETL 後的產物：Staging
• 資料來源：Production；ETL 後的產物：Production

Evaluation

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

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

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

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

小結

跟任何一項開發一樣，在實作 Data Pipeline 之前，一定要先確認需求。而且因為資料有重力（Data Gravity），千萬不能只滿足當下需求，更要再多想一點點，不然之後在搬遷或是轉移上會很麻煩滴。