Flink高频面试题

Flink高频面试题

Apache Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。Flink被设计在所有常见的集群环境中运行，以内存执行速度和任意规模来执行计算。Apache Flink是分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架。
在大数据岗位的面试中，尤其是对实时处理比较感兴趣的企业，面试中对于Flink的考察已经非常普遍，本文整理了Flink的高频面试题，并做了简单的思路分析。

1.面试题一：公司怎么提交实时任务？

我们每次提交都会创建一个新的Flink集群，为每个job提供一个yarn-session，任务之间互相独立，互不影响，方便管理。任务执行完成之后创建的集群也会消失。
集群默认只有一个Job Manager。但为了防止单点故障，我们配置了高可用。我们公司一般配置一个主Job Manager，两个备用Job Manager，然后结合ZooKeeper的使用，来达到高可用。

2.面试题二：怎么做压力测试和监控？

我们一般碰到的压力来自以下几个方面：
一，产生数据流的速度如果过快，而下游的算子消费不过来的话，会产生背压问题。背压的监控可以使用Flink Web UI(localhost:8081)来可视化监控，一旦报警就能知道。一般情况下背压问题的产生可能是由于sink这个操作符没有优化好，做一下优化就可以了。比如如果是写入ElasticSearch，那么可以改成批量写入，可以调大ElasticSearch队列的大小等等策略。
二，设置水位线的最大延迟时间这个参数，如果设置的过大，可能会造成内存的压力。可以设置的最大延迟时间小一些，然后把迟到元素发送到侧输出流中去。晚一点更新结果。或者使用类似于RocksDB这样的状态后端，RocksDB会开辟堆外存储空间，但IO速度会变慢，需要权衡。
三，还有就是滑动窗口的长度如果过长，而滑动距离很短的话，Flink的性能会下降的很厉害。
参见链接：https://www.infoq.cn/article/sIhs_qY6HCpMQNblTI9M
四，状态后端使用RocksDB，还没有碰到被撑爆的问题。
五，尽量使用滚动窗口，这样会大大减轻存储的压力。
六，如果想要达到极限的低延迟，可以考虑使用处理时间（Processing Time）。
七，业务逻辑的编写是最重要的。在算子中（例如processElement, onTimer）业务逻辑一定要尽可能的简单，而不是特别复杂的业务逻辑（举个极端的例子，机器学习这种CPU密集型的程序，十几张表的Join）。如果业务逻辑很复杂的话，将会阻塞数据流的向下传递。性能会急剧下降。

3.面试题三：为什么使用Flink替代Spark？

一，Flink是真正的流处理，延迟在毫秒级，Spark Streaming是微批，延迟在秒级。
二，Flink可以处理事件时间，而Spark Streaming只能处理机器时间，无法保证时间语义的正确性。
三，Flink的检查点算法比Spark Streaming更加灵活，性能更高。Spark Streaming的检查点算法是在每个stage结束以后，才会保存检查点。
四，Flink易于实现端到端一致性。

4.面试题四：Flink的checkPoint存在哪里？

状态后端。内存，文件系统，或者RocksDB。

5.面试题五：如果下级存储不支持事务，Flink如何保证exactly-once?

端到端的exactly-once对sink要求比较高，具体实现主要有幂等写入和事务性写入两种方式。幂等写入的场景依赖于业务逻辑，更常见的是用事务性写入。而事务性写入又有预写日志（WAL）和两阶段提交（2PC）两种方式。如果外部系统不支持事务，那么可以用预写日志的方式，把结果数据先当成状态保存，然后在收到 checkpoint 完成的通知时，一次性写入 sink 系统。

6.面试题六：说一下Flink的状态机制。

Flink内置的很多算子，包括源source，数据存储sink都是有状态的。在Flink中，状态始终与特定算子相关联。Flink会以checkpoint的形式对各个任务的状态进行快照，用于保证故障恢复时的状态一致性。Flink通过状态后端来管理状态和checkpoint的存储，状态后端可以有不同的配置选择。

7.面试题七：海量key去重问题。

