Flume及其优化

1 规模

10台物理机中，3台生产Flume和3台消费Flume，1.7版本。
生产flume：把日志服务器中的数据上传到kafka
消费flume：把kafka中的数据上传到HDFS
日志服务器设置默认保存30天。

2 Source、channel，sink

生产flume：

（1）source使用的是tair dir source，具有断点续传和多目录的功能，在flume1.7产生，1.6版本以前，没有taildir source，使用自定义source（Apache1.7源码）实现断点续传。

（2）tarildir source挂了会有什么影响：数据不会丢，有可能重复，因为数据先读后写，读完了，但是offset可能没写完，导致下次重offset开始读，offset后面的同一个event的数据就重复了。

（3）数据重复了怎么解决：不处理（提高传输效率）或者自身采用事务（自定义source，redis去重）。

（4）是否支持递归遍历文件夹，读取数据：不支持，自定义source（给i归遍历文件夹+taildir读取文件函数）可以实现。

file channel：基于磁盘，可靠性高，传输效率低
memory channel：基于内存，可靠性低，传输效率高
Kafka channel：数据存储在kafka里，基于磁盘，可靠性高，传输效率最高
（1）Channel使用的是kafka channel，将数据直接打入到kafka里，省去了sink的阶段，提升了传输效率。1.6产生，没火因为头信息+内容到后面需要后续清洗，虽然提供了参数，但是很遗憾，没起作用，1.7之后，问题解决，火了
（2）在企业里面如何选择：下一级是kafka，kafka channel。其他根据可靠性选择，比如金融，file channel，普通日志，memory channel。

消费flume:

source使用的是kafka source

channel是file channel，数据落在磁盘上，虽然传输不快，但是数据比较安全

sink是HDFS sink

HDFS sink优化

HDFS sink两个优化:
① 配置checkpointdir与backupcheckpointdir配置到不同硬盘的不同目录里，索引的备份，file channel 能多目录（多磁盘）配置多目录，能提高吞吐量
② 小文件问题，小文件解决方法：文件大小（128m）、文件时间（1h）、event个数（0），向HDFS传送时，设置一个临时文件。

3 三个器（拦截器、选择器、监控器）

两个拦截器：一个是轻度过滤的拦截器，生产flume是 ETL拦截器：判断json的完整性{}，是否是{开头，}结尾，主要过滤json数据不完整的数据，消费flume过滤时间戳不正确的数据（零点漂移问题）；一个是区分类型的拦截器-事件拦截器event：kafka分区处理，商品点击、商品列表、商品详情。。。。
当然也可以自定义拦截器步骤：定义类，实现interceptor接口，重写里面4个方法 （初始化、关闭资源、但event处理、多event处理、builder）。

选择器：为了将不同类型的日志打到不同kafka的topic里，将不同的event发送到不同的kafka的topic里。

监控器：为了监控flume的性能，使用第三方框架Ganglia实时监控Flume，监控source到channel，channel到sink。

监控器优化

优化：如果尝试提交的次数和成功提交的次数，前者>后者，flume集群性能出现了问题，一般是出问题在kafka channel，进行优化，增加 flume的内存（flume-evn.sh）或增加flume的节点数

4 Flume 优化

1）Flume参数调优

Source：增加Source个数和batchSize

Source（使用Tair Dir Source时可增加FileGroups个数）可以增大Source的读取数据的能力。例如：当某一个目录产生的文件过多时需要将这个文件目录拆分成多个文件目录，同时配置好多个Source 以保证Source有足够的能力获取到新产生的数据。
batchSize参数决定Source一次批量运输到Channel的event条数，适当调大这个参数可以提高Source搬运Event到Channel时的性能。

Channel ：增大Capacity

type 选择memory时Channel的性能最好，但是如果Flume进程意外挂掉可能会丢失数据。type选择file时Channel的容错性更好，但是性能上会比memory channel差。
使用file Channel时dataDirs配置多个不同盘下的目录可以提高性能。
Capacity 参数决定Channel可容纳最大的event条数。transactionCapacity 参数决定每次Source往channel里面写的最大event条数和每次Sink从channel里面读的最大event条数。transactionCapacity需要大于Source和Sink的batchSize参数。

Sink ：增加Sink的个数和batciSize

增加Sink的个数可以增加Sink消费event的能力。Sink也不是越多越好够用就行，过多的Sink会占用系统资源，造成系统资源不必要的浪费。
batchSize参数决定Sink一次批量从Channel读取的event条数，适当调大这个参数可以提高Sink从Channel搬出event的性能。

2）file channel 优化

能多目录（多磁盘）配置多目录，能提高吞吐量

3）hdfs sink

小文件解决方法：文件大小（128m）、文件时间（1h）、event个数（0）

4）监控器优化

Ganglia：尝试提交的次数，远远大于最终提交的成功次数，需要优化flume，自身不行：flume，增加flume内存：flume-env.sh找兄弟：增加flume节点个数

5）Flume挂了怎么办

如果是memory channel （100event）有可能丢数据，如果是tail dir source， 不会丢数据，但是有可能重复数据