大數(shù)據(jù)的數(shù)據(jù)采集是大數(shù)據(jù)技術中非常重要、基礎的部分，數(shù)據(jù)不會平白無故地跑到我們的數(shù)據(jù)平臺中，我們得用什么東西把它從現(xiàn)有的設備（比如服務器，路由器、交換機、防火墻、數(shù)據(jù)庫等）中采集過來，再傳輸?shù)綌?shù)據(jù)平臺中，后面才有更加復雜的高難度的處理技術。

在采集過程中，如何應對數(shù)據(jù)多樣性、數(shù)據(jù)量大、變化快等特點，如何保證數(shù)據(jù)采集的可靠性、性能，如何避免重復數(shù)據(jù)，如何保證數(shù)據(jù)質(zhì)量，如何降低資源成本，這些都是大數(shù)據(jù)采集面臨的難點問題，所以，選擇一款合適的采集工具至關重要。

目前，F(xiàn)lume和Logstash是比較主流的數(shù)據(jù)采集工具（主要用于日志采集），以下將對這兩款工具進行詳細介紹以及對比選型。

首先介紹數(shù)據(jù)采集的通用模型，如圖：

其中，數(shù)據(jù)采集和存儲是必要的環(huán)節(jié)，其他并不一定需要。但這只是一個粗略的通用模型，不同開源社區(qū)或者廠家開發(fā)時都會有自己的考慮和目的。Flume和Logstash原則上都屬于數(shù)據(jù)采集這個范疇，但是兩者在技術上或多或少都自帶了一些緩沖、過濾等功能。

一、歷史簡介

Logstash：

Logstash誕生于2009年8月，2013年被ElasticSearch公司收購。Logstash是一個分布式日志收集框架，開發(fā)語言是JRuby，經(jīng)常與ElasticSearch，Kibana配合使用組成著名的ELK技術棧，所謂ELK就是ElasticSearch、

Logstash、Kibana這三個組件（ES負責數(shù)據(jù)的存儲和索引，Logstash負責數(shù)據(jù)采集和過濾轉(zhuǎn)換，Kibana則負責圖形界面處理），后來這三個組件又先后被Elastic.co公司收購。

Logstash非常適合做日志數(shù)據(jù)的采集，可以采用ELK組合使用，也可以作為日志收集軟件單獨出現(xiàn)，單獨出現(xiàn)時可將日志存儲到多種存儲系統(tǒng)或臨時中轉(zhuǎn)系統(tǒng)，如MySQL，redis，kakfa，HDFS, lucene，solr等，并不一定是ElasticSearch。

Flume：

Flume誕生于2010年，最早由Cloudrea開發(fā)，是一個高可用，高可靠，的分布式海量日志采集系統(tǒng)，支持定制各類數(shù)據(jù)發(fā)送方，一般和 kafka 訂閱消息系統(tǒng)搭配較多。其設計原理也是基于將數(shù)據(jù)流，如日志數(shù)據(jù)從各種網(wǎng)站服務器上匯集起來存儲到HDFS，HBase等集中存儲系統(tǒng)中。Flume目前有兩個版本，OG和NG，區(qū)別很大，初始的發(fā)行版本叫做FlumeOG，后被apache收購，改名為Apache Flume，收購重構后的版本統(tǒng)稱為

Flume NG（next generation下一代的意思）；所以現(xiàn)在Flume已經(jīng)是ApacheETL工具集中的一員。

結論：兩者最初的設計目的就不太一樣。Flume本身最初設計的目的是為了把數(shù)

據(jù)傳入HDFS中（并不是為了采集日志而設計，這和Logstash有根本的區(qū)別），所以理所應當側(cè)重于數(shù)據(jù)的傳輸，程序員要非常清楚整個數(shù)據(jù)的路由，并且比Logstash還多了一個可靠性策略，上文中的channel就是用于持久化目的，數(shù)據(jù)除非確認傳輸?shù)较乱晃恢昧耍駝t不會刪除，這一步是通過事務來控制的，這樣的設計使得可靠性非常好。相反，Logstash則明顯側(cè)重對數(shù)據(jù)的預處理，因為日志的字段需要大量的預處理，為解析做鋪墊。

二、系統(tǒng)架構

Logstash：

Logstash的設計非常規(guī)范，有三個組件，分工如下：

1、Shipper：負責日志收集。職責是監(jiān)控本地日志文件的變化，并輸出到

Redis 緩存起來；

2、Broker 可以看作是日志集線器，可以連接多個 Shipper 和多個 Indexer；

3、Indexer 負責日志存儲。在這個架構中會從 Redis 接收日志，寫入到本地文

件。

因為架構比較靈活，所以如果不想用 Logstash 的存儲，也可以對接到Elasticsearch，這也就是前面所說的 ELK 的套路了。

如果繼續(xù)細分，Logstash也可以這么解剖來看

所以Logstash就是這么簡約，全部將代碼集成，程序員不需要關心里面是如何運轉(zhuǎn)的。

Logstash最值得一提的是，在Filter plugin部分具有比較完備的功能，比如grok，能通過正則解析和結構化任何文本，Grok 目前是Logstash最好的方式對非結構化日志數(shù)據(jù)解析成結構化和可查詢化。此外，Logstash還可以重命名、刪除、替換和修改事件字段，當然也包括完全丟棄事件，如debug事件。

還有很多的復雜功能供程序員自己選擇，你會發(fā)現(xiàn)這些功能Flume是絕對沒有（以它的輕量級線程也是不可能做到的）。當然，在input和output兩個插件部分也具有非常多類似的可選擇性功能，程序員可以自由選擇，這一點跟Flume是比較相似的。

