flink的面试题和答案_flink选择题

1、Flink如何保证精确一次性消费
Flink 保证精确一次性消费主要依赖于两种Flink机制

1、Checkpoint机制

2、二阶段提交机制

Checkpoint机制 主要是当Flink开启Checkpoint的时候，会往Source端插入一条barrir，然后这个barrir随着数据流向一直流动，当流入到一个算子的时候，这个算子就开始制作checkpoint，制作的是从barrir来到之前的时候当前算子的状态，将状态写入状态后端当中。然后将barrir往下流动，当流动到keyby 或者shuffle算子的时候，例如当一个算子的数据，依赖于多个流的时候，这个时候会有barrir对齐，也就是当所有的barrir都来到这个算子的时候进行制作checkpoint，依次进行流动，当流动到sink算子的时候，并且sink算子也制作完成checkpoint会向jobmanager 报告 checkpoint n 制作完成。

二阶段提交机制 Flink 提供了CheckpointedFunction与CheckpointListener这样两个接口，CheckpointedFunction中有snapshotState方法，每次checkpoint触发执行方法，通常会将缓存数据放入状态中，可以理解为一个hook，这个方法里面可以实现预提交，CheckpointListyener中有notifyCheckpointComplete方法，checkpoint完成之后的通知方法，这里可以做一些额外的操作。例如FLinkKafkaConumerBase使用这个来完成Kafka offset的提交，在这个方法里面可以实现提交操作。在2PC中提到如果对应流程例如某个checkpoint失败的话，那么checkpoint就会回滚，不会影响数据一致性，那么如果在通知checkpoint成功的之后失败了，那么就会在initalizeSate方法中完成事务的提交，这样可以保证数据的一致性。最主要是根据checkpoint的状态文件来判断的。

2、flink和spark区别
flink是一个类似spark的“开源技术栈”，因为它也提供了批处理，流式计算，图计算，交互式查询，机器学习等。flink也是内存计算，比较类似spark，但是不一样的是，spark的计算模型基于RDD，将流式计算看成是特殊的批处理，他的DStream其实还是RDD。而flink吧批处理当成是特殊的流式计算，但是批处理和流式计算的层的引擎是两个，抽象了DataSet和DataStream。flink在性能上也表现的很好，流式计算延迟比spark少，能做到真正的流式计算，而spark只能是准流式计算。而且在批处理上，当迭代次数变多，flink的速度比spark还要快，所以如果flink早一点出来，或许比现在的Spark更火。

3、Flink的状态可以用来做什么？

Flink的状态可以用来保存中间计算结果或者缓存数据，是实现有状态的计算下Exactly-Once的基础。具体用途包括：

1. 窗口计算：例如天/小时/分钟窗口计算，需要保存窗口内计算所需的每个事件的信息或累积信息。
2. 机器学习：可以使用状态保存当天版本模型参数信息。
3. 历史数据对比：需要记录历史上某一段时间的数据。
4. 数据恢复：主要用于Flink的容错机制。
5. 有状态的操作：如聚合、窗口等算子中内置的状态，托管状态由Flink的运行时（Runtime）来托管的，状态的存储访问、故障恢复和重组等一系列问题都由Flink实现，只需调接口就可以；而原始状态则需要自定义，相当于开辟了一块内存，需要自己管理，实现状态的序列化和故障恢复。

4、Flink的waterMark机制，Flink watermark传递机制

Flink的Watermark机制是为了解决乱序、延迟数据等情况的解决方案，通常和窗口结合使用。Watermark本质上是一个单调递增的时间戳，用来衡量事件时间的进度并控制等待延迟数据的最大时长。当Watermark值大于或等于窗口结束时间时，触发窗口计算。

Watermark的传递在每个并行处理的线程中会一直向下游传递，在并行度不一致的两个处理过程传递Watermark时，会采用广播的方式传递当前Watermark，即上游的Watermark会发送到多个下游处理过程中。

具体来说，Watermark机制通过用户决定等待延迟数据多久后触发计算，来避免无限期等待所有延迟数据到来后才触发窗口计算的情况。同时，Watermark可以触发窗口计算，时间戳为Long.MAX_VALUE表示算子后续没有任何数据。

5、Flink的时间语义

Flink的时间语义主要分为三种：事件时间（Event Time）、处理时间（Process Time）和水位线（Watermark）。

1. 事件时间：事件时间是指数据中的时间戳，通常由事件本身携带的时间信息来确定。在事件时间语义下，Flink会按照事件时间戳的顺序处理数据，并允许数据在处理过程中存在延迟。为了处理乱序事件和延迟数据，Flink引入了水位线机制，通过Watermark来跟踪时间的进度，并控制等待延迟数据的最大时长。
2. 处理时间：处理时间是指当前系统处理数据的时间。在处理时间语义下，Flink将数据按照当前系统时间进行排序处理，不考虑数据中携带的时间戳信息。处理时间语义简单易懂，但是容易受到系统负载和数据倾斜等因素的影响，导致数据处理的不一致性。
3. 水位线：水位线是Flink中用于解决乱序事件和延迟数据处理的一种机制。通过Watermark来生成水位线，可以控制窗口计算的触发时机，使得窗口计算能够正确处理乱序数据和延迟数据。当Watermark到达一个算子时，如果该算子中的所有事件时间戳都小于等于Watermark，那么就可以触发窗口计算。

综上所述，Flink的时间语义提供了多种选择，用户可以根据具体的使用场景选择合适的时间语义来进行数据处理和分析。在实际应用中，为了保证数据处理的正确性和一致性，建议使用事件时间语义和合理的水位线机制来处理乱序和延迟数据。

1. Ingestion time：这是事件进入Flink的时间，通常是指数据被捕获或接收的时间。在Ingestion时间语义下，Flink会按照事件进入的时间顺序进行处理，不会受到系统时间或数据处理速度的影响。因此，Ingestion时间语义可以保证数据的处理顺序和时间戳的准确性，适用于需要精确时间处理的场景，如实时监控、实时分析等。
2. Processing time：这是事件进入算子的时间，即数据处理开始的时间。在Processing时间语义下，Flink会按照当前系统时间对数据进行排序和处理。由于系统时间的不断变化和处理数据所需的时间可能存在延迟，因此Processing时间语义可能导致数据处理的乱序和延迟。这种时间语义相对简单易懂，但是可能不适合需要精确时间处理的场景，如实时金融交易等。

Event Time 事件产生的时间

Ingestion time 事件进入Flink的时间

processing time 事件进入算子的时间

6、Flink window join

Flink的窗口连接（Window Join）是一种基于时间窗口的连接操作，它允许将两个流数据按照指定的时间窗口进行连接。窗口连接可以应用于具有相同或不同key的流数据，通过时间窗口将两个流中的数据关联起来。

在Flink中，窗口连接可以分为两种类型：Tumbling Window Join和Sliding Window Join。

1. Tumbling Window Join：滚动窗口连接是一种固定大小的窗口连接，窗口不重叠且按照时间顺序滚动。在滚动窗口连接中，具有相同key的元素将在指定的时间窗口内进行连接。
2. Sliding Window Join：滑动窗口连接是一种可变大小的窗口连接，窗口之间存在重叠。滑动窗口连接中，具有相同key的元素将在指定的时间窗口内进行连接，且窗口可以按照指定的时间间隔进行滑动。

