【先收藏，早晚用得到】100个Flink高频面试题系列（一）
持续分享有用、有价值、精选的优质大数据面试题
致力于打造全网最全的大数据面试专题题库
1、Flink怎么做压力测试和监控？
参考答案：我们一般碰到的压力来自以下几个方面：
（1）产生数据流的速度如果过快，而下游的算子消费不过来的话，会产生背压。 背压的监控可以使用 Flink Web UI(localhost:8081) 来可视化监控，一旦报警就能知道。一般情况下背压问题的产生可能是由于 sink 这个 操作符没有优化好，做一下优化就可以了。比如如果写入ElasticSearch， 那么可以改成批量写入，可以调 大 ElasticSearch 队列的大小等等策略。
（2）设置 watermark 的最大延迟时间这个参数，如果设置的过大，可能会造成 内存的压力。可以设置最大延迟时间小一些，然后把迟到元素发送到侧输出流中去。 晚一点更新结果。或者使用类似于 RocksDB 这样的状态后端， RocksDB会开辟堆外存储空间，但 IO 速度会变慢，需要权衡。
（3）还有就是滑动窗口的长度如果过长，而滑动距离很短的话，Flink 的性能 会下降的很厉害。我们主要通过时间分片的方法，将每个元素只存入一个“重叠窗口”，这样就可以减少窗口处理中状态的写入。
参考答案：Flink 任务并行度合理行一般根据峰值流量进行压测评估，并且根据集群负载情况留一定量的 buffer 资源。
-
如果数据源已经存在，则可以直接消费进行测试
-
如果数据源不存在，需要自行造压测数据进行测试
对于一个 Flink 任务来说，一般可以按照以下方式进行细粒度设置并行度：
-
source 并行度配置：以 kafka 为例，source 的并行度一般设置为 kafka 对应的 topic 的分区数
-
transform（比如 flatmap、map、filter 等算子）并行度的配置：这些算子一般不会做太重的操作，并行度可以和 source 保持一致，使得算子之间可以做到 forward 传输数据，不经过网络传输
-
keyby 之后的处理算子：建议最大并行度为此算子并行度的整数倍，这样可以使每个算子上的 keyGroup 是相同的，从而使得数据相对均匀 shuffle 到下游算子，如下图为 shuffle 策略
-
sink 并行度的配置：sink 是数据流向下游的地方，可以根据 sink 的数据量及下游的服务抗压能力进行评估。如果 sink 是 kafka，可以设为 kafka 对应 topic 的分区数。注意 sink 并行度最好和 kafka partition 成倍数关系，否则可能会出现如到 kafka partition 数据不均匀的情况。但是大多数情况下 sink 算子并行度不需要特别设置，只需要和整个任务的并行度相同就行。
参考答案：Flink通过实现两阶段提交和状态保存来实现端到端的一致性语义。分为以下几个步骤：
- 开始事务（beginTransaction）：创建一个临时文件夹，来写把数据写入到这个文件夹里面
- 预提交（preCommit）：将内存中缓存的数据写入文件并关闭
- 正式提交（commit）：将之前写完的临时文件放入目标目录下。这代表着最终的数据会有一些延迟
- 丢弃（abort）：丢弃临时文件
若失败发生在预提交成功后，正式提交前。可以根据状态来提交预提交的数据，也可删除预提交的数据。
4、Flink对于迟到数据是怎么处理的参考答案：Flink中 WaterMark 和 Window 机制解决了流式数据的乱序问题，对于因为延迟而顺序有误的数据，可以根据eventTime进行业务处理，对于延迟的数据Flink也有自己的解决办法，主要的办法是给定一个允许延迟的时间，在该时间范围内仍可以接受处理延迟数据：
-
设置允许延迟的时间是通过allowedLateness(lateness: Time)设置
-
保存延迟数据则是通过sideOutputLateData(outputTag: OutputTag[T])保存
-
获取延迟数据是通过DataStream.getSideOutput(tag: OutputTag[X])获取
参考答案：Flink支持不同的重启策略，这些重启策略控制着job失败后如何重启：
1、固定延迟重启策略
固定延迟重启策略会尝试一个给定的次数来重启Job，如果超过了最大的重启次数，Job最终将失败。在连续的两次重启尝试之间，重启策略会等待一个固定的时间。
2、失败率重启策略
失败率重启策略在Job失败后会重启，但是超过失败率后，Job会最终被认定失败。在两个连续的重启尝试之间，重启策略会等待一个固定的时间。
3、无重启策略
Job直接失败，不会尝试进行重启。
持续分享有用、有价值、精选的优质大数据面试题致力于打造全网最全的大数据面试专题题库
