轉載：http://blog.csdn.net/jek123456/article/details/65658790

在某個Logstash的場景下，我產生了為什麽不能用Flume代替Logstash的疑問，因此查閱了不少材料在這裏總結，大部分都是前人的工作經驗下，加了一些我自己的思考在裏面，希望對大家有幫助。

本文適合有一定大數據基礎的讀者朋友們閱讀，但如果你沒有技術基礎，照樣可以繼續看（這就好比你看《葵花寶典》第一頁：欲練此功，必先自宮，然後翻到第二頁：若不自宮，也可練功，沒錯就是這種感覺→_→）。

大數據的數據采集工作是大數據技術中非常重要、基礎的部分，數據不會平白無故地跑到你的數據平臺軟件中，你得用什麽東西把它從現有的設備（比如服務器，路由器、交換機、防火墻、數據庫等）采集過來，再傳輸到你的平臺中，然後才會有後面更加復雜高難度的處理技術。

目前，Flume和Logstash是比較主流的數據采集工具（主要用於日誌采集），但是很多人還不太明白兩者的區別，特別是對用戶來說，具體場景使用合適的采集工具，可以大大提高效率和可靠性，並降低資源成本。

嗑瓜子群眾：餵餵，上面全都是沒用的廢話，說好的故事呢=。=

咳咳，好吧，現在我們開始講正事。首先我們給出一個通用的數據采集模型，主要是讓不太懂計算機或者通信的讀者們了解一下。

其中，數據采集和存儲是必要的環節，其他並不一定需要。是不是很簡單？本來編程其實就是模塊化的東西，沒有那麽難。但是這畢竟只是一個粗略的通用模型，不同開源社區或者商業廠家開發的時候都會有自己的考慮和目的。我們在本文要討論的Flume和Logstash原則上都屬於數據采集這個範疇，盡管兩者在技術上或多或少都自帶了一些緩沖、過濾等等功能。

好，我們先來看Logstash，然後看Flume，等你全部看完你就知道我為什麽這麽安排了。

Logstash是ELK組件中的一個。所謂ELK就是指，ElasticSearch、Logstash、Kibana這三個組件。那麽為什麽這三個組件要合在一起說呢？第一，這三個組件往往是配合使用的（ES負責數據的存儲和索引，Logstash負責數據采集和過濾轉換，Kibana則負責圖形界面處理）；第二，這三個組件又先後被收購於Elastic.co公司名下。是不是很巧合？這裏說個題外話，原ELK Stack在5.0版本加入Beats（一種代理）套件後改稱為Elastic Stack，這兩個詞是一個意思，只不過因為增加了Beats代理工具，改了個名字。

Logstash誕生於2009年8有2日，其作者是世界著名的虛擬主機托管商DreamHost的運維工程師喬丹 西塞（Jordan Sissel）。Logstash的開發很早，對比一下，Scribed誕生於2008年，Flume誕生於2010年，Graylog2誕生於2010年，Fluentd誕生於2011年。2013年，Logstash被ElasticSearch公司收購。這裏順便提一句，Logstash是喬丹的作品，所以帶著獨特的個人性格，這一點不像Facebook的Scribe，Apache的Flume開源基金項目。

你說的沒錯，以上都是廢話。（手動滑稽→_→）

Logstash的設計非常規範，有三個組件，其分工如下：

1、Shipper 負責日誌收集。職責是監控本地日誌文件的變化，並輸出到 Redis 緩存起來；2、Broker 可以看作是日誌集線器，可以連接多個 Shipper 和多個 Indexer；3、Indexer 負責日誌存儲。在這個架構中會從 Redis 接收日誌，寫入到本地文件。

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

如果繼續細分，Logstash也可以這麽解剖來看

貌似到這裏。。。好像就講完了。。。讀者朋友們不要罵我，因為Logstash就是這麽簡約，全部將代碼集成，程序員不需要關心裏面是如何運轉的。

Logstash最值得一提的是，在Filter plugin部分具有比較完備的功能，比如grok，能通過正則解析和結構化任何文本，Grok 目前是Logstash最好的方式對非結構化日誌數據解析成結構化和可查詢化。此外，Logstash還可以重命名、刪除、替換和修改事件字段，當然也包括完全丟棄事件，如debug事件。還有很多的復雜功能供程序員自己選擇，你會發現這些功能Flume是絕對沒有（以它的輕量級線程也是不可能做到的）。當然，在input和output兩個插件部分也具有非常多類似的可選擇性功能，程序員可以自由選擇，這一點跟Flume是比較相似的。

