概述
最近翻Flume官網又有了新的收穫，準備對Flume進行一個詳細的描述，Fume到底是什麼，有什麼用，怎麼用，選型問題，各種參數選擇。當然對於參數的選擇作者在以前剛開始學習的時候遇到過不少坑，不同的版本參數是不一樣的，大家一定要對應着自己的版本去官網查找，官網是最權威的。有什麼不對的地方大家相互交流學習。
Flume介紹
老規矩官網地址
Flume是一種分佈式，可靠，高可用的服務，用於有效地從許多不同的源端收集，聚合和移動大量日誌數據到集中
式數據存儲。 它具有基於流數據流的簡單靈活的架構、它具有可靠性機制和許多故障轉移和恢復機制，具有強大
的容錯能力。 它使用簡單的可擴展數據模型，允許在線分析應用程序。
Apache Flume的使用不僅限於日誌數據聚合。 由於數據源是可定製的，因此Flume可用於傳輸大量事件數據，
包括但不限於網絡流量數據，社交媒體生成的數據，電子郵件消息以及幾乎任何可能的數據源。
看完上面一段話相信大家可能看的也是雲裏霧裏的，最簡單的大家可以理解Flume爲日誌收集的工具，後面會對上面的每句話做個詳細的解讀。
Flume歷史
Flume目前有兩種版本代碼行，版本0.9.x和1.x.
0.9x以前叫做Flume OG（original generation），屬於 cloudera。但隨着 FLume 功能的擴展，Flume OG 代碼工程臃腫、核心組件設計不合理、核心配置不標準等缺點暴露出來，日誌傳輸不穩定的現象尤爲嚴重，爲了解決這些問題，1.X後對Flume進行了重構重構後的版本統稱爲 Flume NG（next generation）；改動的另一原因是將 Flume 納入 apache 旗下，cloudera Flume 改名爲 Apache Flume。Apache Flume是Apache Software Foundation的頂級項目。
Flume產生背景
我們知道對於關係型數據庫我們可以使用sqoop進行數據的處理，導入hive，hdfs,mysql等。那對於一些日誌該怎麼處理呢？（From outside To inside ），怎麼樣定時收集ng產生的日誌到HDFS呢？
我們可能想到直接使用shell寫一個腳本，使用crontab進行調度，這樣不就行了嗎。。但是大家有沒有想到一個問題呢，如果日誌量太大，涉及到存儲格式、壓縮格式、序列化等等一些大數據中常用的東西怎麼辦呢？要從不同的源端收集是不是要寫多個腳本呢？同樣我要存到不同的地方發該怎麼辦呢？肯定不止這些問題。所以Flume出現了來幫助我們解決這些問題。
Flume基本概念
可以參考以前的博客博客地址，
Event： Event是Flume事件處理的最小單元，Flume在讀取數據源時，會將一行數據（也就是遇到\r\n）包裝成一個Event，它主要有倆個部分，Header和Body, Header主要是以Key,Value的形式用來記錄該數據的一些冗餘信息，可用來標記數據唯一信息，利用Header的信息，我們可以對數據做出一些額外的操作，如對數據進行一個簡單過濾，Body則是存入真正數據的地方。
Agent： 代表一個獨立的Flume進程，包含組件Source、 Channel、 Sink。（Agent使用JVM 運行Flume。每臺機器運行一個agent，但是可以在一個agent中包含多個sources、channel和sinks。）
flume之所以這麼神奇，是源於它自身的一個設計，這個設計就是agent，agent本身是一個java進程，運行在日誌收集節點—所謂日誌收集節點就是服務器節點。
1. Source:負責從源端採集數據，輸出到channel中，常用的Source有exec/Spooling Directory/Taildir Source/NetCat
2. Channel:負責緩存Source端來的數據，常用的Channel有Memory/File
3. Sink:處理Channel而來的數據寫到目標端，常用的Sink有HDFS/Logger/Avro/Kafka
總結：Flume處理數據的最小單元是Event，一個Agent代表一個Flume進程，一個Agent=Source+Channel+Sink 組成。Flume牛逼之處也在於他的組成部分，可以進行各種組合選型。
講到這裏相信大家會有個簡單的瞭解了，下面就要對Flume介紹中說的進行詳細的剖析。
Flume特點
前面進行簡單的講解，現在我們來總結Flume具有的一些特點：
1. 可以從不同的源端收集數據；
2. 輸出結果可以到不同的地方，下一個Agent、HDFS、Kafka等。
3. 架構簡單靈活，可配置化，可插拔
4. 有多種Interceptor可供選擇
5. 具有可靠性和可恢復性
6. 具有容錯機制和負載均衡機制（Flume Sink Processors）
7. 具有複製和多路複用機制（flume channel selectors）
Flume詳細剖析
對於分佈式我們這裏就不多說了，大數據場景下必然是的。我們重點講解下高可靠，高可用，怎麼達到可靠，高可用。
可靠性
Flume可靠性：Flume 使用事務性的方式保證傳送Event整個過程的可靠性。 Sink 必須在Event 被存入 Channel 後，或者，已經被傳達到下一站agent裏，又或者已經被存入外部數據目的地之後，才能把 Event 從 Channel 中 remove 掉。這樣數據流裏的 event 無論是在一個 agent 裏還是多個 agent 之間流轉，都能保證可靠，因爲以上的事務保證了 event 會被成功存儲起來。這就保證了端到端的可靠性。比如 Flume支持在本地保存一份文件 channel 作爲備份，而memory channel 將event存在內存 queue 裏，速度快，但丟失的話無法恢復，所以channel的選型，維護也很重要。
flume使用這種事物的方式保證events傳輸的可靠性所以這就不得不提Flume的事務機制（類似數據庫的事務機制）：Flume使用兩個獨立的事務分別負責從soucrce到channel，以及從channel到sink的事件傳遞。
比如spooling directory source 爲文件的每一行創建一個事件，一旦事務中所有的事件全部傳遞到channel且提交成功，那麼source就將該文件標記爲完成。同理，事務以類似的方式處理從channel到sink的傳遞過程，如果因爲某種 原因使得事件無法記錄，那麼事務將會回滾。且所有的事件都會保持到channel中，等待重新傳遞。
可恢復性
events被存儲在channel裏面，如果flume掛了可以從channel中恢復，保證數據不會丟失（不是絕對的），你可以選擇不同類型的channel根據業務需求，例如file channel存儲在本地磁盤，可以保證數據不會丟失，
也有memory channel，他簡單將event存儲在內存隊列中，速度快，但是agent掛掉可能會使得緩存在內存中的數據丟失。
總的來說Flume整體架構的設計和選型（扇入，扇出），使得它具有可靠性和可恢復性。以及後面還會講解的Flume Sink Processors和flume channel selectors也是很重要的一點。
講到這裏大家就可以先進行簡單的操作了，官網也有些例子，對於新手來說看起來還是比較吃力的，可以參考我以前寫的博客Flume基本操作和flume常用場景。大家一定要自己去練習。
架構
未完待續…(最近工作任務稍多，後面會繼續懟)