Flume NG：Flume 发展史上的第一次革命

Acfe

转：http://www.ibm.com/developerworks/cn/data/library/bd-1404flumerevolution/index.html
背景
　　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.2.0-bin.tar.gz
  
  
• 生成配置文件 example.conf。内容如图 6。整个配置分为四部分。表 1 是配置说明。
  
• 进入 bin 目录，使用一下命令启动 Flume，开始日志收集，控制台输出如图 7，传输到 hdfs 的文件如图 8。
  

./flume-ng agent \
--conf-file ../example.conf \
--name agent_ff \
-Dflume.root.logger=INFO,cnsole


图 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。

图 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 的简单配置即可。