flink 学习备忘录-面试重点问题（1）

flink怎样解决乱序问题?

使用事件时间+水位线+窗口
通过watermark对数据重排序,来保证整体数据流的有序性
每当我们每接收到一份数据到buffer中时,我们选定其中最新的watermark值,对buffer里数据的时间小于此watermark值的数据在buffer中做一个排序.然后将此排序好的数据发向下游,因为是排好序的,所以窗口收到15:00的数据时,就知道不会有之前的数据在进来,所以水印可以作为触发计算的标识

流批系统的区别和各自优缺点?

1. 流系统的一大优势就是低延迟,批处理优势是错误恢复容易
2. 批处理任务在每次的批处理操作中都会保存住全部的输入数据,如果出现算错的情况,重新执行一次处理过程即可,没有failover机制
3. 而流式计算中连续不断的数据处理,使得错误恢复变得复杂,Flink的错误恢复机制依靠 CheckPoint来可以实现

某一刻任务执行失败,下一刻怎样完全恢复,重新回到失败的的时间点,任务接着跑?

A: Source的偏移量位置 offset
B: 当时已经进入flink的数据
C: 操作状态的数据
flink会通过定期做checkpoint来实现A B

Flink JobManager的HA(高可用)原理分析

1. Flink的JobManager的HA 跟HDFS的HA相比 不太一样,并不仅仅是主从切换
2. HDFS的HA切换,主要是为了保证数据请求处理的正常服务
3. Flink要让所有的失败任务能够快速回复,即:一个是存储系统的HA实现 一个是计算框架的HA实现
   Flink的JobManager在服务发生切换时(出现故障)要及时的通知外界事物:

• JobManager管理的多个TaskManager
• 在运行的所有Job
• 在请求的JobClient客户端
  这些TaskManager,Job,JobClient收到新的leader信息,能够主动重连新的JobManager地址
  源码调用过程:
  Flink内部定义2类服务做HA时的领导选举和消息通知:
  LeaderElectionService
• LeaderRetrievalService 监听端口
• LeaderRetrievalListener监听接口
  在LeaderElectionService服务的实现中,是采用Apache Curator框架中的LeaderLatch来做领导选举的
  新的leader选出来以后,LeaderRetrievalService服务会第一时间得到通知,然后提取出新的leader地址
  然后通知监听接口LeaderRetrievalListener,通知jobclient job taskmanager

flink与storm对比怎么样？为什么要从storm迁移到flink上？

开发更简单,提供了精确一次的语义,计算更精确

flink与spark对比

Spark 和 Flink 都是通用的能够支持超大规模数据处理，支持各种处理类型的计算引擎。两个系统都有很多值得探讨的方面在这里没有触及，比如 SQL 的优化，和机器学习的集成等等。这里主要是试图从最基本的架构和设计方面来比较一下两个系统。因为上层的功能在一定程度上是可以互相借鉴的，有足够的投入应该都能做好。而基本的设计改变起来会伤筋动骨，更困难一些。
Spark 和 Flink 的不同执行模型带来的最大的区别应该还是在对流计算的支持上。最开始的 Spark Streaming 对流计算想得过于简单，对复杂一点的计算用起来会有不少问题。从 Spark 2.0 开始引入的 Structured Streaming 重新整理了流计算的语义，支持按事件时间处理和端到端的一致性。虽然在功能上还有不少限制，比之前已经有了长足的进步。不过 micro batch 执行方式带来的问题还是存在，特别在规模上去以后性能问题会比较突出。最近 Spark 受一些应用场景的推动，也开始开发持续执行模式。2.3里的实验性发布还只支持简单的 map 类的操作。从最近 Spark+AI Summit 大会上的介绍来看（下图），会发展成一个和 Flink 的流处理模式比较相似的执行引擎。不过从下图来看，主要的功能都还在开发中或者待开发。对将来能做到什么程度，和 Spark 原来的 batch 执行引擎怎么结合

引用
flink面试题
spark与flink对比