[譯] 從 Cron 到 Airflow 的遷移中咱們學到了什麼

• 原文地址：What we learned migrating off Cron to Airflow
• 原文做者：Katie Macias
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：cf020031308
• 校對者：yqian1991

去年秋天，VideoAmp 數據工程部門正在進行重大變革。當時的團隊由三名數據工程師和一名與咱們密切合做的系統工程師組成。咱們集體肯定了如何優化公司的技術債。

當時，數據團隊是全部批處理做業的惟一全部者，這些做業從咱們的實時競價倉庫獲取反饋，提供給 Postgres 數據庫，由 Postgres 數據庫向 UI 填充。若是這些做業失敗，UI 就會過期，咱們的內部交易員和外部客戶將只有陳舊數據可供依據。所以，知足這些做業的服務等級協議對於平臺的成功相當重要。大多數這些做業都是用 Scala 構建的，而且使用了 Spark。這些批處理做業經過 Cron（一種內置於 Linux 的調度工具）被精心地編排。

Cron 的優勢

咱們發現 Cron 形成的一些主要的痛點甚至蓋過了其帶來的好處。 Cron 內置於 Linux 中，無需安裝。此外，Cron 至關可靠，這使它成爲一個吸引人的選擇。所以，Cron 是項目概念證實的絕佳選擇。但成規模使用時效果並很差。

Crontab 文件：之前如何安排應用程序

Cron 的缺點

Cron 的第一個問題是對 crontab 文件的更改不容易追蹤。 crontab 文件包含了在該計算機上運行的做業的調度計劃，這些計劃是跨項目的，但不會在源碼管理中跟蹤，也不會集成到單個項目的部署過程當中。相反，工程師會隨須要進行編輯，但不記錄時間或項目依賴。

第二個問題是做業效果不透明。 Cron 的日誌是輸出到運行做業的服務器上 —— 而不是集中到某處一塊兒。開發人員如何知道做業是成功仍是失敗？不論開發人員是本身瀏覽，仍是須要暴露給下游工程團隊使用，解析日誌獲取這些細節都是昂貴的。

最後，從新運行失敗的做業是權宜且困難的。默認狀況下，Cron 只設置了一些環境變量。新手開發人員常常會驚訝地發現存儲在 crontab 文件中的 bash 命令不會產生與其終端相同的輸出，由於他們的 bash 配置文件中的設置並不存在於 Cron 環境中。這要求開發人員構建出執行命令的用戶環境的全部依賴關係。

很明顯，須要在 Cron 之上構建許多工具才能得到成功。雖然咱們略微解決了一些，但咱們知道有許多功能更強大的開源選項可用。咱們整個團隊使用過的編排工具統共有 Luigi、Oozie 和其餘定製解決方案等，但最終這些經歷仍讓咱們以爲不滿。而 AirBnB 的 Airflow 能入選 Apache 孵化器，這正意味着它衆望所歸。

設置和遷移

以典型的黑客方式，咱們祕密地從現有技術棧中獲取資源，經過設置 Airflow metadb 和主機來證實咱們的想法。

此 metadb 包含了重要的信息，如單向無環圖（DAG）和任務清單、做業的效果和結果，以及用於向其餘任務發送信號的變量。 Airflow metadb 能夠構建在諸如 PostgreSQL 或 SQLite 之類的關係數據庫之上。經過這種依賴，Airflow 能夠擴展到單個實例以外。咱們就挪用了 Amazon RDS 平臺上咱們另外一個團隊用於開發的 PostgreSQL 虛擬機（他們的開發衝刺結束了，他們再也不使用這個實例）。

Airflow 主機安裝在咱們的 spark 開發虛擬機上，是咱們 spark 集羣的一部分。該主機上配置了 LocalExecutor，並運行着調度程序和用於 Airflow 的 UI。安裝在咱們的 spark 集羣中的一個實例上後，咱們的做業具備了執行所須要的 spark 依賴項的權限。這是成功遷移的關鍵，也是以前嘗試失敗的緣由。

