Flink广播状态-RocksDB状态后端
在广播模式的文档中，提到没有RocksDB状态后端：
No RocksDB state backend: Broadcast state is kept in-memory at runtime and memory provisioning should be done accordingly. This holds for all operator states.
如果应用程序使用rocksdb作为状态后端，这将如何影响保存点行为？这是否意味着状态在保存点期间不存储，因此不会恢复？
共有1个答案
广播状态包含在保存点和检查点中。
Flink区分键控和非键控状态。Flink管理的所有状态，包括键控和非键控状态，都包含在保存点和检查点中。
广播状态是一种非键控状态，与所有非键控状态一样，不存储在RocksDB中。当RocksDB用作状态后端时，这意味着键控状态的工作状态保留在RocksDB中，而不是堆中。拍摄状态快照（即保存点或检查点）时，RocksDB的此状态加上所有未设置关键帧的状态将写入快照。
-
我尝试在我的flink应用程序中使用广播状态模式，但经过一些研究，我做了以下工作： 在中，我读取数据，并根据来自的数据对数据进行一些逻辑处理并发出一些元素。基本上，我使用就像广播状态模式一样。我没有专门使用广播，因为没有简单的方法可以从访问我的某些状态。由于我的配置流被用作清理状态的指示符，我在我的中拥有。 流是<代码>。keyBy所以我不希望出现并行性问题 我的问题是，还需要广播哪些案例？在什么
-
我在同一份flink jobs中读了两个Kafka主题。 ：来自第一个主题的消息被保存到rocksdb，然后它将与Stream2联合。 ：来自第二个主题的消息被Stream1保存的状态所丰富，然后它将与Stream1联合。 主题1和主题2是不同的来源，但两个来源的输出基本相同。我必须用topic1的数据来充实topic2的数据。 这里是流动； 这里是问题； 那个流量好吗？ 可以访问由保存的相同的状
-
我们试图构建一个用例，其中来自流的数据通过计算公式运行，但公式本身也应该（很少）是可更新的。从阅读文档来看，在我看来，Flink broadcast state自然适合这种情况。 作为一个实验，我构建了一个简化的版本：假设我有一个整数流，第二个流包含这些整数的乘法因子（我可以随意发送值）。第二个流的频率很低，很容易在事件之间的几天或几周内出现。目前，这两个都实现为简单的套接字服务器，最终产品将使用
-
我的Flink作业从kafka主题读取并将数据存储在RocksDB状态后端，以利用可查询状态。我能够在本地机器中运行作业并查询状态。但是在集群上部署时，我收到以下错误： 我已经尝试在集群级别和作业级别设置rocksDB状态后端。当它设置为作业级别时，我已将其作为阴影依赖项提供。我也尝试在主机集群机器上编译代码。我在所有情况下都会得到相同的错误。 如何解决此错误？
-
在阅读了Flink的文档并四处搜索后，我无法完全理解Flink的句柄在其窗口中的状态。假设我有一个每小时滚动的窗口，其中包含一个聚合函数，该函数将消息累积到某个java pojo或scala case类中。该窗口的大小将与一小时内进入该窗口的事件数量相关联，还是仅仅与POJO/Case类相关联，因为我将事件累加到该对象中。（例如，如果将10000个味精数成一个整数，大小会接近10000*味精大小还
-
主要内容：1.算子状态概述,2.算子状态 编程案例,3.状态持久化和状态后端,4.状态编程总结1.算子状态概述 1.1 算子状态分类 算子状态: 列表状态, 联合列表状态, 广播状态 ListState, UnionListState, BroadcastState 1.2 状态分析 列表状态: 与 Keyed State 中的 ListState 一样，将状态表示为一组数据的列表。与 Keyed State 中的列表状态的区别是：在算子状态的上下文中，不会按键（key）分别处理状态，所以