互聯(lián)網(wǎng)的發(fā)展,，帶來(lái)了日新月異的業(yè)務(wù)種類,，隨著業(yè)務(wù)的增長(zhǎng),，隨之而來(lái)的，是業(yè)務(wù)日志指數(shù)的遞增,。一些公司每條業(yè)務(wù)線,， 提供服務(wù)的線上服務(wù)器就達(dá)幾百臺(tái)之多， 每天的日志量超百億,。如何能夠?qū)⑸⒙湓诟鞣?wù)器上的日志數(shù)據(jù)高效的收集匯總起來(lái),， 成了在數(shù)據(jù)分析處理之前必須解決的問(wèn)題,。

一個(gè)優(yōu)秀的數(shù)據(jù)收集框架，需要具備三點(diǎn)特性,，一是低延遲,，二是可擴(kuò)展,，三是容錯(cuò)性,。

1. 低延遲：從Log數(shù)據(jù)產(chǎn)生到能夠?qū)ζ渥龇治?，希望盡可能快的完成數(shù)據(jù)的收集,。在批處理或者離線分析中,，對(duì)數(shù)據(jù)的實(shí)時(shí)性要求并不高,，但是隨著大數(shù)據(jù)的發(fā)展,，實(shí)時(shí)計(jì)算的能力越來(lái)越強(qiáng),，實(shí)時(shí)分析的場(chǎng)景也越來(lái)越多,，所以對(duì)日志收容的實(shí)時(shí)性要求也越來(lái)越高,。

2. 可擴(kuò)展性：日志分布在服務(wù)器集群上,，由于業(yè)務(wù)或者系統(tǒng)的原因,，集群的服務(wù)器會(huì)發(fā)生變化，如上線,，下線,，宕機(jī)等,，Log收集框架需要能夠相應(yīng)的做出變化,，易擴(kuò)展,，易部署,。

3. 容錯(cuò)性：Log收集系統(tǒng)需要滿足大的吞吐以及承受足夠的壓力,， 這就意味著Log收集系統(tǒng)很可能面臨宕機(jī)的風(fēng)險(xiǎn)， 在這種情況下,， Log系統(tǒng)需要有不丟失數(shù)據(jù)的能力,。

各大互聯(lián)網(wǎng)巨頭都開(kāi)發(fā)了自己的日志收集工具,， 比如Apache的chukwa,，F(xiàn)acebook的scribe,，Cloudera的flume以及ELK stack(歸屬于Elastic.co公司)組合中的logstash,，都是目前比較流行的開(kāi)源的日志收集框架,。 

除此之外,，Linkedin的kafka 和 阿里的TT(TimeTUnel), 也是高效的數(shù)據(jù)傳輸框架,，在其基礎(chǔ)上,，可以方便地搭建出高性能的數(shù)據(jù)收集框架。阿里通過(guò)TT搭建的數(shù)據(jù)收集系統(tǒng),，服務(wù)了一半以上的公司業(yè)務(wù)， 同時(shí)TT在HBase的支撐下,，還可以作為大吞吐的消息隊(duì)列來(lái)使用,。

接下來(lái),，我們就來(lái)逐一的了解一下這些數(shù)據(jù)收集框架,。

chukwa 是Apache 開(kāi)源的針對(duì)大規(guī)模分布式系統(tǒng)的日志收集和分析的項(xiàng)目， 它建立在hdfs以及mr框架的基礎(chǔ)上,，完全繼承了Hadoop的擴(kuò)展性和穩(wěn)定性,。chukwa還包括了一系列組件，用于監(jiān)控?cái)?shù)據(jù),，分析數(shù)據(jù)和數(shù)據(jù)可視化等,。 架構(gòu)圖如下：

從架構(gòu)圖上可以看出， chukwa大致分為五個(gè)部分：

• Hadoop和HBase集群,，用于chukwa處理數(shù)據(jù)

