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状态主要有两种使用方式：

checkpoint的数据恢复

逻辑计算

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

Flink 中的watermark机制是用来处理乱序的，flink的时间必须是event time ，有一个简单的例子就是，假如窗口是5秒，watermark是2秒，那么 总共就是7秒，这个时候什么时候会触发计算呢，假设数据初始时间是1000，那么等到6999的时候会触发5999窗口的计算，那么下一个就是13999的时候触发10999的窗口

其实这个就是watermark的机制，在多并行度中，例如在kafka中会所有的分区都达到才会触发窗口

5、Flink的时间语义

Event Time 事件产生的时间

Ingestion time 事件进入Flink的时间

processing time 事件进入算子的时间

6、Flink window join

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

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

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

7、flink窗口函数有哪些

Tumbing window

Silding window

Session window

Count winodw

8、keyedProcessFunction 是如何工作的。假如是event time的话

KeyedProcessFunction是Apache Flink中的一个核心函数，用于在流处理任务中对每个键（key）的输入数据进行处理。它可以访问和操作键控状态（keyed state），并可以注册定时器（timer）来触发特定事件。

当以事件时间（event time）模式运行时，KeyedProcessFunction可以按照事件的时间戳来处理数据。以下是KeyedProcessFunction在事件时间模式下的工作流程：

1. 初始化：KeyedProcessFunction会先执行open()方法，用于初始化状态、注册定时器等操作。

2. 处理输入数据：对于每个输入的事件数据，KeyedProcessFunction会执行processElement()方法。可以在该方法中访问键控状态，并根据业务逻辑进行处理。处理过程中可以选择将数据输出到侧输出流（side output）或更新状态。

3. 注册定时器：根据需要，KeyedProcessFunction可以在processElement()方法中注册定时器（timer）。定时器可以在未来的某个事件时间点触发操作。例如，可以注册一个定时器来在指定的事件时间点生成某个输出，或者在特定的事件时间范围内更新状态。

4. 定时器触发：当注册的定时器的时间到达时，KeyedProcessFunction会调用onTimer()方法来触发相应的逻辑。可以在该方法中访问键控状态，并根据需要进行操作，例如输出数据、更新状态或注册更多的定时器。

5. 清理资源：当任务结束时，KeyedProcessFunction会执行close()方法，用于释放资源、清理状态等操作。

需要注意的是，KeyedProcessFunction是一种低级别的API，需要手动管理状态和定时器。对于更高级别的处理需求，可以使用Flink提供的窗口函数（Window Function）和触发器（Trigger）来简化处理逻辑。

在Apache Flink中，有几个核心函数用于在流处理任务中对数据进行处理和转换。

1. MapFunction: MapFunction是最简单的核心函数之一，它将一个输入元素转换为一个输出元素，并返回一个新的元素。MapFunction是一个无状态的函数，每个输入元素都是独立的。
2. FlatMapFunction: FlatMapFunction用于将一个输入元素转换为零个或多个输出元素。它可以用于拆分输入元素并生成多个输出元素，也可以过滤掉某些输入元素。FlatMapFunction也是一个无状态的函数。
3. FilterFunction: FilterFunction用于过滤掉不满足特定条件的输入元素。它接受一个输入元素，并根据定义的条件返回一个布尔值。当条件为true时，输入元素被保留，否则被过滤掉。
4. KeyByFunction: KeyByFunction用于将输入流按照指定的键（key）进行分组。它接受一个输入元素，并根据定义的键选择对应的键值对。通过KeyByFunction，可以将流分成多个独立的子流，每个子流包含相同键的元素。
5. ProcessFunction: ProcessFunction是一个更灵活和通用的核心函数，它提供了对流数据的更细粒度的控制。ProcessFunction可以访问和操作键控状态（keyed state），并可以注册定时器（timer）来触发特定事件。它可以处理输入元素、注册定时器、处理定时器触发事件等。

这些核心函数可以通过Flink的DataStream API或Table API进行使用，用于构建数据处理逻辑和转换流数据。它们可以在流处理任务中进行组合和嵌套，以实现复杂的数据处理和转换需求。

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

Apache Flink主要用于流处理任务，但也可以处理离线数据。对于离线数据的处理，可以通过以下几种方式与流数据进行关联：

1. 批处理任务：Flink提供了DataSet API，用于处理批处理任务。使用DataSet API，可以通过读取和处理离线数据集来进行关联操作。可以将离线数据集转换为DataSet，并与流数据集进行Join、CoGroup等操作。
2. 流-批一体化：Flink支持流和批处理的一体化，这意味着可以在流处理任务中直接操作离线数据。可以将离线数据作为流数据的源，通过DataStream API进行处理和关联操作。例如，可以将离线数据作为流数据的广播流（Broadcast Stream），并与实时流数据进行Join操作。
3. 嵌入式数据库：Flink提供了基于键控状态（Keyed State）的数据库（StateBackend），可以将离线数据加载到键控状态中。通过将离线数据加载到状态中，可以在流处理任务中直接访问和关联离线数据。