從 Cron 遷移到 Airflow 帶來了特殊的挑戰。因爲 Airflow 自帶任務調度，咱們不得不修改咱們的應用程序以獲取新格式的輸入。幸運的是，Airflow 經過變量爲調度腳本提供必要的元信息。咱們還去除了咱們在其中構建的大部分工具的應用程序，例如推送警報和信號。最後，咱們最終將許多應用程序拆分爲較小的任務，以遵循 DAG 範例。

Airflow UI：開發人員能夠清楚地從 UI 中辨別出哪些 Dags 是穩定的，哪些不那麼健壯，須要強化。

獲得的教訓

1. 應用程序臃腫 使用 Cron 時，調度邏輯必須與應用程序緊密耦合。每一個應用程序都必須完成 DAG 的整個工做。這個額外的邏輯掩蓋了做爲應用程序目的核心的工做單元。這使得它既難以調試又難以並行開發。自從遷移到 Airflow 以來，將任務放在 DAG 中的想法使團隊可以開發出專一於該工做單元的強大腳本，同時最大限度地減小了咱們的工做量。
2. 優化了批處理做業的效果呈現 經過採用 Airflow UI，數據團隊的批處理做業效果對團隊和依賴咱們數據的其餘工程部門都是透明的。
3. 具備不一樣技能組合的數據工程師能夠共同構建一個管道 咱們的數據工程團隊利用 Scala 和 Python 來執行 Spark 做業。 Airflow 爲咱們的團隊提供了一個熟悉的中間層，能夠在 Python 和 Scala 應用程序之間創建協議 —— 容許咱們支持這兩種技能的工程師。
4. 咱們的批處理做業調度的擴展路徑很明顯 使用 Cron 時，咱們的調度僅限於一臺機器。擴展應用程序須要咱們構建一個協調層。 Airflow 正爲咱們提供了開箱即用的擴展功能。使用 Airflow，從 LocalExecutor 到 CeleryExecutor，從單個機器上的 CeleryExecutor 到多個 Airflow worker，路徑清晰可見。
5. 從新運行做業變得簡單容易 使用 Cron，咱們須要獲取執行的 Bash 命令，並但願咱們的用戶環境與 Cron 環境足夠類似，以便能爲調試而重現問題。現在，經過 Airflow，任何數據工程師均可以直接查看日誌，瞭解錯誤並從新運行失敗的任務。
6. 合適的警報級別 在 Airflow 以前，批處理做業的全部告警都會發送到咱們的流式數據應用程序的告警郵箱中。經過 Airflow，該團隊構建了一個 Slack 操做符，可被全部 DAG 統一調用來推送通知。這使咱們可以未來自咱們的實時競價堆棧的緊急失敗通知與來自咱們的批處理做業的重要但不緊急的通知分開。
7. 一個表現不佳的 DAG 可能會致使整個機器崩潰 爲您的數據團隊設立規範，來監控其做業的外部依賴性，以避免影響其餘做業的服務等級協議。
8. 滾動覆蓋您的 Airflow 日誌 這應該不言而喻，但 Airflow 會存儲全部它所調用的應用程序的日誌。請務必適當地對日誌進行滾動覆蓋，以防止因磁盤空間不足而致使整個機器停機。

五個月後，VideoAmp 的數據工程團隊規模幾乎增長了兩倍。咱們管理着 36 個 DAG，而且數量還在增長！ Airflow 通過擴展可以讓咱們全部的工程師爲咱們的批處理流程作出貢獻和支持。該工具的簡單性使得新工程師上手相對無痛。該團隊正在快速開發改進，例如對咱們的 slack 頻道進行統一的推送告警、升級到 Python3 Airflow、轉移到 CeleryExecutor，以及利用 Airflow 提供的強大功能。

有任何疑問或意見可在這裏直接詢問，或在下面分享你的經驗。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。