為了高效采集大數(shù)據(jù)，依據(jù)采集環(huán)境及數(shù)據(jù)類型選擇適當(dāng)?shù)拇髷?shù)據(jù)采集方法及平臺至關(guān)重要。下面介紹一些常用的大數(shù)據(jù)采集平臺和工具。

1、Flume

Flume作為Hadoop的組件，是由Cloudera專門研發(fā)的分布式日志收集系統(tǒng)。尤其近幾年隨著Flume的不斷完善，用戶在開發(fā)過程中使用的便利性得到很大的改善，F(xiàn)lume現(xiàn)已成為Apache Top項目之一。

Flume提供了從Console（控制臺）、RPC（Thrift-RPC）、Text（文件）、Tail（UNIX Tail）、Syslog、Exec（命令執(zhí)行）等數(shù)據(jù)源上收集數(shù)據(jù)的能力。

Flume采用了多Master的方式。為了保證配置數(shù)據(jù)的一致性，F(xiàn)lume引入了ZooKeeper，用于保存配置數(shù)據(jù)。ZooKeeper本身可保證配置數(shù)據(jù)的一致性和高可用性。另外，在配置數(shù)據(jù)發(fā)生變化時，ZooKeeper可以通知Flume Master節(jié)點。Flume Master節(jié)點之間使用Gossip協(xié)議同步數(shù)據(jù)。

Flume針對特殊場景也具備良好的自定義擴(kuò)展能力，因此Flume適用于大部分的日常數(shù)據(jù)采集場景。因為Flume使用JRuby來構(gòu)建，所以依賴Java運(yùn)行環(huán)境。Flume設(shè)計成一個分布式的管道架構(gòu)，可以看成在數(shù)據(jù)源和目的地之間有一個Agent的網(wǎng)絡(luò)，支持?jǐn)?shù)據(jù)路由。

Flume支持設(shè)置Sink的Failover和加載平衡，這樣就可以保證在有一個Agent失效的情況下，整個系統(tǒng)仍能正常收集數(shù)據(jù)。Flume中傳輸?shù)膬?nèi)容定義為事件（Event），事件由Headers（包含元數(shù)據(jù)，即Meta Data）和Payload組成。

Flume提供SDK，可以支持用戶定制開發(fā)。Flume客戶端負(fù)責(zé)在事件產(chǎn)生的源頭把事件發(fā)送給Flume的Agent?？蛻舳送ǔ：彤a(chǎn)生數(shù)據(jù)源的應(yīng)用在同一個進(jìn)程空間。常見的Flume 客戶端有Avro、Log4J、Syslog和HTTP Post。

2、Fluentd

Fluentd是另一個開源的數(shù)據(jù)收集架構(gòu)，如圖1所示。Fluentd使用C/Ruby開發(fā)，使用JSON文件來統(tǒng)一日志數(shù)據(jù)。通過豐富的插件，可以收集來自各種系統(tǒng)或應(yīng)用的日志，然后根據(jù)用戶定義將日志做分類處理。通過Fluentd，可以非常輕易地實現(xiàn)像追蹤日志文件并將其過濾后轉(zhuǎn)存到 MongoDB 這樣的操作。Fluentd可以徹底地把人從煩瑣的日志處理中解放出來。

圖1  Fluentd架構(gòu)

Fluentd具有多個功能特點：安裝方便、占用空間小、半結(jié)構(gòu)化數(shù)據(jù)日志記錄、靈活的插件機(jī)制、可靠的緩沖、日志轉(zhuǎn)發(fā)。Treasure Data公司對該產(chǎn)品提供支持和維護(hù)。另外，采用JSON統(tǒng)一數(shù)據(jù)/日志格式是它的另一個特點。相對Flume，F(xiàn)luentd配置也相對簡單一些。

Fluentd的擴(kuò)展性非常好，客戶可以自己定制（Ruby）Input/Buffer/Output。Fluentd具有跨平臺的問題，并不支持Windows平臺。

Fluentd的Input/Buffer/Output非常類似于Flume的Source/Channel/Sink。Fluentd架構(gòu)如圖2所示。

圖2  Fluentd架構(gòu)

3、Logstash

Logstash是著名的開源數(shù)據(jù)棧ELK（ElasticSearch，Logstash，Kibana）中的那個L。因為Logstash用JRuby開發(fā)，所以運(yùn)行時依賴JVM。Logstash的部署架構(gòu)如圖3所示，當(dāng)然這只是一種部署的選項。

圖3 Logstash的部署架構(gòu)

一個典型的Logstash的配置如下，包括Input、Filter的Output的設(shè)置。

input {

    file {

        type =>"Apache-access"

        path =>"/var/log/Apache2/other_vhosts_access.log"

    }    

    file {

        type =>"pache-error"

        path =>"/var/log/Apache2/error.log"

    }

}

filter {

    grok {

        match => {"message"=>"%(COMBINEDApacheLOG)"}

    }    

    date {

        match => {"timestamp"=>"dd/MMM/yyyy:HH:mm:ss Z"}

    }

}

output  {

    stdout {}

    Redis {

        host=>"192.168.1.289"

        data_type => "list"

        key => "Logstash"

    }

}

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

4、Chukwa

