Flume是什麼？
Flume是一個分佈式、可靠的、高可用的、適合海量數據的日誌收集系統，用於收集、聚合和移動來自多個不同數據源的大量日誌數據到一個集中存儲中。
工作機制
它是怎麼做到把多個不同數據源的數據傳輸到另一個集中存儲中的呢？
首先來看下Flume的 source—channel—sink組合，如下圖：
運行Flume的核心是需要啓動一個Agent，它是一個長時間運行的Java進程，每個Agent都有三個組件：Source、Channel、Sink。其中Source監控外部源（某一目錄）的數據變化，如果有變化，就會產生Event，並將Event發送給Channel，然後Channel會臨時存儲Event，直到它被轉發到Sink，然後由Sink負責將數據（Event）發送到目的地（上圖的console，也可能爲一個Agent）。
從整個數據傳輸過程來看， 流動的是Event，它是傳輸數據的基本單位。Event從Source流向Channel，再到Sink，最後被寫入目的地。Event 其實是一個Byte數組，它包含可選的header部分和二進制的body部分，其中header部分包含了數據的路由規則，即流向。
核心組件：
- Source 用於接收外部源發送過來的數據，併產生事件。不同的數據源，數據格式可能不同。Flume可以支持Avro、Thift、log4j、syslog、Http POST等方式從外部數據源來傳輸數據。
- Channel 用於臨時存儲Source發送的Event數據，它可以存放在本地文件系統中、內存、JDBC等，直到成功發送到目的地或下一個Agent的Channel中，才能被刪除。
- Sink 用於消費Channel中的Event，並將數據發送到目的地或下一個Source。目的地包括HDFS、Hbase、file等。
事務和可靠性
Flume使用獨立的事務來保證每個Event從Source到Channel，再到Sink的可靠傳遞。如果由於某種原因，Event不能被記錄（log），那麼事務將發生回滾，Event將會保留在Channel中，直到再次傳遞。
Channel可以有兩種的形式來存儲Event：一種爲File Channel，另一種爲Memory Channel。兩者的區別是，File Channel具有持久性，而Memory Chanel沒有。在Event成功寫入到Channel後，File Channel中的Event不會丟失，即使Agent重啓，而Memory Channel中的Event將會丟失。選擇哪一種，應根據應用場景來選擇，使用Memory Channel較File Channel有較高的吞吐量。
複雜的數據流模型
多Agent模型
流合併
對於上圖，如果第二層的Agent4不可用，那麼整個傳輸將會中斷。對於這種情況，Flume中還可以爲每個Agent配置多個Sink，來提高Agent的容錯性和負載均衡：
流複用
Flume支持複用事件，可以將事件流到一個或多個目的地。它通過定義一個流複用器，可以複製或選擇事件路由到一個或多個Channel，如下圖。
