具有数十亿唯一键的 KTable
KTable with billions unique keys
我的需求是使用kafka stream构建实时聚合流水线，数据量大。根据估计，可能的唯一键约为 3 到 40 亿，总消息大小约为 5TB。
高级架构是，从kafka主题中读取，根据某些关键列对其进行聚合，并将聚合结果发布到KTable（kafka紧凑主题）中。 KTable 用于读取以前的状态并使用新的聚合结果进行更新。
KTable 是否可以使用数十亿个唯一键进行扩展？
KTable 将数据存储在应用程序本地的文件系统上，因此您可能希望使用相当持久的键值数据库对其进行备份，并使用 KTable 作为仅保存最多的缓存 recent/frequently 访问记录。此外，如果更改日志主题变得太大，它们可能会妨碍您的应用程序启动时间，因为在应用程序实际标记为“健康”之前，KTable 需要填充更改日志主题中的所有记录。
听起来有可能。 Kafka Streams 使用 RocksDB 作为默认存储引擎，允许溢出到磁盘，因此一个适当的 scaled-out 应用程序可以保存巨大的状态。一个主要考虑因素是您需要多少分片才能获得良好的性能——除了实际的存储要求外，还需要考虑输入数据速率。
另请注意，因为 RocksDB 确实溢出到磁盘，如果一个实例出现故障并且您在同一台机器上重新启动它，则没有必要 re-load 来自 Kafka 变更日志主题的状态，因为本地状态将还在那里。 （对于 Kubernetes 部署，使用有状态集有助于这种情况。）一般来说，如果你有大状态并且想避免迁移状态（即 trade-off 一些“partial/temporary 不可用”以获得更多“稳定”部署），您应该考虑使用静态组成员身份。
对于大小估算，请注意输入主题分区的数量决定了可用于扩展应用程序的最大实例数。因此，您需要为输入的主题配置足够的分区。对于客户端存储估算，请查看容量规划文档：https://docs.confluent.io/current/streams/sizing.html
我的需求是使用kafka stream构建实时聚合流水线，数据量大。根据估计，可能的唯一键约为 3 到 40 亿，总消息大小约为 5TB。
高级架构是，从kafka主题中读取，根据某些关键列对其进行聚合，并将聚合结果发布到KTable（kafka紧凑主题）中。 KTable 用于读取以前的状态并使用新的聚合结果进行更新。
KTable 是否可以使用数十亿个唯一键进行扩展？
KTable 将数据存储在应用程序本地的文件系统上，因此您可能希望使用相当持久的键值数据库对其进行备份，并使用 KTable 作为仅保存最多的缓存 recent/frequently 访问记录。此外，如果更改日志主题变得太大，它们可能会妨碍您的应用程序启动时间，因为在应用程序实际标记为“健康”之前，KTable 需要填充更改日志主题中的所有记录。
听起来有可能。 Kafka Streams 使用 RocksDB 作为默认存储引擎，允许溢出到磁盘，因此一个适当的 scaled-out 应用程序可以保存巨大的状态。一个主要考虑因素是您需要多少分片才能获得良好的性能——除了实际的存储要求外，还需要考虑输入数据速率。
另请注意，因为 RocksDB 确实溢出到磁盘，如果一个实例出现故障并且您在同一台机器上重新启动它，则没有必要 re-load 来自 Kafka 变更日志主题的状态，因为本地状态将还在那里。 （对于 Kubernetes 部署，使用有状态集有助于这种情况。）一般来说，如果你有大状态并且想避免迁移状态（即 trade-off 一些“partial/temporary 不可用”以获得更多“稳定”部署），您应该考虑使用静态组成员身份。
对于大小估算，请注意输入主题分区的数量决定了可用于扩展应用程序的最大实例数。因此，您需要为输入的主题配置足够的分区。对于客户端存储估算，请查看容量规划文档：https://docs.confluent.io/current/streams/sizing.html