flink面试总结

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

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

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

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

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

一个任务重启的时候，有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中设置，所有使用这个配置文件执行的作业都将采用这样的重启策略；也可以在单个作业的代码中配置重启策略。

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

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支持当算子实例并行度发生变化时自动重新分配状态数据。

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

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

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

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

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

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

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

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

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

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

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

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

打散的key是什么

窗口函数：翻滚窗口 (Tumbling Window, 无重叠)
滑动窗口 (Sliding Window, 有重叠)
会话窗口 (Session Window, 活动间隙)
全局窗口 ()