Flink的复习
- Flink的简单介绍，一个面向流处理和批处理的分布式数据计算引擎，可以支持从多种数据来源进行数据接入，也可以输出为多种格式。也就是支持不同的datasource和datasink
- Flink的运行必须要Hadoop吗？
没必要非要依赖Hadoop，因为Flink可以集成太多的大数据基础设施了，比如Yarn，Hbase，HDFS。
- Flink集群构成
http://xinblog.ltd/?p=3971
内部主要存在如下几种角色
JobManager，TaskManager，ResourceManager，Dispatcher
对于JobManager 控制着一个应用，一个计算的执行，负责将应用抽象为JobGraph，然后转换为ExecutionGraph，并进行执行
对于TaskManager，则是Flink的工作进程，提供了计算资源slot，slot中执行了具体任务
对于ResourceManager，则是负责管理TaskManager，负责和JobManager交互，分配资源
Dispatcher，则是负责应用提交，启动JobManager
- Flink和Spark Streaming的区别
其一，架构不同，组件不同，这个是必然的，一个是Master，Worker，Driver，Executor
另一个是JobManager，TaskManager，Slot等构成
其二，两者支持的时间机制不一样，Flink支持的时间机制更多，比如处理时间，实际时间，进入时间，而且Flink支持WaterMark水位机制来处理迟到数据，但是Spark Streaming则是只支持处理时间
其三，Spark Streaming的容错机制，虽然提供了checkpoint机制，但只能保证数据不丢失，不能做到Exactly-Once，而Flink利用了Checkpoint 加上二阶段提交，提供了Exactly-Once的能力。
- Flink 的Checkpoint 容错机制
Flink的的容错机制基于了Chandy-Lamport algorithm算法
在Flink中，每一个JobManager内部都存在着检查点生成器。
会定时的发送检查点barrier 屏障，当下游算子收到的时候，会进行暂停处理，直到所有的上游barrier都到达，之后生成自己的快照，然后向下游算子广播，这样直到sink算子之后，sink算子向JobManager进行汇报，这样就算一个快照制作成功了
那么那这个check point 机制和Spark Streaming进行对比，会发现Flink中的checkpoint机制，会更加的复杂，实现了每个算子的快照，和流动中的数据的快照。
- Flink中的Exactly-Once的实现？
Exactly-once对sink要求较高，主要是由checkpoint + 二阶段提交一同保证
一方面是只有上流的checkpoint生成完成了，sink才会将数据提交，通过这种方式，来保证数据的一致性。
- 如果不支持二阶段提交，还能保证Exactly-once？
那么就跟文件系统的完全一致类似，可以先将文件增加后缀，等提交后再去掉后缀。
- 常见算子
读取相关 从内存中提取 fromElements 从文件读取 readTextFile 从Socket中读取 socketTextStream 自定义读取 creatInput
中间状态转换也有，比如Map，FlatMap。Filter，KeyBy，Reduce，Window，Connect
- Flink延迟高，怎么办
这就是消费能力不够，必然需要进行相关的调优，并发数，CPU，堆内存等参数进行调优，包括并行度的设置，State的设置，checkpoint的设置。
- Flink如何处理反压
Flink内部是消费者模型来传递消息的，FLink的反压设计也是这个模型，只要下游不消费，上游就不会继续进行。
- 如何排查生产环境中的反压问题
可以根据Flink Web UI进行排查，jobManager会进行计算反压的比例
比如如果是 0到0.1之间，说明状态良好
如果状态是0.1到0.5说明有点问题，如果是到0.5之上，则是表示需要进行相关处理了。
那么造成反压的问题可能是checkpoint的频率过高，或者存在数据倾斜，或者GC的设置不合理。
- Flink的状态存储
如果需要存储中间状态，Flink提供了不同的存储方式，MemoryStateBackend
FsStateBackend，RocksDBStateBackend
- 什么是算子链
就是将子算子，尽可能的放在一个线程中执行，这样能够减少数据交换时的占用。
- Flink中的数据倾斜问题
首先是出现的可能原因，比如北京的数据是远高于其他的城市的
或者是本身的代码书写有问题
针对这种数据倾斜的问题，我们可以进行数据更细粒度的拆分，也可以考虑进行预先聚合
- Flink中涉及的Time
主要有三种，分别是Eventtime， Ingestion Time，ProcessTime
分别对应着不同的含义，至于在处理的时候采用哪个处理时间机制，则可以根据实际业务来看。
- Flink中的迟到数据
利用其中的watermark机制可以解决乱序的问题，利用一个最晚到达时间来控制水位最晚达到时间。
- Flink中的CEP 简述下
可以理解为一个状态机，只有满足了这个状态变化，才会输出对应的数据。
基本流程为，定义数据流，定义规则，应用，得到结果
对于其中中间态的数据，则是保存到内存的一个Map结构中。
- Flink如何设置并行度
算子层面可以
SetParallelism(10)
执行层面可以通过提交jar包的时候的-p参数修改并行度
客户端的层面可以设置环境变量
Env.setParallelism(10)
全局层面
Parallelism.default设置，默认为1，可以设置的默认值更大一些。
- Task之间的数据交换
这是交给TaskManager负责的，首先从缓存buffer中收集records，然后再发送。
- Flink的序列化
在Flink中，自己提供了一套序列化方法
支持的种类主要有：
BasicTypeInfo：支持最基本的Java类型，以及String
BasicArrayTypeInfo： 任意Java基本类型的数组 以及String
WritableTypeInfo：任意Hadoop Writable的接口
TupleTypeInfo，自己实现了一个元祖类型
PojoTypeInfo，任意POJO类，实现了getter和setter方法
- Flink如何实现去重
基于状态后段，或者基于布隆过滤器，或者基于BitMap
- 了解Flink SQL吗，如何实现的？
和Spark SQL类似，构建抽象语法树，然后转换为逻辑执行计划和物理执行计划，最后分发到TaskManager中进行运行。