Flink中的广播状态模式：使用时4个重要考虑因素

问题导读

1.什么是广播状态模式？？
2.什么是广播状态？
3.使用广播状态时要注意哪4个重要事项？

关注最新经典文章，欢迎关注公众号

这篇文章探讨了Apache Flink 1.5.0中引入的广播状态模式。在下面的部分中，我们将描述什么是广播状态模式，广播状态与其他类型的算子状态的区别，最后，我们在Flink中使用该功能时会考虑哪些重要的注意事项。

什么是广播状态模式？
广播状态模式指的是流应用程序的低吞吐量事件流（例如，包含一组规则），其中被广播到算子（operator ）的所有并行实例，然后针对来自另一个事件流的原数据所有元素评估（例如金融或信用卡交易）。广播状态模式的一些用例如下：

将规则从低吞吐量事件流应用到原始传入数据：例如，当事务值超过100万美元到operator 的所有并行任务时，广播应发送警报的规则。
数据丰富：例如，丰富包含用户ID的事务（transactions ）流，以及与该用户ID相关联的广播数据。

为了允许这样的applications，关键组件是 Broadcast State，我们在下面描述。

什么是广播状态？
广播状态是Flink中第三种受支持的operator状态。广播状态使Flink用户能够以容错和可重新扩展的方式存储来自广播的低吞吐量事件流的元素（参见上面的示例）。然后，来自第二流（另外一个流）的事件可以流经同一operator的各个实例，该operator将其与广播状态中的事件一起处理。有关其他类型的状态以及如何使用它们的更多信息，请访问此处的Flink文档。

广播状态与其他operator状态之间存在三个主要差异。和其余类型的operator状态不同，Broadcast State：

有map 格式
输入广播事件流
operator任务可以具有多个具有不同名称的广播状态。

重要考虑因素
对于热衷于开始使用Broadcast State的Flink用户，Flink文档提供了有关API以及如何在管道中使用该功能的详细信息。

使用广播状态时要记住以下4个重要事项：

使用广播状态，operator 任务不会相互通信
这就是为什么只有（Keyed）-BroadcastProcessFunction的广播端可以修改广播状态的内容的原因。用户应确保所有operator 任务以相同的方式为每个传入元素修改广播状态的内容。或者，不同的任务可能具有不同的内容，从而导致不一致的结果。

广播状态中的事件顺序可能因任务而异
虽然广播流的元素保证所有元素将（最终）转到所有下游任务，但元素可能以不同的顺序到达每个任务。因此，每个传入元素的任何状态更新都不应取决于传入事件的顺序。

所有operator 任务都checkpoint 自己的广播状态
即使所有任务在其广播状态中存储相同的元素，在checkpoint 时，所有任务都检查它们的广播状态，而不仅仅是其中一个。这是一个设计决策，以避免在恢复期间从单个文件读取并因此避免热点。然而，将checkpoint 状态的大小增加一个因子p（=并行性）是一种权衡。。 Flink保证在恢复/重新缩放时不会出现重复或丢失数据。在具有相同或更小并行度的恢复的情况下，每个任务读取其检查点状态。在按比例放大时，每个任务都会读取自己的状态，其余任务（p_new-p_old）以循环方式读取先前任务的检查点。

RocksDB状态backend 不适用于广播状态
广播状态在运行时保存在内存中。从目前开始，RocksDB状态backend 不适用于operator状态，Flink用户应相应地为所有operator状态安排其应用程序的内存配置。