Author：放翁（文初）

Email：fangweng@taobao.com

Mblog: weibo.com/fangweng

Blog: http://blog.csdn.net/cenwenchu79/

 

概述

       重要：全文內(nèi)容都是參照這個源碼地址內(nèi)容所寫，因此兩邊對著看會更清晰明了：https://github.com/cenwenchu/beatles

 

這篇小記主要處于兩方面考慮：首先，希望打破一提到海量數(shù)據(jù)分析，就只有hadoop基礎(chǔ)上的一系列工具，更多的時候很多企業(yè)需要的是更輕量的設(shè)計（辦喜酒殺豬殺雞未必都要用一把刀），因此將開放平臺基礎(chǔ)分析組件重構(gòu)版本beatles的設(shè)計寫出來，給出更多的思考空間。其次，也是希望推廣一種思想，所有的系統(tǒng)，框架設(shè)計簡化（可擴(kuò)展），小部件精致化，這樣才能讓很多項目能夠整體靈活，細(xì)節(jié)給力。

 

建議

這篇小記一共分成4部分，概述，整體設(shè)計，局部設(shè)計，待續(xù)。如果你只想了解個背景，那么看完概述即可，如果對于流式分析的大框架設(shè)計感興趣（看看省略了分布式計算集群的什么？核心設(shè)計是怎么樣的），請仔細(xì)看完整體設(shè)計。如果還對代碼優(yōu)化有興趣，那請看局部設(shè)計（細(xì)到代碼功能級別）。最后留下的待續(xù)，將會增加后續(xù)的一些擴(kuò)展，及同學(xué)看完后提出問題的解答（比較通用的一些問題，例如容災(zāi)啊，啥啥啥很多被認(rèn)為很重要的東西）

 