无论采用哪种方式，关联离线数据通常需要考虑数据规模和性能等因素。对于大规模的离线数据处理，可以使用分布式文件系统（如HDFS）或分布式数据库（如Apache HBase）来存储和管理离线数据。此外，还可以通过优化算法和调整资源配置等方式来提高关联操作的性能。

10、flink支持的数据类型

DataSet Api 和 DataStream Api、Table Api

Flink支持的数据类型主要包括以下几种：

原子类型：包括Boolean、Byte、Short、Int、Long、Float和Double等基础类型。

字符类型：包括String类型。

复合类型：包括数组类型（Array）、元组类型（Tuple）、以及类类型（Class）。

集合类型：包括Set和Map类型。

时间类型：包括Instant和Time类型，可以用来表示时间戳或持续时间。

其他类型：包括Row、LocalDateTime、Duration、Period等。

特殊类型：对于一些特殊的类型，例如基本数据类型包装类、不可变长整型包装类、大数值包装类、布尔型包装类、字符型包装类等，Flink也提供了相应的包装类。

复合特殊类型：包括List、Map、DataStream、ConnectedStreams等复合类型，以及Tuple1到Tuple25等元组类型。

以上是Flink主要支持的数据类型，对于其他复杂的数据结构，Flink也提供了支持，例如使用DataStream API可以处理更复杂的数据流，使用Table API可以处理结构化数据等。

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

Flink数据倾斜如何查看：

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

KafkaSource端发生的数据倾斜

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

聚合类算子数据倾斜

预聚合加全局聚合

以下是一些解决Flink数据倾斜的方法：

重分区（Redistribute/Reshuffle）: 可以对key进行重新分区，将数据分布到更多的task上，从而避免单个task处理过多数据。例如，使用rebalance()或fullRebalance()方法可以实现重分区。

广播变量（Broadcast Variables）: 可以在作业的开始阶段将数据广播到所有的task中，这样每个task都有一份相同的广播变量。在处理数据时，可以访问这些广播变量，从而避免数据倾斜。

使用连接函数（Join Functions）: 在连接两个流时，可以使用连接函数来处理数据倾斜。连接函数可以决定如何将两个流中的数据进行匹配。通过选择合适的连接函数，可以避免某个流中的数据过多导致的数据倾斜问题。

使用Rich Functions（Rich Map/Reduce Functions）: 可以使用Rich Map或Reduce函数来处理数据倾斜。Rich函数可以访问Flink提供的Context对象，从而获取更多关于作业的信息，如taskManager、executor、jobGraph等。通过使用Rich函数，可以更好地管理和优化作业的性能。

自定义分区器（Custom Partitioners）: 如果以上方法无法解决数据倾斜问题，可以考虑自定义分区器。通过自定义分区器，可以根据数据的特性来分配task，从而避免数据倾斜。

调整并行度（Adjusting Parallelism）: 可以根据实际情况调整作业的并行度。通过增加并行度，可以将任务分配到更多的taskmanager和task上，从而降低单个task的处理压力。

优化数据倾斜的算法/算子: 根据业务场景和实际需要优化特定的算法/算子来处理可能的数据倾斜问题。

12、flink 维表关联怎么做的

在Flink中，可以使用维表（Dimension Table）来与流数据进行关联操作。维表通常是一种静态的数据表，其中包含与流数据相关的附加信息，例如产品信息、用户信息等。维表关联可以通过以下几个步骤来实现：

1. 加载维表数据：首先，需要将维表数据加载到Flink中，可以使用Flink的DataSet API或DataStream API读取维表数据。维表数据可以存储在文件系统、数据库或其他存储介质中。
2. 转换维表数据为广播流：将维表数据转换为广播流（Broadcast Stream），以便可以在流处理任务中进行广播操作。广播流是一种特殊类型的流数据，可以将其广播到所有的并行任务中，以便每个任务都能访问维表数据。
3. 进行维表关联操作：在流处理任务中，可以使用BroadcastStream转换函数（BroadcastStreamProcessFunction）或RichCoFlatMapFunction函数等方式，将广播流与输入流进行关联操作。关联操作可以使用维表数据中的关键属性与输入流中的数据进行匹配。
4. 更新维表数据：维表数据可能会发生变化，因此需要定期或根据需要更新维表数据。可以使用定时任务或外部触发方式来更新维表数据，确保与流数据的关联始终是最新的。

通过以上步骤，可以实现在Flink中使用维表进行关联操作。维表关联可以提供更丰富的数据信息，使得流处理任务能够更准确地分析和处理数据。同时，广播流的方式也可以提高关联操作的性能和并行度。

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

