原文：https://data-artisans.com/blog/broadcast-state-pattern-flink-considerations
作者：Markos Sfikas
译者：云邪（Jark）

在 Apache Flink 1.5.0 中引入了广播状态（Broadcast State）。本文将描述什么是广播状态模式（Broadcast State Pattern），广播状态与其他的 Operator State 有什么区别，最后，我们在 Flink 中使用该功能时需要考虑的一些重要的注意事项。

什么是广播状态模式

广播状态模式指的一种流应用程序，其中低吞吐量的事件流（例如，包含一组规则）被广播到某个 operator 的所有并发实例中，然后针对来自另一条原始数据流中的数据（例如金融或信用卡交易）进行计算。 广播状态模式的一些典型应用案例如下：

• 动态规则：例如，有一个规则：当某个交易超过100万美元时需要发一个警报。我们将这个规则广播到计算交易的算子的所有并发实例中。
• 数据丰富：例如，将用户的详细信息作业广播状态进行广播，对包含用户ID的交易数据流进行数据丰富。

为了实现这样的应用，关键组件是广播状态，我们将在下文详细描述。

什么是广播状态？

广播状态是 Apache Flink 中支持的第三种类型的 operator state。广播状态使得 Flink 用户能够以容错、一致、可扩缩容地将来自广播的低吞吐的事件流数据存储下来。来自另一条数据流的事件可以流经同一 operator 的各个并发实例，并与广播状态中的数据一起处理。有关其他类型的状态，以及如何使用请访问 Flink 官方文档。

广播状态与其他 operator state 之间有三个主要区别。与其余的 operator state 相反，广播状态：

• Map 的格式
• 有一条广播的输入流
• operator 可以有多个不同名字的广播状态

可以查阅我们之前的博客文章，探索 Apache Flink 中使用广播状态的实践指南。

重要注意事项

对于急切开始使用广播状态的 Flink 用户，Apache Flink 官方文档提供了有关 API 的详细指南，以及在应用程序中如何使用该功能。在使用广播状态时要记住以下4个重要事项：

• 使用广播状态，operator task 之间不会相互通信

  这也是为什么(Keyed)-BroadcastProcessFunction上只有广播的一边可以修改广播状态的内容。用户必须保证所有 operator 并发实例上对广播状态的修改行为都是一致的。或者说，如果不同的并发实例拥有不同的广播状态内容，将导致不一致的结果。

• 广播状态中事件的顺序在各个并发实例中可能不尽相同

  虽然广播流的元素保证了将所有元素（最终）都发给下游所有的并发实例，但是元素的到达的顺序可能在并发实例之间并不相同。因此，对广播状态的修改不能依赖于输入数据的顺序。

• 所有 operator task 都会快照下他们的广播状态

  在 checkpoint 时，所有的 task 都会 checkpoint 下他们的广播状态，并不仅仅是其中一个，即使所有 task 在广播状态中存储的元素是一模一样的。这是一个设计倾向，为了避免在恢复期间从单个文件读取而造成热点。然而，随着并发度的增加，checkpoint 的大小也会随之增加，这里会存在一个并发因子 p 的权衡。Flink 保证了在恢复/扩缩容时不会出现重复数据和少数据。在以相同或更小并行度恢复时，每个 task 会读取其对应的检查点状态。在已更大并行度恢复时，每个 task 读取自己的状态，剩余的 task （p_new-p_old）会以循环方式（round-robin）读取检查点的状态。

• RocksDB 状态后端目前还不支持广播状态

  广播状态目前在运行时保存在内存中。因为当前，RocksDB 状态后端还不适用于 operator state。Flink 用户应该相应地为其应用程序配置足够的内存。