Kafka流拓扑优化
在为拓扑光学化做准备时，我偶然发现了以下内容：
目前，Kafka流在启用时执行两种优化： 1-源KTable重新使用源主题作为变更主题。 2-在可能的情况下，Kafka流将多个重新分区主题折叠为一个单独的重新分区主题。
这是第一点的问题。我不完全明白在这里发生了什么。只是为了确保我没有在这里做任何假设。有人能解释一下，以前的状态是什么？
1- KTable是否使用内部变更主题？如果是的话，谁能带我去找医生吗？接下来，这个变化主题是什么？这是真正的重新插入日志，合并更新操作吗？
2-如果我最后的猜测是正确的，我不明白为什么由重新插入组成的变化量只能被源主题所取代？
回答 1
Stack Overflow用户
发布于 2019-07-24 04:32:56
changelog主题是一个用日志压缩配置的Kafka主题。KTable的每个更新都写到changelog主题中。因为主题是压缩的，所以不会丢失任何数据，并且重新读取changelog主题可以重新创建本地存储。
这种优化的假设是，源主题是一个紧凑的主题。在这种情况下，源主题和相应的changelog主题将包含完全相同的数据。因此，优化移除changelog主题，并使用源主题在恢复期间重新创建状态存储。
如果您的输入主题没有压缩，但应用了保留时间，则可能不希望启用优化，因为这可能导致数据丢失。
关于历史:最初，Kafka使用了这种硬编码的优化(因此，如果可能的数据丢失是不可接受的，那么“强制”用户只将压缩的主题读入KTables )。但是，在版本1.0中引入了一个回归错误(通过https://issues.apache.org/jira/browse/KAFKA-3856：新的StreamsBuilder行为不同于旧的KStreamBuilder，StreamsBuilder总是会创建一个变化的主题)“删除”优化。在2.0版本中，这个问题得到了解决，并且优化再次可用。(cf https://issues.apache.org/jira/browse/KAFKA-6874)
注意:优化只适用于源
KTables。对于诸如聚合或其他计算结果的KTables，优化是不可用的，并且将创建一个变更主题(如果没有显式禁用相应存储的容错功能)。
https://stackoverflow.com/questions/57164133
复制相似问题
腾讯云开发者
