1.你的项目中是如何提交实时任务的，有多少个JobManager

1. 我们使用yarn session模式提交任务。每次提交都会创建一个新的 Flink 集群，为每一个 job 提供一个 yarn-session，任务之间互相独立，互不影响，方便管理。任务执行完成之后创建的集群也会消失。
2. 集群默认只有一个 Job Manager。但为了防止单点故障，我们配置了高可用。 一般配置一个主 Job Manager，两个备用 Job Manager，然后结合 ZooKeeper 的使用，来达到高可用。

2.你是怎么做压力测试和监控的

• 如果产生数据流的速度如果过快，而下游的算子消费不过来的话，会产生背压。
• 背压的监控可以使用 Flink Web UI来可视化监控，一旦报警就能知道。一般情况下背压问题的产生可能是由于 sink 这个操作符没有优化好，做一下优化即可。我们的优化有如下几种方式：设置 watermark 的最大延迟时间这个参数，如果设置的过大，可能会造成内存的压力。可以设置最大延迟时间小一些，然后把迟到元素发送到侧输出流中去。 晚一点更新结果。或者使用类似于 RocksDB 这样的状态后端， RocksDB 会开辟堆外存储空间，但 IO 速度会变慢，需要权衡。滑动窗口的长度如果过长，而滑动距离很短的话，Flink 的性能会下降的很厉害。我们主要通过时间分片的方法，将每个元素只存入一个重叠窗口，这样就可以减少窗口处理中状态的写入。状态后端使用RocksDB，保证不会被击穿。

3.项目中为什么用Flink，不用Spark

• 主要考虑的是Flink的低延迟、高吞吐量和对流式数据应用场景更好的支持；另外，Flink可以很好地处理乱序数据，而且可以保证 exactly-once 的状态一致性。

4.如果下级存储不支持事务，Flink如何保证精准一次性

• 端到端的exactly-once对sink要求比较高，具体实现主要有幂等写入和事务性写入两种方式。其中幂等写入的场景依赖于业务逻辑，更常见的是用事务性写入。 而事务性写入又有预写日志（WAL）和两阶段提交（2PC）两种方式。如果外部系统不支持事务，那么可以用预写日志的方式，把结果数据先当成状态保存，然后在收到 checkpoint 完成的通知时，一次性写入sink系统。

5.双十一场景，滑动窗口长度为0.5小时， 滑动距离为5秒钟，亿级用户，怎样计算 UV

• 首当其冲就是布隆过滤器（Bloom Filter）
• 布隆过滤器本质上是一个二进制数组，元素的值不是1就是0。当我们存一个用户id为10的用户，假设我们经过三次哈希，存的数组下标为1，3，7，就将这三个下标的元素改为1。这样每次访问redis之前，先访问布隆过滤器。查询id为10的用户时，经过布隆过滤器的哈希算法，获取到该用户对应的下标是1，3，7。那么，如果这三个数组的下标对应的元素都为1，则表示存在该用户，放行这次请求。如果有一个为0，则不存在该用户。

6.Flink CEP 编程中当状态没有到达的时候会将数据保存在哪里

• 在流式处理中，CEP 当然是要支持 EventTime 的，那么相对应的也要支持数据的迟到现象，也就是 watermark 的处理逻辑。CEP 对未匹配成功的事件序列的处理，和迟到数据是类似的。在 Flink CEP 的处理逻辑中，状态没有满足的和迟到的数据，都会存储在一个Map数据结构中，也就是说，如果我们限定判断事件序列的时长为3分钟，那么内存中就会存储3分钟的数据。

7.Flink 程序在面对数据高峰期时如何处理

• 使用大容量的Kafka把数据先放到消息队列里面作为数据源，再使用Flink进行消费

8.实时数仓怎么分层设计才能兼顾时效性和通用性？

• 如果数据量不大，建立实时数仓只构建 ods -> dwd 就足够使用。ods -> dwd 是为了字段标准化，通用化，然后后面把 dwd 层导入到 OLAP 中进行查询使用；或者建立 ads 层，ads 层直接消费 dwd，这样时效性也可以得到保障。
• 如果数据量大，可以尝试进行 dws 聚合，聚合之后根据数据量（流量）缩减的实际效果来评估是否需要建立此 dws。

9.你一般是将实时数据存储到哪里提供对外服务？有没有标准的数据服务方式？

• 举个例子，电商场景中实时计算商家的用户UV数据，这个数据服务的整体链路由实时数仓到后端再到前端。其中实时数仓就是数据的提供方，后端就是数据的使用方，前端就是数据的展示方。
• 后端作为数据的使用方来说，后端期望的能达到的最好的数据服务方式就是实时数仓能提供一个接口给我，仅需要把商家ID作为入参，这个接口就能把商家的实时用户UV数据返回给后端。

10.介绍下 Flink 中的状态机制

Flink中的状态机制主要是指 Flink 应用程序中的状态管理机制。在 Flink 中，状态是指 Flink 作业中可以被访问和修改的数据。Flink 支持多种类型的状态，例如键控状态、操作符状态、窗口状态等。状态可以存储在内存、堆外内存或分布式文件系统中，可以通过 Checkpoint 和 Savepoint 进行快照和恢复。

Flink 的状态机制主要解决以下两个问题：

1. 状态一致性问题：由于 Flink 应用程序通常需要并发处理大量的数据，因此需要对状态进行并发访问和修改。此时必须保证状态的一致性，避免出现数据不一致等问题。Flink 通过分布式锁和分布式算法来实现状态一致性，保证在并发场景下状态的正确性。
2. 状态快照和恢复问题：为了保证 Flink 应用程序的可靠性和容错性，Flink 采用了 Checkpoint 和 Savepoint 机制对作业的状态进行快照和恢复。Checkpoint 是周期性地将作业状态快照写入分布式存储系统中，以便在程序失败或者非正常关闭时能够恢复程序状态。Savepoint 则是手动触发的状态快照，可以用于停止并重新启动应用程序或将应用程序迁移到新的集群中。