大數據開發平臺(Data Platform)在有讚的最佳實踐

前言

隨着公司規模的增加，對大數據的離線應用開發的需求愈來愈多，這些需求包括但不限於離線數據同步(MySQL/Hive/Hbase/Elastic Search 等之間的離線同步)、離線計算(Hive/MapReduce/Spark 等)、定時調度、運行結果的查詢以及失敗場景的報警等等。

在統一的大數據開發平臺產生以前，面臨一系列的問題：

• 多個開發和調度入口，不一樣的業務部門之間的項目或組件很難複用，同時帶來繁重的運維成本
• Hadoop 的環境對業務團隊的同事來說不友好（除了要熟悉業務之外還須要對底層框架有比較深刻的瞭解）
• 重複的開發工做（例如導表、調度等原本能夠複用的模塊，卻須要在多個項目中重複實現）
• 頻繁的跨部門需求溝通和討論

爲了解決上述遇到的各種問題，同時參考了業界其餘公司的大數據解決方案，咱們設計並實現了大數據開發平臺（Data Platform，簡稱 DP），經過可視化的交互界面，解決離線大數據計算相關的各類環境和工具。

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

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

大數據開發平臺的設計

架構設計

圖1 DP系統架構圖

大數據開發平臺包括調度模塊（基於開源airflow二次開發）、基礎組件（包括公共的數據同步模塊/權限管理等）、服務層（做業生命週期管理/資源管理/測試任務分發/Slave管理等）和監控（機器資源/日誌/基於預測的監控）。這些模塊具體功能和職責爲：<br/>

• 任務調度模塊：支持基於任務優先級的多隊列、分佈式調度。在開源的 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 日誌等）