提高Flink广播性能
我有一个管道，我在其中对事件流应用转换规则（从广播状态）；当我运行广播时
我已附上两种情况的快照：
- 顶部行显示来自Kafka的流消耗事件，底部行显示消耗的规则
共有1个答案
您所做的不仅仅是简单地连接广播和键控流。以前，每个事件只经历一次网络洗牌（重新平衡、哈希和广播连接），现在每个事件有四到五次洗牌。
每次洗牌都很昂贵。尝试减少更改并行性或使用keyBy的次数。
-
我尝试在我的flink应用程序中使用广播状态模式，但经过一些研究，我做了以下工作： 在中，我读取数据，并根据来自的数据对数据进行一些逻辑处理并发出一些元素。基本上，我使用就像广播状态模式一样。我没有专门使用广播，因为没有简单的方法可以从访问我的某些状态。由于我的配置流被用作清理状态的指示符，我在我的中拥有。 流是<代码>。keyBy所以我不希望出现并行性问题 我的问题是，还需要广播哪些案例？在什么
-
在广播模式的文档中，提到没有RocksDB状态后端： 如果应用程序使用rocksdb作为状态后端，这将如何影响保存点行为？这是否意味着状态在保存点期间不存储，因此不会恢复？
-
我们试图构建一个用例，其中来自流的数据通过计算公式运行，但公式本身也应该（很少）是可更新的。从阅读文档来看，在我看来，Flink broadcast state自然适合这种情况。 作为一个实验，我构建了一个简化的版本：假设我有一个整数流，第二个流包含这些整数的乘法因子（我可以随意发送值）。第二个流的频率很低，很容易在事件之间的几天或几周内出现。目前，这两个都实现为简单的套接字服务器，最终产品将使用
-
有1个高通量Kafka流定义如下 上述窗口操作符的水印正确转发。 上述窗口操作符中的需要使用一些保存在某些S3文件中的信息来丰富。S3文件很少更新。 S3文件作为流读取，然后广播以丰富中的元素。 然后连接这两个流，用类型的元素来丰富类型的所有元素。 有2个输入。其中之一是不断转发水印，但广播流没有任何时间信息或水印。这导致EnrichedAProcess的水印根本无法转发，因为它的一个输入没有传入
-
我正在使用一个Flink流式Java应用程序，输入源为Kafka。在我的应用程序中总共使用了4个流。一个是主数据流，另一个3个用于广播流。 我加入了使用任何一种类型的三个广播流。我已经作为流B广播，并且能够在广播过程函数上下文状态（即在processBroadcastElement（））中接收。 我的问题是, > 是否可以在广播状态下存储大数据？ 注意：根据我的理解，Flink广播状态在运行时保存
-
输出如下： 如果两个数组的维数不相同，则元素到元素的操作是不可能的。 然而，在 NumPy 中仍然可以对形状不相似的数组进行操作，因为它拥有广播功能。 较小的数组会广播到较大数组的大小，以便使它们的形状可兼容。 如果满足以下规则，可以进行广播： 如果输入在每个维度中的大小与输出大小匹配，或其值正好为 1，则在计算中可它。 如果上述规则产生有效结果，并且满足以下条件之一，那么数组被称为可广播的。 数