A primary key uniquely identifies a row. In a KTable, the key of each key-value record plays that role: a new record with the same key updates the prior table entry rather than creating an independent event. This suits data where only the latest value matters, such as a user profile. section 8.0
Primary keys shape KTable operations. Grouping by the incoming primary key produces only one record per group, so useful aggregations first group by another field. For stock alerts keyed by stock symbol, grouping by market segment creates groups that can calculate share and dollar volume. Changing the grouping key can require repartitioning because records for one segment may be on different partitions. section 8.4
Aggregate stock alerts by market segment
Create a KTable from the stock-alert topic, then use groupBy to replace each stock-symbol key with its market-segment key. Aggregate the grouped table with an initializer, an adder for the new value, and a subtractor for the old value. The subtractor matters because a later record for the same primary key replaces the prior table value. section 8.4
Listing 8.2 Aggregates with a KTable
KTable<String, StockAlert> stockTable =
builder.table("stock-alert",
Consumed.with(stringSerde, stockAlertSerde)); #1
stockTable.groupBy((key, value) ->
KeyValue.pair(value.getMarketSegment(), value),
Grouped.with(stringSerde, stockAlertSerde)) #2
.aggregate(segmentInitializer, #3
adderAggregator, #4
subtractorAggregator, #5
Materialized.with(stringSerde, segmentSerde))
.toStream()
.to("stock-alert-aggregate",
Produced.with(stringSerde, segmentSerde));
The listing shows a KTable keyed by stock alert, regrouped by market segment before aggregation and output to an aggregate topic. section 8.4
Primary keys also determine ordinary table-table join compatibility. Two tables keyed alike can join on that key. If a client-contract table is keyed by client ID while a commodity table is keyed by commodity code, the keys differ and a direct key join cannot match them. A foreign key join handles this case when the left value contains a field matching the right table’s primary key; a function extracts that field, and a null result produces no join. section 8.6.4
Figure 8.27 Client contracts table uses the client ID for keys, but the value contains a code that matches the key on another table containing commodity information.
The figure contrasts a client-ID primary key with a commodity code stored in the value, motivating foreign key extraction for a table-table join. section 8.6.4