背景

       07年底開始做開放平臺，當(dāng)時每天訪問量在4kw左右，考慮到開放平臺的數(shù)據(jù)透明化需求，開始考慮如何做統(tǒng)計分析，當(dāng)時需求是一天出一次結(jié)果即可，因此自己摸索搭建Hadoop迷你集群，開始了分析之路。09年公司調(diào)整加入淘寶開放平臺，當(dāng)時每天服務(wù)調(diào)用量2億，數(shù)據(jù)分析要求比較散，從服務(wù)的系統(tǒng)數(shù)據(jù)統(tǒng)計到業(yè)務(wù)趨勢統(tǒng)計都有涉及，而且統(tǒng)計需求變化較多，因此開始籌備自己寫簡單的統(tǒng)計抽象模型來規(guī)避MapReduce類，提高適應(yīng)變化的能力，同時出于簡化系統(tǒng)設(shè)計維護(hù)的要求，直接將每日分析數(shù)據(jù)放置到集中服務(wù)器上，每日拉取，切割，分析（統(tǒng)計分析引擎抽象完成）。2010年開放平臺基礎(chǔ)體系開始建立，對于服務(wù)質(zhì)量，應(yīng)用行為，用戶安全都提到了較高的要求上來，分析結(jié)果從原來的統(tǒng)計分析，擴(kuò)展到了監(jiān)控告警，每日分析轉(zhuǎn)變?yōu)樵隽糠治觯l度1小時左右），簡化的任務(wù)調(diào)度模型抽象出來，同時服務(wù)調(diào)用量增漲到了9億。2011年平臺數(shù)據(jù)統(tǒng)計分析及時性要求更高，同時開始開放統(tǒng)計數(shù)據(jù)給外部開發(fā)者（系統(tǒng)可用性和效率要求更高），整體框架和局部設(shè)計不斷優(yōu)化和改進(jìn)，截至今年11月，單日最大服務(wù)調(diào)用量19億，增量統(tǒng)計實時性要求在2分鐘內(nèi)（包含數(shù)據(jù)分析和數(shù)據(jù)產(chǎn)出，低峰期1分鐘，高峰期1分半），系統(tǒng)可用性要求高于99.6％，而投入的服務(wù)器比起動則幾十臺甚至上百上千的Hadoop系統(tǒng)來說，就是一個迷你集群（一臺Master實體機(jī)（16核，16g內(nèi)存），12臺虛擬機(jī)（虛后5核，8g內(nèi)存，實際為4臺實體機(jī)）），每天負(fù)責(zé)600g增量數(shù)據(jù)分析，產(chǎn)出1.5g數(shù)據(jù)。

       很多時候很多開發(fā)人員會問到說在業(yè)務(wù)和代碼結(jié)構(gòu)優(yōu)化沖突的時候怎么辦，老板要結(jié)果，而程序員要的是看起來不惡心的代碼，但很多時候，我們就是在摸索中做事。上面描述的背景就好比開始買的是件夏天穿的短袖，然后天氣不斷變冷，開始給短袖加袖子，然后在身上貼補(bǔ)丁，但最后真的要到冬天的時候，應(yīng)該怎么辦，在秋天和冬天之間，作為核心代碼負(fù)責(zé)人，就應(yīng)該保證系統(tǒng)可用性的情況下做好另一手準(zhǔn)備（簡單來說，時間不是別人給的，而是自己給的，天晴補(bǔ)漏，雨天不愁）。因此年末的兩周將2年中斷斷續(xù)續(xù)走過的路，重新整理了一遍，取名為beatles（甲殼蟲），因為甲殼蟲雖小，但聚集起來能夠吃掉一大片葉子（業(yè)務(wù)系統(tǒng)各種需要分析的數(shù)據(jù)），因此這個框架首先是個很小的內(nèi)核（希望有更多擴(kuò)展和參與者），其次不是一個從頭開始的項目，而是一個兩年多斷斷續(xù)續(xù)演進(jìn)產(chǎn)品的積累。

       Beatles不是一個萬能的技術(shù)產(chǎn)品，它出生和發(fā)展就為它適合的場景做了定義，因此使用和擴(kuò)展的時候需要明確的了解是否合適，避免勿用，下面兩個圖會大志說一下它的特點和適用場景。

       上面這張圖左邊部分是Beatles可以局部犧牲的，右邊部分是場景要求的。由于是對流式數(shù)據(jù)的增量分析，因此對于歷史數(shù)據(jù)的全量挖掘無能為例（這部分完全可以用Hadoop這種離線分析系統(tǒng)來做）。數(shù)據(jù)精確性要求所有數(shù)據(jù)在分析的任何一個環(huán)節(jié)都要做好保護(hù)（數(shù)據(jù)輸入，分析過程，數(shù)據(jù)輸出），而這種強(qiáng)完整性要求勢必會使得系統(tǒng)的效率和可用性降低（和右邊實時性矛盾），因此會被放低一些要求（類似于計費結(jié)算等就直接一天走一次分析即可）。在左面所看重的三個部分大致分布的場景為：監(jiān)控告警（業(yè)務(wù)，系統(tǒng)，用戶，平臺透明化），業(yè)務(wù)即時分析對比（ABtest），系統(tǒng)灰度發(fā)布對比，用戶實時統(tǒng)計展示（非金額等數(shù)據(jù)一致性要求較高的內(nèi)容展示）。

 

整體設(shè)計

       要滿足上面所說的場景，實時流式數(shù)據(jù)分析需要做哪些功能？

任務(wù)調(diào)度抽象

       Beatles的任務(wù)調(diào)度十分簡單，遵循兩個原則：1.按需分配（Slave的多少及Slave自身執(zhí)行任務(wù)的快慢自然促成的分配方式）2.任務(wù)粒度細(xì)化，粗暴簡單的任務(wù)重置（通過透明化監(jiān)控任務(wù)可能出現(xiàn)的問題，避免集群陷入一個任務(wù)的糾結(jié)中）。優(yōu)勢：簡單，高效，易擴(kuò)展（Slave隨時來，隨時走）。劣勢：對于任務(wù)執(zhí)行可控度較弱（通過任務(wù)細(xì)粒度和粗暴重置狀態(tài)的方式來降低風(fēng)險，增加的只是節(jié)點重復(fù)計算的浪費可能性）。

master處理流程

 

       可以看到Master整體就兩部分工作，對內(nèi)部任務(wù)的管理維護(hù)，對外部slave請求的處理（請求獲取任務(wù)，返回處理后的結(jié)果（Slave也可以不返回結(jié)果，根據(jù)Job定義來判斷，防止Master變重））。Master單點并不可怕，只要遵循兩個原則：現(xiàn)場可快速恢復(fù)，分析流程可追趕。因此做到Master所有狀態(tài)定期外移和實時監(jiān)控，即可滿足這種簡單的Master可用性需求。