• 一個(gè)或多個(gè)agent進(jìn)程， 將監(jiān)控的數(shù)據(jù)發(fā)送到HBase集群,。 啟動(dòng)有agent進(jìn)程的節(jié)點(diǎn)被稱作監(jiān)控源節(jié)點(diǎn)

• Solr云集群,，用于存儲(chǔ)索引數(shù)據(jù)文件

• 數(shù)據(jù)分析腳本， 概括Hadoop集群的健康狀況

• HICC,， chukwa的可視化工具

由于依賴于mr去處理數(shù)據(jù),，所以chukwa效率注定不會(huì)太高,，整個(gè)數(shù)據(jù)流在數(shù)據(jù)處理間斷吞吐量急劇下降,。 另外,，chukwa設(shè)計(jì)時(shí)就沒(méi)有將它定位為單純的日志收集工具,，而是囊括數(shù)據(jù)的分析處理， 數(shù)據(jù)可視化等功能的完整的數(shù)據(jù)分析框架,， 在這樣的設(shè)計(jì)思路下,， 數(shù)據(jù)收集和數(shù)據(jù)分析倆大任務(wù)在優(yōu)化目標(biāo)上并不相同,，甚至有可能相悖。所以優(yōu)化效果并不明顯,。 

與其如此,，還不如專一的定位在數(shù)據(jù)收集領(lǐng)域,，數(shù)據(jù)分析和處理等交給其他成熟的框架來(lái)實(shí)現(xiàn)， 如Hive,、Impala等,。 也出于這些原因，chukwa并沒(méi)有被廣泛的使用,。

scribe 是Facebook開(kāi)源的日志收集系統(tǒng),，在facebook內(nèi)部被廣泛使用,。 scribe主要用于收集匯總?cè)罩玖?，易擴(kuò)展,，并且能夠保證在網(wǎng)絡(luò)和部分節(jié)點(diǎn)異常情況下的正常運(yùn)行。 其架構(gòu)圖如下：

應(yīng)用系統(tǒng)中每一臺(tái)日志服務(wù)器都會(huì)部署scribe服務(wù),， scribe服務(wù)收集節(jié)點(diǎn)信息，并將數(shù)據(jù)發(fā)送到scribe中央服務(wù),， scribe中央服務(wù)是多組scribe服務(wù)集群,。如果scribe中央服務(wù)不可用,，本地的scribe服務(wù)就會(huì)將信息寫到本地磁盤,，當(dāng)中央服務(wù)可用時(shí)重新發(fā)送,。 scribe中央服務(wù)將數(shù)據(jù)寫入到最終的目的地，典型的存儲(chǔ)包括nfs或者dfs,， 當(dāng)然,，也可以重新寫到下一個(gè)scribe服務(wù)中。

scribe將客戶端日志組織為類目和信息兩個(gè)部分,，以此來(lái)唯一確定一條消息,。 類目用來(lái)描述信息預(yù)計(jì)的目標(biāo)位置， 可以通過(guò)scribe server中配置來(lái)指定,。 類目同樣也支持前綴方式的配置,， 默認(rèn)可以在文件路徑中插入類目名稱。scribe在一些特定case下會(huì)丟失數(shù)據(jù)：

• 如果客戶端的scribe既不能連接到本地文件系統(tǒng),，也不能連接到scribe中央服務(wù)器

• 如果客戶端scribe服務(wù)崩潰,， 會(huì)造成內(nèi)存中的少量數(shù)據(jù)丟失,，但磁盤數(shù)據(jù)不會(huì)丟失

• 多種情況并發(fā),，如重發(fā)服務(wù)無(wú)法連接到任何的中央服務(wù)器,，而且本地磁盤已滿

• 小概率的延遲導(dǎo)致的消息沖突

從架構(gòu)圖上可以看到,，agent是作為thirft的客戶端與scribe中央服務(wù)器通信的，這樣做的好處顯而易見(jiàn),， 我們可以采用多種編程語(yǔ)言來(lái)開(kāi)發(fā)我們的數(shù)據(jù)收集客戶端,，具備較大的靈活性,。但是依賴于thirft框架，其穩(wěn)定性與吞吐量受到了thirft的制約,， 同時(shí)引入消息隊(duì)列,， 整個(gè)收集框架略顯承重。

