任何完整的大數(shù)據(jù)平臺，一般包括以下的幾個過程：

其中，數(shù)據(jù)采集是所有數(shù)據(jù)系統(tǒng)必不可少的，隨著大數(shù)據(jù)越來越被重視，數(shù)據(jù)采集的挑戰(zhàn)也變的尤為突出。這其中包括：

我們今天就來看看當前可用的一些數(shù)據(jù)采集的產(chǎn)品，重點關注一些它們是如何做到高可靠，高性能和高擴展。

Apache Flume

Flume 是Apache旗下，開源，高可靠，高擴展，容易管理，支持客戶擴展的數(shù)據(jù)采集系統(tǒng)。 Flume使用JRuby來構建，所以依賴Java運行環(huán)境。

Flume最初是由Cloudera的工程師設計用于合并日志數(shù)據(jù)的系統(tǒng)，后來逐漸發(fā)展用于處理流數(shù)據(jù)事件。

Flume設計成一個分布式的管道架構，可以看作在數(shù)據(jù)源和目的地之間有一個Agent的網(wǎng)絡，支持數(shù)據(jù)路由。

　　每一個agent都由Source，Channel和Sink組成。

Source

Source負責接收輸入數(shù)據(jù)，并將數(shù)據(jù)寫入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支持監(jiān)視一個目錄或者文件，解析其中新生成的事件。

Channel

Channel 存儲，緩存從source到Sink的中間數(shù)據(jù)?？墒褂貌煌呐渲脕碜鯟hannel，例如內(nèi)存，文件，JDBC等。使用內(nèi)存性能高但不持久，有可能丟數(shù)據(jù)。使用文件更可靠，但性能不如內(nèi)存。

Sink

Sink負責從管道中讀出數(shù)據(jù)并發(fā)給下一個Agent或者最終的目的地。Sink支持的不同目的地種類包括：HDFS，HBASE，Solr，ElasticSearch，F(xiàn)ile，Logger或者其它的Flume Agent

Flume在source和sink端都使用了transaction機制保證在數(shù)據(jù)傳輸中沒有數(shù)據(jù)丟失。

Source上的數(shù)據(jù)可以復制到不同的通道上。每一個Channel也可以連接不同數(shù)量的Sink。這樣連接不同配置的Agent就可以組成一個復雜的數(shù)據(jù)收集網(wǎng)絡。通過對agent的配置，可以組成一個路由復雜的數(shù)據(jù)傳輸網(wǎng)絡。

配置如上圖所示的agent結構，F(xiàn)lume支持設置sink的Failover和Load Balance，這樣就可以保證即使有一個agent失效的情況下，整個系統(tǒng)仍能正常收集數(shù)據(jù)。

Flume中傳輸?shù)膬?nèi)容定義為事件(Event)，事件由Headers(包含元數(shù)據(jù)，Meta Data)和Payload組成。

Flume提供SDK，可以支持用戶定制開發(fā)：

Flume客戶端負責在事件產(chǎn)生的源頭把事件發(fā)送給Flume的Agent?？蛻舳送ǔ：彤a(chǎn)生數(shù)據(jù)源的應用在同一個進程空間。常見的Flume客戶端有Avro，log4J，syslog和HTTP Post。另外ExecSource支持指定一個本地進程的輸出作為Flume的輸入。當然很有可能，以上的這些客戶端都不能滿足需求，用戶可以定制的客戶端，和已有的FLume的Source進行通信，或者定制實現(xiàn)一種新的Source類型。

同時，用戶可以使用Flume的SDK定制Source和Sink。似乎不支持定制的Channel。

Fluentd

Fluentd (Github 地址)是另一個開源的數(shù)據(jù)收集框架。Fluentd使用C/Ruby開發(fā)，使用JSON文件來統(tǒng)一日志數(shù)據(jù)。它的可插拔架構，支持各種不同種類和格式的數(shù)據(jù)源和數(shù)據(jù)輸出。最后它也同時提供了高可靠和很好的擴展性。Treasure Data, Inc對該產(chǎn)品提供支持和維護。

　　Fluentd的部署和Flume非常相似：

Fluentd的架構設計和Flume如出一轍：

Fluentd的Input/Buffer/Output非常類似于Flume的Source/Channel/Sink。

Input

Input負責接收數(shù)據(jù)或者主動抓取數(shù)據(jù)。支持syslog，http，file tail等。

Buffer

Buffer負責數(shù)據(jù)獲取的性能和可靠性，也有文件或內(nèi)存等不同類型的Buffer可以配置。

