问题： 为什么使用 Flink 替代 Spark？
解答：主要考虑的是 flink 的低延迟、高吞吐量和对流式数据应用场景更好的支持； 另外， flink 可以很好地处理乱序数据， 而且可以保证 exactly-once 的状态一致性。详见文档第一章， 有 Flink 和 Spark 的详细对比。
问题： Flink 的 checkpoint 存在哪里？
解答： 可以是内存， 文件系统， 或者 RocksDB。
问题： 如果下级存储不支持事务， Flink 怎么保证 exactly-once？
解答： 端到端的 exactly-once 对 sink 要求比较高， 具体实现主要有幂等写入和事务性写入两种方式。幂等写入的场景依赖于业务逻辑， 更常见的是用事务性写入。而事务性写入又有预写日志（ WAL） 和两阶段提交（ 2PC） 两种方式。
如果外部系统不支持事务， 那么可以用预写日志的方式， 把结果数据先当成状态保存， 然后在收到 checkpoint 完成的通知时， 一次性写入 sink 系统。
问题： 说一下 Flink 状态机制？
解答：Flink 内置的很多算子， 包括源 source，数据存储 sink 都是有状态的。在Flink 中， 状态始终与特定算子相关联。Flink 会以 checkpoint 的形式对各个任务的状态进行快照， 用于保证故障恢复时的状态一致性。Flink 通过状态后端来管理状态和 checkpoint 的存储， 状态后端可以有不同的配置选择。
问题： Flink 的 checkpoint 机制对比 spark 有什么不同和优势？
解答： spark streaming 的 checkpoint 仅仅是针对 driver 的故障恢复做了数据和元数据的 checkpoint。而 flink 的 checkpoint 机制 要复杂了很多， 它采用的是轻量级的分布式快照， 实现了每个算子的快照， 及流动中的数据的快照。
问题： 请详细解释一下 Flink 的 Watermark 机制。
解答： Watermark 本质是 Flink 中衡量 EventTime 进展的一个机制， 主要用来处理乱序数据。
问题： Flink 中 exactly-once 语义是如何实现的， 状态是如何存储的？
解答： Flink 依靠 checkpoint 机制来实现 exactly-once 语义， 如果要实现端到端的 exactly-once， 还需要外部 source 和 sink 满足一定的条件。状态的存储通过状态后端来管理， Flink 中可以配置不同的状态后端。
问题： Flink CEP 编程中当状态没有到达的时候会将数据保存在哪里？
解答： 在流式处理中， CEP 当然是要支持 EventTime 的， 那么相对应的也要支持数据的迟到现象， 也就是 watermark 的处理逻辑。CEP 对未匹配成功的事件序列的处理， 和迟到数据是类似的。在 Flink CEP 的处理逻辑中， 状态没有满足的和迟到的数据， 都会存储在一个 Map 数据结构中， 也就是说， 如果我们限定判断事件序列的时长为 5 分钟， 那么内存中就会存储 5 分钟的数据， 这在我看来， 也是对内存的极大损伤之一。
问题： Flink 三种时间语义是什么， 分别说出应用场景？
解答：
1.Event Time： 这是实际应用最常见的时间语义。
2.Processing Time： 没有事件时间的情况下， 或者对实时性要求超高的情况下。
3.Ingestion Time： 存在多个 Source Operator 的情况下， 每个 Source Operator 可以使用自己本地系统时钟指派 Ingestion Time。后续基于时间相关的各种操作， 都会使用数据记录中的 Ingestion Time。
问题： Flink 程序在面对数据高峰期时如何处理？
解答： 使用大容量的 Kafka 把数据先放到消息队列里面作为数据源， 再使用Flink 进行消费， 不过这样会影响到一点实时性。
问题： 怎么去重？ 考虑一个实时场景： 双十一场景， 滑动窗口长度为 1 小时， 滑动距离为 10 秒钟， 亿级用户， 怎样计算 UV？
解答： 使用类似于 scala 的 set 数据结构或者 redis 的 set 显然是不行的， 因为可能有上亿个 Key，内存放不下。所以可以考虑使用布隆过滤器（Bloom Filter） 来去重。
问题： 公司怎么提交的实时任务， 有多少 Job Manager？
解答：
- 我们使用 yarn session 模式提交任务。每次提交都会创建一个新的Flink 集群， 为每一个 job 提供一个 yarn-session， 任务之间互相独立， 互不影响， 方便管理。任务执行完成之后创建的集群也会消失。线上命令脚本如下：
bin/yarn-session.sh -n 7 -s 8 -jm 3072 -tm 32768 -qu root.. -nm - -d
其中申请 7 个 taskManager，每个 8 核，每个 taskmanager 有 32768M 内存。
2.集群默认只有一个 Job Manager。但为了防止单点故障，我们配置了高可用。我们公司一般配置一个主 Job Manager， 两个备用 Job Manager， 然后结合ZooKeeper 的使用， 来达到高可用。