在Flink的窗口连接中，需要定义时间窗口和KeySelector，以便将两个流中的数据进行关联。然后，可以使用JoinFunction或FlatJoinFunction来定义如何处理连接后的数据。

需要注意的是，Flink的窗口连接操作需要保证数据的有序性，以避免因数据乱序导致的不正确的连接结果。因此，Flink提供了Watermark机制来跟踪时间进度，并控制等待延迟数据的最大时长。

1、window join，即按照指定的字段和滚动滑动窗口和会话窗口进行 inner join

2、是coGoup 其实就是left join 和 right join，

3、interval join 也就是 在窗口中进行join 有一些问题，因为有些数据是真的会后到的，时间还很长，那么这个时候就有了interval join但是必须要是事件时间，并且还要指定watermark和水位以及获取事件时间戳。并且要设置 偏移区间，因为join 也不能一直等的。

7、flink窗口函数有哪些

Flink的窗口函数主要包括以下几种：

1. 滚动窗口（Tumbling Windows）：滚动窗口是最常用的窗口类型之一。它们有固定的大小，并且不会重叠。例如，如果你指定了一个5分钟的滚动窗口，那么Flink将会为每5分钟的数据生成一个新的窗口，这些窗口之间不会存在任何重叠。
2. 滑动窗口（Sliding Windows）：滑动窗口是另一种常见的窗口类型。与滚动窗口不同，滑动窗口可以重叠。例如，如果你有一个10分钟的窗口，并且每5分钟滑动一次，那么Flink将会为第一个10分钟的数据生成一个窗口，然后为下一个5分钟到15分钟的数据生成另一个窗口，依此类推。
3. 会话窗口（Session Windows）：会话窗口是一种特殊的窗口类型，它们的大小不是固定的，而是根据数据中的会话活动来确定的。会话窗口在一段时间没有活动（即，没有新的事件）后会关闭。这个时间间隔被称为会话超时。
4. 全局窗口（Global Windows）：全局窗口分配器将所有的元素都分配到同一个全局窗口中。这个全局窗口的模式主要用于那些不需要窗口操作的作业，或者与自定义触发器一起使用来进行一些特殊的处理。

在Flink中，你可以使用window()方法来定义窗口，并通过调用tumble(), slide(), session()或global()方法来指定窗口类型。然后，你可以使用reduce(), fold(), apply()等函数来对每个窗口中的数据进行处理。

8、keyedProcessFunction 是如何工作的。假如是event time的话
keyedProcessFunction 是有一个ontime 操作的，假如是 event时间的时候 那么 调用的时间就是查看，event的watermark 是否大于 trigger time 的时间，如果大于则进行计算，不大于就等着，如果是kafka的话，那么默认是分区键最小的时间来进行触发。

KeyedProcessFunction 是 Flink 中的一个功能，它专门用于处理 KeyedStream。当有一个数据进入算子时，它会触发一次 processElement() 的处理。

在处理基于事件时间的数据流时，KeyedProcessFunction 可以提供计时器的功能。在某些特定场景下，这非常有用。例如，你有一个需求，需要获取用户在15分钟后未浏览商品页面的情况，并针对这些用户推送一些优惠商品。你可以使用 KeyedProcessFunction 来实现这个需求，通过设置计时器来检测用户的行为，并在适当的时候触发推送操作。

使用 KeyedProcessFunction 时，你需要实现三个主要的方法：

1. processElement(value, output, ctx)：此方法接收当前处理的数据项，一个输出对象和一个上下文对象。你可以在此方法中处理数据，并使用上下文对象中的计时器功能。
2. timerService()：此方法返回一个 TimerService 对象，你可以使用它来设置和清除计时器。
3. onTimer(timestamp, timeWindow, output, ctx)：此方法将在计时器触发时调用。你可以在此方法中执行你想要的操作，例如推送优惠商品。

在 KeyedProcessFunction 中处理事件时间数据流时，你需要确保数据的时间戳是准确的，并且数据流是按照时间顺序处理的。你可以通过为数据流设置 Watermark 来实现这一点。

请注意，具体实现可能会根据 Flink 的版本和你的需求有所不同，建议查阅 Flink 的官方文档或相关教程以获取更准确的信息和示例。

9、flink是怎么处理离线数据的例如和离线数据的关联？

Flink 提供了多种处理离线数据的方法，其中之一是使用 AsyncIO。这种方法允许在流处理中发出异步请求，等待响应并将结果与流数据进行关联。这种方法适用于对离线数据进行异步查询，例如通过 HTTP 请求或数据库查询。

对于与离线数据的关联，Flink 可以将流数据与离线数据进行连接，以便在流处理中利用离线数据。这可以通过使用 Flink 的连接操作（如 Join）来实现。连接操作允许将具有相同键的流数据和离线数据关联起来，以便在处理过程中利用离线数据。

另外，Flink 还提供了批处理功能，允许将数据分为批进行处理。通过使用 Flink 的批处理功能，可以处理大规模离线数据，并将其与流数据进行关联。这可以通过将批处理作业连接到 Flink 流处理作业来实现。

总的来说，Flink 提供了一些功能强大的工具和功能来处理离线数据，并允许将其与流数据进行关联。这些工具和功能可以根据具体的应用场景选择使用，以便更有效地处理离线数据。

1、async io

2、broadcast

3、async io + cache

4、open方法中读取，然后定时线程刷新，缓存更新是先删除，之后再来一条之后再负责写入缓存

10、flink支持的数据类型

Flink支持多种数据类型，包括：

1. 基础数据类型：Flink支持所有的Java和Scala基础数据类型，如Int、Double、Long、String等。
2. 元组类型：包括Java和Scala中的元组类型。
3. 样例类类型：例如Scala的样例类（case classes）。
4. Java简单对象类型：如POJOs（Plain Old Java Objects）。
5. 其他数据类型：包括Arrays、Lists、Maps、Enums等。
6. 特殊目的的类型：例如Java的ArrayList、HashMap、Enum等。

Flink使用类型信息的概念来表示数据类型，并为每个数据类型生成特定的序列化器、反序列化器和比较器。这些数据类型可以满足各种数据处理和分析的需求。

DataSet Api 和 DataStream Api、Table Api

Apache Flink 是一个流处理和批处理的开源框架，提供了高性能、低延迟的分布式数据流处理功能。在 Flink 中，主要有三种 API：DataSet API、DataStream API 和 Table API。

1. DataSet API：这是 Flink 的批处理 API。使用 DataSet API，你可以编写对大规模数据集进行批处理的程序。这个 API 的设计理念是简洁和易用，类似于使用集合的方式处理数据。
2. DataStream API：这是 Flink 的流处理 API。DataStream API 是为处理实时数据流而设计的，提供了强大的流处理功能，包括时间窗口、水印等。使用 DataStream API，你可以编写对实时数据流进行处理的程序。
3. Table API：Table API 是 Flink 的另一个抽象层，提供了一种声明式的方式来处理数据。Table API 允许你以表格的形式处理数据，并提供了 SQL 查询的功能。你可以使用 Table API 编写查询和转换数据的程序。

这三种 API 各有特点，可以根据具体的使用场景选择适合的 API 进行数据处理。DataSet API 和 DataStream API 是低级别的 API，提供了更多的控制和灵活性；Table API 是声明式的，提供了更简洁的编程模型。

此外，Flink 还提供了统一的执行环境，可以同时处理批处理和流处理任务，使得在 Flink 中编写和运行程序更加方便。