Output

Output負責輸出數(shù)據(jù)到目的地例如文件，AWS S3或者其它的Fluentd。

Fluentd的配置非常方便，如下圖：

　　Fluentd的技術棧如下圖：

FLuentd和其插件都是由Ruby開發(fā)，MessgaePack提供了JSON的序列化和異步的并行通信RPC機制。

　　Cool.io是基于libev的事件驅動框架。

FLuentd的擴展性非常好，客戶可以自己定制(Ruby)Input/Buffer/Output。

Fluentd從各方面看都很像Flume，區(qū)別是使用Ruby開發(fā)，F(xiàn)ootprint會小一些，但是也帶來了跨平臺的問題，并不能支持Windows平臺。另外采用JSON統(tǒng)一數(shù)據(jù)/日志格式是它的另一個特點。相對去Flumed，配置也相對簡單一些。

Logstash

Logstash是著名的開源數(shù)據(jù)棧ELK(ElasticSearch，Logstash，Kibana)中的那個L。

Logstash用JRuby開發(fā)，所有運行時依賴JVM。

Logstash的部署架構如下圖，當然這只是一種部署的選項。

　　一個典型的Logstash的配置如下，包括了Input，filter的Output的設置。

幾乎在大部分的情況下ELK作為一個棧是被同時使用的。所有當你的數(shù)據(jù)系統(tǒng)使用ElasticSearch的情況下，logstash是首選。

Chukwa

Apache Chukwa (github)是apache旗下另一個開源的數(shù)據(jù)收集平臺，它遠沒有其他幾個有名。Chukwa基于Hadoop的HDFS和Map Reduce來構建(顯而易見，它用Java來實現(xiàn))，提供擴展性和可靠性。Chukwa同時提供對數(shù)據(jù)的展示，分析和監(jiān)視。很奇怪的是它的上一次github的更新事7年前?？梢娫擁椖繎撘呀?jīng)不活躍了。

Chukwa的部署架構如下。

Chukwa的主要單元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去相當復雜。

由于該項目已經(jīng)不活躍，我們就不細看了。

Scribe

Scribe是Facebook開發(fā)的數(shù)據(jù)(日志)收集系統(tǒng)。已經(jīng)多年不維護，同樣的，就不多說了。

　　Splunk Forwarder

以上的所有系統(tǒng)都是開源的，在商業(yè)化的大數(shù)據(jù)平臺產(chǎn)品中，Splunk提供完整的數(shù)據(jù)采金，數(shù)據(jù)存儲，數(shù)據(jù)分析和處理，以及數(shù)據(jù)展現(xiàn)的能力。

Splunk是一個分布式的機器數(shù)據(jù)平臺，主要有三個角色：

Splunk內(nèi)置了對Syslog，TCP/UDP，Spooling的支持，同時，用戶可以通過開發(fā)Script Input和Modular Input的方式來獲取特定的數(shù)據(jù)。在Splunk提供的軟件倉庫里有很多成熟的數(shù)據(jù)采集應用，例如AWS，數(shù)據(jù)庫(DBConnect)等等，可以方便的從云或者是數(shù)據(jù)庫中獲取數(shù)據(jù)進入Splunk的數(shù)據(jù)平臺做分析。

這里要注意的是，Search Head和Indexer都支持Cluster的配置，也就是高可用，高擴展的，但是Splunk現(xiàn)在還沒有針對Farwarder的Cluster的功能。也就是說如果有一臺Farwarder的機器出了故障，數(shù)據(jù)收集也會隨之中斷，并不能把正在運行的數(shù)據(jù)采集任務Failover到其它的Farwarder上。

總結：

我們簡單討論了幾種流行的數(shù)據(jù)收集平臺，它們大都提供高可靠和高擴展的數(shù)據(jù)收集。大多平臺都抽象出了輸入，輸出和中間的緩沖的架構。利用分布是的網(wǎng)絡連接，大多數(shù)平臺都能實現(xiàn)一定程度的擴展性和高可靠性。其中Flume，F(xiàn)luentd是兩個被使用較多的產(chǎn)品。如果你用ElasticSearch，Logstash也許是首選，因為ELK棧提供了很好的集成。Chukwa和Scribe由于項目的不活躍，不推薦使用。

Splunk作為一個優(yōu)秀的商業(yè)產(chǎn)品，它的數(shù)據(jù)采集還存在一定的限制，相信Splunk很快會開發(fā)出更好的數(shù)據(jù)收集的解決方案。