每日7千次的跨部門任務排程，有贊怎麼設計大資料開發平臺？

隨著公司規模的增長，對大資料的離線應用開發的需求越來越多，這些需求包括但不限於離線資料同步(MySQL/Hive/Hbase/Elastic Search 等之間的離線同步)、離線計算(Hive/MapReduce/Spark 等)、定時排程、執行結果的查詢以及失敗場景的報警等等。

在統一的大資料開發平臺產生之前，面臨一系列的問題：

• 多個開發和排程入口，不同的業務部門之間的專案或元件很難複用，同時帶來繁重的運維成本
• Hadoop 的環境對業務團隊的同事來講不友好（除了要熟悉業務以外還需要對底層框架有比較深入的瞭解）
• 重複的開發工作（例如導表、排程等本來可以複用的模組，卻需要在多個專案中重複實現）
• 頻繁的跨部門需求溝通和討論

為了解決上述遇到的各類問題，同時參考了業界其他公司的大資料解決方案，我們設計並實現了大資料開發平臺（Data Platform，簡稱 DP），通過視覺化的互動介面，解決離線大資料計算相關的各種環境和工具。

本文將介紹 DP 的系統設計以及在有讚的落地情況，內容包括：

• DP 的系統設計，包括架構設計，以及重點介紹了排程模組的設計
• 目前在有讚的落地現狀
• 總結和展望

大資料開發平臺的設計

架構設計

圖1 DP系統架構圖

大資料開發平臺包括排程模組（基於開源airflow二次開發）、基礎元件（包括公共的資料同步模組/許可權管理等）、服務層（作業生命週期管理/資源管理/測試任務分發/Slave管理等）和監控（機器資源/日誌/基於預測的監控）。這些模組具體功能和職責為：

任務排程模組：支援基於任務優先順序的多佇列、分散式排程。在開源的 airflow 基礎上進行了二次開發，主要新增功能包括：

• 增加多種任務型別（datax/datay/匯出郵件/匯出es/Spark等）
• 根據任務的上下游關係以及重要程度，計算任務的全域性優先順序，根據全域性優先順序排程（優先順序高的優先執行，低的則進入佇列等待）
• 跨 Dag 的任務依賴關係展示（基於全域性 Dag，通過任務的讀寫Hive表資訊建立跨 Dag 的依賴關係）
• 一鍵 Clear 當前節點的所有依賴下游節點（支援跨Dag）

基礎模組：包括離線的全量/增量資料同步、基於Binlog的增量同步、Hive 匯出 ES /郵件、MySQL 同步到 Hbase (開發中)等，參考圖2。

圖2 DP支援的離線資料同步方式（箭頭表示資料流向）

服務模組：負責作業的生命週期管理，包括作業的建立(修改)、測試、釋出、運維等，服務部署採用 Master / Slave 模式，參考圖3所示。其中

• Master 節點支援 HA 以及熱重啟（重啟期間另外一臺提供服務，因此對使用者是無感知的）。Master 節點的主要職責是作業的生命週期管理、測試任務分發、資源管理、通過心跳的方式監控 Slaves 等。

• Slave 節點分佈在排程叢集中，與 Airflow 的 worker 節點公用機器。Slave 節點的主要職責是執行 Master 分發的命令（包括測試、機器監控指令碼等）、更新資源（通過 Gitlab ）等。

圖3 DP 部署圖

監控模組：對排程叢集的機器、資源、排程任務進行全方位的監控和預警。按照監控的粒度和維度分成三類：

• 基礎監控：結合運維監控（程式、IO等）和自定義監控（包括任務環比波動監控、關鍵任務的產出時間監控等）對DP的Master節點和Worker節點進行基礎的監控和報警。
• 日誌監控：通過將任務執行時產出的日誌採集到 Kafka，然後經過 Spark Steaming 解析和分析，可以計算每個任務執行的起止時間、Owner、使用到的資源量（ MySQL 讀寫量、 Yarn 的 CPU / Memory 使用量、排程 Slot 的佔用情況等），更進一步可以分析Yarn任務的實時執行日誌，發現諸如資料傾斜、報錯堆疊資訊等資料。最後將這些資料儲存在 NoSQL（比如 Redis ）以進一步的加工和展示。
• 任務預測監控：通過提前一段時間模擬任務的排程（不真正的跑任務），來預測任務的開始/結束時間，同時可以提早知道可能失敗、超時的任務列表，進而在問題發生之前進行規避。

現階段已經實現的功能：分析可能失敗的任務列表（失敗的原因可能是DB的配置發生更改、上游的節點失敗等）併傳送告警資訊；基於過去一段時間的執行時間資料，模擬整個任務排程，可以計算出任務的開始/結束時間以及超時告警。

未來規劃：任務的執行時長不是基於過去的資料，而是通過讀取的資料量、叢集資源使用率、任務計算複雜程度等多個特徵維度來預測執行時長。

任務排程設計

大資料開發平臺的任務排程是指在作業釋出之後，按照作業配置中指定的排程週期（通過 crontab 指定）在一段時間範圍內（通過開始/結束時間指定）週期性的執行使用者程式碼。任務排程需要解決的問題包括：

