Kafka流：KTable物化

Question

如何识别主题的KTable物化何时完成？

例如，假设KTable只有几百万行。下面的伪代码：

KTable<String, String> kt = kgroupedStream.groupByKey(..).reduce(..); //Assume this produces few million rows

在某个时间点，我想安排一个线程来调用以下内容，该内容写入主题：kt.toStream().to（“output_topic_name”）；

跟进问题：

约束
1)好的，我看到kstream和ktable在kafkastream启动后是无界/无限的。但是，ktable物化（压缩主题）不会在指定的时间段内为同一个键发送多个条目吗。

因此，除非压缩过程尝试清除这些条目并只保留最新的条目，否则下游应用程序将消耗来自主题的相同密钥查询的所有可用条目，从而导致重复。即使压缩过程进行了某种级别的清理，在给定的时间点，当压缩过程正在追赶时，总是不可能有一些键具有多个条目。

2）ReadOnlyKeyValueStore可能允许从存储区进行受控检索，但它仍然缺乏调度检索键、值和写入主题的方法，这需要额外的编码。

可以改进API以允许受控的物化吗？

Answer 1

KTable物化永远不会完成，您也不能“调用”to()。

当您使用Streams API时，您将一系列操作符“插在一起”。实际的方法调用，不触发任何计算，但修改操作符的DAG。

只有通过kafkastreams#start()开始计算之后，才会处理数据。请注意，在计算开始后，您指定的所有运算符都将连续并发地运行。

是的。您必须将KTable看作是一个“版本化表”，它在条目更新时随时间演变。因此，所有更新都被写入changelog主题，并作为变更记录向下游发送（注意，KTables也进行了一些缓存，以“消除”对同一键的连续更新的重复：参见https://docs.confluent.io/current/streams/developer-guide/memory-mgmt.html）。

将消耗来自主题的相同密钥查询的所有可用条目，从而导致重复。

我不认为这些是“重复的”，而是更新的。是的，应用程序需要能够正确处理这些更新。

如果我们有一种方法来安排物化，那将有助于避免重复。

物化是一个连续的过程，只要输入主题中有新的输入记录可用并进行处理，就会更新KTable。因此，在任何时间点都可能有特定密钥的更新。因此，即使您完全控制何时向changelog主题和/或下游发送更新，稍后也可能会有新的更新。这就是流处理的本质。

此外，还可以减少主题中持久化的数据量（增加存储），增加网络流量，增加压缩过程的额外开销来清理它。