微店大數據開發平臺架構演進

《論語·衛靈公》有云：「工欲善其事，必先利其器。「 意欲警示世人：要作好一件事，準備工做很是重要。簡單來講，與其着急忙慌的開始作一件事，不如沉下心來仔細思考下如何作這件事，畢竟從上海到北京，就算晚出發一天，一個開汽車的也比一個徒步的要早到目的地。今天跟你們分享微店大數據平臺誕生的背景以及含有的功能特性和架構設計。

1、爲何須要大數據開發平臺

微店在16年4月份以前，數據開發流程基本是這樣的：
1.開發人員經過公共帳號登陸安裝了Hive、Hadoop客戶端的gateway機器；
2.編寫本身的腳本，調試代碼，完成後經過crontab配置腳本定時執行；
3.爲了防止腳本被其餘同事修改，一些謹慎的同事會在每次開發完本身的腳本後同步一份到本機，後面爲了實現版本控制，把腳本同步到了git；

能夠說這樣的開發方式連「小米加步槍」都算不上，並且存在諸多問題：
1.效率低下。
2.腳本或代碼沒有版本控制，開發人員想回滾到之前的版本很不方便。
3.若開發人員疏忽，添加新的需求後未通過調試，將可能會影響生成的數據，進而影響線上業務。
4.任務缺少權限控制，可登錄gateway的任何人均可修改、運行腳本。
5.對於腳本中依賴的表，只能預估它天天產生的時間，一旦它產出延遲，將影響數據的產出。
6.任務失敗無任何報警，只能依靠人工發現。
7.任務失敗從新恢復後沒法自動通知依賴下游從新生成。
8.任務失敗要逐層向上遊查找最源頭的任務失敗緣由，排查異常繁瑣。
9.一旦gateway機器故障，全部的任務都將灰飛煙滅，毫無疑問這將是一場災難。

爲此，開發一個大數據開發平臺，提升大數據開發的效率，爲線上天天調度的任務保駕護航已迫在眉睫。
在16年4月份，咱們研究並部署了zeus，公司數據開發效率獲得了顯著提升，解決了開發調試腳本，同步腳本，失敗報警等問題，但同時zeus也存在一些問題，zeus使用的GWT的前端框架，開發新的需求比較繁瑣，開發、發佈任務的流程很不規範，改動很容易就影響線上，帶來線上服務的不穩定。基於這些考慮咱們啓動了二期的開發，而且將二期大數據開發平臺定名爲Mars。Mars底層複用zeus，主要規範數據開發、調試、發佈流程，更換zeus前端框架，改成使用extjs，並實現腳本版本控制，回滾歷史腳本等一系列功能。

2、大數據開發平臺應該具有的功能特性

Mars具有的功能特性：
1.引入版本控制，方便開發人員回滾到以前版本，快速恢復線上調度的任務。
2.規範大數據開發、測試、上線的流程。
3.權限控制，任務的全部人、管理員才能夠操做任務。
4.依賴調度，全部依賴的任務執行成功，自動觸發自身執行。
5.任務執行失敗，發送執行失敗消息給任務全部人，人工介入。
6.手動恢復任務，恢復成功後，自動通知下游的任務從新執行。
7.任務依賴圖譜，成功失敗用不一樣顏色區分，失敗源頭一目瞭然。
8.任務信息存儲在數據庫，Mars機器採用分佈式系統架構，即便單臺機器故障也不會影響使用。
9.輸入輸出檢測，判斷輸入表是否準備好，檢測輸出表數據是否完整。
10.合理使用Hadoop資源。用戶只能使用所屬團隊指定的hadoop隊列。

3、Mars大數據平臺構成

大數據開發平臺創建在HDFS、YARN、HiveMeta的基礎服務之上，目前支持經過Hive、Kylin查找數據，後面全部的數據查詢入口將都集成在這裏，包括：ES、Redis、Hades等，大數據平臺目前支持Shell、Hive、MR、Spark四種任務類型。

4、Mars系統架構設計

Mars系統架構圖：

Mars大數據開發平臺依託於Hadoop集羣，全部的mars機器都必須安裝hadoop、Hive客戶端。Mars機器有兩個身份：master&worker。master負責管理Job、給worker分配Job；worker負責執行Job，提交Job到Hadoop集羣，接收Job執行的日誌信息。

5、分佈式系統架構

誰是master，誰是worker

應用啓動時，機器經過搶佔的方式爭當master，經過在數據庫中插入一條記錄的方式標識當前誰是master，master每隔必定時間去更新數據庫，經過維護一個更新時間間接告知worker它還活着，worker一樣每隔必定時間去查詢數據庫，假若master的更新時間超過必定時間間隔，worker則認爲master故障，第一個發現的worker將當仁不讓的成爲新的master。

master、worker容災模式

master與worker之間使用基於protobuf的netty進行通訊，master會每隔一段時間去檢測與worker的鏈接，若發現worker故障，master將斷開與worker的鏈接，把分配到該故障worker上的任務從新分配到其餘worker上去執行；若master故障，worker將使用搶佔的方式爭當新的master，新的mater將停止全部正在運行的Job，從新分配。

6、定時、依賴調度

定時調度

Mars使用Quartz來實現定時調度。Quartz是一個徹底由java編寫的開源做業調度框架。簡單地建立一個實現org.quartz.Job接口的java類。Job接口包含惟一的方法：public void execute(JobExecutionContext context) throws JobExecutionException，在你的Job接口實現類裏面，添加業務邏輯到execute()方法。一旦配置好Job實現類並設定好調度時間，Quartz將密切注意剩餘時間。當調度程序肯定該是通知你做業執行的時候，Quartz框架將調用你的Job實現類（做業類）的execute()方法，去作它該作的事情。

依賴調度

依賴調度是指該Job全部依賴的Job所有成功運行完畢時須要被觸發的任務類型。當且僅當其全部依賴的任務在當天所有成功運行完畢後，依賴任務將會被觸發執行。那麼依賴調度是如何實現的？

例如，任務1十、112爲定時任務，任務119爲依賴任務，任務119依賴任務1十、112。起初119的狀態爲：依賴JobId：1十、112，已就緒JobId：空。1十、112未就緒，119不執行；凌晨2點任務110執行成功，任務119收到110執行成功事件，狀態更新爲：依賴JobId：1十、112，已就緒JobId：1十、112未就緒，119此時仍然不執行；凌晨3點任務112執行成功，任務119收到112執行成功事件，狀態再次被更新爲：依賴JobId：1十、112，已就緒JobId：1十、112。1十、112均已就緒，觸發119開始執行。

7、執行任務都作了哪些工做

後端
1.用戶在開發中心運行、選中運行或在調度中心手動執行、手動恢復。
2.Mars worker機器進行預判斷，包括權限判斷、腳本中是否有參數爲替換等。
3.worker機器向master機器發送執行任務請求。
4.master機器收到執行任務請求，把任務加入執行隊列。
5.master機器定時掃描執行隊列，選擇合適的worker（負載均衡）執行此任務。
6.前置準備。包括：資源文件下載，數據表數據監測等。
7.執行任務。
8.後置處理。包括數據浮動檢查、舊分區清理、添加執行成功標誌等。
9.若是生成告終果文件，還要上傳結果文件到Hadoop，方便之後下載。
前端
1.用戶觸發執行任務。
2.每隔一段時間請求日誌，刷新到前端頁面。
3.任務執行完畢。
4.若是是開發中心有結果數據，則請求Hadoop上的結果數據。
5.進行數據展現。

8、遺留問題及後續發展方向

遺留問題
檢測未跑任務。master掛掉或部署過程當中的定時任務不會被觸發，須要有機制發現這種任務。
從新部署後，正在運行的任務會從新跑。正在運行的任務會被master取消掉，從新分配執行，若是任務執行須要較長的時間，這樣作就是沒法接受的。
檢測數據質量。目前輸出表僅簡單的檢測了數據浮動（即數據大小），對於表中的數據內容須要進一步檢測，以保證數據產出的合法性。

後續發展方向資源帳單。規範用戶Hadoop資源使用。數據地圖。方便用戶找數據。血緣關係。方便用戶追溯數據來源。數據流動。方便數據互通。