1. 如何支援不同型別任務？
2. 如何提供任務排程的高併發（高峰時期每秒需要處理上百個任務執行）？
3. 如何保證相對重要的任務（資料倉儲任務）優先獲取資源並執行？
4. 如何在多臺排程機器上實現負載均衡（主要指CPU/記憶體資源）？
5. 如何保證排程的高可用？
6. 任務排程的狀態、日誌等資訊怎麼比較友好的展示？

為了解決上述問題，我們調研了多種開源框架（Azkaban/Oozie/Airflow等），最終決定採用 Airflow + Celery + Redis + MySQL 作為 DP 的任務排程模組，並結合公司的業務場景和需求，做了一些深度定製，給出瞭如下的解決方案（參考圖4）：

圖4 基於Airflow + Celery + Redis + MySQL的任務排程

針對問題1，在 Airflow 原始的任務型別基礎上，DP 定製了多種任務（實現 Operator ），包括基於 Datax 的匯入匯出任務、基於 Binlog 的 Datay 任務、Hive 匯出 Email 任務、 Hive 匯出 ElasticSearch 任務等等。

針對問題2，一方面通過 Airflow 提供的 Pool + Queue + Slot 的方式實現任務併發個數的管理，以及把未能馬上執行的任務放在佇列中排隊。另一方面通過 Celery 可以實現了任意多臺Worker的分散式部署（水平擴充套件），理論上排程沒有併發上限。

針對問題3，在 Airflow 本身支援的優先順序佇列排程基礎之上，我們根據任務的上下游關係以及標記重要的任務節點，通過全域性DAG計算出每個節點的全域性優先順序，通過將該優先順序作為任務排程的優先順序。這樣可以保證重要的任務會優先排程，確保重要任務產出時間的穩定性。

針對問題4，首先不同型別的任務需要耗費不同型別的資源，比如 Spark 任務是記憶體密集型、Datax 任務是 CPU 密集型等，如果將同一類任務集中在一臺機器上執行，容易導致部分系統資源耗盡而另外一部分資源空閒，同時如果一臺機器的併發任務數過多，容易引起記憶體 OOM 以及 CPU 不斷地切換程式上下文等問題。因此我們的解決方式是：

• 將任務按照需要的資源量分成不同型別的任務，每種型別的任務放到一個單獨的排程佇列中管理。

• 每個佇列設定不同的 Slot ，即允許的最大併發數

• 每臺 Worker 機器同時配置多個佇列

• 基於這些配置，我們可以保證每臺 Worker 機器的 CPU /記憶體使用率保持在相對合理的使用率範圍內，如圖5所示

圖5 排程Worker機器的記憶體使用情況

針對問題5，任務排程模組涉及到的角色包括 Scheduler (生產者)和 Worker (消費者)，因為 Worker 本來就是分散式部署，因此部分機器不可用不會導致整個排程的不可用（其他節點可以繼續服務）。而 Scheduler 存在單點問題，我們的解決方案是除了 Active Scheduler 節點之外，新增一個 Standby Scheduler（參考圖3），Standby節點會週期性地監聽 Active 節點的健康情況，一旦發現 Active Scheduler 不可用的情況，則 Standby 切換為 Active 。這樣可以保證 Scheduler 的高可用。

針對問題6，Airflow 自帶的 Web 展示功能已經比較友好了。

現狀

DP專案從2017年1月開始立項開發，6月份正式投入生產，之後經過了N輪功能迭代，在易用性和穩定性方面有了顯著提升，目前排程叢集包括2臺Master和13臺 Slave（排程）節點（其中2臺用於 Scheduler ，另外11臺用於 Worker )，每天支援7k+的任務排程，滿足資料倉儲、資料中心、BI、商品、支付等多個產品線的應用。

圖6 DP排程任務數趨勢圖

目前DP支援的任務型別包括：

• 離線資料同步：
  • 從 MySQL 到 Hive 的全量/增量資料同步(基於 Datax 二次開發）
  • 從 Hive 到 MySQL 的全量/增量資料同步(基於 Datax 二次開發）
  • 從 MySQL 通過 Binlog ，經過 Nsq/Hdfs/MapReduce 增量同步到 Hive（ Datay ，自研）
  • 從 MySQL 同步到 Hbase (基於 Datax 二次開發）
  • 從 Hive 同步到 ElasticSearch (基於 Datax 二次開發）
• Hadoop 任務：
  • Hive/MapReduce/Spark/Spark SQL
• 其他任務：
  • 將 Hive 表資料以郵件形式匯出（支援 PDF/Excel/Txt 格式的附件）
  • Python/Shell/Jar 形式的指令碼任務

總結和展望

DP 在經過一年半的不斷功能迭代和完善之後，目前日均支援7k+的任務排程，同時在穩定性和易用性方面也有了較大的提升，可以滿足使用者日常對大資料離線開發的大部分使用場景。同時我們也意識到大資料開發這塊還有很多可以挖掘和提升的點，未來我們可能會從這些方面進一步完善平臺的功能和提升使用者體驗：

• 更加豐富的任務型別
• 進一步整合其他平臺或工具，做到大資料開發的一站式體驗
• 提供使用者首頁（空間），提供日常運維工具和管理頁面，更加方便任務的集中管理
• 任務日誌管理優化（包括快速定位出錯資訊/拉取和分析 Yarn 日誌等）

作者簡介：大資料平臺是有贊共享技術的核心團隊之一，該團隊主要由資料技術、資料產品、演算法挖掘、廣告平臺四個小團隊組成，目前共有34位優秀的工程師組成。