Apache Airflow (一)Intro
Apache Airflow 2.1.2版本紀錄
Apache Airflow Intro
以前在讀書時經常需要利用爬蟲定期排程蒐集資料與清理資料,雖然使用了Linux Crontab定期排程,但在任務管理及任務相依不是那麼友善,而且Debug也比較麻煩一點。在第一份工作的時候看到的開發部門用Azure去做Data Pipeline的管理機制,我那時候是個Python Backend,後來就搜尋了一些資訊找到Apache Airflow這工具,現在人生第二份工作用上了,來記錄一下一些使用心得。
什麼是Apache Airflow?
Airflow 是原先由 Airbnb 開發,而後開源出來的工作排程管理平台,用py撰寫的data pipeline排程、監控工作流平台等。提供了多樣的 operator 可以使用,例如 Bash Operator、Python Operator,甚至可以直接對 GCP、S3、Slack 等等進行操作,少了自己刻輪子的麻煩。
DAG
任務循環的重要組成,DAG(Directed Acyclic Graph)意為有向無環圖,主要做任務的關係及依賴。
a任務完成後 -> 執行b c 任務 完成後 -> 執行d任務 而無論任務如何指向,最後都會在d任務結束。
組成元素
Webserver
Webserver是用Flask + Gunicorn架設而成,可以單獨運作及分開部署,若只有 WebServer 沒有其他組成元素,也就只能查看 DAG、Task等一些資訊而已。可用圖形化介面觀看任務排程管理、Log等機制。
Scheduler
Scheduler 負責排程,這裡的排程並不是直接指定哪個 Task 給哪個 Worker 運行,而是從 Metadata Database(你使用的Database) 中查DAG跟Task找尋 DAG 跟 Task 的狀態,並判斷是否將哪些 Task 傳送給 Executor 安排執行。
(會持續監控所有的 DAG 與工作,當有符合條件的工作就會觸發使其執行。)
Executor 定義任務該如何被執行
Executor 會從 Scheduler 接收要執行的 Task,並將這些資訊存進 Queue,並從 Queue 中取出 Task 安排給閒置的 Worker 執行。
SequentialExecutor
:一次只執行一個任務。LocalExecutor
:單台電腦executer,一樣可以起多個Worker(MultiProcess)。CeleryExecutor
:分散式架構 Celery ,用Task Queue 作 Executor,因此可以在多台電腦同時運行多個 Worker。
Worker
Worker 負責實際執行Task。實際的排程工作就是交由 Worker 來執行,同一個 Airflow cluster 中可以有多個 Worker,並且可通過指定 worker queue 使工作能在特定的資源上運作。
Metadata database
用來存取Airflow資料的資料庫。
簡單的敘述後,在後面的會邊實作邊紀錄使用的筆記及概念。
工作流管理工具的比較
來源: Data Pipeline With Airflow
為什麼選擇Airflow?
- 可以使用 Python 中可以想到的任何東西來創建任意複雜的管道。
- 有Airflow 的 Python 基礎讓許多不同系統的整合及延伸變得容易。Airflow 社區已經開發了豐富的延伸與整合,允許 Airflow 與許多不同類型的數據庫、雲服務等。
- 豐富的調度任務語義,允許定期運行管道及建立使用,增量處理的高效管道,以避免對現有結果進行昂貴的重新計算。
- Backfill等功能能夠輕鬆(重新)處理歷史數據,允許在更改Code後重新計算任何python dataset。
- Airflow 的Web 界面提供了一個簡單的UI,用於監控管道運行的結果和調試可能發生的任何故障。
- Airflow 的另一個優勢是它是開源的,這保證可以在 Airflow 上構建您的工作,而不會陷入任何商業鎖定的困境。幾家公司也提供託管 Airflow 解決方案(如果需要一些技術支持),在如何運行和管理 Airflow 安裝方面具有很大的靈活性。
為什麼不選擇Airflow?
雖然 Airflow 具有許多豐富的功能,但 Airflow 的一些設計選擇可能不太適合某些情況。 例如:
- 處理streaming data,因為 Airflow 主要設計用於運行重複性或Batch Data的任務,而不是Streaming workflow。
2. 較少或沒有Python使用經驗的團隊,使用帶有UI的workflow工具(例如: Azure data factory)或靜態的workflow定義可能更有用處。
3. 若是用在更大的系統或資料應用,DAG中的Python Code會很快變得複雜,因此需要對Airflow進行適當的軟體工程架構或設計模式,實施與維護,保持長期的擴展及維護性,避免留下技術債。
最後,Airflow 主要是一個工作流/管道管理平台,目前不包括更廣泛的功能,例如maintain data lineages、data version control等。 如果需要這些功能,可能需要考慮將 Airflow 與提供這些功能的其他專業工具結合起來。
每個團隊有每個團隊適合的工具,以上的簡單介紹,或許可以讓大家稍微了解Airflow是不是適合在團隊中,或許透過比較圖也能找到較適合的管理工具。
以下是我接下來會主要參考的資料,會依照實作中碰到的陸續增加。
Reference
Book: Data pipeline with airflow. Bas Harenslak and Julian De Ruiter.