Question

就我而言，我正在执行hopping window，例如(100sec,1sec)。

KTable<Windowed<String>, aggrTest> WinMinMax = Records.groupByKey().aggregate(new aggrTestInitilizer(), 
        new minMaxCalculator()
        , TimeWindows.of(TimeUnit.SECONDS.toMillis(100)).advanceBy(TimeUnit.SECONDS.toMillis(1)),aggrMessageSerde);

但是这里100sec窗口中的消息数量非常大，这会导致窗口执行需要很长时间。所以，要改善这个窗口执行时间，

我想避免将数据写入中间聚合状态存储（默认情况下kafka流写入）。
另外如果（1）不可能，那么我们可以将窗口生成的中间聚合状态存储在RAM而不是磁盘中吗？（对它们的设置是什么？）
是否有进一步改善窗口执行时间的建议？

Answer 1

不确定您是如何实现MinMaxCalculator()的，但我认为它只是将当前的最小值/最大值与新值进行比较。因此，商店仅包含当前聚合。 - 因此，窗口大小根本不重要，与窗口大小无关，只存储密钥和当前聚合结果。

为您解答问题：

根据设计，聚合需要商店来保持当前的聚合结果 - 因此，您无法摆脱商店。
是的，您可以使用内存存储。 aggregate()方法有一个重载，允许您放置自定义存储，并且有实用程序类来创建内存存储。查看文档（顺便说一句：那些API在Kafka 1.0中得到了很多简化，所以如果你不使用1.0，我建议升级）：https://docs.confluent.io/current/streams/developer-guide/processor-api.html#enable-or-disable-fault-tolerance-of-state-stores-store-changelogs
如上所述，窗口的大小不会影响您的计算速度＆＃34;速度＆＃34;

附注：


如果你使用内存状态而不是RocksDB，你可以将商店大小限制在你的RAM大小 - 如果你的保留时间很长，这可能会成为一个问题，因为状态会变得很大

如果你进行滚动跳转，这需要更多时间，因为需要通过阅读完整的更改日志主题来重新创建状态 - RocksDB存储可以从本地磁盘恢复更快的速度

您可以尝试使用RocksDB并增加KTable缓存大小以提高性能：https://docs.confluent.io/current/streams/developer-guide/memory-mgmt.html

避免在Kafka Streams中写入中间聚合存储

1 个答案: