微店很熟悉的乙個詞彙，微店在16年4月之前，資料開發流程和現在是有很多的差異的;
在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，並實現指令碼版本控制，回滾歷史指令碼等一系列功能。
對於大資料開發平台來講，就必須具備比較強的功能特徵;
1.引入版本控制，方便開發人員回滾到之前版本，快速恢復線上排程的任務。
2.規範大資料開發、測試、上線的流程。
3.許可權控制，任務的所有人、管理員才可以操作任務。
4.依賴排程，所有依賴的任務執行成功，自動觸發自身執行。
5.任務執行失敗，傳送執行失敗訊息給任務所有人，人工介入。
6.手動恢復任務，恢復成功後，自動通知下游的任務重新執行。
7.任務依賴圖譜，成功失敗用不同顏色區分，失敗源頭一目了然。
8.任務資訊儲存在資料庫，mars機器採用分布式系統架構，即使單台機器故障也不會影響使用。
9.輸入輸出檢測，判斷輸入表是否準備好，檢測輸出表資料是否完整。
10.合理使用hadoop資源。使用者只能使用所屬團隊指定的hadoop佇列。
大資料開發平台建立在hdfs、yarn、hivemeta的基礎服務之上，目前支援通過hive、kylin查詢資料，後面所有的資料查詢入口將都整合在這裡，包括：es、redis、hades等，大資料平台目前支援shell、hive、mr、spark四種任務型別。
mars體系架構設計的架構圖：
mars大資料開發平台依託於hadoop集群，所有的mars機器都必須安裝hadoop、hive客戶端。mars機器有兩個身份：master&worker。master負責管理job、給worker分配job；worker負責執行job，提交job到hadoop集群，接收job執行的日誌資訊。
到後來就是分布式的體系架構：
對於分布式來講，就有乙個很明顯的問題就是誰是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，重新分配。
後端的工作主要是：
1.使用者在開發中心執行、選中執行或在排程中心手動執行、手動恢復。
2.mars worker機器進行預判斷，包括許可權判斷、指令碼中是否有引數為替換等。
3.worker機器向master機器傳送執行任務請求。
4.master機器收到執行任務請求，把任務加入執行佇列。
5.master機器定時掃瞄執行佇列，選擇合適的worker（負載均衡）執行此任務。
7.執行任務。
8.後置處理。包括資料浮動檢查、舊分割槽清理、新增執行成功標誌等。
前端主要是
1.使用者觸發執行任務。
2.每隔一段時間請求日誌，重新整理到前端頁面。
3.任務執行完畢。
4.如果是開發中心有結果資料，則請求hadoop上的結果資料。
5.進行資料展示。
而對於這個平台來講還存在一些詬病，
1.檢測未跑任務。master掛掉或部署過程中的定時任務不會被觸發，需要有機制發現這種任務。
2.重新部署後，正在執行的任務會重新跑。正在執行的任務會被master取消掉，重新分配執行，如果任務執行需要較長的時間，這樣做就是無法接受的。
3.檢測資料質量。目前輸出表僅簡單的檢測了資料浮動（即資料大小），對於表中的資料內容需要進一步檢測，以保證資料產出的合法性。
這些需要他們下來的發展中進行改進
大資料平台架構
大資料架構分為 資料採集,傳輸,儲存,排程和處理這五個部分.其中任務定期執行和任務分配,分別使用azkaban和zookeeper，大資料平台整體架構如圖1所示，由圖1可知，大資料平台的基礎是伺服器 硬體 所有計算機相關的服務均是基於伺服器 或主機 伺服器是一切服務和資料的根本，用於儲存 通訊 提供...
DKHadoop大資料平台架構詳解
大資料的時代已經來了，資訊的 式增長使得越來越多的行業面臨這大量資料需要儲存和分析的挑戰。hadoop作為乙個開源的分布式並行處理平台，以其高拓展 高效率 高可靠等優點越來越受到歡迎。這同時也帶動了hadoop商業版的發行。這裡就通過大快dkhadoop為大家詳細介紹一下hadoop大資料平台架構內...
微博深度學習平台架構和實踐讀後感
人工智慧為機器賦予人的智慧型。隨著計算機計算能力越來越強，在重複性勞動和數學計算方面很快超過了人類。然而，一些人類通過直覺可以很快解決的問題，例如自然語言理解 影象識別 語音識別等，長期以來很難通過計算機解決。隨著人工神經網路演算法的成熟 gpu計算能力的提公升，深度學習在這些領域也取得了重大的突破...