個(gè)性化離線實(shí)時(shí)分析系統(tǒng)pora -- 系統(tǒng)架構(gòu) -- IT技術(shù)博客大學(xué)習(xí) -- 共學(xué)習(xí) 共進(jìn)步！

??? 個(gè)性化離線實(shí)時(shí)分析系統(tǒng)pora
????? 歡迎您，來自新浪微博的朋友！如果喜歡，您也可以把這篇文章分享到新浪微博：，這樣除了作為收藏還分享給了您的朋友！您也可以通過RSS訂閱來獲取我們的文章：Goolge源（推薦）, FeedSky源。
????? 祝您好運(yùn)！

??????? 1.業(yè)務(wù)場景

?????? 伴隨著市場和技術(shù)的發(fā)展，個(gè)性化已經(jīng)成為淘寶搜索的一個(gè)重要目標(biāo)。簡單來說，個(gè)性化就是讓每個(gè)用戶在使用淘寶搜索時(shí)都能夠獲取自己最想要的結(jié)果，而不再是千篇一律的展示。實(shí)現(xiàn)個(gè)性化最直接的手段就是通過分析用戶的歷史行為日志，為用戶打上不同的標(biāo)簽，在搜索中根據(jù)這些標(biāo)簽來展示最貼近的結(jié)果。

?????? 在淘寶，用戶屬性分析是通過每天在云梯上定時(shí)運(yùn)行的map reduce job來完成的，產(chǎn)出結(jié)果導(dǎo)入我們的在線kv存儲(chǔ)ups中，搜索引擎通過查詢ups獲取用戶屬性來為用戶返回個(gè)性化的結(jié)果。在云梯上執(zhí)行的全量計(jì)算能夠進(jìn)行復(fù)雜的模型計(jì)算，并且由于利用了云梯強(qiáng)大的計(jì)算能力，計(jì)算全部用戶幾十天的日志也只需花費(fèi)幾個(gè)小時(shí)。

?????? 全量計(jì)算的不足之處在每次計(jì)算的輸入數(shù)據(jù)都是前一天到前N天的日志，無法將用戶當(dāng)天的行為考慮進(jìn)去，因此得到的用戶屬性永遠(yuǎn)是滯后一天的，無法將某些用戶當(dāng)前的屬性很好地反映出來。實(shí)時(shí)增量彌補(bǔ)了這一空缺，通過實(shí)時(shí)分析用戶的行為日志，將最新的用戶屬性反饋給搜索引擎，能夠?yàn)橛脩粽宫F(xiàn)最貼近其當(dāng)前需求的結(jié)果。

??????? 2.系統(tǒng)需求

?????? 結(jié)合我們的業(yè)務(wù)場景和現(xiàn)狀，對(duì)實(shí)時(shí)分析系統(tǒng)大致有以下幾點(diǎn)需求。

?????? (1)不影響在線查詢的效率。這是一個(gè)最基本的需求，也決定了我們系統(tǒng)的定位：離線分析，將相對(duì)較重的分析過程放在離線階段完成，在線過程只需要查詢離線計(jì)算產(chǎn)出的結(jié)果即可。

?????? (2)實(shí)時(shí)。既然稱為實(shí)時(shí)系統(tǒng)，這也是一個(gè)起碼的要求。至于要多實(shí)時(shí)，初步的目標(biāo)是從用戶一次行為發(fā)生到最后的屬性更新在幾秒內(nèi)完成。

?????? (3)可水平擴(kuò)展。個(gè)性化是一個(gè)需要長期打磨的系統(tǒng)工程，在不同的階段對(duì)系統(tǒng)的容量自然有不同的需求，這就需要我們的系統(tǒng)能夠具備良好的水平擴(kuò)展能力。

?????? (4)能應(yīng)對(duì)復(fù)雜多變的業(yè)務(wù)。算法同學(xué)會(huì)在個(gè)性化方面做各種嘗試，我們系統(tǒng)需要提供便利的方式來支持這些嘗試，最好是能夠?qū)⑾鄬?duì)公用的東西與具體的業(yè)務(wù)邏輯剝離開，簡單來說，就是算法邏輯插件化。

?????? (5)高效。實(shí)時(shí)分析每天需要處理的日志量是巨大的，但是在其業(yè)務(wù)價(jià)值沒有得到足夠證明之前，是不可能占用太多的機(jī)器資源的，因此高效也成為了我們的一個(gè)基本需求。

??? 3.系統(tǒng)架構(gòu)

