[Data] Data Pipeline 101（七） — 查核點、安全性、帳密管理

駕馭工具

查核點（checkpoint）

查核點的定義是：在一個 ETL job 中一個獨立的 task，這個獨立的 task 與前後 task 相關聯，但可以查看單獨的狀態、運行狀況、可以獨立執行、重跑。

以上面的圖來說，每個方匡代表的就是一個獨立的查核點。查核點的好處是，如果今天程式段在某個地方，可以不用整個 job 重新來過，只要從壞掉的查核點往後執行就好。

上次有人問說怎樣要切查核點呢？我自己覺得就是當 task 狀態是可以彼此獨立的話就可以切開。比如今天 task 順序是 A-> B，如果 B 查核點運行失敗，不需要從 A 開始執行，直接執行 B 就好，那 B 就是一個可行的查核點。反之，如果切不開，那就不如合併成一個。

安全性

這邊的安全性有幾個地方要注意：

1. 使用者介面：像 Airflow Web Server ，這是是使用者觀察 job 執行的和操作的入口。雖然不能直接刪除 Job，但是仍然可以可以看到 DAG 的 Code。那如果您用的是 Jenkins ，或其他可以直接在 UI 上刪除 Job 的套件，在權限控管上更要小心。
2. Job Runner：Job Runner 通常是用來實際執行 ETL 程式的環境。Job Runner 由於要直接執行各式 ETL，通常會擁有比較多的權限，像是：存取 s3 bucket、存取 Database、Athena，甚至操作其他 AWS 元件等等。所以通常不會直接開放給使用者連線，而是僅開放從公司或特定內部連線存取。

根據以上情況，我們可以從兩方面來控制：

1. 連線管理：網路連線需要一邊管理使用者可以從哪連線，另一邊管理服務可以跟誰連線。一般來說會採取這樣的方式：
   使用者 > UI > Job Runner > Database。
   使用者 > UI > Metadata DB
2. 資源權限管理：在 AWS 上很方便的就是可以透過給予機器 instance_profile 的方式來給予權限，讓 service 可以不用碰到權限管理的問題。但是另外一方面，如果我們都將 Airflow 的 UI / Job Runner 都部署在 k8s 上，要從機器來管理權限恐怕又不是那麼容易。比較理想當然是拆成 node pool，但是現實上…

帳密管理

一個好的程式，就不該把帳號密碼寫在裡面。如果要用到 db connection，可以從環境變數拿，或是像 Airflow 這樣從 secret manager 拿。用統一的 secret manager 拿的好處很多。除了安全之外，當連線資訊要更改時（例如有些公司規定三個月要變更密碼一次），也可以很輕鬆的替換。