說(shuō)起flume 大家并不陌生,，flume是目前使用的比較廣的日志收容工具,。 先說(shuō)說(shuō)flume的歷史,，flume早期是由cloudera 開(kāi)發(fā)設(shè)計(jì)的,， 目前將其早期的版本稱為flume-og,。 隨著大數(shù)據(jù)的發(fā)展，flume的 工程代碼變得越來(lái)越臃腫,， 再加上核心組件設(shè)計(jì)不合理,、核心配置不標(biāo)準(zhǔn)等,，造成flume的越來(lái)越不穩(wěn)定,。 2011年10月22號(hào)，cloudera 完成了Flume-728,，對(duì) Flume 進(jìn)行了大刀闊斧的改造，隨后被納入Apache陣營(yíng),，更名為Apache Flume,，開(kāi)啟了flume-ng的時(shí)代。

我們首先來(lái)看一下flume-og是怎樣的一個(gè)存在,。

flume-og架構(gòu)圖：

從架構(gòu)圖上我們可以了解到,， flume-og 有三種角色的節(jié)點(diǎn)，代理節(jié)點(diǎn)（agent）,、收集節(jié)點(diǎn)（collector）,、主節(jié)點(diǎn)（master），agent 從各個(gè)數(shù)據(jù)源收集日志數(shù)據(jù),，將收集到的數(shù)據(jù)集中到 collector,，然后由收集節(jié)點(diǎn)匯總存入 hdfs,。master 負(fù)責(zé)管理 agent，collector 的活動(dòng),。 仔細(xì)看,，我們會(huì)返現(xiàn)， agent,、collector 都由 source,、sink 組成，代表在當(dāng)前節(jié)點(diǎn)數(shù)據(jù)是從 source 傳送到 sink,， 這也就意味著，節(jié)點(diǎn)中沒(méi)有專門的緩存數(shù)據(jù)的模塊,，節(jié)點(diǎn)之間的數(shù)據(jù)阻塞極易發(fā)生,， 再加上，數(shù)據(jù)流經(jīng)的緩解太多,，必然會(huì)對(duì)吞吐造成影響,。同時(shí)， 為了提高可用性,， 引入zk來(lái)管理 agent, collector, master的配置信息,，大大增加了使用和維護(hù)的成本。

flume-ng架構(gòu)圖：

flume-ng節(jié)點(diǎn)組成：

改版后的flume-ng,， 只保留了一種角色的節(jié)點(diǎn),，代理節(jié)點(diǎn)（agent）， 沒(méi)有了collector和master節(jié)點(diǎn),，這是核心組件最核心的變化,，大大簡(jiǎn)化了部署和維護(hù)的成本。 同時(shí)將節(jié)點(diǎn)由之前的source, sink升級(jí)到現(xiàn)在的source,， channel,， sink三部分，channel專門用于傳輸過(guò)程中數(shù)據(jù)的暫時(shí)緩存,。

 flume-ng不在依賴于zk,，更加靈活，輕便,。自帶多種類型插件,，可以從多種數(shù)據(jù)源中收集數(shù)據(jù)，將數(shù)據(jù)送入到指定的目標(biāo)存儲(chǔ)中,， 借助自定義source,，channel和sink，不斷可以擴(kuò)展數(shù)據(jù)收集的source,，channel,，sink類型,，還可以實(shí)現(xiàn)除日志收集之外的其他功能。 不同類型的agent直接可以相互連接,，形成Pipeline,， 完成更加復(fù)雜的功能。 這也是flume-ng越來(lái)越流行的重要原因,。

logstash 是基于實(shí)時(shí)數(shù)據(jù)管道能力的數(shù)據(jù)收集引擎,， 它可以從不同的數(shù)據(jù)源整理數(shù)據(jù)，統(tǒng)一寫入到你選擇的目標(biāo)存儲(chǔ)中,。 清洗和規(guī)范你的數(shù)據(jù),，方便下游分析和可視化使用。

