flink面试总结

1. checkpoint是怎么实现的，用到了哪些配置项

• 暂停处理新流入数据，将新数据缓存起来
• 将算子子任务的本地状态数据拷贝到一个远程的持久化存储上
• 继续处理新流入的数据，包括刚才缓存起来的数据

2. state存在什么地方
   MemoryStateBackend：放在内存里
   FsStateBackend：放在文件系统里，数据持久化到文件系统上，文件系统包括本地磁盘、HDFS以及包括Amazon、阿里云在内的云存储服务
   RocksDBStateBackend：放在rocksDB，磁盘里

3. checkpoint和savepoint的区别，savepoint是手动触发的

4. state有哪种类型，用了哪些state

5. flink有哪些backends，就是state 后端有哪几种：
   MemoryStateBackend：放在内存里
   FsStateBackend：放在文件系统里
   RocksDBStateBackend：放在rocksDB，磁盘里，RocksDB是一种嵌入式Key-Value数据库，数据实际保存在本地磁盘上。比起FsStateBackend的本地状态存储在内存中，RocksDB利用了磁盘空间，所以可存储的本地状态更大。然而，每次从RocksDB中读写数据都需要进行序列化和反序列化，因此读写本地状态的成本更高。快照执行时，Flink将存储于本地RocksDB的状态同步到远程的存储上，因此使用这种State Backend时，也要配置分布式存储的地址。Asynchronous Snapshot在默认情况也是开启的。

6. state的规模有多大，占用多少空间

7. 一个任务重启的时候，有checkpoint怎么恢复到一个任务里去，flink怎么把checkpoint这个文件恢复到taskmanager里面
   https://lulaoshi.info/flink/chapter-state-checkpoint/checkpoint
   Flink的重启恢复逻辑相对比较简单：
   重启应用，在集群上重新部署数据流图。
   从持久化存储上读取最近一次的Checkpoint数据，加载到各算子子任务上。继续处理新流入的数据。
   这样的机制可以保证Flink内部状态的Excatly-Once一致性。至于端到端的Exactly-Once一致性，要根据Source和Sink的具体实现而定，我们还会在第7章端到端Exactly-Once详细讨论。当发生故障时，一部分数据有可能已经流入系统，但还未进行Checkpoint，Source的Checkpoint记录了输入的Offset；当重启时，Flink能把最近一次的Checkpoint恢复到内存中，并根据Offset，让Source从该位置重新发送一遍数据，以保证数据不丢不重。像Kafka等消息队列是提供重发功能的，socketTextStream就不具有这种功能，也意味着不能保证端到端的Exactly-Once投递保障。
   当一个作业出现故障，进行重启时，势必会暂停一段时间，这段时间上游数据仍然继续发送过来。作业被重新拉起后，肯定需要将刚才未处理的数据消化掉。这个过程可以被理解为，一次跑步比赛，运动员不慎跌倒，爬起来重新向前追击。为了赶上当前最新进度，作业必须以更快的速度处理囤积的数据。所以，在设定资源时，我们必须留出一定的富余量，以保证重启后这段“赶进度”过程中的资源消耗。
   重启策略可以在conf/flink-conf.yaml中设置，所有使用这个配置文件执行的作业都将采用这样的重启策略；也可以在单个作业的代码中配置重启策略。

8. checkpoint存在哪里，最终checkpoint几百G的数据存在什么地方，类似于文件放到hdfs里面一系列的文件，保存state序列化的结果，flink是一个分布式的引擎，每一个节点是怎么拿到这一部分的数据的

state的存放位置
http://09itblog.site/?p=1269

10. keystate和operator state的区别：
    keystate：表示和key相关的一种state,只能用于KeyedStream类型数据集对应的Functions和Operators之上。Keyed State是Operator State的特例，区别在于Keyed State事先按照key对数据集进行了分区，每个Key State仅对应一个Operator和Key的组合。Keyed State可以通过Key Groups进行管理，主要用于当算子并行度发生变化时，自动重新分布Keyed State数据。在系统运行过程中，一个Keyed算子实例可能运行一个或者多个Key Groups 的 keys。
    与Keyed State不同的是，Operator State只和并行的算子实例绑定，和数据元素种的key无关，每个算子实例中持有所有数据元素中的一部分状态数据。Operator State支持当算子实例并行度发生变化时自动重新分配状态数据。

11. flink的一些社区进展，比如1.9支持不了，没法用，用java去自己实现

12. 1.9或者1.10是一个算子的所有barrier发给对齐，1.13用了一个非对齐的barrier机制，部分解决了这个问题，1.14

