apache-kafka - Kafka Streams 内部数据管理

Question

在我的公司，我们广泛使用 Kafka，但出于容错原因，我们一直在使用关系数据库来存储多个中间转换和聚合的结果。现在我们正在探索 Kafka Streams 作为一种更自然的方式来做到这一点。通常，我们的需求非常简单 - 一个这样的例子是

• 收听 <K1,V1>, <K2,V2>, <K1,V2>, <K1,V3>... 的输入队列
• 对于每条记录，执行一些高延迟操作(调用远程服务)
• 如果到时候 <K1,V1>被处理，并且<K1,V2>, <K1,V3>已经产生了，那么我应该处理 V3，因为 V2 已经过时了

为了实现这一点，我正在阅读这个主题 KTable .代码如下所示

KStreamBuilder builder = new KStreamBuilder();
KTable<String, String> kTable = builder.table("input-topic");
kTable.toStream().foreach((K,V) -> client.post(V));
return builder;

这按预期工作，但我不清楚 Kafka 是如何自动实现这一点的。我假设 Kafka 创建内部主题来实现这一点，但我没有看到创建任何内部主题。 Javadoc for the method似乎证实了这一观察。但后来我遇到了这个 official page这似乎表明 Kafka 使用一个单独的数据存储，也就是 RocksDB 以及一个变更日志主题。

现在我很困惑，因为更改日志主题是在什么情况下创建的。我的问题是

1. 如果状态存储的默认行为如官方页面所建议的那样是容错的，那么该状态存储在哪里？在 RocksDB 中？在变更日志主题中或两者？
2. 在生产中依赖 RocksDB 有什么影响？ (已编辑)
   1. 据我了解，对 rocksdb 的依赖是透明的(只是一个 jar 文件)，rocksdb 将数据存储在本地文件系统中。但这也意味着在我们的例子中，该应用程序将在应用程序运行的存储上维护分片数据的副本。当我们用 KTable 替换远程数据库时，它会影响存储，这就是我的观点。
   2. Kafka 版本会确保 RocksDB 继续在各种平台上运行吗？ (因为它似乎是平台相关的，而不是用 Java 编写的)
3. 压缩输入主题日志是否有意义？

我正在使用 v.0.11.0

Answer 1

1. Kafka Streams 在本地存储状态。默认使用 RocksDB。然而，本地状态是短暂的。为了容错，对商店的所有更新也被写入一个变更日志主题。这允许在发生故障或扩大/缩小规模的情况下重建和/或迁移商店。对于您的特殊情况，不会创建更改日志主题，因为 KTable 不是聚合的结果，而是直接从主题填充——这只是一种优化。由于变更日志主题将包含与输入主题完全相同的数据，因此 Kafka Streams 避免了数据重复，并在出现错误情况时将输入主题用作变更日志主题。

2. 不确定您提出这个问题的确切含义。请注意，RocksDB 被视为临时存储。出于各种原因默认使用它，如下所述:Why Apache Kafka Streams uses RocksDB and if how is it possible to change it? (例如，它允许保存比主内存更大的状态，因为它可以溢出到磁盘)。您可以将 RocksDB 替换为任何其他存储。 Kafka Streams 还附带了一个内存存储。 (编辑)

   1. 没错。您需要相应地配置您的应用程序，以便能够存储整体状态的本地分片。有一个尺码指南:https://docs.confluent.io/current/streams/sizing.html

   2. RocksDB 是用 C++ 编写的，并通过 JNI 绑定(bind)包含在内。 Windows 上存在一些已知问题，因为 RocksDB 不为所有版本的 Windows 提供预编译的二进制文件。只要您停留在基于 Linux 的平台上，它就应该可以工作。 Kafka 社区为 RocksDB 运行升级测试以确保它的兼容性。

3. 是的。 Kafka Streams 实际上假定 table() 操作的输入主题是日志压缩的。否则，在发生故障时存在数据丢失的风险。 (编辑)

   1. 如果启用日志压缩，保留时间设置将被忽略。因此，是的，最新的更新将永远保持(或直到写入 value=null 的逻辑删除消息)。请注意，当在代理端执行压缩时，旧数据将被垃圾收集，因此在恢复时，每个键只读取新版本——旧版本在压缩过程中被删除。如果一段时间后您对某些数据不感兴趣，则需要在源主题中写入墓碑以使其正常工作。