Flume

• Flume代理
  • 一个source-channel-sink组合 配置
  • 启动Flume代理
• 事务和可靠性
  • 批量处理
• HDFS sink
  • 分区和拦截器
• 扇出
  • 交付保证
  • 复用选择器
• 通过代理层分发
  • 交付保证
• Sink组
• 组件编目

Flume代理

Flume代理是由持续运行的source（数据来源），channel（用于连接source和sink），sink（数据目标）构成的java进程
Flume的source产生事件，并将其传送给channel，channel存储这些事件直至转发给sink
可以把source-channel-sink视为基本Flume构件

一个source-channel-sink组合 配置属性文件

agent1.sources=source1
agent1.channels=channel1
agent1.sinks=sink1

agent1.sources.source1.type=spooldir  # 监视目录中的新增文件
agent1.sources.source1.spoolDir=/tmp/spooldir

agent1.channels.channel1.type=file  # channel中事件持久化存储在磁盘上

agent1.sinks.sink1.type=logger  # 用于将事件记录到控制台

agent1.sources.source1.channels=channel1
agent.sinks.sink1.channel=channel1

属性名称是一个分级结构，顶级为代理名称，例：agent1
下一级是代理中的不同组件名称，例：source1，channel1，sink1
再下一级是组件属性，例：type

启动Flume代理

flume-ng agent \
--conf-file spool-to-logger.properties \     # 用于指定Flume的属性文件
--name agent1 \    # 指定代理名称
--conf $FLUME_HOME/conf \    # 找到Flume的通用配置
-Dflume.root.logger=INFO，console

事务和可靠性

Flume两个独立的事务：source —> channel ，channel —> sink
spooling directory source为文件的每一行创建一个事件。一旦事务中所有事件全部传递到cannnel且提交成功，那么source就将该文件标记为完成，即重命名为xxx.COMPLETED
channel到sink同理，若由于某些原因事件无法记录，那么事务就会回滚，而所有的事件仍然保存在channel中，等待重新传递
此时如果channel设置为file，则具有持久性，只要事件被写入channel，即使代理重启，事件也不会丢失
如果channel设置为memory，事件缓存在存储器中，重启代理，事件丢失
两者相比，memory的优势在于有较高吞吐量

source产生的每个事件都会到达sink至少一次（at last once），不论source还是sink都可能产生重复
例如，代理重启前有部分或全部事件已经被提交到channel，但是代理重启之后，spooling directory source还是会为未完成的文件重新传递事件，logger sink也会重新记录那些已经记录但未提交的事件
'at last once’看起来是个缺陷，但其实是可以接受的性能上的权衡，重复的事件可以等待后续的流水线来处理（Mapreduce,Hive等）

批量处理

Flume最好尽量以事务为单位来批量处理事件，批量处理方式有利于提高file channel性能，因为每个事务只需要写一次本地磁盘和调用一次fsync

HDFS sink

agent1.sources=source1
agent1.channels=channel1
agent1.sinks=sink1

agent1.sources.source1.type=spooldir  # 监视目录中的新增文件
agent1.sources.source1.spoolDir=/tmp/spooldir

agent1.channels.channel1.type=file  # channel中事件持久化存储在磁盘上

agent1.sinks.sink1.type=hdfs    # 只需将sink改为hdfs
agent1.sinks.sink1.hdfs.path=/tmp/flume   # hdfs路径
agent1.sinks.sink1.inUsePrefix=_   
# 正在进行写操作文件的文件名前缀，Mapreduce会忽略以下划线开始的文件

agent1.sources.source1.channels=channel1
agent.sinks.sink1.channel=channel1

对于正在进行写操作的文件名会添加后缀’ .tmp ',表明文件处理尚未完成

分区和拦截器

Flume事件的数据通常按时间来分区，只需要添加拦截器并修改hdfs.path属性，就可以将存储方式修改为分区存储方式

agent1.sources.source1.interceptors=interceptor1  # 拦截器名称
agent1.sources.source1.interceptors.interceptor1.type=timestamp   # 时间戳拦截器
agent1.sinks.sink1.hdfs.path=/tmp/flume/%Y-%m-%d

拦截器是一种能够对事件流中的事件进行修改或删除的组件，在连接source之后，传递到channel之前对事件进行处理
注意: 如果存在多层Flume代理，那么事件的创建时间和写入时间之间可能存在明显差异，尤其是出现停机的情况。针对这种情况，可以对HDFS sink的hdfs.useLocalTimeStamp属性进行设置，以便使用由运行HDFS sink的Flume代理所产生的时间戳

扇出

扇出指的是从一个source向多个channel即向多个sink传递事件

agent1.sources=source1
agent1.channels=channel1 channel2   # 空格拆分多个cahnnel
agent1.sinks=sink1 sink2    # 空格拆分多个sink

agent1.sources.source1.type=spooldir  # 监视目录中的新增文件
agent1.sources.source1.spoolDir=/tmp/spooldir

agent1.channels.channel1.type=file  # channel中事件持久化存储在磁盘上

agent1.sinks.sink1.type=logger  # 用于将事件记录到控制台

agent1.sources.source1.channels=channel1
agent.sinks.sink1.channel=channel1

交付保证

