Question

这是以下问题的补充：Kafka Streams - How to scale Kafka store generated changelog topics

假设

假设流使用者在存储数据之前需要进行一些转换（用v-> k代替k-> v进行索引）。

最后，目标是每个使用者都需要将完整的转换记录（v-> k）集合存储在rockDB中。我知道上游的另一个处理器可以根据k-> v来产生v-> k，最终使用者可以简单地从globaltable中实现新主题。但是，如果流水线全部由最终用户完成，会发生什么？

KTable<Key, Value> table = builder.table(topic);
table.groupBy((k, v) -> KeyValue.pair(v, k)).reduce((newValue, aggValue) -> newValue,
                                                    (newValue, aggValue) -> null,
                                                    Materialized.as(STORE_NAME));

在这种情况下，哪种选择是最佳实践或最佳选择（如果我的假设不成立，请让我正确）？

如果所有使用者都具有不同的applicationId，而不论groupId为何，则每个使用者都将消耗所有k->事件，并生成具有所有内容的多个changelog中间主题（这不是最佳的存储方式）。
如果所有使用者都具有相同的applicationId，但位于不同的组中，从而独立地加载所有k-> v事件，则它们将在共享变更日志流中共同贡献相同的已计算k-> v事件（基于applicationId）。这看起来并不理想，因为我们会多次计算和产生相同的数据。
如果所有使用者都具有相同的applicationId，并且在同一组中仅消耗k-> v个事件的一部分（根据分区），则它们将在计算的k-> v中贡献一部分共享变更日志流。但是我不清楚每个实现的rocksDB是否将拥有完整的数据集，或者仅具有流经其消费者管道的切片？

Answer 1

对于Kafka Streams，applicationId == groupId。因此（2）是不可能的。

对于（3），该状态是分片/分区的，每个实例仅具有该状态的一部分。

如果要获取状态的完整副本，则需要使用GlobalKTables而不是KTables。

Kafka Streams-共享的更改日志主题

1 个答案: