Join Semantics in Kafka Streams
Join Semantics in Kafka Streams
Kafka Streams is a client library used for building applications and microservices. Learn about the three major types of joins that it offers.
Join the DZone community and get the full member experience.Join For Free
Hortonworks Sandbox for HDP and HDF is your chance to get started on learning, developing, testing and trying out new features. Each download comes preconfigured with interactive tutorials, sample data and developments from the Apache community.
Before getting started, let's get a brief introduction to some core topics:
- Apache Kafka is a distributed streaming platform that enables you to publish and subscribe to a stream of records, also letting you process this stream of records as it occurs.
- Kafka Streams is a client library used for building applications and microservices, where the input and output data are stored in Kafka clusters.
- Interface KStream<K, V> is an abstraction of record stream of key-value pairs. It is defined from one or more Kafka topics that are consumed message by message or as a result of KStream transformation.
- Interface KTable<K, V> is an abstraction of a changelog stream from a primary-keyed table. Each record in this stream is an update on the primary keyed table with the record key as the primary key. Like KStreams, it is defined from one or more Kafka topics that are consumed message-by-message or as a result of a KTable transformation.
Joins in Kafka Streams
Kafka Streams offer three types of joins:
- KStream-KStream join
- KTable-KTable join
- KStream-KTable join
This is a sliding window join, meaning that all tuples close to each other with regard to time are joined. Time here is the difference up to the size of the window.
These joins are always windowed joins because otherwise, the size of the internal state store used to perform the join would grow indefinitely.
In the following example, we perform an inner join between two streams. The output the joined stream will be of type
Since KStream-KStream Join is always windowed joins, we must provide a join window. This can be given using:
KStream<String, String> joined = left.join(right, (leftValue, rightValue) -> "left=" + leftValue + ", right=" + rightValue, /* ValueJoiner */ JoinWindows.of(TimeUnit.MINUTES.toMillis(5)), Serdes.String(), /* key */ Serdes.Long(), /* left value */ Serdes.Double() /* right value */ );
KTable-KTable joins are designed to be consistent with their counterparts in relational databases. They are always non-windowed joins.
The changelog streams of KTables is materialized into local state stores that represent the latest snapshot of their tables. The join result is a new KTable representing changelog stream of the join operation.
In the following example, we will perform an inner join between two KTables. The result will be an updating KTable representing the current result of the join.
KTable<String, String> joined = left.join(right, (leftValue, rightValue) -> "left=" + leftValue + ", right=" + rightValue /* ValueJoiner */ );
The join here is key-based — that is,
leftRecord.key == rightRecord.key — and will be automatically triggered everytime a new input is received.
KStream-KTable joins are asymmetric non-window joins. They allow you to perform table lookups against a KTable everytime a new record is received from the KStream.
The KTable lookup is always done on the current state of the KTable; thus, out-of-order records can yield a non-deterministic result. The result of a KStream-KTable join is a KStream.
In the following example, we will perform an inner join of a KStream with a KTable, effectively doing a table lookup.
KStream<String, String> joined = left.join(right, (leftValue, rightValue) -> "left=" + leftValue + ", right=" + rightValue, /* ValueJoiner */ Serdes.String(), /* key */ Serdes.Long() /* left value */ );
Published at DZone with permission of Himani Arora , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.