共計 1716 個字符，預計需要花費 5 分鐘才能閱讀完成。

如何進行 Flume 的分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

一、什么是 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。

Client        生產數據，運行在一個獨立的線程。

Source        從 Client 收集數據，傳遞給 Channel。

Sink        從 Channel 收集數據，運行在一個獨立線程。

Channel        連接 sources 和 sinks，這個有點像一個隊列。

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、Contextual Routing、Backup Routes，這也正是 NB 之處。

看完上述內容，你們掌握如何進行 Flume 的分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！