在Flink中，Checkpoint是一种机制，用于实现容错性和故障恢复。Checkpoint超时问题通常涉及到两个方面：

1. Checkpoint太慢导致超时：如果Checkpoint的执行时间太长，可能会导致超时问题。可以通过以下几种方式来解决：

• • 增加Checkpoint的间隔时间：可以通过增加Checkpoint的间隔时间来减少每个Checkpoint的负载，降低超时的风险。但这样做可能会减少容错性和故障恢复的能力。
  • 调整Checkpoint的配置参数：可以调整Checkpoint的配置参数，如最大并行度、最大尝试次数等，以提高Checkpoint的执行效率。
  • 优化作业的并发度和计算逻辑：检查作业的并发度和计算逻辑是否合理，是否存在计算瓶颈或数据倾斜等问题，通过优化来提高Checkpoint的执行速度。

1. Checkpoint超时导致任务失败：如果Checkpoint执行超时，可能会导致整个任务失败，需要重新启动任务。解决这个问题可以考虑以下几种方法：

• • 增加Checkpoint的超时时间：可以适当增加Checkpoint的超时时间，以容忍一些临时的网络延迟或资源竞争问题。
  • 检查网络连接和资源竞争：检查网络连接是否稳定，是否有资源竞争的问题，例如磁盘或网络带宽不足等。解决这些问题可以通过增加网络带宽、调整硬件资源分配等方式来改善。
  • 增加任务的资源配额：如果Checkpoint超时是由于资源不足导致的，可以增加任务的资源配额，例如内存、CPU等，以提高任务的执行效率和容错性。

以上是一些常见的解决Checkpoint超时问题的方法。具体的解决方案需要根据实际情况进行调整和优化。

1、是否网络问题

2、是否是barrir问题

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

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

14、flinkTopN与离线的TopN的区别

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

15、sparkstreaming 和flink 里checkpoint的区别

sparkstreaming 的checkpoint会导致数据重复消费

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

16、简单介绍一下cep状态编程

Complex Event Processing（CEP）：

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

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

在Flink CEP（Complex Event Processing）库中，用于处理连续事件序列的模式匹配时，有以下几个可选项：

1. Strictness（严格性）：指定对于连续事件序列是否要求严格匹配。可选值包括：

- STRICT：要求严格匹配，即每个事件都必须按照定义的顺序严格匹配。

- NOT_STRICT：不要求严格匹配，即事件可以在任意顺序下进行匹配。

2. Greediness（贪婪性）：指定模式匹配时的贪婪程度。可选值包括：

- GREEDY：贪婪匹配，即尽可能多地匹配事件序列，即使可能包含多个匹配结果。

- LAZY：懒惰匹配，即只匹配满足最小匹配条件的事件序列，尽量减少匹配结果。

3. Timeout（超时）：指定等待模式匹配的超时时间。可选值包括：

- INFINITE：无限等待，即一直等待直到模式匹配成功或手动取消等待。

- TIMEOUT：超时等待，即在指定的时间内等待模式匹配成功，超时后返回失败。这些可选项可以根据具体的应用场景和需求进行配置，以实现对连续事件序列的灵活处理。根据严格性、贪婪性和超时设置的不同，可以实现不同的模式匹配行为，并根据具体的业务需求进行定制化。

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

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

20、cep底层如何工作

Flink CEP（Complex Event Processing）库的底层工作原理如下：

1. 事件流输入：首先，Flink CEP接收输入的事件流数据。这些事件可以来自各种源，如Kafka、消息队列、文件等。

2. 事件抽取：Flink CEP从输入的事件流中抽取关键字段，用于后续的模式匹配。这些字段可以通过调用API来指定。

3. 模式定义：Flink CEP用户需要定义要匹配的模式，即一系列事件的规则或模板。模式可以使用Flink CEP提供的API来定义，例如`Pattern.begin()`、`Pattern.next()`、`Pattern.followedBy()`等。

4. 模式匹配：一旦模式被定义，Flink CEP开始对输入的事件流进行模式匹配。它使用基于有限状态机（Finite State Machine）的算法，根据模式的定义逐个事件进行匹配。

5. 匹配结果输出：当一个或多个匹配的模式被找到时，Flink CEP将匹配结果输出。根据用户的需求，匹配结果可以被发送到下游处理逻辑，如写入数据库、发送到消息队列等。在底层，Flink CEP使用了Flink的流处理引擎，利用其强大的事件时间和状态管理机制来实现模式匹配。它将输入的事件流转换为数据流，并使用定时器和状态来跟踪和管理事件的到达和处理。通过有效地利用Flink的并发和分布式特性，Flink CEP能够在大规模数据流上进行高效的模式匹配和处理。

21、cep怎么老化