11、Flink出现数据倾斜怎么办？

Flink出现数据倾斜的情况，可以采取以下几种方法解决：

1. 检查任务是否存在反压现象：利用Flink WebUi查看任务是否有反压情况，结果正常，没有出现反压现象。
2. 查看是否存在热点数据：热点数据可能是由于某些原因导致的数据量过大，例如Kafka的topic中某些partition的数据量较大，某些partition的数据量较少。这种情况下，可以使用shuffle、rebalance或rescale算子将数据均匀分配，从而解决数据倾斜的问题。
3. 改造key：如果key导致数据倾斜，可以尝试对key进行改造，让数据分布更加均匀。同时，过滤掉重复的脏数据。
4. 使用滑动窗口：滑动窗口可以将窗口划分成多个子窗口，从而使数据更加均衡地分配到不同的计算节点中。同时，滑动窗口还可以使窗口内的数据更加连续，从而减少数据倾斜的情况。
5. 使用分区：如果数据倾斜的原因是某些key的数据量过大，可以考虑对数据进行分区，从而将数据分散到不同的计算节点中进行处理。

如何处理flink的数据倾斜的问题：

处理Flink中的数据倾斜问题，可以采取以下几种策略：

1. 调整并行度：数据倾斜可能是由于并行度设置过低，导致处理的数据量分布不均。可以通过增加并行度，使得每个并行任务处理的数据量大致相等。
2. 重新分区：如果数据倾斜是由于某个key的分布不均导致的，可以使用Flink的rebalance或repartition操作，对数据进行重新分区，使得每个分区的数据量大致相等。
3. 使用两阶段聚合：在某些场景下，可以使用两阶段聚合来解决数据倾斜问题。首先在每个节点上对相同的key进行本地聚合，然后将各个节点的聚合结果进行全局聚合。这样可以减小每个节点需要处理的数据量，同时避免数据倾斜问题。
4. 调整反压机制：Flink提供了反压机制，可以控制任务的执行速度。如果任务处理速度过快，导致数据积压，可以使用反压机制减缓数据处理速度，避免数据倾斜问题。
5. 使用Watermark延迟：对于时间序列数据等有明显时间顺序的数据，可以使用Watermark延迟来处理数据倾斜问题。通过调整Watermark延迟，可以控制数据处理的速度，使得数据均匀地分配给各个并行任务。
6. 调整窗口大小：如果数据倾斜是由于窗口函数引起的，可以尝试调整窗口大小，使得每个窗口的数据量大致相等。
7. 使用随机前缀：对于某个key的hash值分布不均导致的数据倾斜问题，可以在key上添加随机前缀，使得key的hash值分布更加均匀。

这些策略可以单独使用，也可以结合使用来解决Flink中的数据倾斜问题。需要根据具体情况选择合适的策略。

Flink数据倾斜如何查看：

在flink的web ui中可以看到数据倾斜的情况，就是每个subtask处理的数据量差距很大，例如有的只有一M 有的100M 这就是严重的数据倾斜了。

KafkaSource端发生的数据倾斜

例如上游kafka发送的时候指定的key出现了数据热点问题，那么就在接入之后，做一个负载均衡（前提下游不是keyby）。

聚合类算子数据倾斜

预聚合加全局聚合

12、flink 维表关联怎么做的

在 Flink 中进行维表关联操作，通常涉及到流处理和批处理的场景。维表关联主要是为了在实时计算中，将流数据与维度数据（例如用户画像、商品分类等）进行匹配，从而对流数据进行更丰富的分析和处理。

具体实现上，可以采用以下几种方式：

1. 预加载维表数据：在 Flink 作业的 open 方法中，可以读取外部存储介质（如 MySQL、HBase、Redis 等），获取全量维表信息，并将维表信息全量保存在内存中。处理数据流时，与内存中的维度进行匹配。定时与外部系统的数据同步。这种方式适用于业务刚起步或测试阶段，适用于维表数据量不大、实时性要求不高的场景。
2. 实时查询维表：在 Flink 算子中直接访问外部数据库（如 MySQL），用 MySQL 进行关联。这种方式是同步方式，数据保证是最新的。但是，当流计算数据过大时，会对外部系统带来巨大的访问压力，可能导致线程阻塞、Task 等待数据返回，影响整体任务的吞吐量。这种方式对外部系统的 QPS 要求较高，在大数据实时计算场景下，QPS 远远高于普通的后台系统，峰值高达十万到几十万，整体作业瓶颈转移到外部系统。
3. 预加载+定时更新：在一些场景下，可以采用预加载+定时更新的策略。例如在内存中预加载维表数据，然后定期（例如每小时）从外部系统更新维表数据。这样可以减轻对外部系统的实时查询压力，同时保证维表数据的相对实时性。
4. 使用 Cache 或 Distributed Cache：除了直接从外部系统查询维表数据，还可以考虑使用 Cache 或 Distributed Cache 来缓存维表数据。Flink 提供了 Distributed Cache 机制，可以在 TaskExecutor 上缓存文件，然后在 Task 启动时加载这些文件。这种方式可以减少对外部系统的查询频率，提高效率。

以上是 Flink 进行维表关联的几种常见方式。实际应用中，需要根据业务需求、数据量、实时性要求等因素综合考虑，选择适合的方式进行维表关联操作。

1、async io

2、broadcast

3、async io + cache

4、open方法中读取，然后定时线程刷新，缓存更新是先删除，之后再来一条之后再负责写入缓存

13、Flink checkpoint的超时问题 如何解决？

Flink checkpoint的超时问题可能由多种原因导致，需要具体问题具体分析，但以下是一些常见的解决方法：

1. 检查Flink作业的相关配置参数：确保它们设置得合理。一些与Checkpoint超时相关的参数包括execution.checkpointing.interval、execution.checkpointing.timeout和execution.checkpointing.max-concurrent-checkpoints。增加这些参数的值可能有助于解决超时问题，但要注意不要设置得过大，以免影响故障恢复的及时性或消耗过多的系统资源。
2. 检查处理逻辑：如果数据通道阻塞，可能会导致Checkpoint超时。例如，在从HBase中查询数据时，如果查询到了不存在的key，关联任务可能会超时，导致Checkpoint失败。这种情况下，需要打印相关数据，找出问题所在。
3. 考虑程序是否存在bug或者资源没有释放等问题：这可能导致程序卡住，从而使Checkpoint无法正常进行。
4. 优化数据倾斜问题：如果存在数据倾斜，可能会导致Checkpoint超时。可以通过检查是否存在热点数据，改造key，使用滑动窗口或分区等方法来解决数据倾斜问题。

以上方法仅供参考，具体实施时需要根据实际情况进行调整和优化。如果问题仍然存在，可能需要深入排查Flink代码和配置，或者寻求更专业的技术支持。

1、是否网络问题

2、是否是barrir问题

3、查看webui，是否有数据倾斜

4、有数据倾斜的话，那么解决数据倾斜后，会有改善，

14、flinkTopN与离线的TopN的区别
topn 无论是在离线还是在实时计算中都是比较常见的功能，不同于离线计算中的topn，实时数据是持续不断的，这样就给topn的计算带来很大的困难，因为要持续在内存中维持一个topn的数据结构，当有新数据来的时候，更新这个数据结构

进行Flink的TopN计算，可以通过以下步骤实现：

