A KTable represents the current intermediate state for each key while changes continue to arrive. Unlike a traditional relational table, it contains key-value pairs and is usually partitioned, so each application instance holds only part of the state. section 12.4.1
A KTable is created and maintained through a stateful stream-processing flow:
- Create one from a topic with builder.table("topic"); Kafka Streams reads the topic from the beginning and updates the stored value for each key. section 12.4.1
- Store the state locally, commonly in a fast key-value store such as RocksDB; protect recoverability with a usually compacted changelog topic. section 12.4.1
- Create one from a KStream through aggregation, and convert it back to a KStream with toStream when downstream processing needs the changes. section 12.4.1
Active devices for notification delivery
A notifications pipeline can aggregate the user-devices stream into a KTable containing each user’s active devices. The aggregator adds active devices and removes inactive ones; the notifications stream then joins that table to attach the current device list before writing device notifications. section 12.4.4
Figure 12.7 Processors such as map, filter, and flatMap work on both KStreams and KTables. We use aggregations to create KTables from KStreams and toStream to produce a KStream from a KTable.
Use the stream-table flow to see how aggregations produce KTables and toStream produces a KStream. section 12.4.1
