干货 | 13道精选Flink面试题

        相信小伙伴们对于Flink必定不会感到陌生，做为连续三年蝉联第一，荣膺全球最活跃的 Apache 开源项目，Flink在中国的热度也一直是居高不下。近几年，在社区的推进下，Flink 技术栈在愈来愈多的公司开始获得应用，所以在大数据的求职招聘中，对于Flink的着重考察也变得愈来愈重要。本期文章，菌哥就带你们来总结一下，在面试过程当中，Flink常被问到的知识点有哪些？若是本文对你有帮助，记得在看完以后，一键三连(✧◡✧)

---

一、应用架构

        问题：公司怎么提交的实时任务，有多少 Job Manager？

        解答：

        1. 咱们使用 yarn session 模式提交任务。每次提交都会建立一个新的 Flink 集群，为每个 job 提供一个 yarn-session，任务之间互相独立，互不影响， 方便管理。任务执行完成以后建立的集群也会消失。线上命令脚本以下：

bin/yarn-session.sh -n 7 -s 8 -jm 3072 -tm 32768 -qu root.*.* -nm *-* -d

        其中申请 7 个 taskManager，每一个 8 核，每一个 taskmanager 有 32768M 内存。

        2. 集群默认只有一个 Job Manager。但为了防止单点故障，咱们配置了高可用。 咱们公司通常配置一个主 Job Manager，两个备用 Job Manager，而后结合 ZooKeeper 的使用，来达到高可用。

二、压测和监控

        问题：怎么作压力测试和监控？

        解答：咱们通常碰到的压力来自如下几个方面：

        一，产生数据流的速度若是过快，而下游的算子消费不过来的话，会产生背压。 背压的监控可使用 Flink Web UI(localhost:8081) 来可视化监控，一旦报警就能知道。通常状况下背压问题的产生多是因为 sink 这个 操做符没有优化好，作一下 优化就能够了。好比若是是写入 ElasticSearch， 那么能够改为批量写入，能够调 大 ElasticSearch 队列的大小等等策略。

        二，设置 watermark 的最大延迟时间这个参数，若是设置的过大，可能会形成内存的压力。能够设置最大延迟时间小一些，而后把迟到元素发送到侧输出流中去。 晚一点更新结果。或者使用相似于 RocksDB 这样的状态后端， RocksDB 会开辟堆外存储空间，但 IO 速度会变慢，须要权衡。

        三，还有就是滑动窗口的长度若是过长，而滑动距离很短的话，Flink 的性能会降低的很厉害。咱们主要经过时间分片的方法，将每一个元素只存入一个“重叠窗 口”，这样就能够减小窗口处理中状态的写入。（详情连接：Flink 滑动窗口优化）

        四，状态后端使用 RocksDB，尚未碰到被撑爆的问题

三、为何用 Flink

        问题：为何使用 Flink 替代 Spark？

        解答：主要考虑的是 flink 的低延迟、高吞吐量和对流式数据应用场景更好的支持；另外，flink 能够很好地处理乱序数据，并且能够保证 exactly-once 的状态一致性。

四、checkpoint 的理解

        问题：如何理解Flink的checkpoint

        解答：Checkpoint是Flink实现容错机制最核心的功能，它可以根据配置周期性地基于Stream中各个Operator/task的状态来生成快照，从而将这些状态数据按期持久化存储下来，当Flink程序一旦意外崩溃时，从新运行程序时能够有选择地从这些快照进行恢复，从而修正由于故障带来的程序数据异常。他能够存在内存，文件系统，或者 RocksDB。

五、exactly-once 的保证

        问题：若是下级存储不支持事务，Flink 怎么保证 exactly-once？

        解答：端到端的 exactly-once 对 sink 要求比较高，具体实现主要有幂等写入和 事务性写入两种方式。幂等写入的场景依赖于业务逻辑，更常见的是用事务性写入。 而事务性写入又有预写日志（WAL）和两阶段提交（2PC）两种方式。

        若是外部系统不支持事务，那么能够用预写日志的方式，把结果数据先当成状态保存，而后在收到 checkpoint 完成的通知时，一次性写入 sink 系统。

六、状态机制

        问题：说一下 Flink 状态机制？

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