?????? 說到實(shí)時(shí)分析，前提是實(shí)時(shí)日志收集，這方面淘寶已經(jīng)有了一套的強(qiáng)大的日志收集和分發(fā)系統(tǒng)-TimeTunnel，俗稱TT，TT的延遲在幾百毫秒以內(nèi)，并且提供根據(jù)游標(biāo)來取消息的功能，基本滿足了我們消息對(duì)消息實(shí)時(shí)性和完整性的需求。全量計(jì)算的輸出是實(shí)時(shí)分析系統(tǒng)的另一個(gè)重要的數(shù)據(jù)源，因?yàn)槲覀儗懭氲絬ps提供給搜索引擎的是用戶屬性的最終結(jié)果，合并全量和增量的過程需要在實(shí)時(shí)分析系統(tǒng)中完成。全量計(jì)算是在云梯上完成的，結(jié)果存放在hdfs中，hdfs不能夠提供記錄級(jí)別的操作，考慮到我們的系統(tǒng)需求，必須要有另外一個(gè)提供高效的記錄級(jí)操作的存儲(chǔ)系統(tǒng)來保存這些數(shù)據(jù)。此外，由于算法邏輯通常會(huì)將用戶近兩天的行為都考慮進(jìn)去，我們還需要保存用戶近期的行為記錄。我們選擇hbase作為全量結(jié)果和近期行為數(shù)據(jù)的存儲(chǔ)介質(zhì)，一是由于hbase具有良好的水平擴(kuò)展性，二是由于我們對(duì)hbase的使用比較熟悉。在計(jì)算系統(tǒng)的選型上，我們選擇了人見人愛的開源系統(tǒng)storm.各個(gè)組件的選型確定，整個(gè)系統(tǒng)的架構(gòu)也就出來了。

?????? 系統(tǒng)架構(gòu)

?????? (1)全量數(shù)據(jù)的導(dǎo)入。首先通過distcp方式將云梯上的數(shù)據(jù)拷貝到我們的hadoop集群中，然后使用bulk-load方式將數(shù)據(jù)導(dǎo)入到hbase表中。bulk-load是hbase提供的一種高效的數(shù)據(jù)批量導(dǎo)入工具，具體使用方法可以參考 http://hbase.apache.org/book/arch.bulk.load.html。 全量導(dǎo)入過程每天運(yùn)行一次，我們會(huì)根據(jù)日期新建對(duì)應(yīng)的表。

?????? (2)全量數(shù)據(jù)的切換和刪除。為了讓運(yùn)行在storm中的實(shí)時(shí)分析拓?fù)錂z測并使用到新全量表，我們另外創(chuàng)建了一張全量數(shù)據(jù)索引表，每次導(dǎo)入到新的全量數(shù)據(jù)表時(shí)更新對(duì)應(yīng)的索引，實(shí)時(shí)分析拓?fù)涠ㄆ趻呙杷饕跈z測到索引更新時(shí)自動(dòng)切換到使用新表。

?????? (3)消息完整性的保證。實(shí)時(shí)分析拓?fù)渲袝?huì)保存消息處理的游標(biāo)，并定期刷入到hbase中，這樣即使在節(jié)點(diǎn)失敗或者拓?fù)渲貑⒌那闆r下也能夠恢復(fù)游標(biāo)，處理堆積的消息。

??? 4.實(shí)時(shí)分析拓?fù)?

?????? 當(dāng)一條日志進(jìn)入pora系統(tǒng)后，首先通過解析器解析出若干字段，然后通過過濾邏輯來判斷該條日志是否需要進(jìn)行分析，如果需要，則會(huì)根據(jù)這些字段執(zhí)行需要的join操作，例如將用戶、寶貝的信息補(bǔ)全，然后將join好的日志以及用戶的近期行為和全量屬性傳遞給系統(tǒng)中的算法插件，依次進(jìn)行分析，最后將最新的用戶屬性更新到ups中，提供給外部使用。分析流程對(duì)應(yīng)于storm的拓?fù)浣Y(jié)構(gòu)大致如下：

?????? (1)parser. 負(fù)責(zé)解析日志，根據(jù)配置文件取出需要的字段來。

?????? (2)filter. 過濾邏輯，根據(jù)某些規(guī)則過濾掉一些不感興趣的用戶日志。

?????? (3)joiner. 日志中的字段往往不能夠提供完整的信息，需要一個(gè)join過程來補(bǔ)全字段。在當(dāng)前的實(shí)現(xiàn)中，我們會(huì)根據(jù)日志中的”行為”字段來使用不同的join方式。