13. key分布不均的情况进行打散，key是什么东西，key是不是id之类的东西，负载均衡做了什么事情，key具体是怎么打散的

14. 怎么判断反压，发压是怎么识别的，由外部的监控

15. 怎么判断GC，java GC有哪几种情况，怎么定位具体的问题，有没有使用货源图或者其它类似的工具，https://www.pianshen.com/article/51021696296/ 可视化的工具来看GC

16. flink聚合，多久进行一次输出

17. 任务的并发度，flink的并发，有多少个task，多少slot

18. flink的jobmanager、taskmanager、slot、task的层级关系

19. es的底层用什么做存储的，来支持线上访问

20. map实现一个sample：https://www.cnblogs.com/labuladong/p/13975110.html 随机从数组里取出值，用o1时间，找到对应的值，替换最后一个就可以，后面加上时间分析 get、set、remove，sample，等概率随机返回一个键值对，高性能
    https://www.cnblogs.com/labuladong/p/13975110.html

21. 时间排序，对不同时间段读取cash的数据

22. 聚合函数的底层实现是什么

23. 打散的key是什么

24. 窗口函数：翻滚窗口 (Tumbling Window, 无重叠)
    滑动窗口 (Sliding Window, 有重叠)
    会话窗口 (Session Window, 活动间隙)
    全局窗口 ()
    Flink SQL 窗口函数
    flink窗口函数包含滚动窗口、滑动窗口、会话窗口和OVER窗口
    https://segmentfault.com/a/1190000023296719
    https://juejin.cn/post/6896659752077099016#heading-0
    一种是增量计算，如reduce和aggregate，增量计算指的是窗口保存一份中间数据，每流入一个新元素，新元素与中间数据两两合一，生成新的中间数据，再保存到窗口中。另一种是全量计算，如process。全量计算指的是窗口先缓存该窗口所有元素，等到触发条件后对窗口内的全量元素执行计算。
    Flink窗口全解析：三种时间窗口、窗口处理函数使用及案例
    https://zhuanlan.zhihu.com/p/102325190

flink的checkpoint怎么对齐：Checkpoint对齐机制源码分析

flink的状态管理：Flink 状态管理详解（State TTL、Operator state、Keyed state）https://cloud.tencent.com/developer/article/1792720
Keyed States：记录每个Key对应的状态值一个Task上可能包含多个Key不同Task上不会出现相同的Key ，常用的 MapState, ValueState

Operator States：记录每个Task对应的状态值数据类型

ListState：并发度在改变的时候，会将并发上的每个List都取出，然后把这些List合并到一个新的List,然后根据元素的个数在均匀分配给新的Task;
UnionListState：相比于ListState更加灵活，把划分的方式交给用户去做，当改变并发的时候，会将原来的List拼接起来。然后不做划分，直接交给用户；
BroadcastState：如大表和小表做Join时，小表可以直接广播给大表的分区，在每个并发上的数据都是完全一致的。做的更新也相同，当改变并发的时候，把这些数据COPY到新的Task即可
state 存储在 State Backend 中，State Backend 一共有三种：

MemoryStateBackend
FsStateBackend
RocksDBStateBackend。

https://blog.csdn.net/wangshuminjava/article/details/104494255
（1）Keyed State
　　表示和key相关的一种state,只能用于KeyedStream类型数据集对应的Functions和Operators之上。Keyed State是Operator State的特例，区别在于Keyed State事先按照key对数据集进行了分区，每个Key State仅对应一个Operator和Key的组合。Keyed State可以通过Key Groups进行管理，主要用于当算子并行度发生变化时，自动重新分布Keyed State数据。在系统运行过程种，一个Keyed算子实例可能运行一个或者多个Key Groups 的 keys。
（2）Operator State
　与Keyed State不同的是，Operator State只和并行的算子实例绑定，和数据元素种的key无关，每个算子实例中持有所有数据元素中的一部分状态数据。Operator State支持当算子实例并行度发生变化时自动重新分配状态数据。

flink的并发度设置：2的幂次方
https://codeantenna.com/a/O1QpMH6yfO

flink 1.14的存放位置：https://segmentfault.com/a/1190000040644470
JobManager 动态根据当前任务的执行情况，去明确 Checkpoint Barrier 是从哪里开始触发。同时在部分任务结束后，后续的 Checkpoint 只会保存仍在运行 Task 所对应的 stage，通过这种方式能够让任务执行完成后，还可以继续做 Checkpoint ，在有限流执行中提供更好的容错保障。