架構(gòu)圖如下：

從架構(gòu)圖看,，logstash和flume-ng的設(shè)計(jì)思想很相似,， flume-ng的agent由source,channel,sink三部分組成， 而logstash實(shí)例由input,filter和output三部分組成,。 input同source一樣,，用于從數(shù)據(jù)源中收集數(shù)據(jù)。 filter和channel略有不同,，filter是對(duì)input收集上來(lái)的數(shù)據(jù)做一定的處理后交給output,。 默認(rèn)的filter有 grok filter(用于結(jié)構(gòu)化數(shù)據(jù))， mutate filter（用于更改數(shù)據(jù)結(jié)構(gòu),，如數(shù)據(jù)字段更名,，移除，替換等）,，drop filter（徹底刪除數(shù)據(jù)）,，clone filter(拷貝數(shù)據(jù))， geoip filter(通過(guò)ip地址獲取額外的信息)等,。 output將filter處理后的數(shù)據(jù)送入的指定的存儲(chǔ)或者下一個(gè)logstash的實(shí)例,。

logstash同flume-ng一樣，在實(shí)現(xiàn)日志收集功能的基礎(chǔ)上,，通過(guò)實(shí)現(xiàn)和更改logstash的input, filter, 和output插件,， 可以將一些我們想要的功能，很方便的嵌入到數(shù)據(jù)收集的整個(gè)過(guò)程中,， 加速我們對(duì)大量的多樣話數(shù)據(jù)的感知能力,。

大多數(shù)情況下， logstash作為elk套件的日志收集框架,，實(shí)現(xiàn)實(shí)時(shí)日志分析時(shí)使用,。

kafka 是Linkedin 2010開(kāi)源的基于發(fā)布訂閱模式分布式消息系統(tǒng)，之后加入Apache陣營(yíng),，更名為Apache kafka,。其架構(gòu)如下： 

整個(gè)系統(tǒng)由三部分節(jié)點(diǎn)組成：

• producer：產(chǎn)生指定topic的消息

• broker：在磁盤上存儲(chǔ)維護(hù)各種topic的消息隊(duì)列

• comsumer：訂閱了某個(gè)topic的消費(fèi)者從broker中拉取消息并進(jìn)行處理

broker對(duì)topic的管理是基于順序讀寫磁盤文件而實(shí)現(xiàn)的,，在kafka內(nèi)部，支持對(duì)topic進(jìn)行數(shù)據(jù)分片(partition), 每個(gè)數(shù)據(jù)分片都是一個(gè)有序的,， 不可更改的尾部追加消息隊(duì)列,。隊(duì)列內(nèi)每個(gè)消息都被分配一個(gè)在本數(shù)據(jù)分片的唯一ID，也叫offset,， 消息生產(chǎn)者在產(chǎn)生消息時(shí)可以指定數(shù)據(jù)分片,， 具體方法可以采用round robin 隨機(jī)分配， 也可以根據(jù)一定的應(yīng)用語(yǔ)義邏輯分配,， 比如可以按照用戶uid進(jìn)行哈希分配,，這樣可以保證同一用戶的數(shù)據(jù)會(huì)放入相同的隊(duì)列中， 便于后續(xù)處理,。 也正因?yàn)槿绱耍?kafka有著極高的吞吐量,。 在kafka的基礎(chǔ)上實(shí)現(xiàn)日志收容有著天然的優(yōu)勢(shì)：

• 方便實(shí)現(xiàn)：開(kāi)發(fā)收集數(shù)據(jù)的producer和寫數(shù)據(jù)的consumer即可， producer從日志服務(wù)器上收集日志,，送入broker， consumer從broker拉取數(shù)據(jù),，寫入到目標(biāo)存儲(chǔ)

• 高性能：天然的高吞吐,，較強(qiáng)的可擴(kuò)展性和高可用性， 消息傳遞低延遲

