首页 > 解决方案 > Kafka Stream 拓扑优化

问题描述

在准备拓扑优化时,我偶然发现了以下内容:

目前,Kafka Streams 在启用时执行了两项优化:

1 - 源 KTable 重新使用源主题作为更改日志主题。

2 - 如果可能,Kafka Streams 将多个重新分区主题折叠成一个重新分区主题。

这个问题是针对第一点的。我不完全理解这里发生了什么。只是为了确保我没有在这里做任何假设。有人可以解释一下,之前的状态是什么:

1 - 做 KTable,使用内部变更日志主题?如果是的话,有人能指点我一个关于那个的文档吗?接下来,那个变更日志主题是什么?它实际上是由更新操作组成的更新日志吗?

2 - 如果我最后的猜测是真的,我不明白由 upsert 组成的变更日志如何只能被源主题替换?

标签: apache-kafka-streams

解决方案


变更日志主题是配置了日志压缩的 Kafka 主题。每次更新KTable都会写入更改日志主题。因为主题是压缩的,所以不会丢失任何数据,并且重新读取更改日志主题可以重新创建本地存储。

这种优化的假设是,源主题是一个压缩主题。对于这种情况,源主题和相应的变更日志主题将包含完全相同的数据。因此,优化删除了更改日志主题并使用源主题在恢复期间重新创建状态存储。

如果您的输入主题未压缩但应用了保留时间,您可能不想启用优化,因为这可能会导致数据丢失。

关于历史:最初,Kafka Streams 对这种优化进行了硬编码(因此“强迫”用户只阅读压缩主题,就KTables好像潜在的数据丢失是不可接受的一样)。然而,在版本1.0中引入了一个回归错误(通过https://issues.apache.org/jira/browse/KAFKA-3856:新StreamsBuilder行为与旧行为不同,KStreamBuilder并且StreamsBuilder总是会创建一个变更日志主题)“删除”优化。在版本2.0中,该问题已得到修复,并且可以再次进行优化。(参见https://issues.apache.org/jira/browse/KAFKA-6874

注意:优化仅适用于 source KTables。因为KTables这是计算的结果,如聚合或其他,优化不可用,并且将创建更改日志主题(如果未明确禁用,则会禁用相应存储的容错)。


推荐阅读