#研發解決方案#分佈式並行計算調度和管理系統Summoner

鄭昀 建立於2015/11/10 最後更新於2015/11/12

關鍵詞：佣金計算、定時任務、數據抽取、數據清洗、數據計算、Java、Redis、MySQL、Zookeeper、azkaban二、oozie、mesos

---

Summoner 是國璽部門推出的基於 MySQL+Redis+Zookeeper 的分佈式並行計算調度和管理系統，李紅紅主設。

 

0x00，爲何要作「數據」並行計算調度？

你們均可能作過 基於 MySQL 數據庫的，大規模的、有步驟的、步驟與步驟之間有依賴關係的數據計算。你可能定義了一堆彼此依賴的定時任務，也可能寫成一個大進程跑。

舉一個實際場景吧，在咱們 O2O 業務體系下，我要作人員規模三四千人、有多條業務線、組織結構爲大區-區域-城市-銷售組的銷售團隊的昨日佣金和當月佣金，這裏的挑戰是：

• 涉及到商戶、門店、交易、折扣、覈銷物料等等，數據量很大，至少天天都要算一次，要算得快，
• 激勵政策和佣金計算公式隨着競爭態勢變化，通常一兩個月變一次，
• 數據抽取儘量少影響正常業務，
• 計算邏輯調整後要能快速部署和運行。

那麼，之前可能會定義一些定時任務，天天凌晨從各個業務數據庫（畢竟全都拆庫分表了）裏抽取：

1. 人員組織架構
2. 大區、區域和城市的對照關係
3. 合同以及合同擁有者
4. 商戶和門店
5. 門店下的收單交易
6. 佣金計算公式、規則以及各類權重因子
7. ……

既有全量數據，也有增量數據，因此數據量是很大的。

先算簽約數、開店數、交易量等，再把業績歸結在 BD 身上，根據不一樣業務線的佣金計算公式依次對 BD、BD主管、城市經理等展開各類計算。

 

雖然咱們的 JobCenter 是很優秀的定時任務調度和管理平臺，但它沒有步驟（即定時任務之間的依賴關係）的概念，因此之前咱們只好拍腦殼定 Job1 凌晨1點執行，Job2 凌晨2點執行，Job3和Job4放在3點執行，顯然這只是無奈之舉， 萬一 Job1 跑到凌晨3點纔算完怎麼辦？萬一 Job1 執行失敗了怎麼辦？

 

什麼是步驟？咱們能夠用下圖來理解一個大計算任務下步驟之間的依賴關係：

圖1

爲了應對這種數據量很大的抽取和一環套一環的計算，咱們須要 另行發展一個界面友好的、有步驟概念的、有集羣調度的數據計算系統，以充分利用機器資源。

 

0x01，他山之玉：azkaban2/oozie/mesos

計算資源的調度，好學生有很多，如針對 hadoop 集羣調度和管理的 azkaban2 和 oozie，抽象能力更高的分佈式資源管理框架 apache mesos。

項目開始之初，我但願借鑑 oozie 和 azkaban2 的一些優秀設計思路，咱們其實也是作調度和管理，只不過它們基於 hadoop，咱們基於 mysql 而已。

 

給我深入印象的調度系統特性有：

1. 計算任務有步驟定義，輸入輸出都有靈活的定義，適合於數據收集、清洗、聚合、計算等各類常見計算場景；
2. 步驟能夠經過依賴關係來定義串行仍是並行；
3. 能夠很直觀地看到當前任務執行時跑到了哪個步驟，或者哪些計算小任務；
• 如 oozie 的界面
4. 能夠很直觀地收集和展現當前任務裏的輸出流以及異常日誌流；
5. 能夠很方便地暫停、終止、重啓任務，無需擔憂遺留垃圾中間數據；
6. 有報警機制，有一些簡單指標展現；
7. 計算任務的步驟定義視覺化
• 如 azkaban2 的界面

因而，國璽李紅紅他們開始動手設計。最終出來的效果還不錯，下面介紹一下。