在Flink CEP（Complex Event Processing）(复杂事件处理)中，可以通过配置老化策略来管理匹配模式的过期和清理。老化是指当某个事件模式不再满足匹配条件时将其从匹配状态中移除，释放系统资源。

Flink CEP提供了两种常见的老化策略：

1. 时间老化（Time-based Aging）：根据时间属性来触发老化。可以通过调用`Pattern.within(Time)`方法来指定时间间隔，在每次匹配事件后，如果在指定的时间间隔内没有新的事件进入该模式，那么该模式将被标记为过期并进行清理。

示例：

```***a

Pattern pattern = Pattern.begin("start").where(/* 过滤条件 */)

.next("middle").where(/* 过滤条件 */)

.within(Time.seconds(10));

```

上述示例中，如果在10秒内没有新的事件进入该模式，那么该模式将被标记为过期并清理。

2. 窗口老化（Window-based Aging）：根据匹配模式的窗口大小来触发老化。可以通过调用`Pattern.within(TimeWindow)`方法来指定窗口大小，在每个窗口结束时，窗口内的匹配模式将被标记为过期并清理。

示例：

```***a

Pattern pattern = Pattern.begin("start").where(/* 过滤条件 */)

.next("middle").where(/* 过滤条件 */)

.within(TimeWindow.of(Time.seconds(10)));

```

上述示例中，如果在10秒的窗口内没有新的事件进入该模式，那么该模式将被标记为过期并清理。

通过使用合适的老化策略，可以在Flink CEP中管理匹配模式的过期和清理，从而避免无效的模式匹配占用过多的系统资源。

22、cep性能调优

调优Flink CEP（Complex Event Processing）的性能可以通过以下几个方面进行优化：

1. 并行度配置：根据应用的需求和计算资源的情况，适当调整Flink CEP的并行度。较高的并行度可以提高处理能力，但也会增加通信和状态管理的开销。可以通过设置`ExecutionConfig.setParallelism()`来调整并行度。

2. 状态后端配置：Flink CEP使用状态来跟踪和管理模式匹配的进展。选择合适的状态后端，如MemoryStateBackend或RocksDBStateBackend，可以影响状态管理的效率和可扩展性。

3. 模式定义优化：优化模式的定义可以提高Flink CEP的性能。避免使用过于复杂的模式，尽量缩小模式的范围。可以通过重构模式定义来减少状态的使用，提高匹配速度。

4. 时间窗口设置：合理设置时间窗口大小和滑动步长，以适应事件流的特性。较小的时间窗口可以提高实时性，但对系统资源的需求也更高。可以通过`Pattern.within(Time.seconds())`来设置时间窗口。

5. 下沉操作优化：在模式匹配成功后，下沉操作可以对匹配结果进行处理，如写入数据库或发送到消息队列。优化下沉操作可以提高整体性能。可以考虑批量写入、异步写入等方式来减少IO开销。

6. 状态清理：Flink CEP使用状态来跟踪模式匹配的进展。及时清理不再需要的状态，如通过定时器或超时机制，可以提高系统的性能和资源利用率。

7. 硬件资源配置：为Flink CEP分配足够的计算资源，包括CPU、内存和网络带宽等。合理调整硬件资源配置可以避免资源瓶颈，提高系统的整体性能。

以上是一些常见的Flink CEP性能调优的方法。根据具体的应用场景和需求，可以选择适合的优化策略，以提高Flink 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 keyed1 = ds1.keyBy(o -> o.getString("key"))

DataStream keyed2 = ds2.keyBy(o -> o.getString("key"))

//右边时间戳-5s

keyed1.intervalJoin(keyed2).between(Time.milliseconds(-5), Time.milliseconds(5))

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分区分配策略

在Flink中，分区分配策略用于指定如何将数据分发到并行任务的子任务之间。Flink提供了多种分区分配策略来满足不同的应用场景和需求，下面是常用的几种分区分配策略：

1. Flink默认分区分配策略（DefaultPartitioner）：默认情况下，Flink会使用DefaultPartitioner来进行分区分配。它是根据数据源的并行度和下游算子的并行度进行分区的，即根据数据源的Key对下游算子的并行任务进行轮询分配。

2. Hash分区分配策略（HashPartitioner）：HashPartitioner会根据数据的Key进行散列分区，将相同Key的数据分配到同一个并行任务的子任务中。这种策略适用于需要按照Key进行分组的场景，可以保证相同Key的数据被发送到同一个子任务中。

3. Range分区分配策略（RangePartitioner）：RangePartitioner会将数据按照一定的范围进行分区，确保相同范围的数据被分配到同一个并行任务的子任务中。这种策略适用于需要按照数据范围进行分区的场景，可以保证相近的数据被发送到同一个子任务中。

