深入大資料平臺心臟：餓了麼排程系統全解
一、背景
隨著餓了麼在大資料應用的不斷深入，需要解決任務數量增長快、任務多樣化、任務關係複雜、任務執行效率低及任務失敗不可控等問題。
目前現狀：
-
每天完成大資料任務計算54000+；
-
節點叢集85臺。
二、開源解決方案
1、Ooize
Ooize 是基於工作流排程引擎，是雅虎的開源專案，屬於Java Web應用程式。 由Oozie client和Oozie Server兩個元件構成。
Oozie Server運行於Java Servlet容器（Tomcat）中的Web程式。工作流必須是一個有向無環圖，實際上Oozie就相當於Hadoop的一個客戶端，當用戶需要執行多個關聯的MR任務時，只需要將MR執行順序寫入workflow.xml，然後使用Oozie提交本次任務，Oozie會託管此任務流。
2、AzKaban
AzKaban是一套簡單的任務排程服務，是Linkedin的開源專案，開發語言為Java，包括Web Server、DBServer、ExecutorServer，用於在一個工作流內以一個特定的順序執行一組工作和流程，定義了一種KV檔案格式來建立任務之間的依賴關係，並提供一個易於使用的Web使用者介面維護和跟蹤你的工作流：
3、AirFlow
AirFlow 是一個編排、排程和監控workflow的平臺，由Airbnb開源，現在在Apache Software Foundation 孵化。 AirFlow 將workflow編排為tasks組成的DAGs，排程器在一組workers上按照指定的依賴關係執行tasks。同時， AirFlow 提供了豐富的命令列工具和簡單易用的使用者介面以便使用者檢視和操作，並且 AirFlow 提供了監控和報警系統。
三、餓了麼排程系統特性
-
任務建立簡單，執行頻率支援cron表示式；
-
任務拆分為多種任務型別，支援19種任務型別（計算、推送、抽取、檢測）；
-
任務依賴配置簡單，支援不同週期匹配，提供推薦依賴，DAG VIEW功能；
-
排程與執行支援HA，平滑釋出，宕機恢復，負載均衡，監控告警，故障排查，快速擴容，資源隔離。
支援任務型別：
-
推送：SQL/">MySQL推送、HBase推送、Redis推送、Cassandra推送、HiveToX推送、MySQL多推；
-
抽取：資料抽取；
-
檢測：Dal-slave檢測、資料質量檢測、Edsink檢測、抽取資料檢測、資料有效期、匯入匯出校驗；
-
其他：郵件定時任務。
四、餓了麼排程系統整體架構
餓了麼排程系統整體架構包括5個部分——Web服務、排程執行、基礎服務、底層服務，公共設施：
-
Web服務主要提供任務建立、例項管理、任務依賴管理、worker控制、任務監控告警等；
-
排程執行主要由主備Scheduler和多個worker節點組成，負責任務的排程與執行；
-
基礎服務提供了Eless自助釋出，ELK故障排查，Huskar配置中心，Etrace埋點監控，DOG告警等功能；
-
底層服務提供Hive、Spark、Presto、Kylin、Hadoop支援；
-
公共設施包括MySQL、Redis、Zookeeper。
任務執行過程
-
WebService提供的Api建立任務和依賴關係，將任務資訊存入MySQL；
-
Scheduler定時生成第二天所有任務例項，並定時輪詢檢查並改變任務狀態為ready（是否到了執行時間，是否依賴已完成）；
-
Worker 啟動時註冊資訊至Zookeeper，並定時上報機器狀態給Scheduler；
-
Scheduler的ZkWorkerManager監聽Zookeeper，獲取Worker的註冊資訊；
-
獲取ready的任務，TaskPacketFactory將任務構造成TaskPacket，使用對應的SubmitPolicy投遞任務給Worker；
-
Worker通過Thrift接收任務，將任務解析成InterpreterContext，交給對應的Interpreter執行，最終由Dorker執行任務；
-
Docker執行情況返回給Worker，Worker回撥給Scheduler將狀態寫入MySQL。
五、餓了麼排程系統功能
1、任務依賴
任務依賴通過兩種方式配置，推薦依賴和手動依賴：
-
推薦依賴 是通過任務執行完將表和列的資訊存入MySQL，由餓了麼血緣系統根據表的關聯進行推薦；
-
手動依賴 則是人為通過介面設定表的依賴關係。依賴關係支援不同週期的任務依賴，偏移量支援表示式【，】【~】。
2、失敗快速自動重試
-
當任務執行失敗時，系統自動重新調起，預設重試3次；
-
當任務投遞過程中，節點因資源緊張拒絕投遞，排程會根據負載均衡策略嘗試投遞另一臺機器。
3、自助故障排查
-
任務執行錯誤故障排查： 節點提供Http服務，將任務執行的日誌通過http返回給WebService並展示到介面上，提供使用者自助排查。或者通過頁面上的連線訪問餓了麼錯誤分析平臺（Grace）自動分析；
-
任務非執行錯誤排查： 任務排程和執行通過Flume將任務日誌進行收集，通過在Elk上搜索全域性ID即可檢視排程和執行情況。
4、監控告警
-
任務監控告警： 根據使用者設定的告警規則和告警頻率，對任務執行超過完成時間和失敗的進行手機、郵件、釘釘告警；
-
故障監控和告警： 排程和執行節點進行etrace埋點，通過對接收、執行、回撥等關鍵點的進行監測，當指標低於其他節點時間視窗平均值時，進行告警。
5、排程&執行
6、排程主備自動切換
排程器通過向Zookeeper註冊，並隨機選舉出leader提供排程服務。非leader服務監聽leader狀態並wait，當leader出現故障，立即切換為leader角色提供服務。
7、宕機恢復、自我修復
-
當所有排程都宕機時，排程服務未恢復期間，Worker執行節點回調會出現異常。此時任務狀態會存入本地檔案資料庫，並定時重試回撥。當排程服務恢復時，任務狀態恢復正常；
-
當Worker執行節點宕機時，節點上的任務會處於執行中。當節點重啟時，Worker會自我修復執行中的任務，將節點上未調起的任務重新調起，已經執行中的任務通過讀取Docker執行完寫入本地的狀態檔案進行恢復。
8、平滑釋出
當Worker節點進行版本升級時，執行中的任務進行自我修復，同上。
9、資源隔離和快速擴容
-
通過Docker限制每個任務的Memory和CPU資源使用；
-
將依賴的底層服務打包成映象，擴容時便可以很方便的構建需要的環境。
10、節點故障維護
當節點發生故障或則需要維護時，Worker執行節點通過Web介面即可進行在線上下線服務，下線後認為不再接收任務，但不影響節點上執行中的任務執行。
Q & A
Q1：Worker和Scheduler是通過ZK通訊的嗎？
A1：是通過Thrift進行通訊的。
Q2：一般只是將具體的任務指令碼部署到Docker上？Scheduler和Worker是怎麼部署的？
A2：是的，Scheduler和Worker都是單獨的機器分開部署的，Worker需要部署在宿主機上，Dorker執行在Worker機器上。
Q3：Scheduler如何選取住節點？
A3：Scheduler通過註冊Zookeeper，隨機選出一個節點做為leader，非leader節點做為從節點wait，直到leader釋放鎖，見curator實現。
Q4：請問是Docker任務是跑在Yarn上嗎？
A4：Docker是在宿主機器上跑，主要是做了資源隔離和環境隔離。