開發者筆記 | 避免 Airflow DAG 無法順利啟動的幾個原則
這篇文章在討論使用 Apache Airflow 時，開發者經常遇到的 DAG import error 問題，本文描述了問題、可能原因及建議解法。適合正在使用 Airflow 的 Data Product Developer 參考，希望成為錯誤排除的可能依據。
This article addresses common DAG import errors that developers may encounter when using Apache Airflow. It explains the issues, their potential causes, and offers suggested solutions. The article aims to be a helpful reference to troubleshooting errors for data product developers.
資料人最常用的 Batch 工作排程器 — Airflow，相較於 cronjob 使用起來最大的優勢是有個直覺的使用者介面 (user interface) 幫助開發者掌握任務相依性 (task dependency)，當任務失敗時，可以透過 UI 迅速掌握錯誤訊息 (log) 並且重新執行。Airflow 的詳細介紹文章歡迎大家參考由 Jess Hsieh 撰寫的資料工程大小事（三） — 淺談Airflow（概念篇），我個人覺得非常淺白易懂，在此便不贅述。
如此好用的工具，卻也容易因程式碼編排或撰寫不當，讓人踩坑找不到病灶而困擾著。讓我們來看看以下兩個問題。
問題 1：『DAG 直接無法啟動起來，也沒有 log 可以看，怎麼辦？』
先快速回顧一下 DAG、Task 和 Operator 之間的關係。
- DAG：用以建立任務排程，定義任務相依性
- Task：就是任務啦
- Operator：操作子，用來執行特定 script 的單元
這三者的相對關係可以理解為執掌範疇大小的不同，由大到小分別是 DAG > Task > Operator。通常要看到任務執行失敗的 log ，得在 Task 層級定義清楚才行。
所以問題是，DAG 根本沒有啟動，何來 log 呢？
還好，在官方文件 Best Practice 中揭示了一個重要原則：
You should avoid writing the top level code which is not necessary to create Operators and build DAG relations between them.
意思是，不要在啟動 DAG 時就去呼叫 Top Level Code。白話一點地說，不要在定義 DAG 的 .py 檔裡頭編譯一些耗費時間的模組，否則會讓解析程式碼以渲染出 DAG 的過程效能表現不佳，進而影響整個工作流程系統的擴充性 (scalibility)。
可能地雷：在定義 DAG 的 .py 檔裡做以下動作
- 連接資料庫
- 複雜運算
- 網路操作：例如呼叫 API 或下載檔案
建議做法：需要時再引用！
於任務實際執行時，再做連接資料庫、複雜運算或網路操作等行為，避免不預期錯誤出現。總結來說，當 DAG 啟動時有不預期的情況時，可以先檢查定義 DAG 的 .py 檔本身有沒有問題。
問題 2：『確定有安裝必要套件，但為什麼介面突然就顯示 import error？』
從 Airflow 架構中常見的元件 (components) 各自執掌範圍開始說吧！
- Worker：負責執行 Task
- Scheduler：負責解析 DAG 的定義檔，將 DAG 中設定的參數更新至 Metadata Database 中
- Webserver：負責渲染出漂亮的使用者介面。當 Webserver 服務掛掉時，UI 就進不去了
- Metadata Database：存放 DAG 設定、執行結果等 metadata 的資料庫
在 How to avoid DAG Import Errors in Apache Airflow for worker node dependencies? 的回答區有熱心網友提供了一張架構圖，說明了在 1.x 版與 2.x 版的元件相依關係，可以看見最大的差異是，2.x 版的 DAG 是 Scheduler 讀取 DAG Files 解析後寫入 Metadata Database，再取出由 Webserver 渲染於 UI 上；而 1.x 版是 Scheduler 和 Webserver 均讀取 DAG Files。
所以 import error 在 2.x 版發生時，除了真的是需要的套件沒有安裝到或沒有正確引用，還有一個可能是 Scheduler 寫入 Metadata Database 發生不預期的錯誤，例如：負責運行 Scheduler 的 pod 因為不健康因此被重啟，就是一種可能的錯誤情況。
回答區也有另一位網友提到官方文件所寫的：
Airflow scheduler executes the code outside the Operator’s execute methods with the minimum interval of min_file_process_interval seconds.
意思是 Scheduler 會持續地去解析 DAG Files 的變化，確保最新的定義能被解析出來。若碰到了 Top Level Code 的問題，就有可能在渲染 DAG 的時候就出現 import error。
結語｜Takeaways
Airflow 雖然好用且容易運行，不過有些準則還是要留意，避免排程系統逐步擴增後的潛在問題。
- 從架構上把 DAG 與 Task 分乾淨：DAG 專注於定義排程與任務相依性，Task 才去撰寫任務本身的邏輯及引入套件等。
- 留意系統中各個 components 的運行狀態：當錯誤發生時，除了檢查程式碼本身，也要注意 components 的健康狀態。