4. Custom分区分配策略（CustomPartitioner）：CustomPartitioner允许用户自定义分区逻辑，根据数据的特定特征或业务需求进行分区。用户可以实现Partitioner接口，重写`partition()`方法来自定义分区逻辑。以上是Flink中常用的几种分区分配策略，根据具体的业务场景和需求，选择合适的分区分配策略可以提高作业的性能和效果。

41、Flink关闭后状态端数据恢复得慢怎么办？

如果在Flink关闭之后，状态后端数据恢复得很慢，可能是由于状态后端的配置或者环境问题引起的。

以下是几种可能的解决方法：

1. 调整状态后端的配置：可以通过调整状态后端的配置来提高数据恢复的速度。具体的配置方式取决于所使用的状态后端，例如对于RocksDB状态后端，可以调整相关的配置参数，如`state.backend.rocksdb.block.cache-size`、`state.backend.rocksdb.write-buffer-size`等。可以参考Flink官方文档中有关状态后端的配置参数进行调整。

2. 增加资源：如果状态恢复得慢是由于资源不足导致的，可以尝试增加集群的资源，如增加TaskManager的数量，提升机器的性能等，以提高状态恢复的速度。

3. 优化状态的使用方式：在代码中合理使用状态，可以减少状态的大小和访问频率，从而提高状态的恢复速度。可以考虑使用更加紧凑的数据结构、压缩数据等方式来减小状态的大小。

4. 使用增量快照：Flink支持增量快照的方式来进行状态的持久化和恢复。增量快照只会记录状态的变化部分，可以显著减少快照的大小和恢复的时间。可以在代码中启用增量快照，使用`StateBackend`的`enableIncrementalCheckpointing`方法进行配置。

5. 检查状态后端的性能和配置：如果以上方法仍然无法解决问题，可以检查状态后端的性能和配置。可以检查状态后端所在的机器的硬盘、网络等性能，确保其能够满足状态恢复的需求。同时，也可以检查状态后端的配置是否合理，如并发读写数、IO线程数等。如果以上方法都无法解决问题，可以考虑联系Flink社区寻求更多的帮助和支持。

42、了解flink的savepoint吗？讲一下savepoint和checkpoint的不同和各有什么优势

Savepoint和Checkpoint是Flink中用于实现容错机制的两个重要概念，它们有以下不同和各自的优势：

1. Savepoint（保存点）：

Savepoint是一种手动触发的全局状态快照，用于保存整个应用程序的状态信息。Savepoint可以手动触发，也可以在应用程序运行期间自动定期触发。Savepoint保存了应用程序的整个状态信息，包括所有算子的状态和作业的元数据。Savepoint可以用于应用程序版本升级、任务迁移、故障恢复等场景。

优势：

- 全局状态：Savepoint保存了整个应用程序的状态信息，可以实现全局的状态恢复。

- 灵活性：可以手动触发Savepoint，也可以在运行期间自动定期触发。

- 应用程序管理：Savepoint包含了应用程序的元数据，可以用于应用程序版本管理和任务迁移。

2. Checkpoint（检查点）：

Checkpoint是一种自动触发的局部状态快照，用于保存算子的状态信息。Checkpoint是通过周期性的机制自动触发的，可以设置触发的时间间隔。Checkpoint只保存了每个算子的状态信息，不包含应用程序的元数据。

优势：

- 局部状态：Checkpoint只保存了每个算子的状态信息，因此可以在故障恢复时仅恢复受影响的算子，而不需要恢复整个应用程序的状态。

- 低延迟：由于Checkpoint只保存了局部状态，因此相对于Savepoint来说，生成和恢复Checkpoint的时间更短，可以实现较低的恢复延迟。

总结：Savepoint适用于全局状态的保存和恢复，可以用于应用程序版本管理、任务迁移等场景。Checkpoint适用于局部状态的保存和恢复，可以实现较低的恢复延迟。在实际应用中，通常会同时使用Savepoint和Checkpoint来实现全局和局部的容错机制。

43、flink的状态后端机制

Flink的状态后端是Flink在做checkpoint的时候将状态快照持久化，有三种状态后端 Memery、HDFS、RocksDB

44、flink中滑动窗口和滚动窗口的区别，实际应用的窗口是哪种？用的是窗口长度和滑动步长是多少？

在Flink中，滑动窗口（Sliding Window）和滚动窗口（Tumbling Window）是两种常用的窗口类型，它们有以下区别：

1. 窗口定义：滑动窗口由一个固定大小的窗口长度和一个滑动步长组成，窗口会在数据流中根据滑动步长连续滑动并生成不重叠的窗口。滚动窗口也由一个固定大小的窗口长度组成，但是滚动窗口不会滑动，而是固定在数据流上。

