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