?????? (4)analyzer. 主體分析邏輯。我們將這部分做成了一個(gè) framework + plugins 的結(jié)構(gòu)，其中framework負(fù)責(zé)取全量屬性、取近期行為、取當(dāng)前行為，合并計(jì)算結(jié)果。每個(gè)plugin只需要實(shí)現(xiàn)analyze(全量屬性 + 近期行為 + 當(dāng)前行為)的方法。framework對(duì)用戶屬性進(jìn)行了字段切分，每個(gè)plugin只需要關(guān)心自己處理的那個(gè)字段即可。

?????? 在joiner和analyzer階段，我們做了一個(gè)很小的批量處理，不一定每條日志都會(huì)觸發(fā)計(jì)算，只有當(dāng)累積夠一定條數(shù)后，才做一次集中處理，這樣在latency方面會(huì)有一些損失，但是能夠?qū)?duì)hbase的訪問打包，提高h(yuǎn)base的讀寫性能，從而大大提高系統(tǒng)的qps.這個(gè)批量的大小是可配的，用戶可以根據(jù)場景選擇配置，在qps和latency之間做trade-off,當(dāng)配置為1的時(shí)候，就是完全的單條計(jì)算。

?????? (5)updater.負(fù)責(zé)將analyzer計(jì)算后發(fā)生更新的用戶屬性發(fā)送到ups中，繼而提供給搜索引擎使用。

??????? 5.系統(tǒng)監(jiān)控

?????? 監(jiān)控是一個(gè)線上系統(tǒng)必不可少的一部分。我們除了使用了一些基礎(chǔ)的機(jī)器狀態(tài)監(jiān)控外，hbase集群還使用了集團(tuán)hbase團(tuán)隊(duì)開發(fā)的專用監(jiān)控系統(tǒng)，非常直觀。此外，我們還需要一些業(yè)務(wù)指標(biāo)的監(jiān)控，例如我們的qps,latency,gap(日志處理時(shí)間與日志生產(chǎn)時(shí)間質(zhì)檢單 間隔)，這方面也花費(fèi)了我們一些心思。例如latency的監(jiān)控，storm ui本身提供了即時(shí)數(shù)字的顯示，但是沒有我們想要的曲線圖(或許0.9版本中會(huì)有吧)。最后我們選擇了基于hbase的監(jiān)控繪圖工具openTSDB。我們通過借助storm的ack機(jī)制來統(tǒng)計(jì)消息處理的latency,打印到日志中，然后使用一個(gè)腳本來搜集這些信息發(fā)送給openTSDB服務(wù)器來展示曲線。

?????? pora目前在淘寶個(gè)性化搜索中穩(wěn)定運(yùn)行，每天處理幾十億的日志信息，平均延遲在秒級(jí)。

??????? 6.經(jīng)驗(yàn)教訓(xùn)

?????? (1).zookeeper集群獨(dú)立。因?yàn)閦ookeeper無論對(duì)于hbase還是storm都是至關(guān)重要的，最好將其單獨(dú)搞一個(gè)負(fù)載較低的集群。

?????? (2).hbase表的預(yù)分區(qū)。盡量將請(qǐng)求分散到各個(gè)節(jié)點(diǎn)上，至于預(yù)分區(qū)的原則，就根據(jù)業(yè)務(wù)場景來制定了。例如我們?cè)诖鎯?chǔ)用戶全量屬性數(shù)據(jù)時(shí)是按照用戶名做哈希取模的。

?????? (3).storm使用經(jīng)驗(yàn)

?????? (a).根據(jù)需要修改默認(rèn)參數(shù)。這點(diǎn)是顯然的,storm的默認(rèn)參數(shù)并不能符合每個(gè)業(yè)務(wù)場景的需要，在storm源碼中的conf/defaults.xml目錄下有各個(gè)參數(shù)的默認(rèn)取值，用戶可根據(jù)需要修改。

?????? (b).emit tuple時(shí)一定要new list.出于效率的考慮，storm底層的發(fā)送線程不會(huì)對(duì)該list進(jìn)行深拷貝，會(huì)直接使用。如果用戶不小心修改了該list,會(huì)導(dǎo)致一些莫名其妙的失誤。

?????? (c).重啟supervopior前刪除本地data目錄。storm的supervisor會(huì)在本地data目錄保存一些狀態(tài)信息，在某些情況下這些狀態(tài)與zk中的最新狀態(tài)并不能保持一致，如果不刪除data目錄，容易導(dǎo)致supervisor重啟失敗。

個(gè)性化離線實(shí)時(shí)分析系統(tǒng)pora