2. 窗口边界：在滑动窗口中，窗口的边界是根据事件时间进行调整的。对于一个滑动窗口，如果一个事件的时间戳在窗口的起始时间和结束时间之间，那么该事件将被分配到该窗口中。在滚动窗口中，窗口的边界是固定的，即所有事件被分配到具有相同起始和结束时间的窗口中。

3. 重叠与不重叠：滑动窗口允许窗口之间存在重叠，即相邻窗口之间的数据可以共享。而滚动窗口是不重叠的，每个窗口的数据是独立的。

4. 窗口计算：对于滑动窗口，窗口计算是连续的。每当数据流中的事件进入或离开窗口时，都会触发窗口计算。对于滚动窗口，窗口计算是离散的。只有当一个完整的窗口的所有事件都进入后，才会触发窗口计算。

使用滑动窗口和滚动窗口取决于应用场景和需求。滑动窗口通常用于需要对连续时间范围内的数据进行计算和分析的场景，例如计算最近一小时的用户活跃度。滚动窗口通常用于对固定时间范围内的数据进行计算和统计的场景，例如计算每分钟的交易总额。

在Flink中，可以使用Window API来定义滑动窗口和滚动窗口，并应用相应的窗口函数来对窗口内的数据进行处理。

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，有啥区别？

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

1. 数据处理模型：Spark Streaming使用微批处理模型，将实时数据流划分为一系列的小批次进行处理。而Flink使用连续流处理模型，能够以事件时间为基准进行连续的流处理。

2. 延迟和吞吐量：由于Spark Streaming使用批处理模型，其处理延迟相对较高，一般在几秒到数秒之间。而Flink使用连续流处理模型，能够实现更低的处理延迟，一般在毫秒级别。

3. 状态管理：Spark Streaming使用弹性分布式数据集（RDD）作为中间结果的数据结构，通过RDD的转换和操作来完成状态管理。而Flink使用内部状态（Internal State）来管理状态，能够更灵活地处理状态的更新和维护。

4. 容错机制：Spark Streaming使用基于RDD的容错机制，通过记录批次数据的元数据和日志来实现容错。而Flink使用基于快照的容错机制，能够在事件时间和处理时间上提供一致性保证，并支持精确一次性（Exactly-once）语义。

5. 窗口处理：Spark Streaming提供了基于时间的窗口和滑动窗口的处理机制，但在处理窗口边界和交叉窗口等特殊情况时相对复杂。而Flink提供了灵活且功能强大的窗口操作，支持事件时间和处理时间的窗口计算，以及各种窗口模式的定义和处理。

6. 一体化批流处理：Spark Streaming提供了一体化的批流处理模型，可以在相同的代码和API上同时处理实时流数据和离线批处理数据。而Flink更加专注于流处理，虽然也提供了对批处理的支持，但在处理实时流数据方面更为突出和成熟。

总的来说，Spark Streaming适用于对延迟要求相对较高的场景，且对精确一次性语义要求不太严格的应用。而Flink适用于对低延迟和精确一次性语义有较高要求的实时流处理场景。选择哪个流处理引擎取决于具体的业务需求和性能要求。

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

Flink将StreamGraph转换为JobGraph是在流处理应用程序提交到Flink集群之前的阶段。这个阶段通常称为作业图（JobGraph）构建阶段。在构建作业图的过程中，Flink会对StreamGraph进行优化和转换，以生成最终的JobGraph，用于在Flink集群上执行。这个过程包括以下几个步骤：

1. 算子转换：Flink将StreamGraph中的每个算子（operator）转换为对应的JobVertex（作业顶点），每个JobVertex表示在集群中运行的一个实例。

2. 任务分配：Flink根据算子之间的依赖关系和拓扑结构，将JobVertex划分为不同的任务（task）。每个任务表示一个并行运行的子任务。

3. 算子实例化：Flink将每个JobVertex实例化为一个或多个任务实例。任务实例是作业图中最小的执行单元，可以在集群中的不同任务管理器上并行执行。

4. 边缘连接：Flink根据StreamGraph中的边缘连接关系，将任务实例连接起来，以便进行数据流的传输和通信。

5. 优化转换：Flink对作业图进行优化转换，以提高执行效率和性能。这包括任务调度优化、资源分配优化、流水线优化等。

6. 作业图生成：最后，Flink将转换后的JobGraph提交给Flink集群，用于调度和执行流处理应用程序。总而言之，将StreamGraph转换为JobGraph是在提交作业之前的阶段，它将流处理应用程序转化为可在Flink集群上执行的作业图，以实现对流处理任务的调度和执行。

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

还有kafka数据顺序消费的处理。

50、flink你一般设置水位线设置多少

我们之前设置的水位线是6s

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如何实现在指定时间进行计算。