slave處理流程

       Slave更為單純，整個生命周期就是獲取任務(wù)，分析任務(wù)，返回任務(wù)結(jié)果的一個環(huán)，內(nèi)置一個分析引擎和交互組件，根據(jù)任務(wù)的定義來無差別化的處理各種分析工作（Job定義了數(shù)據(jù)的輸入來源，輸出目標(biāo)地址，分析規(guī)則）。Slave的設(shè)計主要考慮如何做到無業(yè)務(wù)規(guī)則侵入和數(shù)據(jù)來源限制，滿足了這些需求的情況下才能夠?qū)崿F(xiàn)節(jié)點處理無差別性，各種分析任務(wù)可以跑在一個集群上（實現(xiàn)計算節(jié)點可復(fù)用）。

 

任務(wù)抽象

 

       任務(wù)抽象設(shè)計比較簡單，主要結(jié)合任務(wù)調(diào)度設(shè)計，實現(xiàn)計算節(jié)點的無差別化。

       Job是一類分析的定義（例如對gc的日志分析，對服務(wù)調(diào)用日志分析可以定義為兩個Job），Job中的Task表示對于這一類數(shù)據(jù)分析再次拆分任務(wù)，來分解海量數(shù)據(jù)處理，Task中繼承了Job中的輸入和輸出，支持多種模式的數(shù)據(jù)來源和數(shù)據(jù)輸出。Rule就是分析統(tǒng)計模型抽象部分主要分成：Alias（對于分析數(shù)據(jù)的列別名定義），Entry的MapReduce的定義，Report是Entry整合成用戶可接受的Report的定義。

 

統(tǒng)計模型抽象

統(tǒng)計模型抽象主要分為兩部分：統(tǒng)計模型抽象和統(tǒng)計流程抽象。統(tǒng)計模型抽象就是將MapReduce的Key-Value統(tǒng)計，轉(zhuǎn)化成為傳統(tǒng)意義上的報表結(jié)構(gòu)。

 

       分析的輸入:（弱業(yè)務(wù)含義的大表）

       c1,c2,c3,c4,c5,c6

       c1,c2,c3,c4

       c1,c2,c3,c4,c5,c6,c7

       ……

 

 

       MapReduce可以處理的：

      

       

       如下圖，傳統(tǒng)報表的一行可以看作是多個相同key但不同統(tǒng)計字段組合的結(jié)果。

       

       例如：輸入的數(shù)據(jù)結(jié)構(gòu)如下：

       服務(wù)名稱，服務(wù)類型，服務(wù)上行數(shù)據(jù)流量，服務(wù)處理結(jié)果（錯誤碼），服務(wù)耗時

           真實日志如下：（分隔符可在分析時指定，這里用逗號作演示）

           taobao.user.get,read,100,0,20

           taobao.product.add,write,1000,0,50

           ……

 

       那么定制如下MapReduce組合：

       Key：服務(wù)名稱，Value：服務(wù)上行數(shù)據(jù)流量總和。

       Key：服務(wù)名稱，Value：服務(wù)耗時總和。

       Key：服務(wù)名稱，Value：服務(wù)平均耗時。

   Key：服務(wù)名稱，Value：服務(wù)最大耗時。

       Key：服務(wù)名稱，Value：服務(wù)最小耗時。

 

       那么將這些MapReduce處理后的Key-value在組合一次就可以得到：

       Key：服務(wù)名稱，Value：服務(wù)上行數(shù)據(jù)流量總和，服務(wù)耗時總和，服務(wù)平均耗時，服務(wù)最大耗時，服務(wù)最小耗時。

       簡單來說其實就是類似于SQL中的Groupby的方式，將一堆<key，value> groupby  key。

 

分析流程抽象如下：

                                                                                                               

分析流程抽象

流程中可以擴(kuò)展的在第三步和第四步，第三步影響了Key的生成（當(dāng)簡單的列組合成字符串無法滿足生成key的情況下可擴(kuò)展），第四步影響value的生成。（當(dāng)map的value生成以及Reduce無法滿足需求的情況下可擴(kuò)展），要使用min，max…以外的reduce，可以直接在ReduceClass中作處理，然后使用plain輸出實現(xiàn)。

這種流程比傳統(tǒng)的MapReduce的寫法好處在于可以對輸入只讀取一次（海量的日志文件為了多種條件分析，反復(fù)讀取本身就是最大的損耗）。可以看到在文件IO操作上，不會隨著分析模型配置的增多而增長，中間數(shù)據(jù)也不會隨著報表組合的不同而過快膨脹（只要報表復(fù)用Entry足夠多）。

 

