在某個Logstash的場景下，我產(chǎn)生了為什么不能用Flume代替Logstash的疑問，因此查閱了不少材料在這里總結(jié)，大部分都是前人的工作經(jīng)驗(yàn)下，加了一些我自己的思考在里面，希望對大家有幫助。
本文適合有一定大數(shù)據(jù)基礎(chǔ)的讀者朋友們閱讀，但如果你沒有技術(shù)基礎(chǔ)，照樣可以繼續(xù)看（這就好比你看《葵花寶典》第一頁：欲練此功，必先自宮，然后翻到第二頁：若不自宮，也可練功，沒錯就是這種感覺→_→）。
大數(shù)據(jù)的數(shù)據(jù)采集工作是大數(shù)據(jù)技術(shù)中非常重要、基礎(chǔ)的部分，數(shù)據(jù)不會平白無故地跑到你的數(shù)據(jù)平臺軟件中，你得用什么東西把它從現(xiàn)有的設(shè)備（比如服務(wù)器，路由器、交換機(jī)、防火墻、數(shù)據(jù)庫等）采集過來，再傳輸?shù)侥愕钠脚_中，然后才會有后面更加復(fù)雜高難度的處理技術(shù)。
目前，F(xiàn)lume和Logstash是比較主流的數(shù)據(jù)采集工具（主要用于日志采集），但是很多人還不太明白兩者的區(qū)別，特別是對用戶來說，具體場景使用合適的采集工具，可以大大提高效率和可靠性，并降低資源成本。
嗑瓜子群眾：喂喂，上面全都是沒用的廢話，說好的故事呢=。=
咳咳，好吧，現(xiàn)在我們開始講正事。首先我們給出一個通用的數(shù)據(jù)采集模型，主要是讓不太懂計算機(jī)或者通信的讀者們了解一下。
其中，數(shù)據(jù)采集和存儲是必要的環(huán)節(jié)，其他并不一定需要。是不是很簡單？本來編程其實(shí)就是模塊化的東西，沒有那么難。但是這畢竟只是一個粗略的通用模型，不同開源社區(qū)或者商業(yè)廠家開發(fā)的時候都會有自己的考慮和目的。我們在本文要討論的Flume和Logstash原則上都屬于數(shù)據(jù)采集這個范疇，盡管兩者在技術(shù)上或多或少都自帶了一些緩沖、過濾等等功能。
好，我們先來看Logstash，然后看Flume，等你全部看完你就知道我為什么這么安排了。
Logstash是ELK組件中的一個。所謂ELK就是指，ElasticSearch、Logstash、Kibana這三個組件。那么為什么這三個組件要合在一起說呢？第一，這三個組件往往是配合使用的（ES負(fù)責(zé)數(shù)據(jù)的存儲和索引，Logstash負(fù)責(zé)數(shù)據(jù)采集和過濾轉(zhuǎn)換，Kibana則負(fù)責(zé)圖形界面處理）；第二，這三個組件又先后被收購于Elastic.co公司名下。是不是很巧合？這里說個題外話，原ELK Stack在5.0版本加入Beats（一種代理）套件后改稱為Elastic Stack，這兩個詞是一個意思，只不過因?yàn)樵黾恿薆eats代理工具，改了個名字。
Logstash誕生于2009年8有2日，其作者是世界著名的虛擬主機(jī)托管商DreamHost的運(yùn)維工程師喬丹 西塞（Jordan Sissel）。Logstash的開發(fā)很早，對比一下，Scribed誕生于2008年，F(xiàn)lume誕生于2010年，Graylog2誕生于2010年，F(xiàn)luentd誕生于2011年。2013年，Logstash被ElasticSearch公司收購。這里順便提一句，Logstash是喬丹的作品，所以帶著獨(dú)特的個人性格，這一點(diǎn)不像Facebook的Scribe，Apache的Flume開源基金項(xiàng)目。
你說的沒錯，以上都是廢話。（手動滑稽→_→）
Logstash的設(shè)計非常規(guī)范，有三個組件，其分工如下：
1、Shipper 負(fù)責(zé)日志收集。職責(zé)是監(jiān)控本地日志文件的變化，并輸出到 Redis 緩存起來；2、Broker 可以看作是日志集線器，可以連接多個 Shipper 和多個 Indexer；3、Indexer 負(fù)責(zé)日志存儲。在這個架構(gòu)中會從 Redis 接收日志，寫入到本地文件。
這里要說明，因?yàn)榧軜?gòu)比較靈活，如果不想用 Logstash 的存儲，也可以對接到 Elasticsearch，這也就是前面所說的 ELK 的套路了。
如果繼續(xù)細(xì)分，Logstash也可以這么解剖來看
貌似到這里。。。好像就講完了。。。讀者朋友們不要罵我，因?yàn)長ogstash就是這么簡約，全部將代碼集成，程序員不需要關(guān)心里面是如何運(yùn)轉(zhuǎn)的。
Logstash最值得一提的是，在Filter plugin部分具有比較完備的功能，比如grok，能通過正則解析和結(jié)構(gòu)化任何文本，Grok 目前是Logstash最好的方式對非結(jié)構(gòu)化日志數(shù)據(jù)解析成結(jié)構(gòu)化和可查詢化。此外，Logstash還可以重命名、刪除、替換和修改事件字段，當(dāng)然也包括完全丟棄事件，如debug事件。還有很多的復(fù)雜功能供程序員自己選擇，你會發(fā)現(xiàn)這些功能Flume是絕對沒有（以它的輕量級線程也是不可能做到的）。當(dāng)然，在input和output兩個插件部分也具有非常多類似的可選擇性功能，程序員可以自由選擇，這一點(diǎn)跟Flume是比較相似的。
大大的分割線，讀者朋友們可以去上個廁所，然后再買一包瓜子了。
Logstash因?yàn)榧苫O(shè)計，所以理解起來其實(shí)不難。現(xiàn)在我們講講Flume，這塊內(nèi)容就有點(diǎn)多了。
最早Flume是由Cloudrea開發(fā)的日志收集系統(tǒng)，初始的發(fā)行版本叫做Flume OG（就是original generation的意思），作為開源工具，一經(jīng)公布，其實(shí)是很受關(guān)注的一套工具，但是后面隨著功能的拓展，暴露出代碼工程臃腫、核心組件設(shè)計不合理、核心配置不標(biāo)準(zhǔn)等各種缺點(diǎn)。尤其是在Flume OG的最后一個發(fā)行版本0.94.0中，日志傳輸不穩(wěn)定的現(xiàn)象特別嚴(yán)重。我們來看看Flume OG到底有什么問題。
直到現(xiàn)在，你在網(wǎng)絡(luò)上搜索Flume相關(guān)資料的時候還會經(jīng)常出現(xiàn)Flume OG的結(jié)構(gòu)圖，這對新人來說是很不友好的，很容易引起誤導(dǎo)，請讀者朋友們一定要注意！我們可以看到Flume OG有三種角色的節(jié)點(diǎn)：代理節(jié)點(diǎn)（agent）、收集節(jié)點(diǎn)（collector）、主節(jié)點(diǎn)（master）。
流程理解起來也并不困難：agent 從各個數(shù)據(jù)源收集日志數(shù)據(jù)，將收集到的數(shù)據(jù)集中到 collector，然后由收集節(jié)點(diǎn)匯總存入 hdfs。master 負(fù)責(zé)管理 agent，collector 的活動。agent、collector 都稱為 node，node 的角色根據(jù)配置的不同分為 logical node（邏輯節(jié)點(diǎn)）、physical node（物理節(jié)點(diǎn)）。對logical nodes和physical nodes的區(qū)分、配置、使用一直以來都是使用者最頭疼的地方。
agent、collector 由 source、sink 組成，代表在當(dāng)前節(jié)點(diǎn)數(shù)據(jù)是從 source 傳送到 sink。
就算是外行人，看到這里也覺得很頭大，這尼瑪是誰設(shè)計出來的破玩意？
各種問題的暴露，迫使開發(fā)者痛下決心，拋棄原有的設(shè)計理念，徹底重寫Flume。于是在2011 年 10 月 22 號，Cloudera 完成了 Flume-728，對 Flume 進(jìn)行了里程碑式的改動：重構(gòu)核心組件、核心配置以及代碼架構(gòu)，重構(gòu)后的版本統(tǒng)稱為 Flume NG（next generation下一代的意思）；改動的另一原因是將 Flume 納入 apache 旗下，Cloudera Flume 改名為 Apache Flume，所以現(xiàn)在Flume已經(jīng)是Apache ETL工具集中的一員。
這里說個題外話，大家都知道，通常情況下大公司，特別是大型IT公司是比較排斥使用一些不穩(wěn)定的新技術(shù)的，也不喜歡頻繁變換技術(shù)，這很簡單，因?yàn)樽兓苋菀讓?dǎo)致意外。舉個例子，Linux發(fā)展了二十多年了，大部分公司都在使用RedHat、CentOS和Ubuntu這類旨在提供穩(wěn)定、兼容好的版本，如果你看到一家公司用的是Linux新內(nèi)核，那多半是一家新公司，需要用一些新技術(shù)在競爭中處于上風(fēng)。
好，了解了一些歷史背景，現(xiàn)在我們可以放上Flume NG的結(jié)構(gòu)圖了
臥槽，是不是很簡單？！對比一下OG的結(jié)構(gòu)，外行人都會驚嘆：so easy！
這次開發(fā)者吸取了OG的血淋林教訓(xùn)，將最核心的幾塊部分做了改動：
1、NG 只有一種角色的節(jié)點(diǎn)：代理節(jié)點(diǎn)（agent），而不是像OG那么多角色；
2、沒有collector，master節(jié)點(diǎn)。這是核心組件最核心的變化；
3、去除了physical nodes、logical nodes的概念和相關(guān)內(nèi)容；
4、agent 節(jié)點(diǎn)的組成也發(fā)生了變化，NG agent由source、sink、channel組成。
那么這么做有什么好處呢？簡單概括有這么三點(diǎn)：
1、NG 簡化核心組件，移除了 OG 版本代碼工程臃腫、核心組件設(shè)計不合理、核心配置不標(biāo)準(zhǔn)等缺點(diǎn)，使得數(shù)據(jù)流的配置變得更簡單合理，這是比較直觀的一個改進(jìn)點(diǎn)；
2、NG 脫離了 Flume 穩(wěn)定性對 zookeeper 的依賴。在早期的OG版本中，F(xiàn)lume 的使用穩(wěn)定性依賴 zookeeper。它需要 zookeeper 對其多類節(jié)點(diǎn)（agent、collector、master）的工作進(jìn)行管理，尤其是在集群中配置多個 master 的情況下。當(dāng)然，OG 也可以用內(nèi)存的方式管理各類節(jié)點(diǎn)的配置信息，但是需要用戶能夠忍受在機(jī)器出現(xiàn)故障時配置信息出現(xiàn)丟失。所以說 OG 的穩(wěn)定行使用是依賴 zookeeper 的。
3、NG 版本對用戶要求大大降低：安裝過程除了java無需配置復(fù)雜的Flume相關(guān)屬性，也無需搭建zookeeper集群，安裝過程幾乎零工作量。
有人很不解，怎么突然冒出來一個Zookeeper這個概念，這是個啥玩意？簡單的說，Zookeeper 是針對大型分布式系統(tǒng)的可靠協(xié)調(diào)系統(tǒng)，適用于有多類角色集群管理。你可以把它理解為整個Hadoop的總管家，負(fù)責(zé)整個系統(tǒng)所有組件之間的協(xié)調(diào)工作管理。這個組件平時很不起眼，但非常重要。好比一支籃球隊(duì)，五個隊(duì)員個個都是巨星，所以我們平時都習(xí)慣關(guān)注這五個人，但是整個球隊(duì)的獲勝缺不了教練的協(xié)調(diào)組織、戰(zhàn)術(shù)安排，Zookeeper就好比是整個Hadoop系統(tǒng)的教練。比喻雖然有些生硬，只是想說明Zookeeper的重要性，也側(cè)面說明NG在擺脫了Zookeeper的依賴后變得更加輕便，靈活。
說個題外話，OG版本的使用文檔有90多頁，而NG只用 20 多頁的內(nèi)容就完成了新版 Flume 的使用說明。可見在科學(xué)研究領(lǐng)域，人類總是在追求真理，而真理總是可以用最簡單的語言描述出來。
到這里差不多Flume就講的差不多了，因?yàn)檫@個線程工具從原理上講真的很簡單，三段式的結(jié)構(gòu)：源（Source輸入）——存儲（Channel管道）——出口（Sink目標(biāo)輸出）。但也因?yàn)樯婕暗竭@三個結(jié)構(gòu)，所以做配置就比較復(fù)雜，這里舉個例子，我們看看Flume在一些場景下是如何搭建布置的。
這里要糾正幾個很多初學(xué)Flume朋友們的誤區(qū)。首先，F(xiàn)lume已經(jīng)可以支持一個Agent中有多個不同類型的channel和sink，我們可以選擇把Source的數(shù)據(jù)復(fù)制，分發(fā)給不同的目的端口，比如：
其次，F(xiàn)lume還自帶了分區(qū)和攔截器功能，因此不是像很多實(shí)驗(yàn)者認(rèn)為的沒有過濾功能（當(dāng)然我承認(rèn)Flume的過濾功能比較弱）。
讀者可能會隱約感覺到，F(xiàn)lume在集群中最擅長的事情就是做路由了，因?yàn)槊恳粋€Flume Agent相連就構(gòu)成了一條鏈路，這也是眾多采集工具中Flume非常出色的亮點(diǎn)。但是也正因?yàn)槿绱耍绻幸粋€Flume Agent出了問題，那么整個鏈路也會出現(xiàn)問題，所以在集群中需要設(shè)計分層架構(gòu)等來實(shí)現(xiàn)冗余備份。但這么一來，配置又會變得很麻煩。
最后一個大大的分隔線
把Logstash和Flume都講完了，我們最后可以對比總結(jié)一下了。
首先從結(jié)構(gòu)對比，我們會驚人的發(fā)現(xiàn)，兩者是多么的相似！Logstash的Shipper、Broker、Indexer分別和Flume的Source、Channel、Sink各自對應(yīng)！只不過是Logstash集成了，Broker可以不需要，而Flume需要單獨(dú)配置，且缺一不可，但這再一次說明了計算機(jī)的設(shè)計思想都是通用的！只是實(shí)現(xiàn)方式會不同而已。
從程序員的角度來說，上文也提到過了，F(xiàn)lume是真的很繁瑣，你需要分別作source、channel、sink的手工配置，而且涉及到復(fù)雜的數(shù)據(jù)采集環(huán)境，你可能還要做多個配置，這在上面提過了，反過來說Logstash的配置就非常簡潔清晰，三個部分的屬性都定義好了，程序員自己去選擇就行，就算沒有，也可以自行開發(fā)插件，非常方便。當(dāng)然了，F(xiàn)lume的插件也很多，但Channel就只有內(nèi)存和文件這兩種（其實(shí)現(xiàn)在不止了，但常用的也就兩種）。讀者可以看得出來，兩者其實(shí)配置都是非常靈活的，只不過看場景取舍罷了。
其實(shí)從作者和歷史背景來看，兩者最初的設(shè)計目的就不太一樣。Flume本身最初設(shè)計的目的是為了把數(shù)據(jù)傳入HDFS中（并不是為了采集日志而設(shè)計，這和Logstash有根本的區(qū)別），所以理所應(yīng)當(dāng)側(cè)重于數(shù)據(jù)的傳輸，程序員要非常清楚整個數(shù)據(jù)的路由，并且比Logstash還多了一個可靠性策略，上文中的channel就是用于持久化目的，數(shù)據(jù)除非確認(rèn)傳輸?shù)较乱晃恢昧耍駝t不會刪除，這一步是通過事務(wù)來控制的，這樣的設(shè)計使得可靠性非常好。相反，Logstash則明顯側(cè)重對數(shù)據(jù)的預(yù)處理，因?yàn)槿罩镜淖侄涡枰罅康念A(yù)處理，為解析做鋪墊。
回過來看我當(dāng)初為什么先講Logstash然后講Flume？這里面有幾個考慮，其一：Logstash其實(shí)更有點(diǎn)像通用的模型，所以對新人來說理解起來更簡單，而Flume這樣輕量級的線程，可能有一定的計算機(jī)編程基礎(chǔ)理解起來更好；其二：目前大部分的情況下，Logstash用的更加多，這個數(shù)據(jù)我自己沒有統(tǒng)計過，但是根據(jù)經(jīng)驗(yàn)判斷，Logstash可以和ELK其他組件配合使用，開發(fā)、應(yīng)用都會簡單很多，技術(shù)成熟，使用場景廣泛。相反Flume組件就需要和其他很多工具配合使用，場景的針對性會比較強(qiáng)，更不用提Flume的配置過于繁瑣復(fù)雜了。
最后總結(jié)下來，我們可以這么理解他們的區(qū)別：Logstash就像是買來的臺式機(jī)，主板、電源、硬盤，機(jī)箱（Logstash）把里面的東西全部裝好了，你可以直接用，當(dāng)然也可以自己組裝修改；Flume就像提供給你一套完整的主板，電源、硬盤，F(xiàn)lume沒有打包，只是像說明書一樣指導(dǎo)你如何組裝，才能運(yùn)行的起來。
講完，收工。
參考文獻(xiàn)：
《Flume日志收集與Map Reduce模式》張龍 譯
《ELK stack權(quán)威指南》 饒琛琳 編著
www.2cto.com/kf/201607/530428.html? Flume綜述與實(shí)例
www.dataguru.cn/thread-477981-1-1.html? Flume日志收集
www.ibm.com/developerworks/cn/data/library/bd-1404flumerevolution/index.html??Flume NG
shiyanjun.cn/archives/1497.html? Flume日志收集分層架構(gòu)應(yīng)用實(shí)踐
www.cnblogs.com/xing901022/p/5631445.html??Flume日志采集系統(tǒng)
www.tuicool.com/articles/BJRz22V? Logstash指南
tchuairen.blog.51cto.com/3848118/1840596/? Logstash講解與實(shí)戰(zhàn)應(yīng)用
