Flume 作爲 cloudera 開發的實時日誌收集系統，已經受到越來越多的關注。比如 IBM BigInsights 已經將 Flume 作爲產品的一部分。Flume 初始的發行版本目前被統稱爲 Flume OG（original generation），屬於 cloudera。但隨着 FLume 功能的擴展，Flume OG 代碼工程臃腫、核心組件設計不合理、核心配置不標準等缺點暴露出來，尤其是在 Flume OG 的最後一個發行版本 0.94.0 中，日誌傳輸不穩定的現象尤爲嚴重，這點可以在 BigInsights 產品文檔的 troubleshooting 板塊發現。爲了解決這些問題，2011 年 10 月 22 號，cloudera 完成了 Flume-728，對 Flume 進行了里程碑式的改動：重構核心組件、核心配置以及代碼架構，重構後的版本統稱爲 Flume NG（next generation）；改動的另一原因是將 Flume 納入 apache 旗下，cloudera Flume 改名爲 Apache Flume。本文將從基本組件以及用戶體驗的角度闡述 Flume OG 到 Flume NG 發生的革命性變化。
背景
Cloudera 開發的分佈式日誌收集系統 Flume，是 hadoop 周邊組件之一。其可以實時的將分佈在不同節點、機器上的日誌收集到 hdfs 中。Flume 初始的發行版本目前被統稱爲 Flume OG（original generation），屬於 cloudera。但隨着 FLume 功能的擴展，Flume OG 代碼工程臃腫、核心組件設計不合理、核心配置不標準等缺點暴露出來，尤其是在 Flume OG 的最後一個發行版本 0.94.0 中，日誌傳輸不穩定的現象尤爲嚴重，這點可以在 BigInsights 產品文檔的 troubleshooting 板塊發現。爲了解決這些問題，2011 年 10 月 22 號，cloudera 完成了 Flume-728，對 Flume 進行了里程碑式的改動：重構核心組件、核心配置以及代碼架構，重構後的版本統稱爲 Flume NG（next generation）；改動的另一原因是將 Flume 納入 apache 旗下，cloudera Flume 改名爲 Apache Flume。
下面將從核心組件變化、角色變化、用戶配置變化以及實戰等方面闡述 Flume NG 相對於 Flume OG 所發生的革命性變化。
核心組件變化
圖 1 和圖 3 是兩個版本的架構圖。
FLUM OG 的特點是：
- FLUM OG 有三種角色的節點，如圖 1：代理節點（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。如圖 2。
圖 1. FLUM OG 架構圖
圖 2. OG 節點組成圖
對應於 OG 的特點，FLUM NG 的特點是：
- NG 只有一種角色的節點：代理節點（agent）。
- 沒有 collector、master 節點。這是核心組件最核心的變化。
- 去除了 physical nodes、logical nodes 的概念和相關內容。
- agent 節點的組成也發生了變化。如圖 4，NG agent 由 source、sink、channel 組成。
圖 3. FLUM NG 架構圖
圖 4. NG 節點組成圖
從整體上講，NG 在覈心組件上進行了大規模的調整，核心組件的數目由 7 刪減到 4。由於 Flume 的使用涉及到衆多因素，如 avro、thrift、hdfs、jdbc、zookeeper 等，而這些組件和 Flume 的整合都需要關聯到所有組件。所以核心組件的改革對整個 Flume 的使用影響深遠：
- 大大降低了對用戶的要求，如核心組件的變化使得 Flume 的穩定使用不再依賴 zookeeper，用戶無需去搭建 zookeeper 集羣；另外用戶也不再糾結於 OG 中的模糊概念（尤其是 physical nodes、logical nodes，agent、collector）。
- 有利於 Flume 和其他技術、hadoop 周邊組件的整合，比如在 NG 版本中，Flume 輕鬆實現了和 jdbc、hbase 的集成。
- 將 OG 版本中複雜、大規模、不穩定的標籤移除，Flume 實現了向靈活、輕便的轉變，而且在功能上更加強大、可擴展性更高，這一點主要表現在用戶使用 Flume 搭建日誌收集集羣的過程中，後面的章節會詳細介紹。
刪減節點角色，脫離 zookeeper
Zookeeper 是針對大型分佈式系統的可靠協調系統，適用於有多類角色集羣管理。比如在 hbase 中，對 HMaster、HRegionServer 的管理。
在 OG 版本中，Flume 的使用穩定性依賴 zookeeper。它需要 zookeeper 對其多類節點（agent、collector、master）的工作進行管理，尤其是在集羣中配置多個 master 的情況下。當然，OG 也可以用內存的方式管理各類節點的配置信息，但是需要用戶能夠忍受在機器出現故障時配置信息出現丟失。所以說 OG 的穩定行使用是依賴 zookeeper 的。
而在 NG 版本中，節點角色的數量由 3 縮減到 1，不存在多類角色的問題，所以就不再需要 zookeeper 對各類節點協調的作用了，由此脫離了對 zookeeper 的依賴。由於 OG 的穩定使用對 zookeeper 的依賴表現在整個配置和使用過程中，這就要求用戶掌握對 zookeeper 集羣的搭建極其使用（尤其是要熟悉 zookeeper 數據文件夾 data，Flume 節點配置信息存放在此文件夾中）；掌握 Flume 中和 zookeeper 相關的配置。對初次接觸 Flume 的用戶來講，這是非常痛苦的事。
用戶配置變化
從用戶角度來講，配置過程無疑是整個集羣搭建的核心步驟。Flume 的配置分爲兩個部分：安裝和數據傳輸配置。
安裝
OG 在安裝時：
- 在 flume-env.sh 中設置$JAVA_HOME。
- 需要配置文件 flume-conf.xml。其中最主要的、必須的配置與 master 有關。集羣中的每個 Flume 都需要配置 master 相關屬性（如 flume.master.servers、flume.master.store、flume.master.serverid）。
- 如果想穩定使用 Flume 集羣，還需要安裝 zookeeper 集羣，這需要用戶對 zookeeper 有較深入的瞭解。
- 安裝 zookeeper 之後，需要配置 flume-conf.xml 中的相關屬性，如 flume.master.zk.use.external、flume.master.zk.servers。
- 在使用 OG 版本傳輸數據之前，需要啓動 master、agent。
NG 在安裝時，只需要在 flume-env.sh 中設置$JAVA_HOME。
數據傳輸配置
OG 版本的配置途徑有兩個：
- shell 命令：需要用戶掌握 Flume shell 命令；
- master console 頁面：這是 OG 用戶最常用的配置方式；弊端在於，除非用戶熟悉複雜的各類 source，sink 配置函數以及格式（source：大約 25 個，sink：大約 46 個），否則在複雜的集羣環境下，用戶每次只能配置一個節點（指定 source、sink）來保證配置的準確性；
NG 的配置只需要一個配置文件，這個配置文件中存放 source、sink、channel 的配置。如圖 5 中是配置文件 example.conf 裏面的內容，其中 agent_foo 是 agent 名字。然後在啓動 agent 時，使用一下命令指定這個配置文件：
$ bin/flume-ng agent
--conf-file example.conf \
--name agent_foo \
-Dflume.root.logger=INFO,console圖 5. example.conf
實戰 Flume NG
Flume 最常用的使用場景是，從節點收集日誌數據，並以一定的格式存放到分佈式文件系統 hdfs（hadoop 文件系統）中。下面介紹如何使用 Flume NG 從一個節點收集實時日誌，並存放到 hdfs 中。
場景說明：
- 場景中有兩臺主機 host1、host2。
- 數據源是 host2 上的系統日誌文件“/var/log/secure”（登錄到系統存取資料的記錄，本機的測試系統有多人使用，所以記錄在不斷的生成）。數據目的地是 hadoop 文件系統 hdfs。
- 在 host1、host2 上搭建 hadoop 集羣。其中 host1 爲 namenode、jobtracker，host2 爲 datanode、tasktracker。
使用 ng 搭建日誌傳輸場景：flume+hadoop
場景搭建步驟：
- 下載 flume-ng 安裝包，並解壓到 host2。
Flume 發佈了兩類包：source 和 bin。Source 包用於開發工作，bin 包用於安裝 Flume 搭建日誌收集場景。本次實驗用的是 apache-flume-1.5.2-bin.tar.gz
- 生成配置文件 example.conf。內容如圖 6。整個配置分爲四部分。表 1 是配置說明。
圖 6. example.conf
表 1. flume-conf.xml
| Properties Name | Description |
|---|---|
| agent_ff | 用來收集日誌信息的 agent 節點名稱 |
| agent_ff.source | 需要收集的信息源，名字：tailsource-ff |
| agent_ff.sinks | 日誌需要被收集到此處，名字：hdfsSink-ff。 |
| agent_ff.channels | 日誌的收集需要通過此管道，名字：memoryChannel-ff。 |
| tailsource-ff.type | 定義 source 的類型，此處 exec 代表數據源是 exec 命令 |
| tailsource-ff.command | 定義具體命令，此處是對文件/var/log/secure 做 tail |
| tailsource-ff.channels | 數據傳輸的管道，此處的管道名稱應該和 sink 相同。從而將 source、sink 通過 channels 進行連接。 |
| memoryChannel-ff.type | 管道類型，代表事件存儲的方式。Source 產生事件，sink 移除事件，以此代表數據傳輸完成。目前 Flume 支持 6 種 channel。此處是 momery，代表事件是存在內存裏 |
| memoryChannel-ff.capacity | 管道里可以存放的最多的事件數目。此處代表 memoryChannel-ff 最多可存放 1000 個事件。 |
| hdfsSink-ff.type | 數據目的地的類型，此處是將數據存放在 hdfs 中。 |
| hdfsSink-ff.channel | 定義和 source 相關聯的管道。 |
| hdfsSink-ff.hdfs.path | 數據存放在 hdfs 中的位置。 |
| hdfsSink-ff.hdfs.filePrefix | 收集到的數據存放的文件以此爲前綴。如圖 8。 |
| hdfsSink-ff.hdfs.round, hdfsSink-ff.hdfs.roundValue, hdfsSink-ff.hdfs.roundUnit | 定義在 hdfs 中生成的文件的時間戳。此處代表將 hdfs 中的文件的時間戳，向下取整到上一個十分鐘內。比如說，在 2012 年 6 月 12 號上午 11:54:34 生成的事件，在 hdfs 中生成的路徑將是/flume/events/2012-06-12/1150/00。 |
- 進入 bin 目錄，使用一下命令啓動 Flume，開始日誌收集，控制檯輸出如圖 7，傳輸到 hdfs 的文件如圖 8。
./flume-ng agent \
--conf-file ../example.conf \
--name agent_ff \
-Dflume.root.logger=INFO,cnsole圖 7. NG console
圖 8. hdfs
Flume OG vs Flume NG：用戶體驗對比
整體上看，NG 的用戶體驗要比 OG 好得多，這一點從用戶文檔上就可見一斑。OG 版本的使用文檔有 90 多頁，而 OG 只用 20 多頁的內容就完成了新版 Flume 的使用說明。對應於上一節“實戰 Flume NG”，我們使用和 NG 中同樣的場景說明，下面介紹如何使用 OG 搭建同樣的日誌收集場景。用戶可以從場景的搭建上明顯的看出差別：NG 的整個過程只涉及到 hadoop、agent，而 OG 則需要涉及到 hadoop、zookeeper、master、agent、flume-conf.xml。
使用 og 搭建日誌傳輸場景：flume+zookeeper+hadoop
場景搭建步驟：
- 下載 zookeeper 安裝包，並在 host2 上安裝 zookeeper-3.4.3。請參考：zookeeperStarted。
- 下載 flume-0.94.0（OG），並解壓在 host2 上。
- 配置文件 conf/flume-conf.xml，必須配置的信息如表 2。
- 進入 bin 目錄，使用一下命令啓動 flume master、agent。
master: ./flume-daemon.sh start master
agent: ./flume node -n agent-ff- 進入 master 頁面：http://host2:35871/flumemaster.jsp。配置 source、sink。如圖 9。“Submit Query”後 Flume 便開始收集數據。
- agent-ff 控制檯輸出如圖 10。
表 2. flume-conf.xml
| 屬性（Property） | 賦值（Value） |
|---|---|
| flume.master.servers | host2 |
| flume.master.store | zookeeper |
| flume.master.serverid | 0 |
| flume.master.zk.use.external | true |
| flume.master.zk.servers | host2:2181 |
圖 9. OG 配置
圖 10. OG console
結束語
本文通過對比，從核心組件和用戶的角度，闡述了 Flume NG 給 Flume 帶來的第一次革命。從核心組件來講，NG 簡化核心組件，移除了 OG 版本代碼工程臃腫、核心組件設計不合理、核心配置不標準等缺點；另外 NG 脫離了 Flume 穩定性對 zookeeper 的依賴。從用戶角度來講，NG 版本對用戶要求大大降低：安裝過程除了 java 無需配置複雜的 Flume 相關屬性，也無需搭建 zookeeper 集羣，安裝過程幾乎零工作量；數據流的配置過程更加簡單、合理，只需要實現 source、sink、channel 的簡單配置即可。
參考資料
學習
- 訪問 BigInsights Information Center，瞭解關於 BigInsights 的詳細信息。
- 查看 Flume 官方網站，瞭解 Flume 基本知識和最新信息。
- 通過Hadoop 官方網站，瞭解 Hadoop 基本知識和最新信息。
- 通過 Zookeeper 官網，瞭解 Zookeeper 基本知識和最新信息。
- 在 實踐：使用 Apache Hadoop 處理日誌
- 在 developerWorks Information Management 專區，瞭解關於信息管理的更多信息，獲取技術文檔、how-to 文章、培訓、下載、產品信息以及其他資源。
轉自：http://www.ibm.com/developerworks/cn/data/library/bd-1404flumerevolution/index.html