互聯網的發展，帶來了日新月異的業務種類，隨著業務的增長，隨之而來的，是業務日誌指數的遞增。一些公司每條業務線， 提供服務的線上服務器就達幾百臺之多， 每天的日誌量超百億。如何能夠將散落在各服務器上的日誌數據高效的收集彙總起來， 成了在數據分析處理之前必須解決的問題。

一個優秀的數據收集框架，需要具備三點特性，一是低延遲，二是可擴展，三是容錯性。

各大互聯網巨頭都開發了自己的日誌收集工具， 比如Apache的chukwa，Facebook的scribe，Cloudera的flume以及ELK stack(歸屬於Elastic.co公司)組合中的logstash，都是目前比較流行的開源的日誌收集框架。

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

接下來，我們就來逐一的瞭解一下這些數據收集框架。

chukwa

chukwa 是Apache 開源的針對大規模分佈式系統的日誌收集和分析的項目， 它建立在hdfs以及mr框架的基礎上，完全繼承了Hadoop的擴展性和穩定性。chukwa還包括了一系列組件，用於監控數據，分析數據和數據可視化等。 架構圖如下：

chukwa架構

從架構圖上可以看出， chukwa大致分為五個部分：

• Hadoop和HBase集群，用於chukwa處理數據
• 一個或多個agent進程， 將監控的數據發送到HBase集群。 啟動有agent進程的節點被稱作監控源節點
• Solr雲集群，用於存儲索引數據文件
• 數據分析腳本， 概括Hadoop集群的健康狀況
• HICC， chukwa的可視化工具

由於依賴於mr去處理數據，所以chukwa效率註定不會太高，整個數據流在數據處理間斷吞吐量急劇下降。 另外，chukwa設計時就沒有將它定位為單純的日誌收集工具，而是囊括數據的分析處理， 數據可視化等功能的完整的數據分析框架， 在這樣的設計思路下， 數據收集和數據分析倆大任務在優化目標上並不相同，甚至有可能相悖。所以優化效果並不明顯。

與其如此，還不如專一的定位在數據收集領域，數據分析和處理等交給其他成熟的框架來實現， 如Hive、Impala等。 也出於這些原因，chukwa並沒有被廣泛的使用。

scribe

scribe 是Facebook開源的日誌收集系統，在facebook內部被廣泛使用。 scribe主要用於收集彙總日誌流，易擴展，並且能夠保證在網絡和部分節點異常情況下的正常運行。 其架構圖如下：

scribe架構

應用系統中每一臺日誌服務器都會部署scribe服務， scribe服務收集節點信息，並將數據發送到scribe中央服務， scribe中央服務是多組scribe服務集群。如果scribe中央服務不可用，本地的scribe服務就會將信息寫到本地磁盤，當中央服務可用時重新發送。 scribe中央服務將數據寫入到最終的目的地，典型的存儲包括nfs或者dfs， 當然，也可以重新寫到下一個scribe服務中。

scribe將客戶端日誌組織為類目和信息兩個部分，以此來唯一確定一條消息。 類目用來描述信息預計的目標位置， 可以通過scribe server中配置來指定。 類目同樣也支持前綴方式的配置， 默認可以在文件路徑中插入類目名稱。scribe在一些特定case下會丟失數據：

• 如果客戶端的scribe既不能連接到本地文件系統，也不能連接到scribe中央服務器
• 如果客戶端scribe服務崩潰， 會造成內存中的少量數據丟失，但磁盤數據不會丟失
• 多種情況併發，如重發服務無法連接到任何的中央服務器，而且本地磁盤已滿
• 小概率的延遲導致的消息衝突

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

flume

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

我們首先來看一下flume-og是怎樣的一個存在。

flume-og架構

從架構圖上我們可以瞭解到， flume-og 有三種角色的節點，代理節點（agent）、收集節點（collector）、主節點（master），agent 從各個數據源收集日誌數據，將收集到的數據集中到 collector，然後由收集節點彙總存入 hdfs。master 負責管理 agent，collector 的活動。 仔細看，我們會返現， agent、collector 都由 source、sink 組成，代表在當前節點數據是從 source 傳送到 sink， 這也就意味著，節點中沒有專門的緩存數據的模塊，節點之間的數據阻塞極易發生， 再加上，數據流經的緩解太多，必然會對吞吐造成影響。同時， 為了提高可用性， 引入zk來管理 agent, collector, master的配置信息，大大增加了使用和維護的成本。

flume-ng架構

改版後的flume-ng， 只保留了一種角色的節點，代理節點（agent）， 沒有了collector和master節點，這是核心組件最核心的變化，大大簡化了部署和維護的成本。 同時將節點由之前的source, sink升級到現在的source， channel， sink三部分，channel專門用於傳輸過程中數據的暫時緩存。

