Kafka Stream拓扑优化
Kafka Stream topology optimization
在准备拓扑优化时，我偶然发现了以下内容：
Currently, there are two optimizations that Kafka Streams performs
when enabled:
1 - The source KTable re-uses the source topic as the changelog topic.
2 - When possible, Kafka Streams collapses multiple repartition topics
into a single repartition topic.
这个问题是针对第一点的。我不完全了解这里的幕后情况。只是为了确保我没有在这里做任何假设。谁能解释一下，之前是什么状态：
1 - KTable 是否使用内部更新日志主题？如果是的话，有人可以指点我关于那个的文档吗？接下来，该变更日志主题中有什么？它实际上是由更新操作组成的upsert日志吗？
2 - 如果我最后的猜测是真的，我不明白由 upsert 组成的 changelog 怎么可以只被源主题替换？
变更日志主题是配置了 日志压缩 的 Kafka 主题。 KTable 的每个更新都写入更新日志主题。因为主题是压缩的，所以不会丢失任何数据，并且 re-reading 更新日志主题允许 re-create 本地存储。
此优化的假设是，源主题是压缩主题。对于这种情况，源主题和相应的变更日志主题将包含完全相同的数据。因此，优化删除了更改日志主题，并在恢复期间使用源主题 re-create 状态存储。
如果您的输入主题未压缩但应用了保留时间，您可能不想启用优化，因为这可能会导致数据丢失。
关于历史：最初，Kafka Streams 对这种优化进行了硬编码（因此 "forced" 用户只能在不接受潜在数据丢失的情况下将压缩主题读取为 KTables）。但是，在版本 1.0 中引入了回归错误（通过 https://issues.apache.org/jira/browse/KAFKA-3856: the new StreamsBuilder behavior was different to old KStreamBuilder and StreamsBuilder would always create a changelog topic) "removing" the optimization. In version 2.0, the issue was fixed and the optimization is available again. (cf https://issues.apache.org/jira/browse/KAFKA-6874）
Note: the optimization is only available for source KTables. For KTables that are the result of an computation, like an aggregation or other, the optimization is not available and a changelog topic will be created (if not explicitly disabled what disables fault-tolerance for the corresponding store).
在准备拓扑优化时，我偶然发现了以下内容：
Currently, there are two optimizations that Kafka Streams performs when enabled:
1 - The source KTable re-uses the source topic as the changelog topic.
2 - When possible, Kafka Streams collapses multiple repartition topics into a single repartition topic.
这个问题是针对第一点的。我不完全了解这里的幕后情况。只是为了确保我没有在这里做任何假设。谁能解释一下，之前是什么状态：
1 - KTable 是否使用内部更新日志主题？如果是的话，有人可以指点我关于那个的文档吗？接下来，该变更日志主题中有什么？它实际上是由更新操作组成的upsert日志吗？
2 - 如果我最后的猜测是真的，我不明白由 upsert 组成的 changelog 怎么可以只被源主题替换？
变更日志主题是配置了 日志压缩 的 Kafka 主题。 KTable 的每个更新都写入更新日志主题。因为主题是压缩的，所以不会丢失任何数据，并且 re-reading 更新日志主题允许 re-create 本地存储。
此优化的假设是，源主题是压缩主题。对于这种情况，源主题和相应的变更日志主题将包含完全相同的数据。因此，优化删除了更改日志主题，并在恢复期间使用源主题 re-create 状态存储。
如果您的输入主题未压缩但应用了保留时间，您可能不想启用优化，因为这可能会导致数据丢失。
关于历史：最初，Kafka Streams 对这种优化进行了硬编码（因此 "forced" 用户只能在不接受潜在数据丢失的情况下将压缩主题读取为 KTables）。但是，在版本 1.0 中引入了回归错误（通过 https://issues.apache.org/jira/browse/KAFKA-3856: the new StreamsBuilder behavior was different to old KStreamBuilder and StreamsBuilder would always create a changelog topic) "removing" the optimization. In version 2.0, the issue was fixed and the optimization is available again. (cf https://issues.apache.org/jira/browse/KAFKA-6874）
Note: the optimization is only available for source
KTables. ForKTablesthat are the result of an computation, like an aggregation or other, the optimization is not available and a changelog topic will be created (if not explicitly disabled what disables fault-tolerance for the corresponding store).