[Data] Data Pipeline 101(七) — 查核點、安全性、帳密管理
Published in
3 min readApr 20, 2020
駕馭工具
查核點(checkpoint)
查核點的定義是:在一個 ETL job 中一個獨立的 task,這個獨立的 task 與前後 task 相關聯,但可以查看單獨的狀態、運行狀況、可以獨立執行、重跑。
以上面的圖來說,每個方匡代表的就是一個獨立的查核點。查核點的好處是,如果今天程式段在某個地方,可以不用整個 job 重新來過,只要從壞掉的查核點往後執行就好。
上次有人問說怎樣要切查核點呢?我自己覺得就是當 task 狀態是可以彼此獨立的話就可以切開。比如今天 task 順序是 A-> B,如果 B 查核點運行失敗,不需要從 A 開始執行,直接執行 B 就好,那 B 就是一個可行的查核點。反之,如果切不開,那就不如合併成一個。
安全性
這邊的安全性有幾個地方要注意:
- 使用者介面:像 Airflow Web Server ,這是是使用者觀察 job 執行的和操作的入口。雖然不能直接刪除 Job,但是仍然可以可以看到 DAG 的 Code。那如果您用的是 Jenkins ,或其他可以直接在 UI 上刪除 Job 的套件,在權限控管上更要小心。
- Job Runner:Job Runner 通常是用來實際執行 ETL 程式的環境。Job Runner 由於要直接執行各式 ETL,通常會擁有比較多的權限,像是:存取 s3 bucket、存取 Database、Athena,甚至操作其他 AWS 元件等等。所以通常不會直接開放給使用者連線,而是僅開放從公司或特定內部連線存取。
根據以上情況,我們可以從兩方面來控制:
- 連線管理:網路連線需要一邊管理使用者可以從哪連線,另一邊管理服務可以跟誰連線。一般來說會採取這樣的方式:
使用者 > UI > Job Runner > Database。
使用者 > UI > Metadata DB - 資源權限管理:在 AWS 上很方便的就是可以透過給予機器 instance_profile 的方式來給予權限,讓 service 可以不用碰到權限管理的問題。但是另外一方面,如果我們都將 Airflow 的 UI / Job Runner 都部署在 k8s 上,要從機器來管理權限恐怕又不是那麼容易。比較理想當然是拆成 node pool,但是現實上…
帳密管理
一個好的程式,就不該把帳號密碼寫在裡面。如果要用到 db connection,可以從環境變數拿,或是像 Airflow 這樣從 secret manager 拿。用統一的 secret manager 拿的好處很多。除了安全之外,當連線資訊要更改時(例如有些公司規定三個月要變更密碼一次),也可以很輕鬆的替換。