整體組件和流程設(shè)計

角色定義

       Beatles內(nèi)部業(yè)務(wù)組件如上圖。

Master包含兩個子組件，JobManager用于管理任務(wù)，MasterConnector用于與Slave通信。

Slave包含三個組件，SlaveConnector用于與服務(wù)端通信，Analysis Engine用于數(shù)據(jù)分析，JobResultMerger可選，用于在客戶端分擔(dān)服務(wù)端匯總結(jié)果的壓力，同時讓Slave可以多線程并行執(zhí)行任務(wù)。（當(dāng)然單機(jī)可以跑多個Slave的實例）。

Job&Task已經(jīng)提到過用于任務(wù)抽象，支持Slave的Analysis Engine的分析無差別性。

Input&output用于擴(kuò)展整個框架的各種數(shù)據(jù)來源，例如job構(gòu)建的來源，job的輸入和輸出等。

 

整體流程

 

1.     Master利用jobManager通過JobBuilder來構(gòu)建服務(wù)端的任務(wù)集合。

2.     Slave向Master發(fā)起要任務(wù)的請求。

3.     通過Master和Slave的Connector來做交互。

4.     MasterConnector向MasterNode內(nèi)部的事件處理模塊提交事件。

5.     JobManager檢查內(nèi)部任務(wù)狀態(tài)后返回未完成且符合條件的任務(wù)返回給Slave。

6.     SlaveNode收到任務(wù)后調(diào)用內(nèi)部分析引擎并行執(zhí)行任務(wù)分析。

7.     分析引擎獲得任務(wù)的數(shù)據(jù)來源，開始分析數(shù)據(jù)。

8.     如果是多個任務(wù)并行執(zhí)行，合并同一個Job的多個Task的結(jié)果。

9.     導(dǎo)出分析后的結(jié)果

10. 如果是需要匯總到Master的話，利用SlaveConnector返回給Master。

11. MasterConnector獲得返回的分析結(jié)果數(shù)據(jù)。

12. MasterNode類似走事件流程，然后調(diào)度到合并組件合并結(jié)果。

13. 當(dāng)Job任務(wù)全部完成就調(diào)用JobExporter導(dǎo)出數(shù)據(jù)。

 

代碼結(jié)構(gòu)體系：sourcecode：（https://github.com/cenwenchu/beatles）

 

整體包結(jié)構(gòu)

        整個項目內(nèi)容不多，根據(jù)包名的前綴可以發(fā)現(xiàn)主要分成兩塊：node，Statistics。前者是任務(wù)調(diào)度及任務(wù)抽象，后者是統(tǒng)計分析模型抽象。

       Config中是多個角色各自的config定義，同時這些config會在一個實體里傳播，例如MasterConfig就在MasterNode中傳播到jobManager和MasterConnector組件中，SlaveConfig就在SlaveNode傳播到分析引擎組件和SlaveConnector中。

       Node中的結(jié)構(gòu)如下：

       Component：對Node的各個組件接口的實現(xiàn)。

       Connect：Master與Slave交互的接口定義和實現(xiàn)。

       Io：對于Job的輸入輸出來源的接口定義和默認(rèn)幾個實現(xiàn)。

       Event：定義了Master和Slave這樣的Node中需要處理的事件。

       Job：任務(wù)抽象定義。

       Map，Reduce：支持當(dāng)分析引擎無法滿足的Map，Reduce的情況。（足夠通用的情況下可以被抽象到主框架中）

       Operation：定義了Node結(jié)構(gòu)中需要異步處理事件。（因為當(dāng)前Node的Event是單線程處理的，因此事件執(zhí)行如果比較消耗，則需要異步后臺執(zhí)行，或者并行執(zhí)行）

       Util包是一些工具類和定義類。

       Staitistics是分析引擎接口和實現(xiàn)，其中Data中是分析規(guī)則的抽象。

 

至此為止，整體的結(jié)構(gòu)設(shè)計就如上所述了，整體上結(jié)構(gòu)比較簡單直接，可擴(kuò)展性為了支持分析規(guī)則擴(kuò)展，不同計算場景擴(kuò)展，效率和可靠性擴(kuò)展。下一個部分將會細(xì)化到具體的模塊代碼設(shè)計上來談優(yōu)化和代碼技巧。

@import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);