flume-ng agent

flume-ng不在依賴於zk，更加靈活，輕便。自帶多種類型插件，可以從多種數據源中收集數據，將數據送入到指定的目標存儲中， 藉助自定義source，channel和sink，不斷可以擴展數據收集的source，channel，sink類型，還可以實現除日誌收集之外的其他功能。 不同類型的agent直接可以相互連接，形成Pipeline， 完成更加複雜的功能。 這也是flume-ng越來越流行的重要原因。

logstash

logstash 是基於實時數據管道能力的數據收集引擎， 它可以從不同的數據源整理數據，統一寫入到你選擇的目標存儲中。 清洗和規範你的數據，方便下游分析和可視化使用。

logstash架構

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

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

大多數情況下， logstash作為elk套件的日誌收集框架，實現實時日誌分析時使用。

kafka

kafka 是Linkedin 2010開源的基於發佈訂閱模式分佈式消息系統，之後加入Apache陣營，更名為Apache kafka。其架構如下：

kafka架構

整個系統由三部分節點組成：

• producer：產生指定topic的消息
• broker：在磁盤上存儲維護各種topic的消息隊列
• comsumer：訂閱了某個topic的消費者從broker中拉取消息並進行處理

broker對topic的管理是基於順序讀寫磁盤文件而實現的，在kafka內部，支持對topic進行數據分片(partition), 每個數據分片都是一個有序的， 不可更改的尾部追加消息隊列。隊列內每個消息都被分配一個在本數據分片的唯一ID，也叫offset， 消息生產者在產生消息時可以指定數據分片， 具體方法可以採用round robin 隨機分配， 也可以根據一定的應用語義邏輯分配， 比如可以按照用戶uid進行哈希分配，這樣可以保證同一用戶的數據會放入相同的隊列中， 便於後續處理。 也正因為如此， kafka有著極高的吞吐量。 在kafka的基礎上實現日誌收容有著天然的優勢：

• 方便實現：開發收集數據的producer和寫數據的consumer即可， producer從日誌服務器上收集日誌，送入broker， consumer從broker拉取數據，寫入到目標存儲
• 高性能：天然的高吞吐，較強的可擴展性和高可用性， 消息傳遞低延遲

TT(Timetunel)

TT阿里開源的實時數據傳輸平臺，基於thrift通訊框架實現，具有高性能、實時性、順序性、高可靠性、高可用性、可擴展性等特點。

TT架構

整個系統大概分四部分：client，router， zookeeper，broker

• client：用戶訪問timetunnel的接口，通過client用戶可以向timetunnel發佈消息，訂閱消息。
• router：timetunnel的門戶，提供安全認證、服務路由、負載均衡三個功能。router知道每個broker的工作狀態，router總是向client返回正確的broker地址。
• zookeeper：timetunnel的狀態同步模塊，router就是通過zookeeper感知系統狀態變化，例如增加/刪除broker環、環節點的增刪、環對應的topic增刪、系統用戶信息變化等。
• broker：timetunnel的核心，負責消息的存儲轉發。broker以環的形式組成成集群，可以通過配置告知router哪些數據應該被分配到那個集群，以便router正確路由。環裡面的節點是有順序的，每個節點的後續節點自己的備份節點，當節點故障時，可以從備份節點恢復因故障丟失的數據。

和kafka類似，TT自身也只是一個數據傳輸的工具，並沒有日誌採集的功能，但是在它的架構之上，我們很容易去構造一個高性能，大吞吐的數據收集工具。

TT應用架構

如上圖，tt實現的收容框架，大致分為三部分：

1. clientAgent：基於TTclientAPI 實現的日誌收容客戶端，被安裝在日誌服務器上，用於收集數據並將數據送入到消息通訊層；如TailFIle agent， 通過linux的notify機制，監控文件變化，將數據實時的送入消息通訊層
2. 消息通訊層：有client agent收集上來的數據，經過tt集群傳輸後，以一定的數據格式暫時存入底層HBase集群。 消息通訊層，還實現了發佈訂閱的消息機制， 通過TTclientAPI可以訂閱消息通訊層的數據.
3. DeepStorage：通過訂閱消息通訊層數據，通過不同的writer將數據寫入到不同的存儲中，用於接下來的分析處理

我相信大家現在對這幾種框架有了初步的瞭解了，在開始自己的數據分析之旅前，請根據自己的業務需要，選擇合適的收集框架。

閱讀更多 零號程序 的文章

關鍵字: Cloudera Facebook HBase