在Flink中，可以通过窗口操作来实现在指定时间进行计算。窗口是Flink中的一个重要概念，用于将无限的流数据划分为有限的、有序的数据块，以便进行有状态的计算。窗口可以基于时间或者其他维度对数据进行划分。对于基于时间的窗口计算，Flink提供了不同类型的窗口，如滚动窗口、滑动窗口、会话窗口等。可以根据需求选择合适的窗口类型。在窗口操作中，可以通过指定窗口大小和滑动步长来定义窗口的时间范围。窗口会根据数据的时间戳进行划分，将具有相同时间范围的数据分配到同一个窗口中。一旦窗口的时间范围到达，Flink会触发窗口操作，对窗口中的数据进行计算。可以使用各种算子和函数来进行计算，如聚合函数、map、reduce等。需要注意的是，窗口操作是有状态的操作，需要维护窗口中的数据和计算结果。Flink会自动管理窗口状态，可以选择不同的状态后端来存储和管理状态。通过窗口操作，可以在指定的时间范围内对流数据进行计算，实现各种实时统计和聚合分析的需求。可以根据具体的业务场景和需求来选择合适的窗口类型和窗口参数，以满足计算的精度和实时性要求。

55、手写Flink topN

topN是指在一个数据集中，找出前N个最大或最小的元素。例如，在一个销售数据集中，我们需要找出销售额最高的前10个商品，这就是一个topN操作。

实现Flink的TopN功能可以使用Flink的KeyedProcessFunction或者ProcessWindowFunction结合状态来实现。以下是一个简单的手写TopN的示例代码：

```java

public class TopNFunction extends ProcessWindowFunction, String, String, TimeWindow> {

private int n;

private transient ListState> topNState;

public TopNFunction(int n) {

this.n = n;

}

@Override

public void open(Configuration parameters) throws Exception {

ListStateDescriptor> descriptor =

new ListStateDescriptor<>("topNState", TypeInformation.of(new TypeHint>() {}));

topNState = getRuntimeContext().getListState(descriptor);

}

@Override

public void process(String key, Context context, Iterable> input, Collector out) throws Exception {

// 将窗口中的数据保存到状态中

for (Tuple2 element : input) {

topNState.add(element);

}

// 获取窗口结束时间

long windowEnd = context.window().getEnd();

// 定义一个列表，用于保存TopN的结果

List> topNList = new ArrayList<>();

// 遍历状态中的数据，取出TopN

for (Tuple2 element : topNState.get()) {

topNList.add(element);

}

// 按照元素的值进行降序排序

topNList.sort((o1, o2) -> o2.f1 - o1.f1);

// 取出前N个元素

topNList = topNList.subList(0, Math.min(n, topNList.size()));

// 清空状态中的数据

topNState.clear();

// 输出TopN结果

for (Tuple2 element : topNList) {

out.collect("时间窗口: " + windowEnd + "，元素: " + element.f0 + "，次数: " + element.f1);

}

}

}

```

使用示例：

```java

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

DataStream> dataStream = ... // 输入数据流

dataStream

.keyBy(data -> data.f0) // 按照key进行分组

.window(TumblingEventTimeWindows.of(Time.seconds(5))) // 设置窗口大小为5秒

.process(new TopNFunction(3)) // 计算Top3

.print();

env.execute("TopN Example");

```

以上示例实现了一个简单的TopN功能，在每个5秒的窗口中计算出出现频率最高的前3个元素，并输出结果。你可以根据需要修改代码来实现其他的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、Flink优化 你了解多少

Flink作为一个强大的流处理框架，可以通过多种方式进行优化，以提高性能和效率。

以下是一些常见的Flink优化策略：

1. 并行度选择：合理设置任务的并行度可以充分利用集群资源，提高计算效率。可以通过实验和性能测试来确定最佳的并行度。

2. 状态管理：对于具有状态的算子，可以根据需求选择适当的状态后端来存储和管理状态信息，如使用内存、RocksDB等。同时，可以根据业务特点和数据量来调整状态的划分和大小。

3. 状态清理：定期清理过期的状态数据可以节省存储空间和提高查询性能。可以使用定时任务或者基于时间的触发器来清理不再需要的状态。

4. 内存管理：合理设置Flink的内存参数，如堆内存大小、堆外内存大小等，以及JVM参数，如GC策略、内存分配等，可以提升内存利用率和减少GC对性能的影响。

5. 窗口操作优化：对于窗口操作，可以选择合适的窗口类型和触发器，以最大限度地减少计算和数据的移动，提高计算效率。

6. 操作链优化：通过合理设置操作链，将多个算子合并在一起执行，减少数据的序列化和反序列化开销，从而提高计算性能。

7. 数据倾斜处理：对于存在数据倾斜的情况，可以使用一些技术手段进行处理，如使用随机键来均匀分布数据、使用重分区操作来平衡数据分布等。

8. 广播变量：对于需要在任务之间共享的数据，可以使用广播变量，避免数据的重复传输和复制，提高计算效率。