Chukwa是Apache旗下另一個開源的數(shù)據(jù)收集平臺，它遠(yuǎn)沒有其他幾個有名。Chukwa基于Hadoop的HDFS和MapReduce來構(gòu)建（用Java來實現(xiàn)），提供擴(kuò)展性和可靠性。它提供了很多模塊以支持Hadoop集群日志分析。Chukwa同時提供對數(shù)據(jù)的展示、分析和監(jiān)視。該項目目前已經(jīng)不活躍。

Chukwa適應(yīng)以下需求：

（1）靈活的、動態(tài)可控的數(shù)據(jù)源。

（2）高性能、高可擴(kuò)展的存儲系統(tǒng)。

（3）合適的架構(gòu)，用于對收集到的大規(guī)模數(shù)據(jù)進(jìn)行分析。

Chukwa架構(gòu)如圖4所示。

圖4  Chukwa架構(gòu)

5、Scribe

Scribe是Facebook開發(fā)的數(shù)據(jù)（日志）收集系統(tǒng)。其官網(wǎng)已經(jīng)多年不維護(hù)。Scribe為日志的“分布式收集，統(tǒng)一處理”提供了一個可擴(kuò)展的，高容錯的方案。當(dāng)中央存儲系統(tǒng)的網(wǎng)絡(luò)或者機(jī)器出現(xiàn)故障時，Scribe會將日志轉(zhuǎn)存到本地或者另一個位置；當(dāng)中央存儲系統(tǒng)恢復(fù)后，Scribe會將轉(zhuǎn)存的日志重新傳輸給中央存儲系統(tǒng)。Scribe通常與HADOOP結(jié)合使用，用于向HDFS中push（推）日志，而Hadoop通過MapReduce作業(yè)進(jìn)行定期處理。

Scribe架構(gòu)如圖5所示。

圖5  Scribe架構(gòu)

Scribe架構(gòu)比較簡單，主要包括三部分，分別為Scribe agent、Scribe和存儲系統(tǒng)。

6、Splunk

在商業(yè)化的大數(shù)據(jù)平臺產(chǎn)品中，Splunk提供完整的數(shù)據(jù)采集、數(shù)據(jù)存儲、數(shù)據(jù)分析和處理，以及數(shù)據(jù)展現(xiàn)的能力。Splunk是一個分布式機(jī)器數(shù)據(jù)平臺，主要有三個角色。Splunk架構(gòu)如圖6所示。

圖6  Splunk架構(gòu)

Search：負(fù)責(zé)數(shù)據(jù)的搜索和處理，提供搜索時的信息抽取功能。

Indexer：負(fù)責(zé)數(shù)據(jù)的存儲和索引。

Forwarder：負(fù)責(zé)數(shù)據(jù)的收集、清洗、變形，并發(fā)送給Indexer。

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

Search Head和Indexer都支持Cluster的配置，即高可用、高擴(kuò)展的、但Splunk現(xiàn)在還沒有針對Forwarder的Cluster的功能。也就是說，如果有一臺Forwarder的機(jī)器出了故障，則數(shù)據(jù)收集也會隨之中斷，并不能把正在運(yùn)行的數(shù)據(jù)收集任務(wù)因故障切換（Failover）到其他的Forwarder上。

7、Scrapy

python的爬蟲架構(gòu)叫Scrapy。Scrapy是由Python語言開發(fā)的一個快速、高層次的屏幕抓取和Web抓取架構(gòu)，用于抓取Web站點并從頁面中提取結(jié)構(gòu)化數(shù)據(jù)。Scrapy的用途廣泛，可以用于數(shù)據(jù)挖掘、監(jiān)測和自動化測試。

Scrapy吸引人的地方在于它是一個架構(gòu)，任何人都可以根據(jù)需求方便地進(jìn)行修改。它還提供多種類型爬蟲的基類，如BaseSpider、Sitemap爬蟲等，最新版本提供對Web 2.0爬蟲的支持。

Scrapy運(yùn)行原理如圖7所示。

圖7  Scrapy運(yùn)行原理

Scrapy的整個數(shù)據(jù)處理流程由Scrapy引擎進(jìn)行控制。Scrapy運(yùn)行流程如下：

（1）Scrapy引擎打開一個域名時，爬蟲處理這個域名，并讓爬蟲獲取第一個爬取的URL。

（2）Scrapy引擎先從爬蟲那獲取第一個需要爬取的URL，然后作為請求在調(diào)度中進(jìn)行調(diào)度。

（3）Scrapy引擎從調(diào)度那里獲取接下來進(jìn)行爬取的頁面。

（4）調(diào)度將下一個爬取的URL返回給引擎，引擎將它們通過下載中間件發(fā)送到下載器。

（5）當(dāng)網(wǎng)頁被下載器下載完成以后，響應(yīng)內(nèi)容通過下載器中間件被發(fā)送到Scrapy引擎。

（6）Scrapy引擎收到下載器的響應(yīng)并將它通過爬蟲中間件發(fā)送到爬蟲進(jìn)行處理。

（7）爬蟲處理響應(yīng)并返回爬取到的項目，然后給Scrapy引擎發(fā)送新的請求。

（8）Scrapy引擎將抓取到的放入項目管道，并向調(diào)度器發(fā)送請求。

（9）系統(tǒng)重復(fù)第（2）步后面的操作，直到調(diào)度器中沒有請求，然后斷開Scrapy引擎與域之間的聯(lián)系。