大数据技术之高频面试题（三）：涉及技术Flume、kafka

问题导读

1.Flume组成有哪些？
2.Flume拦截器有哪些知识点？
3.Flume采集数据会丢失吗?
4.FileChannel如何优化？
5.如何控制Kafka丢不丢数据？
6.Kafka分区分配策略默认哪两种？


4.4 Flume相关总结
4.4.1 Flume组成，Put事务，Take事务
1）Flume组成，Put事务，Take事务
        Taildir Source：断点续传、多目录。Flume1.6以前需要自己自定义Source记录每次读取文件位置，实现断点续传。
        File Channel：数据存储在磁盘，宕机数据可以保存。但是传输速率慢。适合对数据传输可靠性要求高的场景，比如，金融行业。
        Memory Channel：数据存储在内存中，宕机数据丢失。传输速率快。适合对数据传输可靠性要求不高的场景，比如，普通的日志数据。
        Kafka Channel：减少了Flume的Sink阶段，提高了传输效率。           
        Source到Channel是Put事务
        Channel到Sink是Take事务


4.4.2 Flume拦截器
        （1）拦截器注意事项
                项目中自定义了：ETL拦截器和区分类型拦截器。
采用两个拦截器的优缺点：优点，模块化开发和可移植性；缺点，性能会低一些
        （2）自定义拦截器步骤
a）实现 Interceptor
b）重写四个方法

•         initialize 初始化
•         public Event intercept(Event event) 处理单个Event
•         public List<Event> intercept(List<Event> events) 处理多个Event，在这个方法中调用Event intercept(Event event)
•         close 方法
  

c）静态内部类，实现Interceptor.Builder


4.4.3 Flume采集数据会丢失吗?（防止数据丢失的机制）
不会，Channel存储可以存储在File中，数据传输自身有事务。

4.4.4 Flume内存
开发中在flume-env.sh中设置JVM heap为4G或更高，部署在单独的服务器上（4核8线程16G内存）
-Xmx与-Xms最好设置一致，减少内存抖动带来的性能影响，如果设置不一致容易导致频繁fullgc。

4.4.5 FileChannel优化
通过配置dataDirs指向多个路径，每个路径对应不同的硬盘，增大Flume吞吐量。
官方说明如下：
Comma separated list of directories for storing log files. Using multiple directories on separate disks can improve file channel peformance
checkpointDir和backupCheckpointDir也尽量配置在不同硬盘对应的目录中，保证checkpoint坏掉后，可以快速使用backupCheckpointDir恢复数据

4.4.6 HDFS Sink小文件处理
（1）HDFS存入大量小文件，有什么影响？
元数据层面：每个小文件都有一份元数据，其中包括文件路径，文件名，所有者，所属组，权限，创建时间等，这些信息都保存在Namenode内存中。所以小文件过多，会占用Namenode服务器大量内存，影响Namenode性能和使用寿命
计算层面：默认情况下MR会对每个小文件启用一个Map任务计算，非常影响计算性能。同时也影响磁盘寻址时间。
        （2）HDFS小文件处理
官方默认的这三个参数配置写入HDFS后会产生小文件，hdfs.rollInterval、hdfs.rollSize、hdfs.rollCount
基于以上hdfs.rollInterval=3600，hdfs.rollSize=134217728，hdfs.rollCount =0，hdfs.roundValue=10，hdfs.roundUnit= second几个参数综合作用，效果如下：
（1）tmp文件在达到128M时会滚动生成正式文件
（2）tmp文件创建超10秒时会滚动生成正式文件


4.5 Kafka相关总结

4.5.1 Kafka架构



4.5.2 Kafka压测
Kafka官方自带压力测试脚本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）。Kafka压测时，可以查看到哪个地方出现了瓶颈（CPU，内存，网络IO）。一般都是网络IO达到瓶颈。

4.5.3 Kafka的机器数量
Kafka机器数量=2*（峰值生产速度*副本数/100）+1

4.5.4 Kafka的日志保存时间
7天
4.5.5 Kafka的硬盘大小
每天的数据量*7天

4.5.6 Kafka监控
公司自己开发的监控器；
开源的监控器：KafkaManager、KafkaMonitor

4.5.7 Kakfa分区数
分区数并不是越多越好，一般分区数不要超过集群机器数量。分区数越多占用内存越大（ISR等），一个节点集中的分区也就越多，当它宕机的时候，对系统的影响也就越大。
分区数一般设置为：3-10个

4.5.8 副本数设定
一般我们设置成2个或3个，很多企业设置为2个。

4.5.9 多少个Topic
          通常情况：多少个日志类型就多少个Topic。也有对日志类型进行合并的。

4.5.10 Kafka丢不丢数据
Ack=0，相当于异步发送，消息发送完毕即offset增加，继续生产。
Ack=1，leader收到leader replica 对一个消息的接受ack才增加offset，然后继续生产。
Ack=-1，leader收到所有replica 对一个消息的接受ack才增加offset，然后继续生产。

4.5.11 Kafka的ISR副本同步队列
ISR（In-Sync Replicas），副本同步队列。ISR中包括Leader和Follower。如果Leader进程挂掉，会在ISR队列中选择一个服务作为新的Leader。有replica.lag.max.messages（延迟条数）和replica.lag.time.max.ms（延迟时间）两个参数决定一台服务是否可以加入ISR副本队列，在0.10版本移除了replica.lag.max.messages参数，防止服务频繁的进去队列。
任意一个维度超过阈值都会把Follower剔除出ISR，存入OSR（Outof-Sync Replicas）列表，新加入的Follower也会先存放在OSR中。

4.5.12 Kafka分区分配策略
在 Kafka内部存在两种默认的分区分配策略：Range和 RoundRobin。
Range是默认策略。Range是对每个Topic而言的（即一个Topic一个Topic分），首先对同一个Topic里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。然后用Partitions分区的个数除以消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。
例如：我们有10个分区，两个消费者（C1，C2），3个消费者线程，10 / 3 = 3而且除不尽。
C1-0 将消费 0, 1, 2, 3 分区
C2-0 将消费 4, 5, 6 分区
C2-1 将消费 7, 8, 9 分区
RoundRobin：前提：同一个Consumer Group里面的所有消费者的num.streams（消费者消费线程数）必须相等；每个消费者订阅的主题必须相同。
第一步：将所有主题分区组成TopicAndPartition列表，然后对TopicAndPartition列表按照hashCode进行排序，最后按照轮询的方式发给每一个消费线程。

4.5.13 Kafka中数据量计算
每天总数据量100g，每天产生1亿条日志， 10000万/24/60/60=1150条/每秒钟
平均每秒钟：1150条
低谷每秒钟：400条
高峰每秒钟：1150条*（2-20倍）=2300条-23000条
每条日志大小：0.5k-2k
每秒多少数据量：2.3M-20MB

4.5.14 Kafka挂掉
1）Flume记录
2）日志有记录
3）短期没事

4.5.15 Kafka消息数据积压，Kafka消费能力不足怎么处理？
1）如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）
2）如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。