Flume整理

---

1. Flume 概述

​

Flume 是 Cloudera 基于流式架构的高可用，高可靠，分布式的海量日志采集、聚合和传输的系统。

2. Flume 基础架构

1. Agent

   Agent 是一个 JVM 进程，它以事件的形式将数据从源头送至目的。

   Agent 主要有 3 个部分组成，Source、Channel、Sink。

2. Source

   Source 是负责接收数据到 Flume Agent 的组件。Source 可以处理各种类型、格式的日志数据，包括 avro、thrift、exec、jms、spooling directory、netcat、taildir、sequence generator、syslog、http等。

3. Event

   传输单元，Flume 数据传输的基本单元，以 Event 的形式将数据从源头送至目的地。Event 由 Header 和 Body 两部分组成，Header 用来存放该 event 的一些属性，为 K-V 结构，Body 用来存放该条数据，形式为字节数组。

4. Channel Processor

   Event 通过 Channel Processor 处理进入 Channel，在此之前，Channel Processor 会讲 Event 先转发给 Intercepter 过滤器链，再通过 Channel Selector 转发给符合规则的 Channel。

5. Intercepter

   拦截器，通常在这里的拦截器，会对数据进行 ETL 处理，将残缺或者不合格数据拦截掉。

6. Channel Selector

   ChannelSelector 的作用就是选出 Event 发往指向的Channel。其共有两种类型，分别是 复制(Replicating) 和 多路复用(Multiplexing)。

   • 复制： 会将同一个 Event 发往所有的 Channel
   • 多路复用： 会根据相应的原则，将不同的 Event 发往不同的 Channel。