七、海量 key 去重

        问题：怎么去重？考虑一个实时场景：双十一场景，滑动窗口长度为 1 小时， 滑动距离为 10 秒钟，亿级用户，怎样计算 UV？

        解答：使用相似于 scala 的 set 数据结构或者 redis 的 set 显然是不行的， 由于可能有上亿个 Key，内存放不下。因此能够考虑使用布隆过滤器（Bloom Filter） 来去重。

八、checkpoint 与 spark 比较

        问题：Flink 的 checkpoint 机制对比 spark 有什么不一样和优点？

        解答： spark streaming 的 checkpoint 仅仅是针对 driver 的故障恢复作了数据和元数据的checkpoint。而 flink 的 checkpoint 机制要复杂了不少，它采用的是轻量级的分布式快照，实现了每一个算子的快照，及流动中的数据的快照。

九、watermark 机制

        问题：请详细解释一下 Flink 的 Watermark 机制。

        解答：在使用 EventTime 处理 Stream 数据的时候会遇到数据乱序的问题，流处理从 Event（事 件）产生，流经 Source，再到 Operator，这中间须要必定的时间。虽然大部分状况下，传输到 Operator 的数据都是按照事件产生的时间顺序来的，可是也不排除因为网络延迟等缘由而致使乱序的产生，特别是使用 Kafka 的时候，多个分区之间的数据没法保证有序。所以， 在进行 Window 计算的时候，不能无限期地等下去，必需要有个机制来保证在特定的时间后， 必须触发 Window 进行计算，这个特别的机制就是 Watermark（水位线）。Watermark是用于处理乱序事件的。

        在 Flink 的窗口处理过程当中，若是肯定所有数据到达，就能够对 Window 的全部数据作窗口计算操做（如汇总、分组等），若是数据没有所有到达，则继续等待该窗口中的数据所有到达才开始处理。这种状况下就须要用到水位线(WaterMarks)机制，它可以衡量数据处理进度（表达数据到达的完整性），保证事件数据（所有）到达 Flink 系统，或者在乱序及延迟到达时，也可以像预期同样计算出正确而且连续的结果。

十、exactly-once 如何实现

        问题：Flink 中 exactly-once 语义是如何实现的，状态是如何存储的？

        解答：Flink 依靠 checkpoint 机制来实现 exactly-once 语义，若是要实现端到端 的 exactly-once，还须要外部 source 和 sink 知足必定的条件。状态的存储经过状态 后端来管理，Flink 中能够配置不一样的状态后端。

十一、CEP

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

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

十二、三种时间语义

        问题：Flink 三种时间语义是什么，分别说出应用场景？

        解答：

• Event Time：这是实际应用最多见的时间语义，指的是事件建立的时间，每每跟watermark结合使用

• Processing Time：指每个执行基于时间操做的算子的本地系统时间，与机器相关。适用场景：没有事件时间的状况下，或者对实时性要求超高的状况

• Ingestion Time：指数据进入Flink的时间。适用场景：存在多个 Source Operator 的状况下，每一个 Source Operator 可使用本身本地系统时钟指派 Ingestion Time。后续基于时间相关的各类操做， 都会使用数据记录中的 Ingestion Time

1三、数据高峰的处理

        问题：Flink 程序在面对数据高峰期时如何处理？

        解答：使用大容量的 Kafka 把数据先放到消息队列里面做为数据源，再使用 Flink 进行消费，不过这样会影响到一点实时性。
        

小结

        本次分享的Flink面试题难度不大，但足够考验一个数据工程师对于Flink的基本认知水平。要想职业道路好走，就得跟上技术发展的潮流！本期文章就到这里，后期会为你们分享更多干货内容，敬请期待！你知道的越多，你不知道的也越多，我是Alice，咱们下一期见！

彩蛋

        为了能鼓励你们多学会总结，菌在这里贴上本身平时作的思惟导图，须要的朋友，能够关注博主我的微信公众号【猿人菌】，后台回复“思惟导图”便可获取。

        更有海量面经奉送

关注便可获取高质量思惟导图，互联网一线大厂面经，大数据珍藏精品书籍...期待您的关注!

本文同步分享在 博客“Alice菌”（CSDN）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。