1. 数据分区：Flink首先根据键值对数据进行分区，这样具有相同键的数据会被发送到同一个任务实例进行处理。
2. 状态管理：Flink提供了强大的状态管理功能，可以用来存储和更新每个键的TopN元素。通常，可以使用ListState或者MapState来存储每个键的TopN元素。
3. 数据更新：当新的数据到达时，Flink会更新对应键的状态。如果新的数据比状态中的元素更大（或更小，取决于是要TopN大的元素还是小的元素），那么Flink会将新的数据添加到状态中，并删除最小（或最大）的元素，以保持状态中只有N个元素。
4. 定时器：Flink允许设置定时器，当时间到达某个点时，Flink会触发一个回调函数。可以在这个回调函数中输出当前的TopN元素。这样，可以定期地输出TopN结果，而不是在每次数据更新时都输出。

15、sparkstreaming 和flink 里checkpoint的区别
sparkstreaming 的checkpoint会导致数据重复消费

但是flink的 checkpoint可以 保证精确一次性，同时可以进行增量，快速的checkpoint的，有三个状态后端，memery、rocksdb、hdfs

在Spark Streaming和Flink中，checkpoint都用于确保数据处理的可靠性和容错性，但两者在实现方式和应用上有一些区别。

1. 实现方式：

• Spark Streaming的checkpoint机制主要是针对driver的故障恢复，通过checkpoint将必要的数据或操作进行备份。它只备份了数据和元数据，但无法保证精确一次的处理语义。
• Flink的checkpoint机制则更为复杂，它采用轻量级的分布式快照技术，实现了每个算子的快照以及流动中的数据的快照。Flink的checkpoint机制基于Chandy-Lamport算法的分布式一致性快照，通过在数据输入源发送Barrier同步全局状态，从而保证Flink内部的一致性语义。

1. 应用：

• Spark Streaming的checkpoint用于从运行流应用程序的驱动程序的节点故障中恢复。然而，Spark Streaming的checkpoint只能用于数据不丢失，可能会重复处理，不能做到恰一次处理语义。
• Flink通过Checkpoint机制实现精确一次的语义。在Flink1.4版本之后，在sink function中增加了TwoPhaseCommitSinkFunction函数，通过两段提交构建从数据源到数据输出的一个端到端的精确一次语义的Flink作业。当然，输出端也必须要有事务回滚的特性，如Kafka0.11版本等。

综上所述，Spark Streaming和Flink的checkpoint机制在实现方式和应用上都有所不同。Spark Streaming主要针对driver的故障恢复，而Flink则通过Checkpoint机制实现精确一次的语义。

16、简单介绍一下cep状态编程
Complex Event Processing（CEP）：

FLink Cep 是在FLink中实现的复杂时间处理库，CEP允许在无休止的时间流中检测事件模式，让我们有机会掌握数据中重要的部分，一个或多个由简单事件构成的时间流通过一定的规则匹配，然后输出用户想得到的数据，也就是满足规则的复杂事件。

CEP（Complex Event Processing）状态编程是一种处理复杂事件流的方法，它基于事件的状态转换和计算。在CEP中，事件流被视为一个状态转换系统，其中每个事件触发状态转换，并且可以根据特定条件更新系统的状态。

CEP状态编程的主要特点如下：

1. 事件驱动：CEP基于事件流进行计算，每个事件都可以触发状态转换。
2. 状态转换：在CEP中，系统状态会随着事件的到来而发生变化。通过定义状态转换规则，可以定义事件触发时的状态更新逻辑。
3. 模式匹配：CEP可以对事件流中的模式进行匹配，例如检测特定的事件序列或事件之间的关联关系。
4. 流处理：CEP处理的是连续的事件流，而不是离散的事件集合。它可以实时处理事件，并产生新的事件流作为输出。
5. 复杂事件处理：与传统的简单事件处理不同，CEP可以处理复杂事件，这些事件由多个简单事件组成，并具有特定的结构和意义。
6. 历史数据：CEP可以处理历史数据和实时数据，并根据需要将它们结合起来进行计算和推理。

在实际应用中，CEP可以用于实现各种复杂的事件驱动系统，如金融风险控制系统、智能交通系统、物联网应用等。通过CEP状态编程，可以有效地处理和分析大量的事件数据，并实时地响应和处理各种事件。

17、 Flink cep连续事件的可选项有什么

Apache Flink 的 CEP (Complex Event Processing) 模块提供了对连续事件流的强大处理能力。对于连续事件的可选项，以下是几个关键的功能和概念：

1. Pattern Detection:

   这是CEP的主要功能。允许你定义一组模式，然后实时监测这些模式在输入流中的出现。模式可以是简单的事件序列或更复杂的结构。

2. Pattern Duration:

   对于某些事件序列，你可能不仅仅关心它们是否出现，还关心它们持续的时间。例如，你可能想检测一个持续超过特定时间间隔的特定事件序列。

3. Timed Patterns:

   在某些情况下，你可能对特定时间间隔内的事件序列感兴趣。例如，你想知道某个股票在连续几天内是否每天都上涨。

4. Pattern金光匹配:

   除了基于时间的事件序列外，还可以基于某些条件匹配事件。例如，你可以匹配超过特定阈值的事件。

5. Stateful Operations:

   在CEP中，你可以使用有状态的操作来处理事件。例如，你可以跟踪某个特定事件的计数，或者存储前一个事件的值以便后续使用。

6. Watermarks:

   由于网络延迟、系统延迟或其他原因，事件的时间戳可能不是完全准确的。Watermarks 是用来处理这种时间戳不准确的情况的工具。它们可以帮助确定哪些事件是“晚到”的，并据此进行适当的处理。

7. Windowing:

   虽然CEP主要用于连续事件流，但有时你可能需要对事件进行分组（窗口化），以便进行更复杂的分析。Flink 的窗口API可以与CEP结合使用来实现这一点。

8. Event Time vs Processing Time:

   在处理事件流时，事件的时间戳可以是基于事件的实际发生时间（称为事件时间）或基于处理系统的时间（称为处理时间）。CEP支持这两种时间概念，并提供了相应的处理机制。

9. Pattern Iterations:

   这是更高级的功能，允许你检测到重复出现的模式或模式序列。例如，你想知道一个特定的事件是否在短时间内重复发生多次。

10. Side Output:

    在某些情况下，你可能希望将不符合主输出模式的事件发送到另一个流中。例如，你可能想将不符合特定模式的事件记录到一个审计日志中。

11. NFA (Non-Deterministic Finite Automaton) Patterns:

    与传统的正则表达式或有限状态机不同，CEP支持基于NFA的模式匹配。这意味着它可以更灵活地处理事件流的复杂性和不确定性。

12. Dynamic Patterns:

• 在某些情况下，你可能希望根据某些条件动态地更改正在监视的模式。例如，随着时间的推移和市场条件的变化，你可能想要调整正在监视的股票价格模式。

1. Pattern Correlation: * 这是更高级的功能，允许你根据两个或多个模式之间的相关性来检测事件。例如，你可能想找到与特定股票价格模式相关联的新闻发布模式。
2. Pattern Correlation with Rule Definition: * 允许你定义规则来定义两个或多个模式之间的相关性。这为你提供了更大的灵活性来定义和匹配模式之间的关系。综上所述，Flink CEP 为连续事件流提供了广泛的功能和选项，使得它在处理和分析复杂事件数据方面非常强大和灵活。

18、如何通过flink的CEP来实现支付延迟提醒

使用Apache Flink的CEP模块来实现支付延迟提醒的基本步骤如下：

