Hello Nag, Yes, your conclusion sounds right.
“Sum the values per key” is a statement that doesn’t really make sense in a KTable context, since there is always just one value per key (the latest update). I think the docs are just trying to drive the point home that in a KTable, there is just one value per key, whereas in a KStream, each key has a sequence of values. Thanks, John On Wed, Jul 22, 2020, at 10:22, Nag Y wrote: > I understood A KStream is an abstraction of a record stream and A KTable is > an abstraction of a changelog stream ( updates or inserts) and the > semantics around it. > > However, this is where some confusion arises .. From confluent documentation > <https://docs.confluent.io/current/streams/concepts.html> > > To illustrate, let’s imagine the following two data records are being sent > to the stream: > > ("alice", 1) --> ("alice", 3) > > *If your stream processing application were to sum the values per user*, it > would return 3 for alice. Why? Because the second data record would be > considered an update of the previous record. Compare this behavior of > KTable with the illustration for KStream above, which would return 4 for > alice. > > Coming to the highlighted area , *if we were to sum the values* , it should > be 4 . right ? However, *if we were to look at the "updated" view of the > logs* , yes , it is 3 as KTable maintains either updates or inserts . Did I > get it right ? >
