大数据面试题--Flink基础篇
谈一谈对Flink的理解和认识？
Flink是一个纯粹的流处理框架，所有的算子操作都是有状态的。Flink提供强大的状态管理、完备的窗口计算等策略。相比较于其他流处理框架而言，Flink具有高吞吐和低延迟的优势，能够基于Event-Time实现窗口状态计算，同时也支持对延迟数据的处理。
Flink这款框架在架构的设计上和Spark的宏观架构非常相似，在资源管理上底层可以使用standalone、yarn、Mesos (Apache下的开源分布式资源管理框架) 等资源管理器，对于HDFS、HBase等存储系统也是完全兼容。
Flink和Spark的最大区别在于底层计算引擎的实现方式，Spark底层使用RDD批处理模型实现所有计算，而Flink底层计算引擎使用流处理模型实现所有计算，因此，Spark在批处理引擎构建的流处理存在延迟高的问题，而Flink在流处理之上封装了DataStream/DataSet API分别用来实现流处理和批处理，在DataStream/DataSet API之上同样也提供了Table API，这类似Spark DStream、Structured Streaming的功能，除此之外，Flink在DataSet API里也提供了Flink ML(Flink的机器学习（ML）库)、Gelly API，这类似Spark提供的Spark ML和GraphX等组件。
Flink比较擅长流处理–高吞吐、低延迟
Spark比较擅长批处理–高性能、高延迟
介绍一下Flink的计算流程？
在Flink这款计算框架中，Client负责计算程序的DataFlow Graph(数据流图，可以理解为一种执行计划)，将计算好的DataFlow Graph提交给JobManager，然后JobManager根据任务中的最大并行度，给该任务分配计算资源Task Slot，JobManager根据DataFlow Graph描述的Task(Stage)，将Task根据并行度转换为SubTask，然后将SubTask任务提交给相应的Task Manager进行执行。在整个计算过程中由JobManager负责任务调度、检查点协调。
解释以下什么是Client、JobManager、TaskManager、Task、SubTask、Task Slot以及与Spark区别？
- Client：类似Driver，但是不负责任务调度，Client负责计算DataFlow Graph。
- JobManager：类似ClusterManager，但是它除了分配资源以外，还需要负责任务调度、检查点协调。
- TaskManager：真正执行任务的节点，负责运行SubTask。
- Task：Flink通过Operator Chain将若干个算子归到一个Task中，等价于Spark中的Stage。
- SubTask：每一个Task都有并行度，SubTask就是根据Task并行度创建的一组线程，等价于Spark中的Taskset
- TaskSlot：任务槽，Flink通过Task Slot对TaskManager内存进行均分，每一个Task Slot只能分配给一个Job，但是一个Task Slot可以执行同一个Job的不同Task的SubTask任务，类似于Spark Core。
GlobalPartitioner、ShufflePartitioner、RebalancePartitioner、RescalePartitioner、BroadcastPartitioner、ForwardPartitioner、KeyGroupStreamPartitioner
- GlobalPartitioner
上游的数据全部发送给下游实例的第一分区 - ShufflePartitioner
将上游任务的数据随机发送给下游的一个分区 - RebalancePartitioner
将上游分区的数据分别以轮询的方式发送给下游分区 - RescalePartitioner
基于上下游Operator的并行度，将记录以循环的方式输出到下游Operator的每个实例。
举例：上游并行度是2，下游是4，则上游一个并行度以循环的方式将记录输出到下游的两个并行度上；上游另一个并行度以循环的方式将记录输出到下游的一个并行度上。若上游并行度是4，下游并行度是2，则上游两个并行度将记录输出到下游一个并行度上；上游另两个并行度将记录输出到下游另一个并行度上。 - BroadcastPartitioner
上游所有分区数据广播给下游任务的每一个分区。 - ForwardPartitioner
要求上下游分区数目必须一致，实现one to one形式的数据发送。 - KeyGroupStreamPartitioner
基于Key的hash，保证相同的key发送给下游的同一个分区。
Flink支持哪几种重启策略？分别如何配置？
- 固定延迟重启策略(Fixed Delay Restart Strategy)
固定延迟重启策略会尝试一个给定的次数来重启Job，如果超过了最大的重启次数，Job最终将失败。在连续的两次重启尝试之间，重启策略会等待一个固定的时间。 - 失败率重启策略(Failure Rate Restart Strategy)
失败率重启策略在Job失败后会重启，但是超过失败率后，Job会最终被认定失败。在两个连续的重启尝试之间，重启策略会等待一个固定的时间。 - 无重启策略(No Restart Strategy)
Job直接失败，不会尝试进行重启。 - 后背重启策略(Fallback Restart Strategy)
使用群集定义的重新启动策略。这对于启用检查点的流式传输程序很有帮助。默认情况下，如果没有定义其他重启策略，则选择固定延迟重启策略。
可以通过配置flink-conf.ymal
restart-strategy: failure-rate
restart-strategy.failure-rate.max-failures-per-interval: 3
restart-strategy.failure-rate.failure-rate-interval: 5 min
restart-strategy.failure-rate.delay: 10s
或者
val env = ExecutionEnvironment.getExecutionEnvironment()
env.setRestartStrategy(RestartStrategies.failureRateRestart(
3, // max failures per unit
Time.of(5, TimeUnit.MINUTES), //time interval for measuring failure rate
Time.of(10, TimeUnit.SECONDS) // delay
))
请问重启策略和故障恢复策略有何区别？
重启策略规定是否以及什么时间启动故障恢复策略；而故障恢复策略描绘的是如何恢复。故障恢复一般通过在flink-conf.ymal文件中进行如下配置：
jobmanager.execution.failover-strategy: all|region
Flink的分布式缓存有什么作用？如何使用？
Flink中的分布式缓存等价于Spark中的广播变量，系统会在计算之前将文件分发给所有TaskManager节点，后续所有的算子在使用的时候可以直接从TaskManager节点获取。
fsEnv.registerCachedFile("hdfs:///xxx.xxxx","jdbcCon")
实现RichFunction接口，核心代码如下：
val cache = getRuntimeContext.getDistributedCache
val jdbcConFile = cache.getFile("jdbcCon")
Flink中的广播变量在使用时需要注意什么事项？
这是用在批处理模型中的一种手段，等价于Spark中的广播变量。
val bEnv = ExecutionEnvironment.getExecutionEnvironment
val broad = bEnv.fromElements(1,2,3,4)
bEnv.fromElements("a b c")
.flatMap(_.split(" "))
.map(new RichMapFunction[String,(String,Int)] {
override def map(value: String): (String, Int) = {
val list = getRuntimeContext.getBroadcastVariable("nums")
println(list)
(value,0)
}
}).withBroadcastSet(broad,"nums")
.print()
Flink的窗口分类有哪些？什么是Trigger & Evictor？
滑动、滚动、会话、Global，其中Trigger用于指定窗口触发的时机，Evictor用于剔除窗口的元素。
Flink支持的时间类型有哪些？请各自介绍一下？
- Event Time(事件时间)
事件时间是每个独立事件在产生它的设备上发生的时间，这个时间在事件进入Flink之前就已经嵌入到事件中，时间顺序取决于事件产生的地方，和下游数据处理系统的时间无关。 - Ingestion Time(接入时间)
接入时间是数据进入Flink系统的时间，接入时间依赖于Source Operator所在主机的系统时钟，因为接入时间在数据接入过程生成后，时间戳不再发生变化，和后续处理数据的Operator所在主机的时钟没有关系，所以不会因为某台机器时钟不同步或者网络延迟而导致计算结果不准确的问题。相比于Event Time，Ingestion Time不能处理乱序时间，因此不用生成对应的水印。 - Processing Time(处理时间)
处理时间是指数据在操作算子计算过程中获取到的主机系统时间。当用户选择使用Processing Time时，所有和时间相关的计算算子，例如window计算，在当前的任务中所有算子将直接使用其所在主机的系统时间。基于Processing Time时间概念，Flink程序的性能相对较高，延迟也比较低，对接入到系统中的数据时间相关的计算完全交给算子内部决定，虽然在性能和易用性上有优势，但是 在处理乱序数据时，Processing Time不是最优选择，数据本身不乱序，如果每台机器的时钟不同步也会导致数据在处理过程中出现乱序，Processing Time适用于时间计算精度不是特别高的计算场景。Flink在默认情况下使用Processing Time，如果想用其他时间类型，则在创建StreamExecutionEnvironment时调用下面这个方
法：setStreamTimeCharacteristic()设置时间类型。
WaterMark指的是什么？可以用来解决什么问题？如何生成水印？水印的原理是什么？
- watermark指的是水位线（水印）。
- watermark用于处理乱序事件，而正确地处理乱序事件，通常需要watermark机制结合window来实现。
- watermark = max(Event Time)(流计算引擎所能获取到的最大事件时间) - Late Time(允许延迟的时间)。
- watermark是一种衡量Event Time进展的机制，它是数据本身的一个隐藏属性，通常基于Event Time的数据，自身都包含一个timestamp.watermark用于处理乱序事件，要想正确地处理乱序事件，通常 需要结合window来实现。由于流处理从事件产生到最终被处理，中间有一个过程和时间，大部分 数据都能按照事件产生地时间到达，但是也不排除由于网络、背压等原因导致乱序的产生，对 此，我们不能无限期等待，必须要有个机制来保证一个特定的时间后触发窗口计算，此时watermark便发挥作用了，它表示当watermark没过窗口后，watermark之前的数据已经全部抵达（即使后面还有延迟的数据）。
Flink的容错机制是什么？
Flink基于分布式快照与可部分重发的数据源实现容错，用户可以自定义对整个Job进行快照的时间间隔，当任务失败时，Flink会将整个Job作业恢复到最近一次快照，并从数据源重发快照之后的数据。
Checkpoint和Savepoint区别？
从概念上来说，Flink的Checkpoint和Savepoint的不同之处在于备份与传统数据库系统中的恢复日志不 同，Checkpoint的主要目的是在作业的意外失败时提供恢复机制，它的生命周期由Flink来管理，即Flink创建、拥有和发布Checkpoint，无用户交互。作为一种恢复和定期触发的方法，Checkpoint实现 的两个主要设计目标是轻量级和快速恢复，针对这些目标的优化可以利用某些属性，例如，Job Code在执行尝试期间不会改变。与此相反，Savepoint由用户创建、拥有和删除，Savepoint必须在终止作业后继续存在，它的生成和恢复成本较高，并且更多地关注可移植性和对前面提交作业更改的支持。
Flink Kafka如何保证精准一次的语义操作？
- 一旦所有的Operator操作完成各自的pre-commit，它们会发起一个commit，如果有一个pre-commit失败，所有其他的pre-commit必须终止，并且Flink会回滚到最近成功完成的checkpoint。
- 一旦pre-commit阶段完成，必须确保commit阶段也要成功（Operator和外部系统都要对此进行保 证），倘若commit阶段失败，Flink就会崩溃，然后会根据用户重启策略执行重启逻辑，之后再次 重试commit，这个过程至关重要，如果commit无法顺利执行，就可能出现数据丢失的情况，因此，所有Operator操作必须对checkpoint的最终结果达成共识，即所有Operator操作都必须认定数据提交要么成功执行，要么被终止后回滚。