1. 设置Flink环境：

   • 首先，你需要设置一个Flink环境，包括集群配置、任务配置等。

2. 引入必要的依赖：

   • 在你的Flink项目中，你需要引入CEP和相关依赖。

3. 定义事件类型：

   • 定义你的事件数据结构。例如，你可能有一个PaymentEvent类，其中包含支付的详细信息，如支付ID、支付金额、支付时间等。

4. 编写CEP作业：

   • 使用Flink CEP API编写CEP作业。这个作业将读取支付事件流，并使用CEP API来定义和检测延迟支付的模式。

5. 定义模式：

   • 定义你想要检测的模式。例如，你可能想检测支付金额超过特定阈值且在一定时间窗口内未完成的情况。

6. 设置时间窗口和延迟：

   • 根据业务需求，设置适当的时间窗口和延迟时间。例如，你可以设置一个5分钟的窗口，并检测超过30秒延迟的支付。

7. 处理匹配的事件：

   • 当匹配到延迟支付模式时，你可以执行相应的操作，如发送警报或记录到日志中。

8. 部署和运行作业：

   • 将你的CEP作业部署到Flink集群上，并启动作业。

9. 监控和调整：

   • 监控CEP作业的性能和输出。根据实际情况调整模式、时间窗口等参数。

10. 优化和扩展：

• 根据实际需求，优化CEP作业的性能，并可能添加更多的功能或模式来满足业务需求。

这只是一个基本的概述。具体的实现细节将取决于你的具体需求和业务逻辑。建议深入研究Flink CEP的文档和示例，以更深入地了解如何使用它来处理连续事件流。

19、Flink cep 你用过哪些业务场景

Flink CEP（Complex Event Processing）在实际应用中有很多业务场景，以下是其中的一些：

1. 金融交易监控：在金融行业，Flink CEP可以用于实时监控金融交易流，检测异常交易或欺诈行为。例如，当一位客户连续进行大额交易或在短时间内进行多笔交易时，系统可以发出警报。
2. 物流跟踪：在物流行业，通过实时分析物流运输过程中的事件，Flink CEP可以帮助监控货物的运输状态，预测运输延迟，并及时采取相应措施。
3. 智能交通管理：在智能交通领域，Flink CEP可以对交通数据进行实时分析，检测交通违规行为或路况异常情况，为交通管理部门提供及时的信息，以优化交通流和减少拥堵。
4. 物联网（IoT）应用：在物联网环境中，Flink CEP可以对各种设备生成的事件进行分析，如传感器数据、设备状态变化等，从而实现对设备状态的实时监控、故障预测和智能控制。
5. 实时用户行为分析：在互联网应用中，Flink CEP可以对用户的实时行为进行分析，如点击流分析、用户访问路径跟踪等，以了解用户兴趣和需求，优化产品设计或推荐相关内容。
6. 实时市场趋势预测：在电商或股票市场中，Flink CEP可以对市场数据进行实时分析，预测市场趋势，帮助企业做出及时的商业决策。
7. 智能制造监控：在智能制造领域，Flink CEP可以对生产过程中的各种事件进行分析，如设备故障、质量检测等，以提高生产效率和产品质量。
8. 网络安全监控：在网络安全领域，Flink CEP可以实时监测网络流量和安全事件，检测恶意流量或网络攻击，及时发出警报并采取相应的防范措施。

这些只是Flink CEP的一些常见业务场景示例。实际上，任何需要对大量事件进行实时分析的场景都可以是Flink CEP的应用场景。Flink CEP的强大之处在于它能够处理高速的事件流，检测复杂的事件模式，并提供实时结果，从而帮助企业实现实时响应和智能决策。

20、cep底层如何工作
21、cep怎么老化
22、cep性能调优
23、Flink的背压，介绍一下Flink的反压，你们是如何监控和发现的呢。
Flink 没有使用任何复杂的机制来解决反压问题，Flink 在数据传输过程中使用了分布式阻塞队列。我们知道在一个阻塞队列中，当队列满了以后发送者会被天然阻塞住，这种阻塞功能相当于给这个阻塞队列提供了反压的能力。

当你的任务出现反压时，如果你的上游是类似 Kafka 的消息系统，很明显的表现就是消费速度变慢，Kafka 消息出现堆积。

如果你的业务对数据延迟要求并不高，那么反压其实并没有很大的影响。但是对于规模很大的集群中的大作业，反压会造成严重的“并发症”。首先任务状态会变得很大，因为数据大规模堆积在系统中，这些暂时不被处理的数据同样会被放到“状态”中。另外，Flink 会因为数据堆积和处理速度变慢导致 checkpoint 超时，而 checkpoint 是 Flink 保证数据一致性的关键所在，最终会导致数据的不一致发生。

Flink Web UI

Flink 的后台页面是我们发现反压问题的第一选择。Flink 的后台页面可以直观、清晰地看到当前作业的运行状态。

Web UI，需要注意的是，只有用户在访问点击某一个作业时，才会触发反压状态的计算。在默认的设置下，Flink的TaskManager会每隔50ms触发一次反压状态监测，共监测100次，并将计算结果反馈给JobManager，最后由JobManager进行反压比例的计算，然后进行展示。

在生产环境中Flink任务有反压有三种OK、LOW、HIGH

OK正常

LOW一般

HIGH高负载

24、Flink的CBO，逻辑执行计划和物理执行计划
Flink的优化执行其实是借鉴的数据库的优化器来生成的执行计划。

CBO，成本优化器，代价最小的执行计划就是最好的执行计划。传统的数据库，成本优化器做出最优化的执行计划是依据统计信息来计算的。Flink 的成本优化器也一样。Flink 在提供最终执行前，优化每个查询的执行逻辑和物理执行计划。这些优化工作是交给底层来完成的。根据查询成本执行进一步的优化，从而产生潜在的不同决策：如何排序连接，执行哪种类型的连接，并行度等等。

// 待完成

25、Flink中数据聚合，不使用窗口怎么实现聚合
valueState 用于保存单个值

ListState 用于保存list元素

MapState 用于保存一组键值对

ReducingState 提供了和ListState相同的方法，返回一个ReducingFunction聚合后的值。

AggregatingState和 ReducingState类似，返回一个AggregatingState内部聚合后的值

26、Flink中state有哪几种存储方式
Memery、RocksDB、HDFS

27、Flink 异常数据怎么处理
异常数据在我们的场景中，一般分为缺失字段和异常值数据。

异常值： 宝宝的年龄的数据，例如对于母婴行业来讲，一个宝宝的年龄是一个至关重要的数据，可以说是最重要的，因为宝宝大于3岁几乎就不会在母婴上面购买物品。像我们的有当日、未知、以及很久的时间。这样都属于异常字段，这些数据我们会展示出来给店长和区域经理看，让他们知道多少个年龄是不准的。如果要处理的话，可以根据他购买的时间来进行实时矫正，例如孕妇服装、奶粉的段位、纸尿裤的大小，以及奶嘴啊一些能够区分年龄段的来进行处理。我们并没有实时处理这些数据，我们会有一个底层的策略任务夜维去跑，一个星期跑一次。

缺失字段： 有的字段真的缺失的很厉害，能修补就修补。不能修补就放弃，就像上家公司中的新闻推荐过滤器。

28、Flink 监控你们怎么做的
1、我们监控了Flink的任务是否停止

2、我们监控了Flink的Kafka的LAG