Flume：

下圖是Flume NG的架構圖：

Flume 從原理上看很簡單，三段式的結構：源（Source輸入）—存儲（Channel管道）—出口（Sink目標輸出）。但也因為涉及到這三個結構，所以做配置就比較復雜，這里舉個例子，看看Flume在一些場景下是如何搭建布置的，如下圖是Flume的集群部署：

Flume支持一個Agent中有多個不同類型的channel和sink，我們可以選擇把

Source的數(shù)據(jù)復制，分發(fā)給不同的目的端口，如下圖（Flume的多重復使用）：

其次，F(xiàn)lume還自帶了分區(qū)和攔截器功能，所以Flume也是有過濾功能的，只是Flume的過濾功能比較弱。Flume在集群中最擅長的事情就是做路由了，因為每一個Flume Agent相連就構成了一條鏈路，這也是眾多采集工具中Flume非常出色的亮點。但是也正因為如此，如果有一個Flume Agent出了問題，那么整個鏈路也會出現(xiàn)問題，所以在集群中需要設計分層架構等來實現(xiàn)冗余備份。但這么一來，配置又會變得很麻煩。

結論：我們會驚人的發(fā)現(xiàn)，兩者是多么的相似！Logstash的Shipper、

Broker、Indexer分別和Flume的Source、Channel、Sink各自對應！只不過是Logstash集成了，Broker可以不需要，而Flume需要單獨配置，且缺一不可，但這再一次說明了計算機的設計思想都是通用的！只是實現(xiàn)方式會不同而已。

三、開發(fā)配置

從程序員的角度來說，F(xiàn)lume配置比較繁瑣，你需要分別作source、channel、sink的手工配置，而且涉及到復雜的數(shù)據(jù)采集環(huán)境，你可能還要做多個配置，而Logstash的配置就非常簡潔清晰，三個部分的屬性都定義好了，程序員自己去選擇就行，就算沒有，也可以自行開發(fā)插件，非常方便。當然了，F(xiàn)lume的插件也很多，但Channel就只有內(nèi)存和文件這兩種（其實現(xiàn)在不止了，但常用的也就兩種）。讀者可以看得出來，兩者其實配置都是非常靈活的，只不過看場景取舍罷了。

四、性能、可靠性

因為Logstash內(nèi)部是沒有persist queue（打印隊列）的機制，所以在異常情況下，可能出現(xiàn)數(shù)據(jù)丟失的問題。所以選擇Logstash一般認為這個日志可能不重要。而Flume在高可用（可靠性）方面做得比較好，有自己的內(nèi)部機制確保這個問題，所以可以用于一些更重要的業(yè)務日志場景下。

性能上Logstash要高于Flume,因為Flume運用了一套安全機制，犧牲了部分性能。

五、插件

Logstash插件豐富，有幾十個插件，而且配置靈活，所以在擴展功能上比較全面。Flume沒有豐富的插件，主要靠二次開發(fā)（其實source和sink的種類也有一二十個，channel就比較少了）；

六、市場占有率級使用平臺

logstash是用的最多的，github上有4000+ stars，因為它好在有一套完整的日志收集（logstash）、日志存儲（elasticsearch）、日志展示分析（kibana）套件，搭建起來非常方便。

Logstash用戶：

Flume用戶：美團

七、總結

Logstash：

1、內(nèi)部沒有一個persist queue（打印隊列），異常情況可能會丟失部分數(shù)據(jù)；

2、由ruby編寫，需要ruby環(huán)境，插件很多；

3、偏重數(shù)據(jù)的預處理，為數(shù)據(jù)解析做鋪墊；

4、插件豐富，Logstash有幾十個插件，配置靈活；

5、Logstash的input和Fillter還有output之間都存在buffer，進行緩沖；

6、有ELK套件，技術成熟，使用場景廣泛，但比較重量級

Flume：

1.分布式高可靠高可用的數(shù)據(jù)采集系統(tǒng)，高效的從不同數(shù)據(jù)源收集、聚合、遷移數(shù)據(jù)到一個集中的數(shù)據(jù)存儲；

2、側(cè)重數(shù)據(jù)傳輸，使用基于事務的數(shù)據(jù)傳遞方式保證事件傳遞的可靠性，確保不會丟數(shù)據(jù)，用于重要日志場景；

3、由java開發(fā)，沒有豐富的插件，主要靠二次開發(fā)（source和sink的種類也有一二十個，channel就比較少了）；

4、輕量級線程，輕量級框架，以配置文件為中心，提供了JavaAPI；

5、安裝部署比較復雜，配置繁瑣，source，channel，sink三大組件都需要配置；

6.三層架構：source、channel、sink，是一個完整的基于插件的架構，有獨立開發(fā)的第三方插件；

7、Flume直接使用channel做持久化（可以理解為沒有filter）最后，flume是apache的，可以使用hadoop的hdfs，后端分析用MapReduce，選擇靈活多樣，而Logstash其實更有點像通用的模型，讓一切都變的簡單，所以對新人來說理解起來更簡單；Logstash就像是買來的臺式機，主板、電源、硬盤，機箱（Logstash）把里面的東西全部裝好了，你可以直接用，當然也可以自己組裝修改；Flume就像提供給你一套完整的主板，電源、硬盤，F(xiàn)lume沒有打包，只是像說明書一樣指導你如何組裝，才能運行的起來。