This chapter covers
- Defining the relationship between streams and tables
- Updating records, and the KTable abstraction
- Aggregations, and windowing and joining KStreams and KTables
- Global KTables
- Queryable state stores
So far, we’ve covered the KStream API and adding state to a Kafka Streams application. In this chapter, we’re going to look deeper into adding state. Along the way, you’ll be introduced to a new abstraction, the KTable.
In discussing the KStream API, we’ve talked about individual events or an event stream. In the original ZMart example, when Jane Doe made a purchase, you considered the purchase to be an individual event. You didn’t keep track of how many purchases Jane made, or how often. In the context of a database, the purchase event stream could be considered a series of inserts. Because each record is new and unrelated to any other record, you could continually insert them into a table.
Now let’s add a primary key (customer ID) to each purchase event. You have a series of related purchase events or updates for Jane Doe. Because you’re using a primary key, each purchase is updated with respect to Jane’s purchase activity. Treating an event stream as inserts, and events with keys as updates, is how you’ll define the relationship between streams and tables.
In this chapter, we’ll cover the relationship between streams and tables in more depth. This relationship is important, as it will help you understand how the KTable operates.