3、我们会进行实时数据对账，例如销售额。

29、Flink 有数据丢失的可能吗
Flink有三种数据消费语义：

At Most Once 最多消费一次 发生故障有可能丢失
At Least Once 最少一次 发生故障有可能重复
Exactly-Once 精确一次 如果产生故障，也能保证数据不丢失不重复。
flink 新版本已经不提供 At-Most-Once 语义。

30、Flink interval join 你能简单的写一写吗
DataStream<T> keyed1 = ds1.keyBy(o -> o.getString("key"))
DataStream<T> keyed2 = ds2.keyBy(o -> o.getString("key"))
//右边时间戳-5s<=左边流时间戳<=右边时间戳-1s
keyed1.intervalJoin(keyed2).between(Time.milliseconds(-5), Time.milliseconds(5))
1
2
3
4
31、Flink 提交的时候 并行度如何制定，以及资源如何配置
并行度根据kafka topic的并行度，一个并行度3个G

32、Flink的boardcast join 的原理是什么
利用 broadcast State 将维度数据流广播到下游所有 task 中。这个 broadcast 的流可以与我们的事件流进行 connect，然后在后续的 process 算子中进行关联操作即可。

33、flink的source端断了，比如kafka出故障，没有数据发过来，怎么处理？
会有报警，监控的kafka偏移量也就是LAG。

34、flink有什么常用的流的API?
window join 啊 cogroup 啊 map flatmap，async io 等

35、flink的水位线，你了解吗，能简单介绍一下吗
Flink 的watermark是一种延迟触发的机制。

一般watermark是和window结合来进行处理乱序数据的，Watermark最根本就是一个时间机制，例如我设置最大乱序时间为2s，窗口时间为5秒，那么就是当事件时间大于7s的时候会触发窗口。当然假如有数据分区的情况下，例如kafka中接入watermake的话，那么watermake是会流动的，取的是所有分区中最小的watermake进行流动，因为只有最小的能够保证，之前的数据都已经来到了，可以触发计算了。

36、Flink怎么维护Checkpoint？在HDFS上存储的话会有小文件吗
默认情况下，如果设置了Checkpoint选项，Flink只保留最近成功生成的1个Checkpoint。当Flink程序失败时，可以从最近的这个Checkpoint来进行恢复。但是，如果我们希望保留多个Checkpoint，并能够根据实际需要选择其中一个进行恢复，这样会更加灵活。Flink支持保留多个Checkpoint，需要在Flink的配置文件conf/flink-conf.yaml中，添加如下配置指定最多需要保存Checkpoint的个数。

小文件问题是有的，但是并不是很多所以无需关心，在公司不大的情况下 无需关心。

37、Spark和Flink的序列化，有什么区别吗？
Spark 默认使用的是 Java序列化机制，同时还有优化的机制，也就是kryo

Flink是自己实现的序列化机制，也就是TypeInformation

38、Flink是怎么处理迟到数据的？但是实际开发中不能有数据迟到，怎么做？
Flink 的watermark是一种延迟触发的机制。

一般watermark是和window结合来进行处理乱序数据的，Watermark最根本就是一个时间机制，例如我设置最大乱序时间为2s，窗口时间为5秒，那么就是当事件时间大于7s的时候会触发窗口。当然假如有数据分区的情况下，例如kafka中接入watermake的话，那么watermake是会流动的，取的是所有分区中最小的watermake进行流动，因为只有最小的能够保证，之前的数据都已经来到了，可以触发计算了。

39、画出flink执行时的流程图。

40、Flink分区分配策略
41、Flink关闭后状态端数据恢复得慢怎么办？
42、了解flink的savepoint吗？讲一下savepoint和checkpoint的不同和各有什么优势
43、flink的状态后端机制
Flink的状态后端是Flink在做checkpoint的时候将状态快照持久化，有三种状态后端 Memery、HDFS、RocksDB

44、flink中滑动窗口和滚动窗口的区别，实际应用的窗口是哪种？用的是窗口长度和滑动步长是多少？
45、用flink能替代spark的批处理功能吗
Flink 未来的目标是批处理和流处理一体化，因为批处理的数据集你可以理解为是一个有限的数据流。Flink 在批出理方面，尤其是在今年 Flink 1.9 Release 之后，合入大量在 Hive 方面的功能，你可以使用 Flink SQL 来读取 Hive 中的元数据和数据集，并且使用 Flink SQL 对其进行逻辑加工，不过目前 Flink 在批处理方面的性能，还是干不过 Spark的。

目前看来，Flink 在批处理方面还有很多内容要做，当然，如果是实时计算引擎的引入，Flink 当然是首选。

46、flink计算的UV你们是如何设置状态后端保存数据
可以使用布隆过滤器。

47、sparkstreaming和flink在执行任务上有啥区别，不是简单的流处理和微批，sparkstreaming提交任务是分解成stage，flink是转换graph，有啥区别？

Apache Spark Streaming和Apache Flink在执行任务上的主要区别在于它们对流处理的处理方式、执行模型和数据模型。

1. 流处理与微批处理：

   • Spark Streaming实际上是基于微批处理的，它将流数据视为一系列的小批量数据，并使用Spark核心的批处理引擎进行处理。
   • Flink则直接处理流数据，没有微批的概念。这种处理方式使得Flink在实时性方面具有更好的表现，尤其是在低延迟场景中。

2. 执行模型：

   • Spark Streaming的执行模型是基于Spark的DAG（有向无环图）执行模型。它将Spark Streaming作业分解为多个小批次作业，每个作业对应一个DAG，然后由Spark的TaskScheduler逐个执行。这意味着Spark Streaming在处理过程中存在固定的延迟。
   • Flink使用的是流执行模型，数据流在节点之间直接流动，一旦一个节点处理完数据，就可以将结果发送到下一个节点。这种模型减少了延迟，并允许Flink更好地处理实时数据。

3. 数据模型：

   • Spark Streaming的数据模型是基于RDD（Resilient Distributed Dataset）的，即弹性分布式数据集。它适合处理大规模的数据集，但对于小规模数据集，Flink的流处理模型更为高效。
   • Flink的基本数据模型是数据流和事件序列，这使得Flink能够更好地处理连续和流式数据。此外，Flink也支持基于事件时间或处理时间的窗口操作，这为更复杂的数据分析提供了灵活性。

4. SQL功能：

   • Spark Streaming提供了Spark SQL作为其查询工具，而Flink提供了自己的Table API和SQL API。Spark SQL对于已经熟悉SQL和Spark的用户来说更为友好，而Flink的API更为灵活，可以支持更复杂的流式计算场景。

5. 有环数据流的处理：

   • Spark Streaming不支持有环的数据流，因为它基于RDD模型，RDD之间是静态确定的。对于需要处理有环数据流的复杂流式计算场景，Flink更具优势。

综上所述，Spark Streaming和Flink在流处理方面各有优势。Spark Streaming更适合大规模的数据处理和批处理场景，而Flink更适合低延迟和高并发的实时流处理场景。在实际应用中，需要根据具体需求来选择使用哪种工具。

Spark Streaming和Flink是两个流处理框架，它们在执行任务上有以下区别：

1. 执行模式：Spark Streaming采用的是微批处理模式，将实时数据切分成小的批次进行处理，每个批次的数据在内存中进行计算。而Flink采用的是事件驱动的流处理模式，数据以事件流的形式进行处理，可以实现毫秒级的低延迟。