7. Channel

   Channel 是位于 Source 和 Sink 之间的缓冲区。Channel 允许 Source 和 Sink 运作在不同速率上。Channel 是线程安全(put事务和take数据，详见[Flume事务](#6. Flume 事务))的，可以同时处理几个 Source 的写入操作和几个Sink 的读取操作。Flume 自带两种 Channel：Memory Channel 和 File Channel。

   • Memory Channel：内存中的队列，速度快性能高，但是不安全。

   • File Channel：安全性高，但是速度慢性能低。

   • Kafka Channel：
     生产环境最常用的是官方提供的 Kafka Channel插件：吞吐量大，并且Kafka与其他框架连接紧密，数据源众多。

8. SinkProcessor

   SinkProcessor是Sink拉去Channel数据的策略， 共有三种类型 ， 分别是默认(DefaultSinkProcessor) 、负载均衡(LoadBalancingSinkProcessor) 和 故障转移(FailoverSinkProcessor)。

   默认策略 对应的是单个的 Sink ， 负载均衡和故障转移对应的是 Sink Group。

9. Sink

   Sink 不断地轮询 Channel 中的事件且批量地移除它们，并将这些事件批量写入到存储或索引系统 或被发送到另一个 Flume Agent。Sink 组件目的地有 hdfs、logger、file、HBase、solr等，且支持自定义。

3. Flume 拓扑结构

3.1. 简单串联

这种模式是将多个 flume 顺序连接起来了，从最初的 source 开始到最终 sink 传送的目的存储系统。此模式不建议桥接过多的 flume 数量， flume 数量过多不仅会影响传输速率，而且一旦传输过程中某个节点 flume 宕机，会影响整个传输系统。

3.2. 复制和多路复用

Flume 支持将事件流向一个或者多个目的地。单Source，多Channel模式通过channelSelector将相同数据复制到多个channel 中，或者将不同数据分发到不同的 channel 中，不同 sink 可以选择传送到不同的目的地。

3.3. 负载均衡和故障转移

Flume使用将多个sink逻辑上分到一个sink组，sink组配合不同的SinkProcessor可以实现负载均衡和错误恢复的功能。

3.4. 聚合

这种模式是我们最常见的，也非常实用，日常 web 应用通常分布在上百个服务器，大者甚至上千个、上万个服务器。产生的日志，处理起来也非常麻烦。用 flume 的这种聚合方式能很好的解决这一问题，每台服务器部署一个 flume 采集日志，传送到一个集中收集日志的flume(可以做统一处理，比如HDFS小文件问题)，再由此 flume 上传到 hdfs、hive、hbase 等，进行日志分析。

4. Flume 项目应用

4.1. 采集Flume

主要任务就是采集日志服务器上的日志文件logFIle，传入 Kafka 主题 topic_log， 尽量保证logFile读入Flume的过程可靠。

1. Source

   • Exec Source：可以实时搜集数据，但是在Flume不运行或者Shell命令出错的情况下，数据会丢失，不具备断点续传。

   • Spooling Directory Source：监控目录，支持断点续传。

   • TailDir Source：支持断点续传 以及 多目录。Flume1.6以后框架自己实现断点续传。

     Flume使用模糊匹配文件名称，这时候如果使用log文件名可能发生改变的log4j，一旦改变之前正在被读取数据的文件，那么又要从头开始读取，会造成数据重复。推荐使用logback，不改变文件名称。

   Source 中使用简单的 ETLInterceper，将残缺的数据拦截处理。

2. Channel

   KafkaChannel数据存储在Kafka里面，Kafka存储的数据有持久化有副本，数据安全得以保证。

   Flume1.7之前 ，parseAsFlumeEvent 参数关闭无效，导致进入 Kafka Channel 的数据类型为 Flume Event，会携带一些不需要的header元信息。

3. Sink

   由于使用了 Kafka Channel，省去了 Sink，提高了效率。

4.2. 聚合 Flume

主要任务是集合所有的采集Flume数据，对日志数据做统一处理，采集Flume到聚合Flume中，还可以处理小文件问题。

1. Source

   因为数据源是Kafka，自然使用 Kafka Source，消费 topic_log数据。

   使用 Time拦截器，将key从默认 linux 时间改为实际时间ts，方便后续HDFS Sink 使用。

2. Channel

   • MemoryChannel

     传输数据速度更快，但因为数据保存在JVM的堆内存中，Agent进程挂掉会导致数据丢失，适用于对数据质量要求不高的需求。

   • FileChannel

     输速度相对于Memory慢，但数据安全保障高，Agent进程挂掉也可以从失败中恢复数据。

   • KafkaChannel

     吞吐量大，效率高，数据量大的时候，可以使用 Kafka Channel。

3. Sink

   HDFS Sink，在经过优化之后，较之之前只能依当前时间进行HDFS分区存储，提供了指定时间(header的key)作为分区条件。前面使用的 TimeIntercepter，指定了 时间时间ts 作为分区条件，大大减少 零点漂移 问题的发生。

   官方默认的这三个参数配置写入HDFS后会产生小文件，效果如下：

   1. hdfs.rollSize=134217728；文件在达到128M时会滚动生成新文件。
   2. hdfs.rollInterval=3600；文件创建超3600秒时会滚动生成新文件。
   3. hdfs.rollCount =0；不使用数据条数阈值。

   用户行为日志数据，还会使用LZOP压缩为可分片的压缩包。

6. Flume 事务

6.1. Put 事务(推送事件：Source -> Channel)

Source从文件中读取出来数据后，进入Put事务，写入临时缓冲区 putList，putList 达到一定阈值时将数据全部 doCommit 提交到 Channel中。如果全部提交成功，清除putList，并告知Source将这部分数据文件数据标记完成。如果提交失败，putList doRollback回滚数据，尝试下次 doCommit，知道成功。

6.2. Take 事务(拉取事件：Channel -> Sink)

数据先从Channel出来，进入事务，写入临时缓冲区 takeList，takeList数据达到阈值后，将数据全部 doCommit 到 Sink。如果全部提交成功，清除takeList。如果出现异常提交失败，doRollback回滚数据，并将 takeList 的数据退回给Channel。

7. Flume 监控

使用第三方框架 Ganglia(肛裂) 实时监控 Flume。

8. Flume 采集数据会丢失吗？

根据 Flume 的架构原理，Flume 是不可能丢失数据的，其内部有完善的事务机制，Source 到 Channel 是事务性的，Channel 到 Sink 是事务性的，因此这两个环节不会出现数据的丢失，唯一可能丢失数据的情况是：Put事务提交，Task事务没有完成， Channel 采用 memoryChannel，agent 宕机导致数据丢失，或者 Channel 存储数据已满，导致 Source 不再写入，未写入的数据丢失。

Flume 不会丢失数据，但是有可能造成数据重复，拓扑结构中，上一个Sink成功发出，但是没有接收到响应，Sink 会再次发送数据，此时可能会导致数据的重复。