[譯] 從 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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。