2. 任务调度：Spark Streaming将实时数据流切分成一系列的微批次，每个微批次作为一个RDD进行处理，任务调度是基于Spark的调度器进行的。而Flink以数据流为单位进行任务调度，将整个流图转换成有向无环图（DAG），通过任务调度器执行。

3. 容错性：Spark Streaming采用了离线批处理框架Spark的容错机制，通过RDD的弹性分布式数据集实现容错。Flink则采用了基于检查点（checkpoint）的容错机制，可以精确地恢复任务状态。

4. 窗口处理：Spark Streaming使用窗口操作来处理数据流，可以基于时间或数量来定义窗口。Flink也支持基于时间和数量的窗口操作，但还提供了更多的窗口类型和灵活性，如滑动窗口、会话窗口等。

5. 状态管理：Spark Streaming使用DStream来管理流处理的状态，每个批次的状态都会被保存和更新。Flink使用状态后端（State Backend）来管理状态，可以将状态保存在内存、文件系统或外部存储中，支持更大规模和更复杂的状态管理。

总的来说，Spark Streaming更适合对数据进行微批处理，适用于对延迟要求不高的场景，而Flink更适合实时流处理，适用于对低延迟和高吞吐量要求较高的场景。此外，Flink在一些功能上更加灵活和丰富，如窗口处理和状态管理方面。

48、flink把streamgraph转化成jobGraph是在哪个阶段？

Flink在执行流处理任务时，将流图（StreamGraph）转换为作业图（JobGraph）的过程发生在作业提交（Job Submission）阶段。具体来说，这个转换过程包括以下几个步骤：

1. 创建StreamGraph：首先，用户通过Flink的API编写流处理程序，构建流图（StreamGraph），描述了数据流的处理逻辑、操作算子以及数据流之间的连接关系。

2. 优化StreamGraph：接下来，Flink会对StreamGraph进行优化，包括优化算子的顺序、合并相邻的算子等，以提高执行效率。

3. 转换为JobGraph：一旦StreamGraph被优化，Flink将其转换为作业图（JobGraph）。作业图是一个有向无环图（DAG），表示了流图中的操作算子、数据流以及它们之间的依赖关系。

4. 作业提交：最后，将作业图提交给Flink的作业管理器（JobManager），作业管理器会负责将作业图进行调度和执行，分配资源，并监控整个作业的运行过程。

需要注意的是，转换为作业图是一个静态的过程，发生在作业提交阶段，而不是在作业执行阶段。一旦作业图被提交，Flink会根据作业图进行任务调度和执行，实现流处理任务的实时计算。

49、Flink中的watermark除了处理乱序数据还有其他作用吗？
还有kafka数据顺序消费的处理。

除了处理乱序数据之外，Flink中的水印（Watermark）还有其他重要作用：

1. 时间语义：水印在Flink中用于实现事件时间语义。通过水印，Flink可以确定数据流中的事件时间范围，从而能够正确处理延迟数据和乱序数据，确保在事件时间上的正确性。

2. 窗口触发：水印还可以用于触发窗口操作。当水印到达窗口边界时，Flink可以根据水印来判断窗口是否可以进行计算，以触发窗口的计算操作。

3. 延迟数据处理：水印还可以用于处理延迟数据。通过水印的引入，Flink可以在一定程度上容忍延迟数据，从而实现更加灵活和准确的事件时间处理。

总的来说，水印在Flink中不仅用于处理乱序数据，还在事件时间处理、窗口计算等方面起着至关重要的作用。通过水印的引入，Flink可以实现更加准确和可靠的事件时间语义，保证数据流处理的正确性和准确性。

50、flink你一般设置水位线设置多少
我们之前设置的水位线是6s

在Flink中，水位线是一个重要的概念，用于确定何时触发Checkpoint。但是，具体的设置应该根据实际的应用场景和需求来确定。

一般来说，水位线的设置需要考虑以下几个因素：

1. 数据量：如果数据量很大，需要更多的时间来处理，那么应该将水位线设置得更高一些，以便有足够的时间来完成数据处理。
2. 延迟要求：如果应用程序对延迟有较高的要求，那么应该将水位线设置得较低一些，以便能够更快地触发Checkpoint。
3. 资源利用率：如果资源利用率较高，那么可以将水位线设置得稍高一些，以便更好地利用资源。

在Flink中，可以通过配置参数来调整水位线的值。具体来说，可以通过调整state.backend.checkpoint.interval参数来设置Checkpoint的时间间隔，以及通过调整state.backend.checkpoint.timeout参数来设置Checkpoint的超时时间。

总之，水位线的设置需要根据实际的应用场景和需求来确定，以达到最佳的性能和可靠性。

52、Flink任务提交流程

Flink任务提交后，Client向HDFS上传Flink的jar包和配置，之后向Yarn ResourceManager提交任务，ResourceManager分配Container资源并通知对应的NodeManager启动

ApplicationMaster，ApplicationMaster启动后加载Flink的jar包和配置构建环境，然后启动JobManager；之后Application Master向ResourceManager申请资源启动TaskManager

，ResourceManager分配Container资源后，由ApplicationMaster通知资源所在的节点的NodeManager启动TaskManager，NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager，TaskManager启动向JobManager发送心跳，并等待JobManager向其分配任务。

53、Flink技术架构图

54、flink如何实现在指定时间进行计算。
55、手写Flink topN
57、Flink的Join算子有哪些
一般join是发生在window上面的:

1、window join，即按照指定的字段和滚动滑动窗口和会话窗口进行 inner join

2、是coGoup 其实就是left join 和 right join，

3、interval join 也就是 在窗口中进行join 有一些问题，因为有些数据是真的会后到的，时间还很长，那么这个时候就有了interval join但是必须要是事件时间，并且还要指定watermark和水位以及获取事件时间戳。并且要设置 偏移区间，因为join 也不能一直等的。

58、Flink1.10 有什么新特性吗？
https://dafei1288.blog.csdn.net/article/details/104289882?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromBaidu-1.not_use_machine_learn_pai&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromBaidu-1.not_use_machine_learn_pai

59、Flink的重启策略
固定延迟重启策略

固定延迟重启策略是尝试给定次数重新启动作业。如果超过最大尝试次数，则作业失败。在两次连续重启尝试之间，会有一个固定的延迟等待时间。

故障率重启策略

故障率重启策略在故障后重新作业，当设置的故障率（failure rate）超过每个时间间隔的故障时，作业最终失败。在两次连续重启尝试之间，重启策略延迟等待一段时间。

无重启策略

作业直接失败，不尝试重启。

后备重启策略

使用群集定义的重新启动策略。这对于启用检查点的流式传输程序很有帮助。默认情况下，如果没有定义其他重启策略，则选择固定延迟重启策略。

60、Flink什么时候用aggregate()或者process()
aggregate： 增量聚合

process： 全量聚合

当计算累加操作时候可以使用aggregate操作。

当计算窗口内全量数据的时候使用process，例如排序等操作。

61、Flinksql优化 你了解多少

Apache Flink是一个流处理和批处理的开源计算框架，能够在大规模数据流中进行状态计算，同时保证精确性和高效性。使用Flink SQL可以在Flink上运行SQL查询。以下是一些进行Flink SQL调优的方法：

1. 并行度设置：并行度影响Flink作业的执行速度，可以通过设置并行度来提高任务的执行速度。

