記得第一次參與大數據平臺從無到有的搭建，最開始任務調度就是用的Crontab，分時日月周，各種任務腳本配置在一臺主機上。crontab 使用非常方便，配置也很簡單。剛開始任務很少，用著還可以，每天起床巡檢一下日志。隨著任務越來越多，出現了任務不能在原來計劃的時間完成，出現了上級任務跑完前，后面依賴的任務已經起來了，這時候沒有數據，任務就會報錯，或者兩個任務并行跑了，出現了錯誤的結果。排查任務錯誤原因越來麻煩，各種任務的依賴關系越來越負責，最后排查任務問題就行從一團亂麻中，一根一根梳理出每天麻繩。crontab雖然簡單，穩定，但是隨著任務的增加和依賴關系越來越復雜，已經完全不能滿足我們的需求了，這時候就需要建設自己的調度系統了。

多個任務單元之間往往有著強依賴關系，上游任務執行并成功，下游任務才可以執行。比如上游任務1結束后拿到結果，下游任務2、任務3需結合任務1的結果才能執行，因此下游任務的開始一定是在上游任務成功運行拿到結果之后才可以開始。而為了保證數據處理結果的準確性，就必須要求這些任務按照上下游依賴關系有序、高效的執行，最終確保能按時正常生成業務指標。

Apache Airflow是一種功能強大的工具，可作為任務的有向無環圖（DAG）編排、任務調度和任務監控的工作流工具。Airflow在DAG中管理作業之間的執行依賴，并可以處理作業失敗，重試和警報。開發人員可以編寫Python代碼以將數據轉換為工作流中的操作。

主要有如下幾種組件構成：

具體執行流程：

將各個任務操作組件拖放到工作區，kettle支持各種常見的數據轉換。此外，用戶可以將Python，Java，JavaScript和SQL中的自定義腳本拖放到畫布上。kettle可以接受許多文件類型作為輸入，還可以通過JDBC，ODBC連接到40多個數據庫，作為源或目標。社區版本是免費的，但提供的功能比付費版本少。

XXL-JOB是一個分布式任務調度平臺，其核心設計目標是開發迅速、學習簡單、輕量級、易擴展。將調度行為抽象形成“調度中心”公共平臺，而平臺自身并不承擔業務邏輯，“調度中心”負責發起調度請求；將任務抽象成分散的JobHandler，交由“執行器”統一管理，“執行器”負責接收調度請求并執行對應的JobHandler中業務邏輯；因此，“調度”和“任務”兩部分可以相互解耦，提高系統整體穩定性和擴展性。（后來才知道XXL是作者名字拼音首字母縮寫）

調度系統開源工具有很多，可以結合自己公司人員的熟悉程度和需求選擇合適的進行改進。

調度平臺其實需要解決三個問題：任務編排、任務執行和任務監控。

調度平臺設計中還需要注意以下幾項：

ETL 開發是數據工程師必備的技能之一，在數據倉庫、BI等場景中起到重要的作用。但很多從業者連 ETL 對應的英文是什么都不了解，更不要談對 ETL 的深入解析，這無疑是非常不稱職的。做ETL 你可以用任何的編程語言來完成開發，無論是 shell、python、java 甚至數據庫的存儲過程，只要它最終是讓數據完成抽取（E）、轉化（T）、加載（L）的效果即可。由于ETL是極為復雜的過程，而手寫程序不易管理，所以越來越多的可視化調度編排工具出現了。

不管黑貓白貓，只要能逮住老鼠就是好貓。不管是哪種工具，只要具備高效運行、易于維護兩個特點，都是一款好工具。