[[175654]]

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

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

1. 低延遲：從Log數據產生到能夠對其做分析，希望盡可能快的完成數據的收集。在批處理或者離線分析中，對數據的實時性要求并不高，但是隨著大數據的發展，實時計算的能力越來越強，實時分析的場景也越來越多，所以對日志收容的實時性要求也越來越高。
2. 可擴展性：日志分布在服務器集群上，由于業務或者系統的原因，集群的服務器會發生變化，如上線，下線，宕機等，Log收集框架需要能夠相應的做出變化，易擴展，易部署。
3. 容錯性：Log收集系統需要滿足大的吞吐以及承受足夠的壓力， 這就意味著Log收集系統很可能面臨宕機的風險， 在這種情況下， Log系統需要有不丟失數據的能力。

各大互聯網巨頭都開發了自己的日志收集工具， 比如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大致分為五個部分：

• 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中央服務將數據寫入到最終的目的地，典型的存儲包括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節點組成：

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

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

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。其架構如下：

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

• 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)

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

其架構如下：

整個系統大概分四部分：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實現的收容框架，大致分為三部分：

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

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