转载自Jark's Blog,文末有详细信息。

在 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 用户应该相应地为其应用程序配置足够的内存。
    

标签: flink

添加新评论