KTableとローカルストアの違い
これらのエンティティ間の違いは何ですか？
私が思うに、KTable-シンプルkafka compaction削除ポリシーのトピック。また、KTableでロギングが有効になっている場合、変更ログもあり、削除ポリシーは_compaction,delete_。
ローカルストア-RockDBに基づくメモリ内のKey-Valueキャッシュ。ただし、ローカルストアにも変更ログがあります。
どちらの場合も、特定の期間（？）のキーの最後の値を取得します。ローカルストアは、集計ステップや結合などに使用されます。ただし、圧縮戦略を使用した新しいトピックもその後に作成されます。
例えば：
_KStream<K, V> source = builder.stream(topic1);
KTable<K, V> table = builder.table(topic2); // what will happen here if i read data from topic with deletion policy delete and compaction? Will additional topic be created for store data or just a local store (cache) be used for it?
// or
KTable<K, V> table2 = builder.table(..., Materialized.as("key-value-store-name")) // what will happen here? As i think, i just specified a concrete name for local store and now i can query it as a regular key-value store
source.groupByKey().aggregate(initialValue, aggregationLogic, Materialized.as(...)) // Will new aggregation topic be created here with compaction deletion policy? Or only local store will be used?
_また、私はビルダーbuilder.addStateStore(...)を使用して状態ストアを作成できます。ここで、ロギング（変更ログ）およびキャッシング（???）を有効/無効にできます。
私はこれを読みました： https://docs.confluent.io/current/streams/developer-guide/memory-mgmt.html ですが、いくつかの詳細はまだわかりません。特にStreamCache（RockDBキャッシュではない）を無効にでき、リレーショナルデータベースのCDCシステムの完全なコピーを取得できる場合
KTableは、時間とともに更新されるテーブルのlogical抽象化です。さらに、それをマテリアライズドテーブルではなく、テーブルへのすべての更新レコードで構成される変更ログストリームと考えることができます。比較 https://docs.confluent.io/current/streams/concepts.html#duality-of-streams-and-tables 。したがって、概念的にはKTableは必要に応じてハイブリッドになりますが、時間の経過とともに更新されるテーブルとして考える方が簡単です。
内部的には、KTableはRocksDBとKafkaのトピックを使用して実装されます。 RocksDBは、テーブルの現在のデータを格納します（RocksDBはメモリ内ストアではなく、ディスクに書き込むことができることに注意してください）。同時に、KTable（つまり、RocksDB）への各更新は、対応するKafkaトピックに書き込まれます。Kafkaトピックはフォールトトレランスの理由で使用され（RocksDB自体は短命であると見なされ、RocksDBを介してディスクに書き込むことはフォールトトレランスを提供しないが、使用された変更ログトピック）、最新のことを確認するためにログ圧縮を有効にして構成されますRocksDBの状態は、トピックから読み取ることで復元できます。
ウィンドウ化された集約によって作成されたKTableがある場合、Kafkaトピックは_compact,delete_で構成され、期限切れの古いデータ（つまり、古いウィンドウ）を回避します。テーブル（つまり、RocksDB）は無制限に大きくなります。
RocksDBの代わりに、ディスクに書き込まないKTableのメモリ内ストアを使用することもできます。このストアには、フォールトトレランスの理由でストアへのすべての更新を追跡するchangelogトピックもあります。
builder.addStateStore()を使用して手動でストアを追加する場合は、RocksDBまたはインメモリストアを追加することもできます。この場合、KTableと同様のフォールトトレランスのために変更ログを有効にすることができます（KTableが作成されるとき、内部的にはまったく同じAPIを使用していることに注意してください-KTableいくつかの内部の詳細を隠すより高いレベルの抽象化です）。
キャッシングの場合：これはKafka Streams内およびストア（RocksDBまたはインメモリのいずれか）の上に実装されており、手動で追加した「プレーン」ストアの場合は、 KTables。Compare https://docs.confluent.io/current/streams/developer-guide/memory-mgmt.html したがって、キャッシングはRocksDBキャッシングとは無関係です。