2. 选择合适的时间特性：Flink SQL支持三种时间特性：事件时间，处理时间和摄取时间。选择合适的时间特性可以提高Flink SQL查询的效率。

3. 优化Join操作：在Flink SQL中，Join操作是性能瓶颈的常见来源。可以通过选择更高效的Join算法，比如Sort-Merge Join或Hash Join来优化Join操作。

4. 使用Watermark：Watermark是Flink用来处理事件时间的一种机制，可以帮助Flink处理延迟的数据。合理使用Watermark可以提高查询的准确性。

5. 内存管理：通过合理设置Flink的内存参数，可以避免OOM（Out of Memory）错误，提高作业的稳定性。

6. 使用索引：对数据进行索引可以加快数据的查询速度。

7. 选择合适的数据存储格式：选择适合你的数据和查询的数据存储格式，可以提高查询的效率。

8. 使用窗口：在处理流数据时，窗口是一种常用的处理模式。选择合适的窗口类型和大小，可以提高查询的效率。

9. 优化网络参数：Flink通过网络进行数据传输，优化网络参数也可以提高Flink作业的执行速度。

10. 使用CEP（Complex Event Processing）：如果你的查询涉及到复杂的事件模式，可以使用Flink的CEP库来进行优化。

以上是一些基本的Flink SQL调优方法，具体的调优策略可能需要根据你的具体需求和环境来确定。

62、Flink内存溢出怎么办？

Flink内存溢出（Out of Memory，OOM）是在Flink运行过程中常见的问题，通常是由于分配给Flink的内存不足以处理当前的任务引起的。处理Flink内存溢出的方法有以下几点：

1. 增加Flink的内存：这是最直接的方法，你可以通过配置文件增加Flink的总内存或者各个部分的内存。例如，你可以增加taskmanager.heap.size来增加TaskManager的堆内存，或者增加taskmanager.memory.process.size来增加Flink进程的总内存。

2. 优化数据结构：使用更加高效的数据结构可以减少内存的使用。例如，你可以使用ValueState代替ListState来存储状态，或者使用更高效的数据类型，如Int代替Integer。

3. 使用更高效的算法：一些算法可能会产生大量的中间结果，导致内存溢出。你可以尝试使用更高效的算法来减少中间结果的数量。

4. 使用RocksDB作为状态后端：RocksDB是一个持久化的键值存储，可以将状态数据存储在磁盘上，而不是内存中。这可以显著减少内存的使用。

5. 控制并行度：并行度越高，每个TaskManager需要处理的数据就越多，可能会导致内存溢出。你可以尝试减小并行度来减少每个TaskManager的内存压力。

6. 控制数据倾斜：数据倾斜是导致内存溢出的常见原因。你可以通过重新分区或者使用更好的哈希函数来减少数据倾斜。

7. 限制缓冲区的大小：Flink使用缓冲区来存储中间结果，你可以通过限制缓冲区的大小来减少内存的使用。

63.如何进行flink的数据倾斜处理？

Flink处理数据倾斜（Data Skew）的一些方法：

1. 数据预处理：如果数据倾斜的原因是某些键的值过多，可以在数据进入Flink之前进行预处理，例如对这些值进行哈希或者取模等操作，使得这些值分散到更多的键中。

2. 使用更好的哈希函数：如果数据倾斜的原因是哈希函数的问题，可以尝试使用更好的哈希函数，使得数据更均匀地分布到各个任务中。

3. 重新分区（Repartition）：Flink提供了rebalance操作，可以将数据重新均匀地分布到所有并行任务中。

4. 使用分层聚合（Two-Level Aggregation）：对于聚合操作，可以先在每个并行任务内部进行局部聚合，然后再进行全局聚合，这样可以减少数据传输和全局聚合的压力。

5. 动态调整并行度：Flink支持动态调整并行度，可以根据数据的实际情况动态调整任务的并行度，减轻数据倾斜的影响。

6. 使用Managed Memory：Flink的Managed Memory可以自动管理内存，当内存不足时，可以将部分数据溢出到磁盘，避免因为数据倾斜导致的内存溢出。

以上只是一些基本的方法，具体的解决方案可能需要根据你的具体情况来确定。

63、说说Flink中的keyState包含哪些数据结构
64、Flink shardGroup的概念

65.详细讲解一下checkpoint

Checkpoint是Flink实现容错机制最核心的功能，能够根据配置周期性地基于Stream中各个Operator的状态来生成Snapshot快照，从而将这些状态数据定期持久化存储下来。当Flink程序一旦意外崩溃时，重新运行程序时可以有选择地从这些快照进行恢复，从而修正因为故障带来的程序数据状态中断。

Checkpoint的原理如下：

1. Checkpoint Barrier：这是Flink分布式快照的核心概念之一，称之为屏障或者数据栅栏（可以理解为快照的分界线）。Barrier是一种特殊的内部消息，在进行Checkpoint的时候Flink会在数据流源头处周期性地注入Barrier，这些Barrier会作为数据流的一部分，一起流向下游节点并且不影响正常的数据流。
2. 数据源：如Kafka，记录了所有有状态的operator当前的状态信息（例如sum中的数值）和当前检查点开始时数据源中消息的offset。

Checkpoint的过程可以简述为以下步骤：

1. Flink在数据流的源头处周期性地注入Barrier。
2. Barrier流经Flink的数据流并最终到达所有的sink。
3. 当sink收到Barrier时，它触发一个Checkpoint。
4. 在Checkpoint过程中，每个Operator都会在其状态中记录一个Snapshot。
5. Flink将这个Snapshot保存下来，以便在失败时能够恢复。

此外，关于Checkpoint还有一些需要注意的事项：

1. 默认情况下，Flink使用异步的方式进行Checkpoint，这意味着Checkpoint可能会与正常的数据处理同时进行。这种方式的优点是可以减少Checkpoint对数据处理性能的影响，但缺点是如果在程序崩溃时Checkpoint还没有完成，那么可能会丢失一部分数据。
2. Checkpoint的频率和持续时间会影响到Flink程序的性能和容错能力。如果Checkpoint的频率设置得过高，那么会频繁地进行Checkpoint操作，从而增加系统负载并降低数据处理性能。如果Checkpoint的频率设置得过低，那么在程序崩溃时可能会丢失较多的数据。因此，需要根据实际的应用场景和需求来选择合适的Checkpoint频率。
3. Checkpoint的持久化存储方式也会影响到Flink程序的容错能力。如果Checkpoint数据只是存储在内存中，那么在系统崩溃时可能会丢失。如果Checkpoint数据存储在磁盘上，那么在系统崩溃时可以恢复数据，但会增加磁盘I/O负载并降低Checkpoint的效率。因此，需要根据实际的应用场景和需求来选择合适的存储方式。
4. 在选择Checkpoint的方式时，需要权衡系统负载和容错能力之间的平衡。例如，可以选择在特定的时间窗口内进行Checkpoint操作，或者在系统负载较低的时候进行Checkpoint操作。
5. 在处理大数据量和高吞吐量的场景下，需要特别注意Checkpoint的性能和资源消耗。可以通过优化Flink作业和配置参数来提高Checkpoint的性能和资源利用率。例如，可以通过减少Operator的数量和复杂度、优化数据序列化和压缩算法、调整并行度和任务分配等方式来提高Checkpoint的性能和资源利用率。

————————————————
版权声明：本文为CSDN博主「中国好胖子、」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_43704599/article/details/113847416