同時滿足多業務部門調度，有贊怎麼設計大數據開發平臺？

隨着公司規模的增長，對大數據的離線應用開發的需求越來越多，這些需求包括但不限於離線數據同步(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位優秀的工程師組成。