Hadoop生态圈之Flume（一）

1. 概述

       Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的软件。

       Flume的核心是把数据从数据源(source)收集过来，再将收集到的数据送到指定的目的地(sink)。为了保证输送的过程一定成功，在送到目的地(sink)之前，会先缓存数据(channel),待数据真正到达目的地(sink)后，flume在删除自己缓存的数据。

2. 运行机制

• flume 本身是一个 Java 进程，在需要采集数据机器上启动 ---->  agent 进程
• agent 进程里面包含了：source（采集源）、sink（下沉地）、channel（数据传输通道）
• 在整个数据的传输的过程中，流动的是event，它是Flume内部数据传输的最基本单元。event将传输的数据进行封装。如果是文本文件，通常是一行记录，event也是事务的基本单位。event从source，流向channel，再到sink，本身为一个字节数组，并可携带headers(头信息)信息。event代表着一个数据的最小完整单元，从外部数据源来，向外部的目的地去。
• 一个完整的event包括：event headers、event body、event信息，其中event信息就是flume收集到的日记记录。

3. 核心组件

• source：用于对接各个不同的数据源
• sink：用于对接各个不同存储数据的目的地（数据下沉地）
• channel：用于中间临时存储缓存数据

4. 运行架构

4.1 简单架构

只需要部署一个 agent 进程即可（单个 agent 采集数据）

4.2 复杂架构

       多个 agent 之间串联，相当于大家手拉手共同完成数据的采集传输工作，在串联的架构中没有主从之分，大家的地位都是一样的。

5. Flume 的安装部署

1. 上传安装包到数据源所在节点上，然后解压  tar -zxvf apache-flume-1.8.0-bin.tar.gz，然后进入flume的目录，修改conf下的flume-env.sh，在里面配置JAVA_HOME
2. 根据数据采集需求配置采集方案，描述在配置文件中(文件名可任意自定义)
3. 指定采集方案配置文件，在相应的节点上启动flume agent

5.1 测试程序环境

（1）现在 flume 的 conf 目录下新建一个文件

vim  netcat-logger.conf

# 定义这个agent中各组件的名字
a1.sources = r1
a1.sinks = k1
a1.channels = c1

# 描述和配置source组件：r1
a1.sources.r1.type = netcat
a1.sources.r1.bind = 192.168.106.100
a1.sources.r1.port = 44444

# 描述和配置sink组件：k1
a1.sinks.k1.type = logger

# 描述和配置channel组件，此处使用是内存缓存的方式
a1.channels.c1.type = memory
a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100

# 描述和配置source  channel   sink之间的连接关系
a1.sources.r1.channels = c1
a1.sinks.k1.channel = c1

（2）启动 agent 去采集数据

bin/flume-ng agent -c conf -f conf/netcat-logger.conf -n a1  -Dflume.root.logger=INFO,console

（3）测试

先要往 agent 采集监听的端口上发送数据，让 agent 有数据可采：随便在一个能跟 agent 节点联网的机器上输入如下命令：

telnet 192.168.106.100 44444

6. flume 的开发步骤

1. 重点就是根据业务需求编写采集方案配置文件
2. 文件名见名知意，通常以 source——sink.conf
3. 具体需要描述清楚sink source channel 组件配置信息，结合观望配置
4. 启动命令：

bin/flume-ng agent --conf conf --conf-file conf/netcat-logger.conf --name a1 -Dflume.root.logger=INFO,console  命令完整版

bin/flume-ng agent -c ./conf -f ./conf/spool-hdfs.conf -n a1 -Dflume.root.logger=INFO,console  命令精简版

--conf指定配置文件的目录
--conf-file指定采集方案路径
--name  agent进程名字 要跟采集方案中保持一致

7. 简单架构案例

7.1 采集目录到 HDFS

采集需求：服务器的某特定目录下，会不断产生新的文件，每当有新文件出现，就需要把文件采集到HDFS中去

根据需求，首先定义以下3大要素：

1. 采集源，即source——监控文件目录 :  spooldir
2. 下沉目标，即sink——HDFS文件系统  :  hdfs sink
3. source和sink之间的传递通道——channel，可用file channel 也可以用内存channel

（1）编写配置文件

# Name the components on this agent
a1.sources = r1
a1.sinks = k1
a1.channels = c1

# Describe/configure the source
##注意：不能往监控目中重复丢同名文件
a1.sources.r1.type = spooldir
a1.sources.r1.spoolDir = /root/logs
a1.sources.r1.fileHeader = true

# Describe the sink
a1.sinks.k1.type = hdfs
a1.sinks.k1.hdfs.path = /flume/events/%y-%m-%d/%H%M/
a1.sinks.k1.hdfs.filePrefix = events-

#是否开启时间上的舍弃  控制文件夹以多少时间间隔滚动
#以下述为例：就会每10分钟生成一个文件夹
a1.sinks.k1.hdfs.round = true
a1.sinks.k1.hdfs.roundValue = 10
a1.sinks.k1.hdfs.roundUnit = minute

#roll控制写入hdfs文件 以何种方式进行滚动
#如果三个都配置  谁先满足谁触发滚动
#如果不想以某种属性滚动  设置为0即可
#以时间间隔
a1.sinks.k1.hdfs.rollInterval = 3
#以文件大小
a1.sinks.k1.hdfs.rollSize = 20
#以event个数
a1.sinks.k1.hdfs.rollCount = 5
a1.sinks.k1.hdfs.batchSize = 1
a1.sinks.k1.hdfs.useLocalTimeStamp = true

#生成的文件类型，默认是Sequencefile，可用DataStream，则为普通文本
a1.sinks.k1.hdfs.fileType = DataStream

