【文章內(nèi)容簡介】 Solr4提供了NRTsoftmit的解決方案，softmit無需進(jìn)行提交索引操作，就可以搜素到最新對索引的變更，不過對索引的變更并沒有syncmit到硬盤存儲上，若發(fā)生意外導(dǎo)致程序非正常結(jié)束，未mit的數(shù)據(jù)會丟失，因此需要定時的進(jìn)行mit操作。平臺中對數(shù)據(jù)的索引和存儲操作是異步的，可以大大提高可用性和吞吐量；只對某些屬性字段做索引操作，存儲數(shù)據(jù)的標(biāo)識key，減少索引的大?。粩?shù)據(jù)是存儲在分布式存儲HBase中的，HBase對二級索引搜索支持的不好，然而可以結(jié)合Solr搜索功能進(jìn)行多維度的檢索統(tǒng)計(jì)。索引數(shù)據(jù)和HBase數(shù)據(jù)存儲的一致性，也就是如何保障HBase存儲的數(shù)據(jù)都被索引過，可以采用confirm確認(rèn)機(jī)制，通過在索引前建立待索引數(shù)據(jù)隊(duì)列，在數(shù)據(jù)存儲并索引完成后，從待索引數(shù)據(jù)隊(duì)列中刪除數(shù)據(jù)。7)日志收集在整個交易過程中，會產(chǎn)生大量的日志，這些日志需要收集到分布式存儲系統(tǒng)中存儲起來，以便于集中式的查詢和分析處理。日志系統(tǒng)需具備三個基本組件，分別為agent（封裝數(shù)據(jù)源，將數(shù)據(jù)源中的數(shù)據(jù)發(fā)送給collector），collector（接收多個agent的數(shù)據(jù)，并進(jìn)行匯總后導(dǎo)入后端的store中），store（中央存儲系統(tǒng)，應(yīng)該具有可擴(kuò)展性和可靠性，應(yīng)該支持當(dāng)前非常流行的HDFS）。開源的日志收集系統(tǒng)業(yè)界使用的比較多的是cloudera的Flume和facebook的Scribe，其中Flume目前的版本FlumeNG對Flume從架構(gòu)上做了較大的改動。在設(shè)計(jì)或者對日志收集系統(tǒng)做技術(shù)選型時，通常需要具有以下特征：a、應(yīng)用系統(tǒng)和分析系統(tǒng)之間的橋梁，將他們之間的關(guān)系解耦b、分布式可擴(kuò)展，具有高的擴(kuò)展性，當(dāng)數(shù)據(jù)量增加時，可以通過增加節(jié)點(diǎn)水平擴(kuò)展日志收集系統(tǒng)是可以伸縮的，在系統(tǒng)的各個層次都可伸縮，對數(shù)據(jù)的處理不需要帶狀態(tài)，伸縮性方面也比較容易實(shí)現(xiàn)。c、近實(shí)時性在一些時效性要求比較高的場景中，需要可以及時的收集日志，進(jìn)行數(shù)據(jù)分析；一般的日志文件都會定時或者定量的進(jìn)行rolling，所以實(shí)時檢測日志文件的生成，及時對日志文件進(jìn)行類似的tail操作，并支持批量發(fā)送提高傳輸效率；批量發(fā)送的時機(jī)需要滿足消息數(shù)量和時間間隔的要求。d、容錯性Scribe在容錯方面的考慮是，當(dāng)后端的存儲系統(tǒng)crash時，scribe會將數(shù)據(jù)寫到本地磁盤上，當(dāng)存儲系統(tǒng)恢復(fù)正常后，scribe將日志重新加載到存儲系統(tǒng)中。FlumeNG通過SinkProcessor實(shí)現(xiàn)負(fù)載均衡和故障轉(zhuǎn)移。多個Sink可以構(gòu)成一個SinkGroup。一個SinkProcessor負(fù)責(zé)從一個指定的SinkGroup中激活一個Sink。SinkProcessor可以通過組中所有Sink實(shí)現(xiàn)負(fù)載均衡；也可以在一個Sink失敗時轉(zhuǎn)移到另一個。e、事務(wù)支持Scribe沒有考慮事務(wù)的支持。Flume通過應(yīng)答確認(rèn)機(jī)制實(shí)現(xiàn)事務(wù)的支持，參見下圖，通常提取發(fā)送消息都是批量操作的，消息的確認(rèn)是對一批數(shù)據(jù)的確認(rèn)，這樣可以大大提高數(shù)據(jù)發(fā)送的效率。f、可恢復(fù)性FlumeNG的channel根據(jù)可靠性的要求的不同，可以基于內(nèi)存和文件持久化機(jī)制，基于內(nèi)存的數(shù)據(jù)傳輸?shù)匿N量比較高，但是在節(jié)點(diǎn)宕機(jī)后，數(shù)據(jù)丟失，不可恢復(fù)；而文件持久化宕機(jī)是可以恢復(fù)的。g、數(shù)據(jù)的定時定量歸檔數(shù)據(jù)經(jīng)過日志收集系統(tǒng)歸集后，一般存儲在分布式文件系統(tǒng)如Hadoop，為了便于對數(shù)據(jù)進(jìn)行后續(xù)的處理分析，需要定時(TimeTrigger)或者定量(SizeTrigger的rolling分布式系統(tǒng)的文件。8)數(shù)據(jù)同步在交易系統(tǒng)中，通常需要進(jìn)行異構(gòu)數(shù)據(jù)源的同步，通常有數(shù)據(jù)文件到關(guān)系型數(shù)據(jù)庫，數(shù)據(jù)文件到分布式數(shù)據(jù)庫，關(guān)系型數(shù)據(jù)庫到分布式數(shù)據(jù)庫等。數(shù)據(jù)在異構(gòu)源之間的同步一般是基于性能和業(yè)務(wù)的需求，數(shù)據(jù)存儲在本地文件中一般是基于性能的考慮，文件是順序存儲的，效率還是比較高的；數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)一般是基于查詢的需求；而分布式數(shù)據(jù)庫是存儲越來越多的海量數(shù)據(jù)的，而關(guān)系型數(shù)據(jù)庫無法滿足大數(shù)據(jù)量的存儲和查詢請求。在數(shù)據(jù)同步的設(shè)計(jì)中需要綜合考慮吞吐量、容錯性、可靠性、一致性的問題同步有實(shí)時增量數(shù)據(jù)同步和離線全量數(shù)據(jù)區(qū)分，下面從這兩個維度來介紹一下，實(shí)時增量一般是Tail文件來實(shí)時跟蹤文件變化，批量或者多線程往數(shù)據(jù)庫導(dǎo)出,這種方式的架構(gòu)類似于日志收集框架。這種方式需要有確認(rèn)機(jī)制，包括兩個方面。一個方面是Channel需要給agent確認(rèn)已經(jīng)批量收到數(shù)據(jù)記錄了，發(fā)送LSN號給agent，這樣在agent失效恢復(fù)時，可以從這個LSN點(diǎn)開始tail；當(dāng)然對于允許少量的重復(fù)記錄的問題(發(fā)生在channel給agent確認(rèn)的時，agent宕機(jī)并未受到確認(rèn)消息)，需要在業(yè)務(wù)場景中判斷。另外一個方面是sync給channel確認(rèn)已經(jīng)批量完成寫入到數(shù)據(jù)庫的操作，這樣channel可以刪除這部分已經(jīng)confirm的消息?；诳煽啃缘囊?，channel可以采用文件持久化的方式。參見下圖離線全量遵循空間間換取時間，分而治之的原則，盡量的縮短數(shù)據(jù)同步的時間，提高同步的效率。需要對源數(shù)據(jù)比如mysql進(jìn)行切分，多線程并發(fā)讀源數(shù)據(jù)，多線程并發(fā)批量寫入分布式數(shù)據(jù)庫比如HBase,利用channel作為讀寫之間的緩沖，實(shí)現(xiàn)更好的解耦，channel可以基于文件存儲或者內(nèi)存。參見下圖：對于源數(shù)據(jù)的切分，如果是文件可以根據(jù)文件名稱設(shè)置塊大小來切分。對于關(guān)系型數(shù)據(jù)庫，由于一般的需求是只離線同步一段時間的數(shù)據(jù)(比如凌晨把當(dāng)天的訂單數(shù)據(jù)同步到HBase)，所以需要在數(shù)據(jù)切分時(按照行數(shù)切分)，會多線程掃描整個表(及時建索引，也要回表)，對于表中包含大量的數(shù)據(jù)來講，IO很高，效率非常低；這里解決的方法是對數(shù)據(jù)庫按照時間字段(按照時間同步的)建立分區(qū)，每次按照分區(qū)進(jìn)行導(dǎo)出。9)數(shù)據(jù)分析從傳統(tǒng)的基于關(guān)系型數(shù)據(jù)庫并行處理集群、用于內(nèi)存計(jì)算近實(shí)時的，到目前的基于hadoop的海量數(shù)據(jù)的分析，數(shù)據(jù)的分析在大型電子商務(wù)網(wǎng)站中應(yīng)用非常廣泛，包括流量統(tǒng)計(jì)、推薦引擎、趨勢分析、用戶行為分析、數(shù)據(jù)挖掘分類器、分布式索引等等。并行處理集群有商業(yè)的EMCGreenplum，Greenplum的架構(gòu)采用了MPP(大規(guī)模并行處理)，基于postgresql的大數(shù)據(jù)量存儲的分布式數(shù)據(jù)庫。內(nèi)存計(jì)算方面有SAP的HANA，開源的nosql內(nèi)存型的數(shù)據(jù)庫mongodb也支持mapreduce進(jìn)行數(shù)據(jù)的分析。海量數(shù)據(jù)的離線分析目前互聯(lián)網(wǎng)公司大量的使用Hadoop，Hadoop在可伸縮性、健壯性、計(jì)算性能和成本上具有無可替代的優(yōu)勢，事實(shí)上已成為當(dāng)前互聯(lián)網(wǎng)企業(yè)主流的大數(shù)據(jù)分析平臺Hadoop通過MapReuce的分布式處理框架，用于處理大規(guī)模的數(shù)據(jù)，伸縮性也非常好；但是MapReduce最大的不足是不能滿足實(shí)時性的場景，主要用于離線的分析?；贛apRduce模型編程做數(shù)據(jù)的分析，開發(fā)上效率不高，位于hadoop之上Hive的出現(xiàn)使得數(shù)據(jù)的分析可以類似編寫sql的方式進(jìn)行，sql經(jīng)過語法分析、生成執(zhí)行計(jì)劃后最終生成MapReduce任務(wù)進(jìn)行執(zhí)行，這樣大大提高了開發(fā)的效率，做到以adhoc(計(jì)算在query發(fā)生時)方式進(jìn)行的分析?；贛apReduce模型的分布式數(shù)據(jù)的分析都是離線的分析，執(zhí)行上都是暴力掃描，無法利用類似索引的機(jī)制；開源的ClouderaImpala是基于MPP的并行編程模型的，底層是Hadoop存儲的高性能的實(shí)時分析平臺，可以大大降低數(shù)據(jù)分析的延遲。，一方面原有的MapReduce框架存在JobTracker單點(diǎn)的問題，另外一方面JobTracker在做資源管理的同時又做任務(wù)的調(diào)度工作，隨著數(shù)據(jù)量的增大和Job任務(wù)的增多，明顯存在可擴(kuò)展性、內(nèi)存消耗、線程模型、可靠性和性能上的缺陷瓶頸；yarn對整個框架進(jìn)行了重構(gòu)，分離了資源管理和任務(wù)調(diào)度，從架構(gòu)設(shè)計(jì)上解決了這個問題。參考Yarn的架構(gòu)10)實(shí)時計(jì)算在互聯(lián)網(wǎng)領(lǐng)域，實(shí)時計(jì)算被廣泛實(shí)時監(jiān)控分析、流控、風(fēng)險控制等領(lǐng)域。電商平臺系統(tǒng)或者應(yīng)用對日常產(chǎn)生的大量日志和異常信息，需要經(jīng)過實(shí)時過濾、分析，以判定是否需要預(yù)警；同時需要對系統(tǒng)做自我保護(hù)機(jī)制，比如對模塊做流量的控制，以防止非預(yù)期的對系統(tǒng)壓力過大而引起的系統(tǒng)癱瘓，流量過大時，可以采取拒絕或者引流等機(jī)制；有些業(yè)務(wù)需要進(jìn)行風(fēng)險的控制，比如彩票中有些業(yè)務(wù)需要根據(jù)系統(tǒng)的實(shí)時銷售情況進(jìn)行限號與放號。原始基于單節(jié)點(diǎn)的計(jì)算，隨著系統(tǒng)信息量爆炸式產(chǎn)生以及計(jì)算的復(fù)雜度的增加，單個節(jié)點(diǎn)的計(jì)算已不能滿足實(shí)時計(jì)算的要求，需要進(jìn)行多節(jié)點(diǎn)的分布式的計(jì)算，分布式實(shí)時計(jì)算平臺就出現(xiàn)了。這里所說的實(shí)時計(jì)算，其實(shí)是流式計(jì)算，概念前身其實(shí)是CEP復(fù)雜事件處理，相關(guān)的開源產(chǎn)品如Esper，業(yè)界分布式的流計(jì)算產(chǎn)品YahooS4,Twitterstorm等，以storm開源產(chǎn)品使用最為廣泛。對于實(shí)時計(jì)算平臺，從架構(gòu)設(shè)計(jì)上需要考慮以下幾個因素：伸縮性隨著業(yè)務(wù)量的增加，計(jì)算量的增加，通過增加節(jié)點(diǎn)處理，就可以處理。高性能、低延遲從數(shù)據(jù)流入計(jì)算平臺數(shù)據(jù)，到計(jì)算輸出結(jié)果，需要性能高效且低延遲，保證消息得到快速的處理，做到實(shí)時計(jì)算。可靠性保證每個數(shù)據(jù)消息得到一次完整處理。容錯性系統(tǒng)可以自動管理節(jié)點(diǎn)的宕機(jī)失效，對應(yīng)用來說，是透明的。Twitter的Storm在以上這幾個方面做的比較好，下面簡介一下Storm的架構(gòu)。整個集群的管理是通過zookeeper來進(jìn)行的。客戶端提交拓?fù)涞絥imbus。Nimbus針對該拓?fù)浣⒈镜氐哪夸浉鶕?jù)topology的配置計(jì)算task，分配task，在zookeeper上建立assignments節(jié)點(diǎn)存儲task和supervisor機(jī)器節(jié)點(diǎn)中woker的對應(yīng)關(guān)系。在zookeeper上創(chuàng)建taskbeats節(jié)點(diǎn)來監(jiān)控task的心跳；啟動topology。Supervisor去zookeeper上獲取分配的tasks，啟動多個woker進(jìn)行，每個woker生成task，一個task一個線程；根據(jù)topology信息初始化建立task之間的連接。Task和Task之間是通過zeroMQ管理的；之后整個拓?fù)溥\(yùn)行起來。Tuple是流的基本處理單元，也就是一個消息，Tuple在task中流轉(zhuǎn)，Tuple的發(fā)送和接收過程如下：發(fā)送Tuple，Worker提供了一個transfer的功能，用于當(dāng)前task把tuple發(fā)到到其他的tas