9. 算子链合并：将多个算子链合并成一个大的算子链，可以减少数据的序列化和反序列化开销，提高计算性能。

10. 调优和监控：定期监控Flink作业的运行情况，收集关键指标和日志，根据性能瓶颈进行调优，如调整并行度、调整资源分配等。这些优化策略可以结合具体的业务场景和需求来使用，根据实际情况进行调整和优化，以提高Flink作业的性能和效率。

62、Flink内存溢出怎么办

当在Flink作业中遇到内存溢出问题时，可以尝试以下几种方法来解决：

1. 增加可用内存：可以通过调整Flink任务管理器的内存分配来增加可用内存。可以通过修改`taskmanager.memory.process.size`和`taskmanager.memory.jvm-overhead.max`参数来增加任务管理器的内存限制。

2. 减少数据量：如果作业处理的数据量较大，可以尝试减少数据量来减轻内存压力。可以通过对数据进行过滤、分区、聚合等操作来减少数据量。

3. 使用内存优化算法：Flink提供了一些内存优化算法来减少内存使用量，如使用布隆过滤器、压缩算法等。可以根据场景选择合适的优化算法来减少内存占用。

4. 增加并行度：可以通过增加任务的并行度来分散数据和计算负载，从而减少单个任务的内存使用量。

5. 调整状态大小：如果作业中使用了有状态的算子，可以尝试减小状态的大小来减少内存占用。可以使用Flink提供的状态后端来管理状态，以便在内存不足时将状态存储在外部存储系统中。

6. 使用外部存储系统：如果内存不足，可以考虑将部分数据存储在外部存储系统中，如Hadoop HDFS、Amazon S3等。可以使用Flink提供的连接器来读取和写入外部存储系统中的数据。

7. 使用更高版本的Flink：Flink不断更新和优化内存管理机制，使用最新版本的Flink可能会有更好的内存管理性能。

除了上述方法，还可以通过监控和分析内存使用情况，查看具体的内存溢出原因，并根据实际情况采取相应的优化措施。

63、说说Flink中的keyState包含哪些数据结构

在Flink中，keyState是用于存储有状态算子中的键控状态的数据结构。keyState可以存储和管理与特定键相关联的状态信息。keyState主要有以下几种数据结构：

1. ValueState：ValueState是最简单的键控状态，用于存储一个单一的值。可以将ValueState视为键值对的形式，其中键是由当前处理的数据流中的键控状态的键决定的，而值是与该键关联的状态值。

2. ListState：ListState用于存储一个列表。可以将ListState视为键值对的形式，其中键是由当前处理的数据流中的键控状态的键决定的，而值是一个列表，可以向列表中添加、删除和查询元素。

3. ReducingState：ReducingState用于存储一个可被重复聚合的值。可以将ReducingState视为键值对的形式，其中键是由当前处理的数据流中的键控状态的键决定的，而值是一个可被重复聚合的值。每当有新的值添加到ReducingState中时，Flink会将新值与已经存在的值进行聚合。

4. FoldingState：FoldingState用于存储一个可被重复折叠的值。可以将FoldingState视为键值对的形式，其中键是由当前处理的数据流中的键控状态的键决定的，而值是一个可被重复折叠的值。每当有新的值添加到FoldingState中时，Flink会使用指定的折叠函数将新值与已经存在的值进行折叠。这些数据结构可以根据具体的业务需求选择使用，用于存储和管理与键相关联的状态信息，实现有状态的数据处理和计算。

64、Flink shardGroup的概念

在Flink中，shardGroup(碎片组)是用于将数据流分区进行逻辑分组的概念。

在流处理中，数据流可以被分为多个并行的子流，每个子流都会被分配给不同的任务进行处理。而shardGroup的作用是将这些并行的子流进行逻辑上的分组，以便在后续的操作中能够对同一组的子流进行特定的处理。

shardGroup通常在keyBy操作之后使用，keyBy操作会根据指定的键对数据流进行重分区，将相同键的数据分配到同一个并行任务中。而shardGroup则是在重分区之后，对具有相同键值的子流进行进一步的分组。

通过shardGroup，可以将具有相同键值的子流分配到同一个并行任务中，这样可以保证具有相同键值的数据在同一个任务中进行处理，从而实现有状态的操作。shardGroup可以用于进行有状态的聚合、窗口操作等，有助于提高处理效率和减少数据交换。

需要注意的是，shardGroup只是逻辑上的分组，不会改变数据的物理分区和并行度。具体的任务分配和数据交换仍然由Flink的任务调度器和数据流的分区机制来负责。

————————————————

版权声明：本文为CSDN博主「中国好胖子、」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：64道企业真实Flink题目让你无惧Flink面试（带答案）_flink面试题-CSDN博客