如何识别主题的ktable物化何时完成？
例如，假设ktable有几百万行。伪代码如下：
KTable<String, String> kt = kgroupedStream.groupByKey(..).reduce(..); //Assume this produces few million rows在某个时候，我想安排一个线程来调用以下内容，即写入主题：kt.tostream（）.to（“output_topic_name”）；
我想确保所有数据都是作为上述调用的一部分编写的。另外，一旦调用了上述“to”方法，是否可以在下一个计划中调用它，或者第一个调用是否始终保持活动状态？
后续问题：
约束条件
1） 好的，我看到一旦kafkastream启动，kstream和ktable是无限的。但是，ktable materialization（压缩主题）不会在指定的时间段内为同一个键发送多个条目。
因此，除非压缩过程试图清除这些内容并只保留最新的内容，否则下游应用程序将使用来自主题的同一关键字查询的所有可用条目，从而导致重复。即使压缩过程进行了某种程度的清理，但在给定的时间点上，由于压缩过程正在进行，因此始终不可能存在某些键具有多个条目。
我假设ktable在rocksdb中对于给定的密钥只有一个记录。如果我们有办法安排物化，那将有助于避免重复。另外，减少主题中持久化的数据量（增加存储），增加网络通信量，为清理压缩过程增加额外的开销。
2） 也许readonlykeyvaluestore允许从存储中进行受控的检索，但是它仍然缺乏计划检索关键字、值和写入主题的方法，这需要额外的编码。
是否可以改进api以允许受控的物化？
1条答案
按热度按时间piztneat1#
一个ktable物化永远不会完成，你不能“调用”一个
to()任何一个。当您使用streams api时，您将一个dag操作符“插在一起”。实际方法调用时，不触发任何计算，而是修改运算符的dag。
只有在你通过
KafkaStreams#start()数据已处理。请注意，您指定的所有运算符都将在计算开始后连续并发运行。没有“计算结束”，因为上游应用程序可以随时将新数据写入输入主题，因此输入应该是无界/无限的。因此，您的程序永远不会自行终止。如果需要，可以通过
KafkaStreams#close()不过。在执行过程中，不能更改dag。如果要更改它，需要停止计算并创建一个新的
KafkaStreams将修改后的dag作为输入的示例跟进：
对。您必须将ktable视为一个“版本表”，它在条目更新时会随着时间的推移而变化。因此，所有更新都会写入changelog主题，并作为更改记录发送到下游（注意，ktables也会进行一些缓存，以“消除”对同一个键的连续更新：cf。https://docs.confluent.io/current/streams/developer-guide/memory-mgmt.html).
将使用主题中相同键查询的所有可用条目，从而导致重复。
我不认为这些是“重复”，但作为更新。是的，应用程序需要能够正确处理这些更新。
如果我们有办法安排物化，那将有助于避免重复。
物化是一个连续的过程，每当输入主题中有新的输入记录并进行处理时，ktable就会更新。因此，在任何时间点都可能有特定密钥的更新。因此，即使您完全控制何时向changelog主题和/或下游发送更新，以后也可能会有新的更新。这就是流处理的本质。
另外，减少主题中持久化的数据量（增加存储），增加网络通信量，为清理压缩过程增加额外的开销。
如上所述，缓存用于节省资源。
是否可以改进api以允许受控的物化？
如果提供的ktable语义不满足您的需求，您可以编写一个定制操作符作为
Processor或者Transformer，将键值存储附加到它，并实现所需的任何内容。