iT邦幫忙

2021 iThome 鐵人賽

DAY 13
0
AI & Data

資料產品開發與專案管理系列 第 13

[Day 13] 資料產品生命週期管理-加工資料(二)

接續上篇

介紹一下一般開發 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 做成變數,這樣就可以很簡單的下類似的查詢。

設計模式標準化

https://ithelp.ithome.com.tw/upload/images/20210913/20141140lI9pGAMcZw.png

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

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


上一篇
[Day 12] 資料產品生命週期管理-加工資料(一)
下一篇
[Day 14] 資料產品生命週期管理-描述型模型
系列文
資料產品開發與專案管理30

尚未有邦友留言

立即登入留言