[[175654]]

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

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

1. 低延遲：從Log數(shù)據(jù)產(chǎn)生到能夠?qū)ζ渥龇治?，希望盡可能快的完成數(shù)據(jù)的收集。在批處理或者離線分析中，對數(shù)據(jù)的實(shí)時(shí)性要求并不高，但是隨著大數(shù)據(jù)的發(fā)展，實(shí)時(shí)計(jì)算的能力越來越強(qiáng)，實(shí)時(shí)分析的場景也越來越多，所以對日志收容的實(shí)時(shí)性要求也越來越高。
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)巨頭都開發(fā)了自己的日志收集工具， 比如Apache的chukwa，F(xiàn)acebook的scribe，Cloudera的flume以及ELK stack(歸屬于Elastic.co公司)組合中的logstash，都是目前比較流行的開源的日志收集框架。

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

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

chukwa

chukwa 是Apache 開源的針對大規(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í)就沒有將它定位為單純的日志收集工具，而是囊括數(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ù)分析和處理等交給其他成熟的框架來實(shí)現(xiàn)， 如Hive、Impala等。 也出于這些原因，chukwa并沒有被廣泛的使用。

scribe

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

應(yīng)用系統(tǒng)中每一臺日志服務(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è)部分，以此來唯一確定一條消息。 類目用來描述信息預(yù)計(jì)的目標(biāo)位置， 可以通過scribe server中配置來指定。 類目同樣也支持前綴方式的配置， 默認(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ù)器，而且本地磁盤已滿
• 小概率的延遲導(dǎo)致的消息沖突

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

flume

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

我們首先來看一下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)中沒有專門的緩存數(shù)據(jù)的模塊，節(jié)點(diǎn)之間的數(shù)據(jù)阻塞極易發(fā)生， 再加上，數(shù)據(jù)流經(jīng)的緩解太多，必然會(huì)對吞吐造成影響。同時(shí)， 為了提高可用性， 引入zk來管理 agent, collector, master的配置信息，大大增加了使用和維護(hù)的成本。

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

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

改版后的flume-ng， 只保留了一種角色的節(jié)點(diǎn)，代理節(jié)點(diǎn)(agent)， 沒有了collector和master節(jié)點(diǎn)，這是核心組件最核心的變化，大大簡化了部署和維護(hù)的成本。 同時(shí)將節(jié)點(diǎn)由之前的source, sink升級到現(xiàn)在的source， channel， sink三部分，channel專門用于傳輸過程中數(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越來越流行的重要原因。

logstash

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是對input收集上來的數(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(通過ip地址獲取額外的信息)等。 output將filter處理后的數(shù)據(jù)送入的指定的存儲(chǔ)或者下一個(gè)logstash的實(shí)例。

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

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

kafka

kafka 是Linkedin 2010開源的基于發(fā)布訂閱模式分布式消息系統(tǒng)，之后加入Apache陣營，更名為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對topic的管理是基于順序讀寫磁盤文件而實(shí)現(xiàn)的，在kafka內(nèi)部，支持對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)用語義邏輯分配， 比如可以按照用戶uid進(jìn)行哈希分配，這樣可以保證同一用戶的數(shù)據(jù)會(huì)放入相同的隊(duì)列中， 便于后續(xù)處理。 也正因?yàn)槿绱耍?kafka有著極高的吞吐量。 在kafka的基礎(chǔ)上實(shí)現(xiàn)日志收容有著天然的優(yōu)勢：

• 方便實(shí)現(xiàn)：開發(fā)收集數(shù)據(jù)的producer和寫數(shù)據(jù)的consumer即可， producer從日志服務(wù)器上收集日志，送入broker， consumer從broker拉取數(shù)據(jù)，寫入到目標(biāo)存儲(chǔ)
• 高性能：天然的高吞吐，較強(qiáng)的可擴(kuò)展性和高可用性， 消息傳遞低延遲

TT(Timetunel)

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

其架構(gòu)如下：

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

• client：用戶訪問timetunnel的接口，通過client用戶可以向timetunnel發(fā)布消息，訂閱消息。
• router：timetunnel的門戶，提供安全認(rèn)證、服務(wù)路由、負(fù)載均衡三個(gè)功能。router知道每個(gè)broker的工作狀態(tài)，router總是向client返回正確的broker地址。
• zookeeper：timetunnel的狀態(tài)同步模塊，router就是通過zookeeper感知系統(tǒng)狀態(tài)變化，例如增加/刪除broker環(huán)、環(huán)節(jié)點(diǎn)的增刪、環(huán)對應(yīng)的topic增刪、系統(tǒng)用戶信息變化等。
• broker：timetunnel的核心，負(fù)責(zé)消息的存儲(chǔ)轉(zhuǎn)發(fā)。broker以環(huán)的形式組成成集群，可以通過配置告知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ù)墓ぞ?，并沒有日志采集的功能，但是在它的架構(gòu)之上，我們很容易去構(gòu)造一個(gè)高性能，大吞吐的數(shù)據(jù)收集工具。

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

1. clientAgent：基于TTclientAPI 實(shí)現(xiàn)的日志收容客戶端，被安裝在日志服務(wù)器上，用于收集數(shù)據(jù)并將數(shù)據(jù)送入到消息通訊層;如TailFIle agent， 通過linux的notify機(jī)制，監(jiān)控文件變化，將數(shù)據(jù)實(shí)時(shí)的送入消息通訊層
2. 消息通訊層：有client agent收集上來的數(shù)據(jù)，經(jīng)過tt集群傳輸后，以一定的數(shù)據(jù)格式暫時(shí)存入底層HBase集群。 消息通訊層，還實(shí)現(xiàn)了發(fā)布訂閱的消息機(jī)制， 通過TTclientAPI可以訂閱消息通訊層的數(shù)據(jù).
3. DeepStorage：通過訂閱消息通訊層數(shù)據(jù)，通過不同的writer將數(shù)據(jù)寫入到不同的存儲(chǔ)中，用于接下來的分析處理

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