# Use a channel which buffers events in memory
a1.channels.c1.type = memory
#默认该通道中最大的可以存储的event数量
a1.channels.c1.capacity = 1000
#每次最大可以从source中拿到或者送到sink中的event数量
a1.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a1.sources.r1.channels = c1
a1.sinks.k1.channel = c1

（2）启动命令：  
bin/flume-ng agent -c ./conf -f ./conf/spool-hdfs.conf -n a1 -Dflume.root.logger=INFO,console

（3）注意

• 注意其监控的文件夹下面不能有同名文件的产生
• 如果有，报错且罢工，后续就不再进行数据的监视采集了
• 在企业中通常给文件追加时间戳命名的方式保证文件不回重名

7.2 采集文件到 HDFS

采集需求：比如业务系统使用log4j生成的日志，日志内容不断增加，需要把追加到日志文件中的数据实时采集到hdfs

根据需求，首先定义以下3大要素：

1. 采集源，即source——监控文件内容更新 :  exec  ‘tail -F file’
2. 下沉目标，即sink——HDFS文件系统  :  hdfs sink
3. Source和sink之间的传递通道——channel，可用file channel 也可以用 内存channel

（1）配置文件编写

# Name the components on this agent
a1.sources = r1
a1.sinks = k1
a1.channels = c1

# Describe/configure the source
a1.sources.r1.type = exec
a1.sources.r1.command = tail -F /root/logs/test.log
a1.sources.r1.channels = c1

# Describe the sink
a1.sinks.k1.type = hdfs
a1.sinks.k1.hdfs.path = /flume/tailout/%y-%m-%d/%H%M/
a1.sinks.k1.hdfs.filePrefix = events-
a1.sinks.k1.hdfs.round = true
a1.sinks.k1.hdfs.roundValue = 10
a1.sinks.k1.hdfs.roundUnit = minute
a1.sinks.k1.hdfs.rollInterval = 3
a1.sinks.k1.hdfs.rollSize = 20
a1.sinks.k1.hdfs.rollCount = 5
a1.sinks.k1.hdfs.batchSize = 1
a1.sinks.k1.hdfs.useLocalTimeStamp = true
#生成的文件类型，默认是Sequencefile，可用DataStream，则为普通文本
a1.sinks.k1.hdfs.fileType = DataStream

# Use a channel which buffers events in memory
a1.channels.c1.type = memory
a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a1.sources.r1.channels = c1
a1.sinks.k1.channel = c1

（2）启动命令：  
bin/flume-ng agent -c ./conf -f ./conf/exec-hdfs.conf -n a1 -Dflume.root.logger=INFO,console

（3）使用脚本模拟数据实时变化的过程

while true; do date >> /root/logs/test.log;done

【注】exec source 可以执行指定的linux command 把命令的结果作为数据进行收集

8. Flume 的 load-balance、failover

8.1 Load balancing Sink Processor

       负载均衡是用于解决一台机器(一个进程)无法解决所有请求而产生的一种算法。Load balancing Sink Processor能够实现load balance功能，如下图Agent1是一个路由节点，负责将Channel暂存的Event均衡到对应的多个Sink组件上，而每个Sink组件分别连接到一个独立的Agent上，示例配置，如下所示：

• flume的负载均衡
  • 所谓的负载均衡 用于解决一个进程或者程序处理不了所有请求 多个进程一起处理的场景
  • 同一个请求只能交给一个进行处理 避免数据重复
  • 如何分配请求就涉及到了负载均衡的算法：轮询（round_robin） 随机（random） 权重
• flume串联跨网络传输数据
  • avro sink
  • avro source

        使用上述两个组件指定绑定的端口ip 就可以满足数据跨网络的传递 通常用于flume串联架构中

• flume串联启动

        通常从远离数据源的那一级开始启动

配置文件：

a1.sinkgroups = g1
a1.sinkgroups.g1.sinks = k1 k2 k3
a1.sinkgroups.g1.processor.type = load_balance

a1.sinkgroups.g1.processor.backoff = true  #如果开启，则将失败的sink放入黑名单

a1.sinkgroups.g1.processor.selector = round_robin  # 另外还支持random

#在黑名单放置的超时时间，超时结束时，若仍然无法接收，则超时时间呈指数增长
a1.sinkgroups.g1.processor.selector.maxTimeOut=10000 

8.2 Failover Sink Processor

       Failover Sink Processor能够实现failover功能，具体流程类似load balance，但是内部处理机制与load balance完全不同。

       Failover Sink Processor维护一个优先级Sink组件列表，只要有一个Sink组件可用，Event就被传递到下一个组件。故障转移机制的作用是将失败的Sink降级到一个池，在这些池中它们被分配一个冷却时间，随着故障的连续，在重试之前冷却时间增加。一旦Sink成功发送一个事件，它将恢复到活动池。 Sink具有与之相关的优先级，数量越大，优先级越高。

       例如，具有优先级为100的sink在优先级为80的Sink之前被激活。如果在发送事件时汇聚失败，则接下来将尝试下一个具有最高优先级的Sink发送事件。如果没有指定优先级，则根据在配置中指定Sink的顺序来确定优先级。

• 容错又称之为故障转移 容忍错误的发生。

• 通常用于解决单点故障 给容易出故障的地方设置备份

• 备份越多 容错能力越强 但是资源的浪费越严重

配置文件：

a1.sinkgroups = g1
a1.sinkgroups.g1.sinks = k1 k2 k3
a1.sinkgroups.g1.processor.type = failover
a1.sinkgroups.g1.processor.priority.k1 = 5  #优先级值, 绝对值越大表示优先级越高
a1.sinkgroups.g1.processor.priority.k2 = 7
a1.sinkgroups.g1.processor.priority.k3 = 6
a1.sinkgroups.g1.processor.maxpenalty = 20000  #失败的Sink的最大回退期（millis）