本課分三部分內容：
-
第一部分講什麼是Flume；
-
第二部分講Flume+Kafka+Spark Streaming應用場景；
-
第三部分講Kafka數據寫入Spark Streaming有兩種方式。
一、什麼是Flume?
Flume
作爲
Cloudera
開發的實時日誌收集系統，受到了業界的認可與廣泛應用。Flume
初始的發行版本目前被統稱爲
Flume OG（original
generation），屬於
Cloudera。但隨着
Flume
功能的擴展，Flume OG
代碼工程臃腫、核心組件設計不合理、核心配置不標準等缺點暴露出來，尤其是在
Flume OG
的最後一個發行版本 0.94.0
中，日誌傳輸不穩定的現象尤爲嚴重，爲了解決這些問題，2011
年 10
月 22
號，Cloudera
完成了
Flume-728，對
Flume
進行了里程碑式的改動：重構核心組件、核心配置以及代碼架構，重構後的版本統稱爲
Flume NG（next
generation）；改動的另一原因是將
Flume
納入 apache
旗下，Cloudera Flume
改名爲 Apache Flume。
Flume的特點
Flume是一個分佈式、可靠、和高可用的海量日誌採集、聚合和傳輸的系統。支持在日誌系統中定製各類數據發送方，用於收集數據；同時，Flume提供對數據進行簡單處理，並寫到各種數據接受方(比如文本、HDFS、Hbase等)的能力
。
Flume的數據流由事件(Event)貫穿始終。事件是Flume的基本數據單位，它攜帶日誌數據(字節數組形式)並且攜帶有頭信息，這些Event由Agent外部的Source生成，當Source捕獲事件後會進行特定的格式化，然後Source會把事件推入(單個或多個)Channel中。你可以把Channel看作是一個緩衝區，它將保存事件直到Sink處理完該事件。Sink負責持久化日誌或者把事件推向另一個Source。
Flume的可靠性
當節點出現故障時，日誌能夠被傳送到其他節點上而不會丟失。Flume提供了三種級別的可靠性保障，從強到弱依次分別爲：end-to-end（收到數據agent首先將event寫到磁盤上，當數據傳送成功後，再刪除；如果數據發送失敗，可以重新發送）；Store
on failure（這也是scribe採用的策略，當數據接收方crash時，將數據寫到本地，待恢復後，繼續發送）；Besteffort（數據發送到接收方後，不會進行確認）。
Flume的可恢復性
還是靠Channel。推薦使用FileChannel，事件持久化在本地文件系統裏(性能較差)。
Flume的一些核心概念
Agent
使用JVM 運行Flume。每臺機器運行一個agent，但是可以在一個agent中包含多sources和sinks。
1. Client 生產數據，運行在一個獨立的線程。
2. Source 從Client收集數據，傳遞給Channel。
3. Sink 從Channel收集數據，運行在一個獨立線程。
4. Channel 連接sources 和sinks ，這個有點像一個隊列。
5. Events 可以是日誌記錄、 avro 對象等。
Flume以agent爲最小的獨立運行單位。一個agent就是一個JVM。單agent由Source、Sink和Channel三大組件構成，如下圖：
值得注意的是，Flume提供了大量內置的Source、Channel和Sink類型。不同類型的Source，Channel和Sink可以自由組合。組合方式基於用戶設置的配置文件，非常靈活。比如：Channel可以把事件暫存在內存裏，也可以持久化到本地硬盤上。Sink可以把日誌寫入HDFS、HBase，甚至是另外一個Source等等。Flume支持用戶建立多級流，也就是說，多個agent可以協同工作，並且支持Fan-in、Fan-out、ContextualRouting、Backup
Routes，這也正是其強大之處。如下圖所示:
二、Flume+Kafka+Spark Streaming應用場景
1、Flume集羣採集外部系統的業務信息，將採集後的信息發生到Kafka集羣，最終提供Spark Streaming流框架計算處理，流處理完成後再將最終結果發送給Kafka存儲，架構如下圖：
2、Flume集羣採集外部系統的業務信息，將採集後的信息發生到Kafka集羣，最終提供Spark Streaming流框架計算處理，流處理完成後再將最終結果發送給Kafka存儲，同時將最終結果通過Ganglia監控工具進行圖形化展示，架構如下圖：
3、我們如果對Spark改進的話，可以做的事情有：SparkStreaming 交互式的360度的可視化，Spark Streaming 交互式3D可視化UI；Flume集羣採集外部系統的業務信息，將採集後的信息發生到Kafka集羣，最終提供Spark Streaming流框架計算處理，流處理完成後再將最終結果發送給Kafka存儲，將最終結果同時存儲在數據庫（Mysql）、內存中間件（Redis、MemSQL）中，同時將最終結果通過Ganglia監控工具進行圖形化展示。架構如下圖：
三、Kafka數據寫入SparkStreaming有兩種方式：
1、一種是Receivers，這個方法使用了Receivers來接收數據，Receivers的實現使用到Kafka高層次的消費者API，對於所有的Receivers，接收到的數據將會保存在Spark 分佈式的Executors中，然後由Spark Streaming啓動的Job來處理這些數據；然而，在默認的配置下，這種方法在失敗的情況下會丟失數據，爲了保證零數據丟失，你可以在SparkStreaming中使用WAL日誌功能，這使得我們可以將接收到的數據保存到WAL中（WAL日誌可以存儲在HDFS上），所以在失敗的時候，我們可以從WAL中恢復，而不至於丟失數據。
2、另一種是DirectAPI，產生數據和處理數據的時候是在兩臺機器上？其實是在同一臺數據上，由於在一臺機器上有Driver和Executor，所以這臺機器要足夠強悍。
Flume集羣將採集的數據放到Kafka集羣中，Spark Streaming會實時在線的從Kafka集羣中通過DirectAPI拿數據，可以通過Kafka中的topic+partition查詢最新的偏移量（offset）來讀取每個batch的數據，即使讀取失敗也可再根據偏移量來讀取失敗的數據，保證應用運行的穩定性和數據可靠性。
溫馨提示：
1、Flume集羣數據寫入Kafka集羣時可能會導致數據存放不均衡，即有些Kafka節點數據量很大、有些不大，後續會對分發數據進行自定義算法來解決數據存放不均衡問題。
2、強烈推薦在生產環境下用DirectAPI，但是我們可以進行改進，對DirectAPI進行優化，降低其延遲。
總結：
實際生產環境下，蒐集分佈式的日誌以Kafka爲核心。
課程筆記來源:
DT大數據夢工廠IMF傳奇行動課程學員整理。YY直播永久課堂頻道68917580每晚8點準時開課。
Lifeis short, you need spark!
