KTable is a Kafka Streams update stream: each key identifies a table row, and a later record with that key replaces the earlier value. Unlike a KStream, where same-key records remain independent events, a KTable represents the latest known value per key. This fits data such as user profiles, stock prices, or reference data, where prior versions are no longer the current answer. section 8.0 section 8.1.1
Figure 8.4 In a changelog, each incoming record overwrites the previous one with the same key. You’d have four events with a record stream, but for an update stream, you have only two.
A changelog can contain several events for the same keys, while the corresponding table retains only each key’s latest value. section 8.1.1
Create a table from a topic with StreamsBuilder.table(). Kafka Streams creates a persistent state store to track its contents; provide Serdes because store keys and values are handled as byte arrays. A null value is a tombstone: it removes that key from the table, state store, and backing changelog. Table data is partitioned across tasks according to the source topic’s partitions. section 8.2
A KTable changes how common stream-processing operations behave:
- Convert it with toStream() when downstream processing or console output needs an event stream; KTable itself has no print() or peek() methods. section 8.1.2
- Use filter, filterNot, mapValues, and transformValues fluently; each returns a new KTable. Incoming tombstones pass through, while filtered-out values become tombstones in the result. section 8.3
- Expect aggregation operations to produce a KTable. Stateful results may be cached, so downstream operators receive the latest cached update when the cache flushes rather than every intermediate result. section 7.2.1
Comparing stock quotes as events and updates
Read stock quotes as both a KStream and a KTable, then call toStream() before printing the table. Across three rounds of quotes, the KStream prints all nine records because every quote is an event. The KTable prints the three final values because later quotes update the same stock keys. Duplicate keys therefore mean updates when interpreted as a table. section 8.1.2
KTable aggregation requires grouping by a field other than the table’s primary key. Grouping by the original key would leave one record per group, so groupBy commonly changes the key and can force repartitioning. The resulting KGroupedTable aggregates with an initializer, an adder for the new value, and a subtractor that removes the old value associated with an update. section 8.4
Aggregating stock market segments
A stock-alert table keyed by symbol can be regrouped by market segment, such as technology, then aggregated into share and dollar volumes. When a stock alert changes, the subtractor removes its previous volume and value from the segment aggregate, and the adder contributes the new values. The aggregate can then be converted to a stream and written to an output topic. section 8.4
Tables also support enrichment and table relationships. Join a KStream containing events with a KTable holding facts or dimension data to add details to each event. KTable-to-KTable joins, including foreign-key joins, combine table data. A GlobalKTable keeps all records from its source topic on every application instance, making it useful as a reference table and avoiding KStream co-partitioning requirements for its joins. section 8.0 section 8.7