是阿里開(kāi)源的實(shí)時(shí)數(shù)據(jù)傳輸平臺(tái),，基于thrift通訊框架實(shí)現(xiàn),，具有高性能、實(shí)時(shí)性,、順序性,、高可靠性、高可用性,、可擴(kuò)展性等特點(diǎn),。

其架構(gòu)如下：

整個(gè)系統(tǒng)大概分四部分：client，router,， zookeeper,，broker

• client：用戶訪問(wèn)timetunnel的接口，通過(guò)client用戶可以向timetunnel發(fā)布消息,，訂閱消息,。

• router：timetunnel的門戶，提供安全認(rèn)證,、服務(wù)路由,、負(fù)載均衡三個(gè)功能。router知道每個(gè)broker的工作狀態(tài),，router總是向client返回正確的broker地址,。

• zookeeper：timetunnel的狀態(tài)同步模塊,，router就是通過(guò)zookeeper感知系統(tǒng)狀態(tài)變化，例如增加/刪除broker環(huán),、環(huán)節(jié)點(diǎn)的增刪,、環(huán)對(duì)應(yīng)的topic增刪、系統(tǒng)用戶信息變化等,。

• broker：timetunnel的核心,，負(fù)責(zé)消息的存儲(chǔ)轉(zhuǎn)發(fā)。broker以環(huán)的形式組成成集群,，可以通過(guò)配置告知router哪些數(shù)據(jù)應(yīng)該被分配到那個(gè)集群,，以便router正確路由。環(huán)里面的節(jié)點(diǎn)是有順序的,，每個(gè)節(jié)點(diǎn)的后續(xù)節(jié)點(diǎn)自己的備份節(jié)點(diǎn),，當(dāng)節(jié)點(diǎn)故障時(shí)，可以從備份節(jié)點(diǎn)恢復(fù)因故障丟失的數(shù)據(jù),。

和kafka類似,，TT自身也只是一個(gè)數(shù)據(jù)傳輸?shù)墓ぞ撸](méi)有日志采集的功能,，但是在它的架構(gòu)之上,，我們很容易去構(gòu)造一個(gè)高性能，大吞吐的數(shù)據(jù)收集工具,。 

如上圖,，tt實(shí)現(xiàn)的收容框架，大致分為三部分：

1. clientAgent：基于TTclientAPI 實(shí)現(xiàn)的日志收容客戶端,，被安裝在日志服務(wù)器上,，用于收集數(shù)據(jù)并將數(shù)據(jù)送入到消息通訊層；如TailFIle agent,， 通過(guò)linux的notify機(jī)制,，監(jiān)控文件變化，將數(shù)據(jù)實(shí)時(shí)的送入消息通訊層

2. 消息通訊層：有client agent收集上來(lái)的數(shù)據(jù),，經(jīng)過(guò)tt集群傳輸后,，以一定的數(shù)據(jù)格式暫時(shí)存入底層HBase集群。 消息通訊層,，還實(shí)現(xiàn)了發(fā)布訂閱的消息機(jī)制,，      通過(guò)TTclientAPI可以訂閱消息通訊層的數(shù)據(jù).

3. DeepStorage：通過(guò)訂閱消息通訊層數(shù)據(jù)，通過(guò)不同的writer將數(shù)據(jù)寫入到不同的存儲(chǔ)中,，用于接下來(lái)的分析處理

我相信大家現(xiàn)在對(duì)這幾種框架有了初步的了解了,，在開(kāi)始自己的數(shù)據(jù)分析之旅前，請(qǐng)根據(jù)自己的業(yè)務(wù)需要，選擇合適的收集框架,。

近期精彩活動(dòng)（直接點(diǎn)擊查看）：

福利 · 閱讀 | 免費(fèi)申請(qǐng)讀大數(shù)據(jù)新書(shū) 第12期 

END

大數(shù)據(jù)

為大家提供與大數(shù)據(jù)相關(guān)的最新技術(shù)和資訊,。