大大的分割線，讀者朋友們可以去上個廁所，然後再買一包瓜子了。

Logstash因為集成化設計，所以理解起來其實不難。現在我們講講Flume，這塊內容就有點多了。

最早Flume是由Cloudrea開發的日誌收集系統，初始的發行版本叫做Flume OG（就是original generation的意思），作為開源工具，一經公布，其實是很受關註的一套工具，但是後面隨著功能的拓展，暴露出代碼工程臃腫、核心組件設計不合理、核心配置不標準等各種缺點。尤其是在Flume OG的最後一個發行版本0.94.0中，日誌傳輸不穩定的現象特別嚴重。我們來看看Flume OG到底有什麽問題。

直到現在，你在網絡上搜索Flume相關資料的時候還會經常出現Flume OG的結構圖，這對新人來說是很不友好的，很容易引起誤導，請讀者朋友們一定要註意！我們可以看到Flume OG有三種角色的節點：代理節點（agent）、收集節點（collector）、主節點（master）。

流程理解起來也並不困難：agent 從各個數據源收集日誌數據，將收集到的數據集中到 collector，然後由收集節點匯總存入 hdfs。master 負責管理 agent，collector 的活動。agent、collector 都稱為 node，node 的角色根據配置的不同分為 logical node（邏輯節點）、physical node（物理節點）。對logical nodes和physical nodes的區分、配置、使用一直以來都是使用者最頭疼的地方。

agent、collector 由 source、sink 組成，代表在當前節點數據是從 source 傳送到 sink。

就算是外行人，看到這裏也覺得很頭大，這尼瑪是誰設計出來的破玩意？

各種問題的暴露，迫使開發者痛下決心，拋棄原有的設計理念，徹底重寫Flume。於是在2011 年 10 月 22 號，Cloudera 完成了 Flume-728，對 Flume 進行了裏程碑式的改動：重構核心組件、核心配置以及代碼架構，重構後的版本統稱為 Flume NG（next generation下一代的意思）；改動的另一原因是將 Flume 納入 apache 旗下，Cloudera Flume 改名為 Apache Flume，所以現在Flume已經是Apache ETL工具集中的一員。

這裏說個題外話，大家都知道，通常情況下大公司，特別是大型IT公司是比較排斥使用一些不穩定的新技術的，也不喜歡頻繁變換技術，這很簡單，因為變化很容易導致意外。舉個例子，Linux發展了二十多年了，大部分公司都在使用RedHat、CentOS和Ubuntu這類旨在提供穩定、兼容好的版本，如果你看到一家公司用的是Linux新內核，那多半是一家新公司，需要用一些新技術在競爭中處於上風。

好，了解了一些歷史背景，現在我們可以放上Flume NG的結構圖了

臥槽，是不是很簡單？！對比一下OG的結構，外行人都會驚嘆：so easy！

這次開發者吸取了OG的血淋林教訓，將最核心的幾塊部分做了改動：

1、NG 只有一種角色的節點：代理節點（agent），而不是像OG那麽多角色；

2、沒有collector，master節點。這是核心組件最核心的變化；

3、去除了physical nodes、logical nodes的概念和相關內容；

4、agent 節點的組成也發生了變化，NG agent由source、sink、channel組成。

那麽這麽做有什麽好處呢？簡單概括有這麽三點：

1、NG 簡化核心組件，移除了 OG 版本代碼工程臃腫、核心組件設計不合理、核心配置不標準等缺點，使得數據流的配置變得更簡單合理，這是比較直觀的一個改進點；

2、NG 脫離了 Flume 穩定性對 zookeeper 的依賴。在早期的OG版本中，Flume 的使用穩定性依賴 zookeeper。它需要 zookeeper 對其多類節點（agent、collector、master）的工作進行管理，尤其是在集群中配置多個 master 的情況下。當然，OG 也可以用內存的方式管理各類節點的配置信息，但是需要用戶能夠忍受在機器出現故障時配置信息出現丟失。所以說 OG 的穩定行使用是依賴 zookeeper 的。

3、NG 版本對用戶要求大大降低：安裝過程除了java無需配置復雜的Flume相關屬性，也無需搭建zookeeper集群，安裝過程幾乎零工作量。