後來咱們的容器私有云用了 apache mesos，我以爲 mesos 這種高度抽象的資源調度和管理系統很是適合咱們的數據並行計算應用場景，因而假想了一番：咱們寫調度器去和 mesos 通訊，告訴它要去執行什麼命令，它去負責在整個 cluster 裏調度；咱們寫的工程以及控制檯有點兒像 marathon，依託於 mesos+chronos；咱們寫的從不一樣數據源抽取原始數據、計算佣金的代碼，打成 jar 包後放在 mesos master 上，配置好後，mesos slave 真的接到調度指令去運行時，會本身從 master 節點下載 jar 包並執行，blabla……這樣 mesos 能替咱們省了很多開發工做。

 

0x02，Summoner的特性

下面介紹一下咱們針對數據計算的分佈式並行計算調度系統——Summoner（魔法師）。

咱們命名一個大計算任務爲『工做流』，工做流下有多個任務，任務彼此之間能夠可視化地創建依賴關係。

工做流能夠設定 Quartz cron 表示式從而按期執行，能夠直觀地看到任務執行的進度，執行日誌、異常日誌，狀態。

咱們還能夠複用任務，一個任務能夠隸屬於多個工做流。這樣當佣金計算規則變化時，咱們只須要複用一部分任務，新增一些任務，另建一個新工做流把任務串起來便可，同時把原來的工做流禁用，這樣進退自如。

負責執行任務的客戶端（jar包）可以自動註冊（經過 Zookeeper），因而系統知道如今有多少個機器節點能夠執行某一個任務。

因而，假如任務B有了10個客戶端註冊，任務A抽取了一千萬條交易記錄，系統將這批記錄分拆爲十份，發給10個任務B客戶端，因而任務B將在多個機器節點上並行計算，而後系統再去調度任務C。

 

它的菜單功能有：

• 資源配置管理
• 工做流管理
• 任務管理
• 依賴關係管理
• 註冊管理（客戶端註冊和服務器端註冊）
• 任務調度管理
• 調度管理
• 實時數據管理
• 工做流執行狀況
• 調度日誌管理
• 調度日誌

 

下面是首頁工做臺，咱們能夠看到本身賬號下有多少個工做流執行完成/失敗/暫停執行/取消執行，以及系統報警和信息的通知。

圖2 summoner首頁工做臺

 

首先，咱們須要創建工做流：

圖3 資源配置管理-工做流管理

 

咱們還要把任務建起來，任務真正的執行者是一個 Java 實現的任務處理類：

圖4 任務管理

 

圖5 編輯任務

其次，咱們要任務之間的依賴關係創建起來：

圖6 依賴關係管理

 

而後管理工做流：

圖7 工做流圖管理

咱們可讓工做流當即執行，來觀察它的進度：

圖8 調度日誌管理

 

以及每個任務的進度：

圖9 工做流執行詳情

 

集羣裏不一樣節點均可能會捲入工做流執行，它們產生的日誌會被 flume 聚合，以後在平臺上實時展現：

圖10 工做流執行日誌

 

圖11 客戶端註冊

 

圖12 服務器端註冊

 

圖13 系統通知

 

Summoner 是 JobCenter 的延伸和有益補充，它們各自有各自的應用場景。咱們還會借鑑 mesos 的先進理念，進一步提高 Summoner 的集羣調度能力。

 

-EOF-

20160108注：2015年年末也看到了噹噹網對它的「 分佈式任務調度框架：噹噹elastic-job開源項目的10項特性」作了闡述，有一些理念類似，如任務分片，分佈式，值得咱們進一步學習。

歡迎閱讀個人其餘電商文章：

1. 內部Hybrid App經驗解讀
2. iDB是如何運轉的 一
3. #研發解決方案#iDB-數據庫自動化運維平臺
4. 容器私有云和持續發佈都要解決哪些基礎問題 第二集
5. 容器私有云和持續發佈都要解決哪些基礎問題 第一集

 

歡迎訂閱個人微信訂閱號『老兵筆記』，請掃描二維碼關注：