Flume使用独立的事务负责从spooling directory source 到每一个channel的每批事件的传递，若其中有任何一个事务失败，这些事件都不会从source中删除，而是等待稍后重试
如果不介意是否有一些事件未能交付给logger sink，可以指定channel为optional channel（可选的），在这种情况下，如果与该channel相关联的事务失败，source并不会保留事件。
如果在两个channel的事务都提交之前代理出现故障，在代理重启之后所有受影响的事件都会重新传递，即使未提交的cahnnel被标记为optional也是这样。需要把source属性selector.optional设置为一个空格分隔的channel列表：
agent1.sources.source1.selector.optional=channel2

复用选择器

正常扇出流是向所有cahnnel复制事件，若希望自定义，可以通过source上设置一个复用选择器实现，可自定义路由规则。

通过代理层分发

代理层分发（分层结构的Flume代理）就是能够将来自一组节点的事件汇聚到一个文件中，减少文件的数量，增加文件的大小，减轻HDFS的压力，并提高MapReduce处理效率，另外由于文件输入数据节点变多，文件更快更新，使得文件可用于分析的时间更接近于事件的创建时间。
要构建分层结构，需要使用某种特殊的sink来通过网络发送事件，再加上相应的source来接收这些事件。Avro sink可通过Avro RPC将事件发送给运行在另一个Flume代理上的其他Avro，另外也可以使用Thrift sink，通过Thrift RPC做同样的事情，并搭配一个Thtift source

# first
agent1.sources=source1
agent1.channels=channel1 
agent1.sinks=sink1   

agent1.sources.source1.type=spooldir 
agent1.sources.source1.spoolDir=/tmp/spooldir

agent1.channels.channel1.type=file  
agent1.channels.channel1.checkpointDir=/tmp/agent1/file-channel/checkpoint
agent1.channels.channel1.dataDirs=/tmp/agent1/file-channel/data

agent1.sinks.sink1.type=avro
agent1.sinks.sink1.hostname=loaclhost
agent1.sinks.sink1.port=10000

agent1.sources.source1.channels=channel1
agent.sinks.sink1.channel=channel1

# second
agent1.sources=source2
agent1.channels=channel2 
agent1.sinks=sink2

agent1.sources.source2.type=avro 
agent1.sources.source2.bind=loaclhost
agent1.sources.source2.port=10000

agent1.channels.channel2.type=file  
agent1.channels.channel2.checkpointDir=/tmp/agent2/file-channel/checkpoint
agent1.channels.channel2.dataDirs=/tmp/agent2/file-channel/data

agent1.sinks.sink1.type=hdfs
agent1.sinks.sink1.hdfs.path=/tmp/flume

agent1.sources.source1.channels=channel1
agent.sinks.sink1.channel=channel1

两个代理需要分别运行

交付保证

Flume事务确保每一批事件都能可靠的从source传递到channel，以及从channel传递到sink。在Avro sink-source连接的背景下，事务可用于确保将事件可靠的从一个代理传递到下一个代理
在agent1中，Avro sink从file channel中读取一批事件的操作被封装在一个事务中，只有当Avro sink收到确认，表示他到agent2 的Avro source RPC断点的写操作成功时事务才会提交，当agent2将事件批量写入file channel操作的事务被成功提交后才会发送该确认。

Sink组

sink组允许将多个sink当做一个sink处理，以实现故障转移或负载均衡。若第二层代理不可用，事件将被传递给另一个第二层代理，从而使这些事件不中断的到达HDFS

agent1.sources=source1
agent1.channels=channel1 
agent1.sinks=sink1   sink2   # 多个sink
agent1.sinkgroups=sinkgroup1   # sink组

agent1.sources.source1.type=spooldir 
agent1.sources.source1.spoolDir=/tmp/spooldir

agent1.channels.channel1.type=file  

agent1.sinkgroups.sinkgroup1.sinks=sink1 sink2
agent1.sinkgroups.sinkgroup1.processor.type=load_balance
agent1.sinkgroups.sinkgroup1.processor.backoff=true

agent1.sinks.sink1.type=avro
agent1.sinks.sink1.hostname=loaclhost
agent1.sinks.sink1.port=10000

agent1.sinks.sink1.type=avro
agent1.sinks.sink1.hostname=loaclhost
agent1.sinks.sink1.port=10001

agent1.sources.source1.channels=channel1
agent.sinks.sink1.channel=channel1

定义两个Avro sink :sink1 sink2，他们之间区别在于所连接的Avro断点不同（由于本地主机运行区别在端口上，对分布式结构来说，是两个主机不同而端口相同）
处理器类型load_balance，试图使用循环选择机制在组中的两个sink成员之间分发事件流。若某个sink不可用，尝试下一个sink，如果两个都不可用，事件也不会从channel中移除，就像单个sink情况一样。
默认情况下，sink处理器不会记住sink不可用性，所以每次传递都会重试故障的sink，效率低。所以可设置processor.backoff属性改变这种行为，让故障sink在指数增加超时周期内被列入黑名单（最长30s）

组件编目

Source：                               Sink:                       Channel:               Interceptor:
Avro                                   Avro                        File                   Host
Exec                                   Elasticsearch               JDBC                   Mrophline
HTTP								   HBase                       Memory                 Regex extractor
JMS									   Logger                                             Regex filtering
Netcat								   Null                                               static
Sequence generator			           Thrift                                             Timestamp
Spooling director					   File roll                                          UUID
Syslog								   IRC
Thrift                                 Mrophline(Solr)
Twitter