有人很不解，怎麽突然冒出來一個Zookeeper這個概念，這是個啥玩意？簡單的說，Zookeeper 是針對大型分布式系統的可靠協調系統，適用於有多類角色集群管理。你可以把它理解為整個Hadoop的總管家，負責整個系統所有組件之間的協調工作管理。這個組件平時很不起眼，但非常重要。好比一支籃球隊，五個隊員個個都是巨星，所以我們平時都習慣關註這五個人，但是整個球隊的獲勝缺不了教練的協調組織、戰術安排，Zookeeper就好比是整個Hadoop系統的教練。比喻雖然有些生硬，只是想說明Zookeeper的重要性，也側面說明NG在擺脫了Zookeeper的依賴後變得更加輕便，靈活。

說個題外話，OG版本的使用文檔有90多頁，而NG只用 20 多頁的內容就完成了新版 Flume 的使用說明。可見在科學研究領域，人類總是在追求真理，而真理總是可以用最簡單的語言描述出來。

到這裏差不多Flume就講的差不多了，因為這個線程工具從原理上講真的很簡單，三段式的結構：源（Source輸入）——存儲（Channel管道）——出口（Sink目標輸出）。但也因為涉及到這三個結構，所以做配置就比較復雜，這裏舉個例子，我們看看Flume在一些場景下是如何搭建布置的。

這裏要糾正幾個很多初學Flume朋友們的誤區。首先，Flume已經可以支持一個Agent中有多個不同類型的channel和sink，我們可以選擇把Source的數據復制，分發給不同的目的端口，比如：

其次，Flume還自帶了分區和攔截器功能，因此不是像很多實驗者認為的沒有過濾功能（當然我承認Flume的過濾功能比較弱）。

讀者可能會隱約感覺到，Flume在集群中最擅長的事情就是做路由了，因為每一個Flume Agent相連就構成了一條鏈路，這也是眾多采集工具中Flume非常出色的亮點。但是也正因為如此，如果有一個Flume Agent出了問題，那麽整個鏈路也會出現問題，所以在集群中需要設計分層架構等來實現冗余備份。但這麽一來，配置又會變得很麻煩。

最後一個大大的分隔線

把Logstash和Flume都講完了，我們最後可以對比總結一下了。

首先從結構對比，我們會驚人的發現，兩者是多麽的相似！Logstash的Shipper、Broker、Indexer分別和Flume的Source、Channel、Sink各自對應！只不過是Logstash集成了，Broker可以不需要，而Flume需要單獨配置，且缺一不可，但這再一次說明了計算機的設計思想都是通用的！只是實現方式會不同而已。

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

其實從作者和歷史背景來看，兩者最初的設計目的就不太一樣。Flume本身最初設計的目的是為了把數據傳入HDFS中（並不是為了采集日誌而設計，這和Logstash有根本的區別），所以理所應當側重於數據的傳輸，程序員要非常清楚整個數據的路由，並且比Logstash還多了一個可靠性策略，上文中的channel就是用於持久化目的，數據除非確認傳輸到下一位置了，否則不會刪除，這一步是通過事務來控制的，這樣的設計使得可靠性非常好。相反，Logstash則明顯側重對數據的預處理，因為日誌的字段需要大量的預處理，為解析做鋪墊。

回過來看我當初為什麽先講Logstash然後講Flume？這裏面有幾個考慮，其一：Logstash其實更有點像通用的模型，所以對新人來說理解起來更簡單，而Flume這樣輕量級的線程，可能有一定的計算機編程基礎理解起來更好；其二：目前大部分的情況下，Logstash用的更加多，這個數據我自己沒有統計過，但是根據經驗判斷，Logstash可以和ELK其他組件配合使用，開發、應用都會簡單很多，技術成熟，使用場景廣泛。相反Flume組件就需要和其他很多工具配合使用，場景的針對性會比較強，更不用提Flume的配置過於繁瑣復雜了。

最後總結下來，我們可以這麽理解他們的區別：Logstash就像是買來的臺式機，主板、電源、硬盤，機箱（Logstash）把裏面的東西全部裝好了，你可以直接用，當然也可以自己組裝修改；Flume就像提供給你一套完整的主板，電源、硬盤，Flume沒有打包，只是像說明書一樣指導你如何組裝，才能運行的起來。

講完，收工。

參考文獻：

《Flume日誌收集與Map Reduce模式》張龍 譯

《ELK stack權威指南》 饒琛琳 編著

www.2cto.com/kf/201607/530428.html Flume綜述與實例

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日誌收集分層架構應用實踐

www.cnblogs.com/xing901022/p/5631445.html Flume日誌采集系統

www.tuicool.com/articles/BJRz22V Logstash指南

tchuairen.blog.51cto.com/3848118/1840596/ Logstash講解與實戰應用

聊聊Flume和Logstash的那些事兒