考虑一个实时场景：双十一场景，滑动窗口长度为 1 小时，滑动距离为 10 秒钟，亿级用户，怎样计算 UV？解答：使用类似于 scala 的 set 数据结构或者 redis 的 set 显然是不行的，因为可能有上亿个 Key，内存放不下。所以可以考虑使用布隆过滤器（Bloom Filter）来去重。

8.面试题八：Flink的CheckPoint和Spark的比较。

spark streaming 的 checkpoint 仅仅是针对 driver 的故障恢复做了数据和元数据的 checkpoint。而 flink 的 checkpoint 机制要复杂了很多，它采用的是轻量级的分布式快照，实现了每个算子的快照，及流动中的数据的快照。文章链接：https://cloud.tencent.com/developer/article/1189624

9.面试题九：Flink的三种语义是什么？分别说出应用场景。

Event Time：这是实际应用最常见的时间语义。
Processing Time：没有事件时间的情况下，或者对实时性要求超高的情况下。
Ingestion Time：存在多个Source Operator的情况下，每个Source Operator可以使用自己本地系统时钟指派 Ingestion Time。后续基于时间相关的各种操作，都会使用数据记录中的 Ingestion Time。

10.面试题十：Flink CEP编程中当状态没有到达的时候会将数据保存在哪里？

在流式处理中，CEP 当然是要支持 EventTime 的，那么相对应的也要支持数据的迟到现象，也就是watermark的处理逻辑。CEP对未匹配成功的事件序列的处理，和迟到数据是类似的。在 Flink CEP的处理逻辑中，状态没有满足的和迟到的数据，都会存储在一个Map数据结构中，也就是说，如果我们限定判断事件序列的时长为5分钟，那么内存中就会存储5分钟的数据，这在我看来，也是对内存的极大损伤之一。

11.面试题十一：Flink的资源是如何设置的，设置资源的依据是什么？

我们公司购买的云计算资源比较多，所以跑平常的任务没有发现什么问题。会提前mock比较大的数据量，做一下压力测试，然后决定使用多少资源。
以下6个方面是确定 Flink 集群大小时最先要考虑的一些因素：
记录数和每条记录的大小
确定集群大小的首要事情就是估算预期进入流计算系统的每秒记录数（也就是我们常说的吞吐量），以及每条记录的大小。不同的记录类型会有不同的大小，这将最终影响 Flink 应用程序平稳运行所需的资源。

不同 key 的数量和每个 key 存储的 state 大小
应用程序中不同 key 的数量和每个 key 所需要存储的 state 大小，都将影响到 Flink 应用程序所需的资源，从而能高效地运行，避免任何反压。

状态的更新频率和状态后端的访问模式
第三个考虑因素是状态的更新频率，因为状态的更新通常是一个高消耗的动作。而不同的状态后端（如 RocksDB，Java Heap）的访问模式差异很大，RocksDB 的每次读取和更新都会涉及序列化和反序列化以及 JNI 操作，而 Java Heap 的状态后端不支持增量 checkpoint，导致大状态场景需要每次持久化的数据量较大。这些因素都会显著地影响集群的大小和 Flink 作业所需的资源。

网络容量
网络容量不仅仅会受到 Flink 应用程序本身的影响，也会受到可能正在交互的 Kafka、HDFS 等外部服务的影响。这些外部服务可能会导致额外的网络流量。例如，启用 replication 可能会在网络的消息 broker 之间产生额外的流量。

磁盘带宽
如果你的应用程序依赖了基于磁盘的状态后端，如 RocksDB，或者考虑使用 Kafka 或 HDFS，那么磁盘的带宽也需要纳入考虑。

机器数量及其可用 CPU 和内存
最后但并非最不重要的，在开始应用部署前，你需要考虑集群中可用机器的数量及其可用的 CPU 和内存。这最终确保了在将应用程序投入生产之后，集群有充足的处理能力。

12.面试题十二：Flink程序在面对数据高峰时如何处理？

1，使用大容量的Kafka把数据先放到消息队列里面。再使用Flink进行消费，不过这样会影响到一点实时性。
2，使用滚动窗口
3，使用处理时间
4，下游使用消费速度快的外围设备（如Kafka）