文章目录
– HDFS Sink如何避免生成大量小文件
- 官方默认的这三个参数配置写入HDFS后是会产生小文件的，需要修改配置项：hdfs.rollInterval、hdfs.rollSize、hdfs.rollCount
- 基于以上hdfs.rollInterval=600，hdfs.rollSize=134217728，hdfs.rollCount =0，几个参数综合作用，效果如下：
（1）hdfs.rollSize=134217728表示tmp文件在达到128M时会滚动生成正式文件
（2）hdfs.rollInterval=600tmp表示hdfs sink间隔超10分钟将创建的临时文件滚动成最终目标文件。
（3）hdfs.rollCount =0表示不按照事务的数量来进行滚动生成文件 - 举例：在2018-01-01 05:23的时侯sink接收到数据，那会产生如下tmp文件：
/atguigu/20180101/atguigu.201801010520.tmp
即使文件内容没有达到128M，也会在05:33时滚动生成正式文件
/atguigu/20180101/atguigu.201801010520
– file channel /memory channel/kafka channel的区别及如何选择
一、区别
（1）file channel
- 数据存储于磁盘，宕机数据可以保存。
- 优势：可靠性高；劣势：传输速度低
- 默认容量：100万event
- 注意：
FileChannel可以通过配置dataDirs指向多个路径，每个路径对应不同的硬盘，增大Flume吞吐量。
（2）memory channel
- 数据存储于内存，宕机数据丢失
- 优势：传输速度快；劣势：可靠性差
- 默认容量：100个event
（3）kafka channel
- 数据存储于Kafka，
基于磁盘，有副本机制，可靠性高； 传输速度极快：kafka channel > memory channel + kafka sink- 速度大于memory channel的主要原因:省去了sink阶段
二、生产环境如何选择
- 如果下一级是kafka,优先选择kafka channel
- 如果是金融、对钱要求准确的公司，对数据传输可靠性要求高的场景，选择file channel
- 如果就是普通的日志数据，通常可以选择memory channel，要求速度足够快，对安全性要求不是特别高。虽然安全性得不到保障，但是每天丢几百万数据又怎样，PB级亿万富翁，掉1块钱会捡？
– Flume组成、每个组件的常用类型及其特点
一、Source
- Taildir Source：断点续传、多目录。Flume1.6以前没有，需要自己自定义Source记录每次读取文件位置，实现断点续传。
- Avro Source：Avro端口监听并接收来自外部的Avro客户流的事件。
- Exec Source：Exec Source的配置就是设定一个Unix(linux)命令，然后通过这个命令不断输出数据。如果进程退出，Exec Source也一起退出，不会产生进一步的数据。
- Spooling Directory Source：Spooling Directory Source监测配置的目录下新增的文件，并将文件中的数据读取出来。
二、Channel
- File Channel：数据存储在磁盘，宕机数据可以保存。但是传输速率慢。适合对数据传输可靠性要求高的场景，比如，金融行业。
- Memory Channel：数据存储在内存中，宕机数据丢失。传输速率快。适合对数据传输可靠性要求不高的场景，比如，普通的日志数据。
- Kafka Channel：减少了Flume的Sink阶段，提高了传输效率。
三、Sink
- HDFS Sink：当需要将事件消息写入到Hadoop分布式文件系统（HDFS）时，可以使用HDFS Sink。
- Avro Sink：和 Avro Source一起工作，用于构建Flume分层收集数据消息结构。
- Kafka Sink：通过该Sink可将事件消息数据发布到Kafka topic 上。其目标是将Flume与Kafka集成，以便基于拉式的处理系统可以处理来自各种Flume Source的数据。 目前支持Kafka 0.9.x以上系列版本。
– 关于Taildir source
（1）有哪些特点？
- 断点续传、多目录
（2）哪个flume版本产生的？
- Apache1.7、CDH1.6
（3）没有断点续传功能时怎么做的？
- 通过自定义Source实现
（4）taildir挂了怎么办？
- 挂掉了也没事，挂掉期间继续往文件里追加的内容会等flume恢复后从断点处继续上传，但是可能因为断点未及时记录而产生重复数据
（5）怎么处理重复数据？
- 不处理：生产环境通常不在flume端处理，因为在Flume中处理效率很低，会严重影响传输效率
- 处理
方式一：自身处理：在taildirsource里面增加自定义事务
方式二：找兄弟：下一级处理（hive dwd sparkstreaming flink布隆）、去重手段（groupby、开窗取窗口第一条、redis）
（6）taildir source 是否支持递归遍历文件夹读取文件？
- 不支持，需要自定义Source，递归遍历文件夹 +读取文件
– 关于Flume流式处理事务流程
- 事务：ACID 主要是A：原子性，共进退
- Source到Channel是Put事务
- Channel到Sink是Take事务
- putList是阻塞式队列，能缓存多少可以通过transactionCapacity设置，如果Channel内存队列空间不足Source就不拉数据了。
- Sink并没有把这些Event数据拉出来，只是引用到Sink而已，如果输出成功doCommit会把Channel中相应数据销毁。sink提交失败数据归还到Channel里，其实只是把数据的引用销毁。
- Flume1.7有个Bug，会导致Sink拉数据进入死循环，导致CPU占满。
- 其中回滚的动作可以理解为就是等待，也可能是把数据归还给上级。
– Flume Agent内部原理
- ChannelSelector的作用就是选出Event将要被发往哪个Channel。其共有两种类型，分别是Replicating（复制）和Multiplexing（多路复用），ReplicatingSelector会将同一个Event发往所有的Channel，Multiplexing会根据相应的原则（根据
header中value值的不同进行分流），将不同的Event发往不同的Channel，需配合拦截器使用。 - SinkProcessor共有三种类型，分别是：
DefaultSinkProcessor：默认Channel和Sink是一对一的关系。
LoadBalancingSinkProcessor：可以实现负载均衡的功能，但是一个Sink组只能消费Channel中每个Event一次，也就是说每一个Event只能被一个Sink拉走，Channel和Sink只能是一对多的关系。
FailoverSinkProcessor：有点HA的意思，故障转移，Active挂了小弟开始顶替就完事，FailoverSinkProcessor对应的也是Sink Group，FailoverSinkProcessor可以错误恢复的功能（涉及退避算法，如果一个sink挂掉了，会等1s，2s，4s，8s看是否起来，上限是30s，等待时间上限可以通过processor.selector.maxTimeOut配置 ）