Flink 精确一次语义（EOS） 的保障，两阶段提交
准备阶段协调者向参与者发送预提交，参与者记录当前日志用于回滚和重放，实际提交时协调者向参与这发送提交请求，参与者真实提交数据，若参与者提交成功，则发送ack到协调者，协调者收到所有参与者的ack事务完成，否则向所有参与者发送回滚请求，按照之前记录的状态完成回滚并返回ack.
此外，flink精确一次需要kafka精确一次语义支持
说说 Flink 的常用算子？
Flink 最常用的常用算子包括：Map：DataStream → DataStream，输入一个参数产生一个参数，map 的功能是对输入的参数进行转换操作。Filter：过滤掉指定条件的数据。KeyBy：按照指定的 key 进行分组。Reduce：用来进行结果汇总合并。Window：窗口函数，根据某些特性将每个 key 的数据进行分组（例如：在 5s 内到达的数据）
flink某个任务卡住了怎么处理
Flink 中在使用聚合函数 GroupBy、Distinct、KeyBy 等函数时出现数据热点该如何解决？
数据倾斜和数据热点是所有大数据框架绕不过去的问题。处理这类问题主要从 3 个方面入手：
Key 的设计上
把热 key 进行拆分，先聚合热key，再二次聚合
参数设置
Flink 1.9.0 SQL(Blink Planner) 性能优化中一项重要的改进就是升级了微批模型，即
MiniBatch。原理是缓存一定的数据后再触发处理，以减少对 State 的访问，从而提升吞吐和减少数据的输出量。
hive调优
Flink 任务延迟高，想解决这个问题，你会如何入手？
在 Flink 的后台任务管理中，我们可以看到 Flink 的哪个算子和 task 出现了反压（网络流控）。最主要的手段是资源调优和算子调优。资源调优即是对作业中的 Operator 的并发数（parallelism）、CPU（core）、堆内存（heap_memory）等参数进行调优。作业参数调优包括：并行度的设置，State 的设置，checkpoint 的设置。
Flink 有没有重启策略？说说有哪几种？
Flink 实现了多种重启策略。
固定延迟重启策略（Fixed Delay Restart Strategy）：固定延迟重启策略是尝试给定次数重新启动作业。如果超过最大尝试次数，则作业失败。在两次连续重启尝试之间，会有一个固定的延迟等待时间。
故障率重启策略（Failure Rate Restart Strategy）：故障率重启策略在故障后重新作业，当设置的故障率（failure rate）超过每个时间间隔的故障时，作业最终失败。在两次连续重启尝试之间，重启策略延迟等待一段时间。
没有重启策略（No Restart Strategy） ：作业直接失败，不尝试重启。
后备重启策略（Fallback Restart Strategy） ：使用群集定义的重新启动策略。这对于启用检查点的流式传输程序很有帮助。
默认情况下，如果没有定义其他重启策略，则选择固定延迟重启策略。
sql笔试：连续三天登录的用户
思路：三次自联结查询即可
select a.username
from logtable a,logtable b,logtable c
where a.time=b.time + 1 and b.time=c.time+1
and a.action='loging' and b.action='loging' and c.action='loging'
and a.usernaem=b.username and a.username=c.username
select a.username from logtable a,logtable b,logtable c where a.time=b.time + 1 and b.time=c.time+1 and a.action='loging' and b.action='loging' and c.action='loging' and a.usernaem=b.username and a.username=c.username
Flink 中水印是什么概念，起到什么作用？
Watermark 是 Apache Flink 为了处理 EventTime 窗口计算提出的一种机制, 本质上是一种时间戳。 一般来讲 Watermark 经常和 Window 一起被用来处理乱序事件。
Flink 是如何保证 Exactly-once 语义的？
Checkpoint机制加两阶段提交
Flink 通过实现两阶段提交和状态保存来实现端到端的一致性语义。 分为以下几个步骤：
开始事务（beginTransaction）创建一个临时文件夹，来写把数据写入到这个文件夹里面
预提交（preCommit）将内存中缓存的数据写入创建的临时文件并关闭
正式提交（commit）将之前写完的临时文件放入目标目录下。这代表着最终的数据会有一些延迟
丢弃（abort）丢弃临时文件
若失败发生在预提交成功后，正式提交前。可以根据状态来提交预提交的数据，也可删除预提交的数据。
Flink 计算资源的调度是如何实现的？
TaskManager 中最细粒度的资源是 Task slot，代表了一个固定大小的资源子集，每个TaskManager 会将其所占有的资源平分给它的 slot。
通过调整 task slot 的数量，用户可以定义 task 之间是如何相互隔离的。每个 TaskManager 有一个 slot，也就意味着每个 task 运行在独立的 JVM 中。每个 TaskManager 有多个 slot 的话，也就是说多个 task 运行在同一个 JVM 中。
而在同一个 JVM 进程中的 task，可以共享 TCP 连接（基于多路复用）和心跳消息，可以减少数据的网络传输，也能共享一些数据结构，一定程度上减少了每个 task 的消耗。 每个 slot 可以接受单个 task，也可以接受多个连续 task 组成的 pipeline，如下图所示，FlatMap 函数占用一个 taskslot，而 key Agg 函数和 sink 函数共用一个 taskslot：
Flink 分布式快照的原理是什么？
Flink 的分布式快照是根据 Chandy-Lamport 算法量身定做的。简单来说就是持续创建分布式数据流及其状态的一致快照。 核心思想是在 input source 端插入 barrier，控制 barrier 的同步来实现 snapshot 的备份和 exactly-once 语义。
