<!--
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
-->

<script><!--#include virtual="../../js/templateData.js" --></script>

<script id="content-template" type="text/x-handlebars-template">
  <!-- h1>Developer Guide for Kafka Streams</h1 -->
  <!-- div class="sub-nav-sticky">
    <div class="sticky-top">
      <div style="height:35px">
        <a href="/{{version}}/documentation/streams/">Introduction</a>
        <a class="active-menu-item" href="/{{version}}/documentation/streams/developer-guide">Developer Guide</a>
        <a href="/{{version}}/documentation/streams/core-concepts">Concepts</a>
        <a href="/{{version}}/documentation/streams/quickstart">Run Demo App</a>
        <a href="/{{version}}/documentation/streams/tutorial">Tutorial: Write App</a>
      </div>
    </div>
  </div -->


    <div class="section" id="streams-dsl">
        <span id="streams-developer-guide-dsl"></span><h1>Streams DSL<a class="headerlink" href="#streams-dsl" title="Permalink to this headline"></a></h1>
        <p>The Kafka Streams DSL (Domain Specific Language) is built on top of the Streams Processor API. It is the recommended for
            most users, especially beginners. Most data processing operations can be expressed in just a few lines of DSL code.</p>
        <div class="contents local topic" id="table-of-contents">
            <p class="topic-title first"><b>Table of Contents</b></p>
            <ul class="simple">
                <li><a class="reference internal" href="#overview" id="id7">Overview</a></li>
                <li><a class="reference internal" href="#creating-source-streams-from-kafka" id="id8">Creating source streams from Kafka</a></li>
                <li><a class="reference internal" href="#transform-a-stream" id="id9">Transform a stream</a><ul>
                    <li><a class="reference internal" href="#stateless-transformations" id="id10">Stateless transformations</a></li>
                    <li><a class="reference internal" href="#stateful-transformations" id="id11">Stateful transformations</a><ul>
                        <li><a class="reference internal" href="#aggregating" id="id12">Aggregating</a></li>
                        <li><a class="reference internal" href="#joining" id="id13">Joining</a><ul>
                            <li><a class="reference internal" href="#join-co-partitioning-requirements" id="id14">Join co-partitioning requirements</a></li>
                            <li><a class="reference internal" href="#kstream-kstream-join" id="id15">KStream-KStream Join</a></li>
                            <li><a class="reference internal" href="#ktable-ktable-equi-join" id="id16">KTable-KTable Equi-Join</a></li>
                            <li><a class="reference internal" href="#ktable-ktable-fk-join" id="id34">KTable-KTable Foreign-Key Join</a></li>
                            <li><a class="reference internal" href="#kstream-ktable-join" id="id17">KStream-KTable Join</a></li>
                            <li><a class="reference internal" href="#kstream-globalktable-join" id="id18">KStream-GlobalKTable Join</a></li>
                        </ul>
                        </li>
                        <li><a class="reference internal" href="#windowing" id="id19">Windowing</a><ul>
                            <li><a class="reference internal" href="#hopping-time-windows" id="id21">Hopping time windows</a></li>
                            <li><a class="reference internal" href="#tumbling-time-windows" id="id20">Tumbling time windows</a></li>
                            <li><a class="reference internal" href="#sliding-time-windows" id="id22">Sliding time windows</a></li>
                            <li><a class="reference internal" href="#session-windows" id="id23">Session Windows</a></li>
                            <li><a class="reference internal" href="#window-final-results" id="id31">Window Final Results</a></li>
                        </ul>
                        </li>
                    </ul>
                    </li>
                    <li><a class="reference internal" href="#applying-processors-processor-api-integration" id="id24">Applying processors (Processor API integration)</a></li>
                    <li><a class="reference internal" href="#transformers-removal-and-migration-to-processors" id="id37">Transformers removal and migration to processors</a></li>
                </ul>
                </li>
                <li><a class="reference internal" href="#naming-a-streams-app" id="id33">Naming Operators in a Streams DSL application</a></li>
                <li><a class="reference internal" href="#controlling-emit-rate" id="id32">Controlling KTable update rate</a></li>
                <li><a class="reference internal" href="#versioned-state-stores" id="id36">Using timestamp-based semantics for table processors</a></li>
                <li><a class="reference internal" href="#writing-streams-back-to-kafka" id="id25">Writing streams back to Kafka</a></li>
                <li><a class="reference internal" href="#testing-a-streams-app" id="id26">Testing a Streams application</a></li>
                <li><a class="reference internal" href="#scala-dsl" id="id27">Kafka Streams DSL for Scala</a></li>
                <ul>
                    <li><a class="reference internal" href="#scala-dsl-sample-usage" id="id28">Sample Usage</a></li>
                    <li><a class="reference internal" href="#scala-dsl-implicit-serdes" id="id29">Implicit Serdes</a></li>
                    <li><a class="reference internal" href="#scala-dsl-user-defined-serdes" id="id30">User-Defined Serdes</a></li>
                </ul>
            </ul>
        </div>
        <div class="section" id="overview">
            <h2><a class="toc-backref" href="#id7">Overview</a><a class="headerlink" href="#overview" title="Permalink to this headline"></a></h2>
            <p>In comparison to the <a class="reference internal" href="processor-api.html#streams-developer-guide-processor-api"><span class="std std-ref">Processor API</span></a>, only the DSL supports:</p>
            <ul class="simple">
                <li>Built-in abstractions for <a class="reference internal" href="../core-concepts.html#streams_concepts_duality"><span class="std std-ref">streams and tables</span></a> in the form of
                    <a class="reference internal" href="#streams_concepts_kstream"><span class="std std-ref">KStream</span></a>, <a class="reference internal" href="#streams_concepts_ktable"><span class="std std-ref">KTable</span></a>, and
                    <a class="reference internal" href="#streams_concepts_globalktable"><span class="std std-ref">GlobalKTable</span></a>.  Having first-class support for streams and tables is crucial
                    because, in practice, most use cases require not just either streams or databases/tables, but a combination of both.
                    For example, if your use case is to create a customer 360-degree view that is updated in real-time, what your
                    application will be doing is transforming many input <em>streams</em> of customer-related events into an output <em>table</em>
                    that contains a continuously updated 360-degree view of your customers.</li>
                <li>Declarative, functional programming style with
                    <a class="reference internal" href="#streams-developer-guide-dsl-transformations-stateless"><span class="std std-ref">stateless transformations</span></a> (e.g. <code class="docutils literal"><span class="pre">map</span></code> and <code class="docutils literal"><span class="pre">filter</span></code>)
                    as well as <a class="reference internal" href="#streams-developer-guide-dsl-transformations-stateful"><span class="std std-ref">stateful transformations</span></a>
                    such as <a class="reference internal" href="#streams-developer-guide-dsl-aggregating"><span class="std std-ref">aggregations</span></a> (e.g. <code class="docutils literal"><span class="pre">count</span></code> and <code class="docutils literal"><span class="pre">reduce</span></code>),
                    <a class="reference internal" href="#streams-developer-guide-dsl-joins"><span class="std std-ref">joins</span></a> (e.g. <code class="docutils literal"><span class="pre">leftJoin</span></code>), and
                    <a class="reference internal" href="#streams-developer-guide-dsl-windowing"><span class="std std-ref">windowing</span></a> (e.g. <a class="reference internal" href="#windowing-session"><span class="std std-ref">session windows</span></a>).</li>
            </ul>
            <p>With the DSL, you can define <a class="reference internal" href="../core-concepts.html#streams_topology"><span class="std std-ref">processor topologies</span></a> (i.e., the logical
                processing plan) in your application. The steps to accomplish this are:</p>
            <ol class="arabic simple">
                <li>Specify <a class="reference internal" href="#streams-developer-guide-dsl-sources"><span class="std std-ref">one or more input streams that are read from Kafka topics</span></a>.</li>
                <li>Compose <a class="reference internal" href="#streams-developer-guide-dsl-transformations"><span class="std std-ref">transformations</span></a> on these streams.</li>
                <li>Write the <a class="reference internal" href="#streams-developer-guide-dsl-destinations"><span class="std std-ref">resulting output streams back to Kafka topics</span></a>, or expose the processing results of your application directly to other applications through <a class="reference internal" href="interactive-queries.html#streams-developer-guide-interactive-queries"><span class="std std-ref">interactive queries</span></a> (e.g., via a REST API).</li>
            </ol>
            <p>After the application is run, the defined processor topologies are continuously executed (i.e., the processing plan is put into
                action). A step-by-step guide for writing a stream processing application using the DSL is provided below.</p>
            <p>For a complete list of available API functionality, see also the <a href="/{{version}}/javadoc/org/apache/kafka/streams/package-summary.html">Streams</a> API docs.</p>
        </div>

        <div class="section" id="dsl-core-constructs-overview">
            <h4 class="anchor-heading"><a id="streams_concepts_kstream" class="anchor-link"></a><a href="#streams_concepts_kstream">KStream</a></h4>

            <p>
                Only the <strong>Kafka Streams DSL</strong> has the notion of a <code>KStream</code>.
            </p>

            <p>
                A <strong>KStream</strong> is an abstraction of a <strong>record stream</strong>, where each data record represents a self-contained datum in the unbounded data set. Using the table analogy, data records in a record stream are always interpreted as an &quot;INSERT&quot; -- think: adding more entries to an append-only ledger -- because no record replaces an existing row with the same key. Examples are a credit card transaction, a page view event, or a server log entry.
            </p>

            <p>
                To illustrate, let's imagine the following two data records are being sent to the stream:
            </p>

            <div class="sourcecode">
                <p>(&quot;alice&quot;, 1) --&gt; (&quot;alice&quot;, 3)</p>
            </div>

            <p>
                If your stream processing application were to sum the values per user, it would return <code>4</code> for <code>alice</code>. Why? Because the second data record would not be considered an update of the previous record. Compare this behavior of KStream to <code>KTable</code> below,
                which would return <code>3</code> for <code>alice</code>.
            </p>

            <h4 class="anchor-heading"><a id="streams_concepts_ktable" class="anchor-link"></a><a href="#streams_concepts_ktable">KTable</a></h4>

            <p>
                Only the <strong>Kafka Streams DSL</strong> has the notion of a <code>KTable</code>.
            </p>

            <p>
                A <strong>KTable</strong> is an abstraction of a <strong>changelog stream</strong>, where each data record represents an update. More precisely, the value in a data record is interpreted as an &quot;UPDATE&quot; of the last value for the same record key, if any (if a corresponding key doesn't exist yet, the update will be considered an INSERT). Using the table analogy, a data record in a changelog stream is interpreted as an UPSERT aka INSERT/UPDATE because any existing row with the same key is overwritten. Also, <code>null</code> values are interpreted in a special way: a record with a <code>null</code> value represents a &quot;DELETE&quot; or tombstone for the record's key.
            </p>
            <p>
                To illustrate, let's imagine the following two data records are being sent to the stream:
            </p>

            <div class="sourcecode">
                <p>
                    (&quot;alice&quot;, 1) --&gt; (&quot;alice&quot;, 3)
                </p>
            </div>

            <p>
                If your stream processing application were to sum the values per user, it would return <code>3</code> for <code>alice</code>. Why? Because the second data record would be considered an update of the previous record.
            </p>

            <p>
                <strong>Effects of Kafka's log compaction:</strong> Another way of thinking about KStream and KTable is as follows: If you were to store a KTable into a Kafka topic, you'd probably want to enable Kafka's <a href="http://kafka.apache.org/documentation.html#compaction">log compaction</a> feature, e.g. to save storage space.
            </p>

            <p>
                However, it would not be safe to enable log compaction in the case of a KStream because, as soon as log compaction would begin purging older data records of the same key, it would break the semantics of the data. To pick up the illustration example again, you'd suddenly get a <code>3</code> for <code>alice</code> instead of a <code>4</code> because log compaction would have removed the <code>(&quot;alice&quot;, 1)</code> data record. Hence log compaction is perfectly safe for a KTable (changelog stream) but it is a mistake for a KStream (record stream).
            </p>

            <p>
                We have already seen an example of a changelog stream in the section <a class="reference internal" href="../core-concepts.html#streams_concepts_duality"><span class="std std-ref">streams and tables</span></a>. Another example are change data capture (CDC) records in the changelog of a relational database, representing which row in a database table was inserted, updated, or deleted.
            </p>

            <p>
                KTable also provides an ability to look up <em>current</em> values of data records by keys. This table-lookup functionality is available through <strong>join operations</strong> (see also <strong>Joining</strong> in the Developer Guide) as well as through <strong>Interactive Queries</strong>.
            </p>

            <h4 class="anchor-heading"><a id="streams_concepts_globalktable" class="anchor-link"></a><a href="#streams_concepts_globalktable">GlobalKTable</a></h4>

            <p>Only the <strong>Kafka Streams DSL</strong> has the notion of a <strong>GlobalKTable</strong>.</p>

            <p>
                Like a <strong>KTable</strong>, a <strong>GlobalKTable</strong> is an abstraction of a <strong>changelog stream</strong>, where each data record represents an update.
            </p>

            <p>
                A GlobalKTable differs from a KTable in the data that they are being populated with, i.e. which data from the underlying Kafka topic is being read into the respective table. Slightly simplified, imagine you have an input topic with 5 partitions. In your application, you want to read this topic into a table. Also, you want to run your application across 5 application instances for <strong>maximum parallelism</strong>.
            </p>

            <ul>
                <li>
                    If you read the input topic into a <strong>KTable</strong>, then the &quot;local&quot; KTable instance of each application instance will be populated with data <strong>from only 1 partition</strong> of the topic's 5 partitions.
                </li>

                <li>
                    If you read the input topic into a <strong>GlobalKTable</strong>, then the local GlobalKTable instance of each application instance will be populated with data <strong>from all partitions of the topic</strong>.
                </li>
            </ul>

            <p>
                GlobalKTable provides the ability to look up <em>current</em> values of data records by keys. This table-lookup functionality is available through <code class="interpreted-text">join operations</code>.
                Note that a GlobalKTable has <strong>no</strong> notion of time in contrast to a KTable.
            </p>
            <p>Benefits of global tables:</p>

            <ul>
                <li>
                    More convenient and/or efficient <strong>joins</strong>: Notably, global tables allow you to perform star joins, they support &quot;foreign-key&quot; lookups (i.e., you can lookup data in the table not just by record key, but also by data in the record values), and they are more efficient when chaining multiple joins. Also, when joining against a global table, the input data does not need to be <strong>co-partitioned</strong>.
                </li>
                <li>
                    Can be used to &quot;broadcast&quot; information to all the running instances of your application.
                </li>
            </ul>

            <p>Downsides of global tables:</p>
            <ul>
                <li>Increased local storage consumption compared to the (partitioned) KTable because the entire topic is tracked.</li>
                <li>Increased network and Kafka broker load compared to the (partitioned) KTable because the entire topic is read.</li>
            </ul>

        </div>
        <div class="section" id="creating-source-streams-from-kafka">
            <span id="streams-developer-guide-dsl-sources"></span><h2><a class="toc-backref" href="#id8">Creating source streams from Kafka</a><a class="headerlink" href="#creating-source-streams-from-kafka" title="Permalink to this headline"></a></h2>
            <p>You can easily read data from Kafka topics into your application.  The following operations are supported.</p>
            <table border="1" class="non-scrolling-table width-100-percent docutils">
                <colgroup>
                    <col width="22%" />
                    <col width="78%" />
                </colgroup>
                <thead valign="bottom">
                <tr class="row-odd"><th class="head">Reading from Kafka</th>
                    <th class="head">Description</th>
                </tr>
                </thead>
                <tbody valign="top">
                <tr class="row-even"><td><p class="first"><strong>Stream</strong></p>
                    <ul class="last simple">
                        <li><em>input topics</em> &rarr; KStream</li>
                    </ul>
                </td>
                    <td><p class="first">Creates a <a class="reference internal" href="#streams_concepts_kstream"><span class="std std-ref">KStream</span></a> from the specified Kafka input topics and interprets the data
                        as a <a class="reference internal" href="#streams_concepts_kstream"><span class="std std-ref">record stream</span></a>.
                        A <code class="docutils literal"><span class="pre">KStream</span></code> represents a <em>partitioned</em> record stream.
                        <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/StreamsBuilder.html#stream(java.lang.String)">(details)</a></p>
                        <p>In the case of a KStream, the local KStream instance of every application instance will
                            be populated with data from only <strong>a subset</strong> of the partitions of the input topic.  Collectively, across
                            all application instances, all input topic partitions are read and processed.</p>
                        <pre class="line-numbers"><code class="language-java">import org.apache.kafka.common.serialization.Serdes;
import org.apache.kafka.streams.StreamsBuilder;
import org.apache.kafka.streams.kstream.KStream;

StreamsBuilder builder = new StreamsBuilder();

KStream&lt;String, Long&gt; wordCounts = builder.stream(
    &quot;word-counts-input-topic&quot;, /* input topic */
    Consumed.with(
      Serdes.String(), /* key serde */
      Serdes.Long()   /* value serde */
    );</code></pre>
                        <p>If you do not specify Serdes explicitly, the default Serdes from the
                            <a class="reference internal" href="config-streams.html#streams-developer-guide-configuration"><span class="std std-ref">configuration</span></a> are used.</p>
                        <p>You <strong>must specify Serdes explicitly</strong> if the key or value types of the records in the Kafka input
                            topics do not match the configured default Serdes. For information about configuring default Serdes, available
                            Serdes, and implementing your own custom Serdes see <a class="reference internal" href="datatypes.html#streams-developer-guide-serdes"><span class="std std-ref">Data Types and Serialization</span></a>.</p>
                        <p class="last">Several variants of <code class="docutils literal"><span class="pre">stream</span></code> exist. For example, you can specify a regex pattern for input topics to read from (note that all matching topics will be part of the same input topic group, and the work will not be parallelized for different topics if subscribed to in this way).</p>
                    </td>
                </tr>
                <tr class="row-odd"><td><p class="first"><strong>Table</strong></p>
                    <ul class="last simple">
                        <li><em>input topic</em> &rarr; KTable</li>
                    </ul>
                </td>
                    <td><p class="first">Reads the specified Kafka input topic into a <a class="reference internal" href="#streams_concepts_ktable"><span class="std std-ref">KTable</span></a>.  The topic is
                        interpreted as a changelog stream, where records with the same key are interpreted as UPSERT aka INSERT/UPDATE
                        (when the record value is not <code class="docutils literal"><span class="pre">null</span></code>) or as DELETE (when the value is <code class="docutils literal"><span class="pre">null</span></code>) for that key.
                        <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/StreamsBuilder.html#table-java.lang.String(java.lang.String)">(details)</a></p>
                        <p>In the case of a KTable, the local KTable instance of every application instance will
                            be populated with data from only <strong>a subset</strong> of the partitions of the input topic.  Collectively, across
                            all application instances, all input topic partitions are read and processed.</p>
                        <p>You must provide a name for the table (more precisely, for the internal
                            <a class="reference internal" href="../architecture.html#streams_architecture_state"><span class="std std-ref">state store</span></a> that backs the table).  This is required for
                            supporting <a class="reference internal" href="interactive-queries.html#streams-developer-guide-interactive-queries"><span class="std std-ref">interactive queries</span></a> against the table. When a
                            name is not provided the table will not be queryable and an internal name will be provided for the state store.</p>
                        <p>If you do not specify Serdes explicitly, the default Serdes from the
                            <a class="reference internal" href="config-streams.html#streams-developer-guide-configuration"><span class="std std-ref">configuration</span></a> are used.</p>
                        <p>You <strong>must specify Serdes explicitly</strong> if the key or value types of the records in the Kafka input
                            topics do not match the configured default Serdes. For information about configuring default Serdes, available
                            Serdes, and implementing your own custom Serdes see <a class="reference internal" href="datatypes.html#streams-developer-guide-serdes"><span class="std std-ref">Data Types and Serialization</span></a>.</p>
                        <p class="last">Several variants of <code class="docutils literal"><span class="pre">table</span></code> exist, for example to specify the <code class="docutils literal"><span class="pre">auto.offset.reset</span></code> policy to be used when
                            reading from the input topic.</p>
                    </td>
                </tr>
                <tr class="row-even"><td><p class="first"><strong>Global Table</strong></p>
                    <ul class="last simple">
                        <li><em>input topic</em> &rarr; GlobalKTable</li>
                    </ul>
                </td>
                    <td><p class="first">Reads the specified Kafka input topic into a <a class="reference internal" href="#streams_concepts_globalktable"><span class="std std-ref">GlobalKTable</span></a>.  The topic is
                        interpreted as a changelog stream, where records with the same key are interpreted as UPSERT aka INSERT/UPDATE
                        (when the record value is not <code class="docutils literal"><span class="pre">null</span></code>) or as DELETE (when the value is <code class="docutils literal"><span class="pre">null</span></code>) for that key.
                        <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/StreamsBuilder.html#globalTable-java.lang.String(java.lang.String)">(details)</a></p>
                        <p>In the case of a GlobalKTable, the local GlobalKTable instance of every application instance will
                            be populated with data from <strong>all</strong> the partitions of the input topic.</p>
                        <p>You must provide a name for the table (more precisely, for the internal
                            <a class="reference internal" href="../architecture.html#streams_architecture_state"><span class="std std-ref">state store</span></a> that backs the table).  This is required for
                            supporting <a class="reference internal" href="interactive-queries.html#streams-developer-guide-interactive-queries"><span class="std std-ref">interactive queries</span></a> against the table. When a
                            name is not provided the table will not be queryable and an internal name will be provided for the state store.</p>
                        <pre class="line-numbers"><code class="language-java">import org.apache.kafka.common.serialization.Serdes;
import org.apache.kafka.streams.StreamsBuilder;
import org.apache.kafka.streams.kstream.GlobalKTable;

StreamsBuilder builder = new StreamsBuilder();

GlobalKTable&lt;String, Long&gt; wordCounts = builder.globalTable(
    &quot;word-counts-input-topic&quot;,
    Materialized.&lt;String, Long, KeyValueStore&lt;Bytes, byte[]&gt;&gt;as(
      &quot;word-counts-global-store&quot; /* table/store name */)
      .withKeySerde(Serdes.String()) /* key serde */
      .withValueSerde(Serdes.Long()) /* value serde */
    );</code></pre>
                        <p>You <strong>must specify Serdes explicitly</strong> if the key or value types of the records in the Kafka input
                            topics do not match the configured default Serdes. For information about configuring default Serdes, available
                            Serdes, and implementing your own custom Serdes see <a class="reference internal" href="datatypes.html#streams-developer-guide-serdes"><span class="std std-ref">Data Types and Serialization</span></a>.</p>
                        <p class="last">Several variants of <code class="docutils literal"><span class="pre">globalTable</span></code> exist to e.g. specify explicit Serdes.</p>
                    </td>
                </tr>
                </tbody>
            </table>
        </div>
        <div class="section" id="transform-a-stream">
            <span id="streams-developer-guide-dsl-transformations"></span><h2><a class="toc-backref" href="#id9">Transform a stream</a><a class="headerlink" href="#transform-a-stream" title="Permalink to this headline"></a></h2>
            <p>The KStream and KTable interfaces support a variety of transformation operations.
                Each of these operations can be translated into one or more connected processors into the underlying processor topology.
                Since KStream and KTable are strongly typed, all of these transformation operations are defined as
                generic functions where users could specify the input and output data types.</p>
            <p>Some KStream transformations may generate one or more KStream objects, for example:
                - <code class="docutils literal"><span class="pre">filter</span></code> and <code class="docutils literal"><span class="pre">map</span></code> on a KStream will generate another KStream
                - <code class="docutils literal"><span class="pre">split</span></code> on KStream can generate multiple KStreams</p>
            <p>Some others may generate a KTable object, for example an aggregation of a KStream also yields a KTable. This allows Kafka Streams to continuously update the computed value upon arrivals of <a class="reference internal" href="../core-concepts.html#streams_concepts_aggregations"><span class="std std-ref">out-of-order records</span></a> after it
                has already been produced to the downstream transformation operators.</p>
            <p>All KTable transformation operations can only generate another KTable. However, the Kafka Streams DSL does provide a special function
                that converts a KTable representation into a KStream. All of these transformation methods can be chained together to compose
                a complex processor topology.</p>
            <p>These transformation operations are described in the following subsections:</p>
            <ul class="simple">
                <li><a class="reference internal" href="#streams-developer-guide-dsl-transformations-stateless"><span class="std std-ref">Stateless transformations</span></a></li>
                <li><a class="reference internal" href="#streams-developer-guide-dsl-transformations-stateful"><span class="std std-ref">Stateful transformations</span></a></li>
            </ul>
            <div class="section" id="stateless-transformations">
                <span id="streams-developer-guide-dsl-transformations-stateless"></span><h3><a class="toc-backref" href="#id10">Stateless transformations</a><a class="headerlink" href="#stateless-transformations" title="Permalink to this headline"></a></h3>
                <p>Stateless transformations do not require state for processing and they do not require a state store associated with
                    the stream processor. Kafka 0.11.0 and later allows you to materialize the result from a stateless <code class="docutils literal"><span class="pre">KTable</span></code> transformation. This allows the result to be queried through <a class="reference internal" href="interactive-queries.html#streams-developer-guide-interactive-queries"><span class="std std-ref">interactive queries</span></a>. To materialize a <code class="docutils literal"><span class="pre">KTable</span></code>, each of the below stateless operations <a class="reference internal" href="interactive-queries.html#streams-developer-guide-interactive-queries-local-key-value-stores"><span class="std std-ref">can be augmented</span></a> with an optional <code class="docutils literal"><span class="pre">queryableStoreName</span></code> argument.</p>
                <table border="1" class="non-scrolling-table width-100-percent docutils">
                    <colgroup>
                        <col width="22%" />
                        <col width="78%" />
                    </colgroup>
                    <thead valign="bottom">
                    <tr class="row-odd"><th class="head">Transformation</th>
                        <th class="head">Description</th>
                    </tr>
                    </thead>
                    <tbody valign="top">
                    <tr class="row-even"><td><p class="first"><strong>Branch</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; BranchedKStream</li>
                        </ul>
                    </td>
                        <td><p class="first">Branch (or split) a <code class="docutils literal"><span class="pre">KStream</span></code> based on the supplied predicates into one or more <code class="docutils literal"><span class="pre">KStream</span></code> instances.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#split()">details</a>)</p>
                            <p>Predicates are evaluated in order.  A record is placed to one and only one output stream on the first match:
                                if the n-th predicate evaluates to true, the record is placed to n-th stream. If a record does not match any predicates,
                                it will be routed to the default branch, or dropped if no default branch is created.</p>
                            <p>Branching is useful, for example, to route records to different downstream topics.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; stream = ...;
Map&lt;String, KStream&lt;String, Long&gt;&gt; branches =
    stream.split(Named.as(&quot;Branch-&quot;))
        .branch((key, value) -&gt; key.startsWith(&quot;A&quot;),  /* first predicate  */
             Branched.as(&quot;A&quot;))
        .branch((key, value) -&gt; key.startsWith(&quot;B&quot;),  /* second predicate */
             Branched.as(&quot;B&quot;))
        .defaultBranch(Branched.as(&quot;C&quot;))              /* default branch */
);

// KStream branches.get(&quot;Branch-A&quot;) contains all records whose keys start with &quot;A&quot;
// KStream branches.get(&quot;Branch-B&quot;) contains all records whose keys start with &quot;B&quot;
// KStream branches.get(&quot;Branch-C&quot;) contains all other records
</code></pre>
                        </td>
                    </tr>
                    <tr class="row-odd"><td><p class="first"><strong>Broadcast/Multicast</strong></p>
                        <ul class="last simple">
                            <li>no operator</li>
                        </ul>
                    </td>
                        <td><p class="first">Broadcasting a <code class="docutils literal"><span class="pre">KStream</span></code> into multiple downstream operators.</p>
                            <p>A record is sent to more than one operator by applying multiple operators to the same <code class="docutils literal"><span class="pre">KStream</span></code> instance.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; stream = ...;
KStream&lt;...&gt; stream1 = stream.map(...);
KStream&lt;...&gt; stream2 = stream.mapValue(...);
KStream&lt;...&gt; stream3 = stream.flatMap(...);
</code></pre>
                            <p class="first">Multicasting a <code class="docutils literal"><span class="pre">KStream</span></code> into multiple downstream operators.</p>
                            <p>In contrast to <strong>branching</strong>, which sends each record to at most one downstream branch,
                               a multicast may send a record to any number of downstream <code class="docutils literal"><span class="pre">KStream</span></code> instances.</p>
                            <p>A multicast is implemented as a broadcast plus filters.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; stream = ...;
KStream&lt;...&gt; stream1 = stream.filter((key, value) -&gt; key.startsWith(&quot;A&quot;)); // contains all records whose keys start with "A"
KStream&lt;...&gt; stream2 = stream.filter((key, value) -&gt; key.startsWith(&quot;AB&quot;)); // contains all records whose keys start with "AB" (subset of stream1)
KStream&lt;...&gt; stream3 = stream.filter((key, value) -&gt; key.contains(&quot;B&quot;)); // contains all records whose keys contains a "B" (superset of stream2)
</code></pre>
                        </td>
                    </tr>
                    <tr class="row-even"><td><p class="first"><strong>Filter</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KStream</li>
                            <li>KTable &rarr; KTable</li>
                        </ul>
                    </td>
                        <td><p class="first">Evaluates a boolean function for each element and retains those for which the function returns true.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#filter-org.apache.kafka.streams.kstream.Predicate-">KStream details</a>,
                            <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KTable.html#filter-org.apache.kafka.streams.kstream.Predicate-">KTable details</a>)</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; stream = ...;

// A filter that selects (keeps) only positive numbers
KStream&lt;String, Long&gt; onlyPositives = stream.filter((key, value) -&gt; value &gt; 0);
</code></pre>
                        </td>
                    </tr>
                    <tr class="row-odd"><td><p class="first"><strong>Inverse Filter</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KStream</li>
                            <li>KTable &rarr; KTable</li>
                        </ul>
                    </td>
                        <td><p class="first">Evaluates a boolean function for each element and drops those for which the function returns true.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#filterNot-org.apache.kafka.streams.kstream.Predicate-">KStream details</a>,
                            <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KTable.html#filterNot-org.apache.kafka.streams.kstream.Predicate-">KTable details</a>)</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; stream = ...;

// An inverse filter that discards any negative numbers or zero
KStream&lt;String, Long&gt; onlyPositives = stream.filterNot((key, value) -&gt; value &lt;= 0);

</code></pre>
                        </td>
                    </tr>
                    <tr class="row-even"><td><p class="first"><strong>FlatMap</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KStream</li>
                        </ul>
                    </td>
                        <td><p class="first">Takes one record and produces zero, one, or more records.  You can modify the record keys and values, including
                            their types.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#flatMap-org.apache.kafka.streams.kstream.KeyValueMapper-">details</a>)</p>
                            <p><strong>Marks the stream for data re-partitioning:</strong>
                                Applying a grouping or a join after <code class="docutils literal"><span class="pre">flatMap</span></code> will result in re-partitioning of the records.
                                If possible use <code class="docutils literal"><span class="pre">flatMapValues</span></code> instead, which will not cause data re-partitioning.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;Long, String&gt; stream = ...;
KStream&lt;String, Integer&gt; transformed = stream.flatMap(
     // Here, we generate two output records for each input record.
     // We also change the key and value types.
     // Example: (345L, &quot;Hello&quot;) -&gt; (&quot;HELLO&quot;, 1000), (&quot;hello&quot;, 9000)
    (key, value) -&gt; {
      List&lt;KeyValue&lt;String, Integer&gt;&gt; result = new LinkedList&lt;&gt;();
      result.add(KeyValue.pair(value.toUpperCase(), 1000));
      result.add(KeyValue.pair(value.toLowerCase(), 9000));
      return result;
    }
  );
</code></pre>
                        </td>
                    </tr>
                    <tr class="row-odd"><td><p class="first"><strong>FlatMapValues</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KStream</li>
                        </ul>
                    </td>
                        <td><p class="first">Takes one record and produces zero, one, or more records, while retaining the key of the original record.
                            You can modify the record values and the value type.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#flatMapValues-org.apache.kafka.streams.kstream.ValueMapper-">details</a>)</p>
                            <p><code class="docutils literal"><span class="pre">flatMapValues</span></code> is preferable to <code class="docutils literal"><span class="pre">flatMap</span></code> because it will not cause data re-partitioning.  However, you
                                cannot modify the key or key type like <code class="docutils literal"><span class="pre">flatMap</span></code> does.</p>
                            <pre class="line-numbers"><code class="language-java">// Split a sentence into words.
KStream&lt;byte[], String&gt; sentences = ...;
KStream&lt;byte[], String&gt; words = sentences.flatMapValues(value -&gt; Arrays.asList(value.split(&quot;\\s+&quot;)));
</code></pre>
                        </td>
                    </tr>
                    <tr class="row-even"><td><p class="first"><strong>Foreach</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; void</li>
                            <li>KStream &rarr; void</li>
                            <li>KTable &rarr; void</li>
                        </ul>
                    </td>
                        <td><p class="first"><strong>Terminal operation.</strong>  Performs a stateless action on each record.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#foreach-org.apache.kafka.streams.kstream.ForeachAction-">details</a>)</p>
                            <p>You would use <code class="docutils literal"><span class="pre">foreach</span></code> to cause <em>side effects</em> based on the input data (similar to <code class="docutils literal"><span class="pre">peek</span></code>) and then <em>stop</em>
                                <em>further processing</em> of the input data (unlike <code class="docutils literal"><span class="pre">peek</span></code>, which is not a terminal operation).</p>
                            <p><strong>Note on processing guarantees:</strong> Any side effects of an action (such as writing to external systems) are not
                                trackable by Kafka, which means they will typically not benefit from  Kafka&#8217;s processing guarantees.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; stream = ...;

// Print the contents of the KStream to the local console.
stream.foreach((key, value) -&gt; System.out.println(key + &quot; =&gt; &quot; + value));
</code></pre>
                        </td>
                    </tr>
                    <tr class="row-odd"><td><p class="first"><strong>GroupByKey</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KGroupedStream</li>
                        </ul>
                    </td>
                        <td><p class="first">Groups the records by the existing key.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#groupByKey--">details</a>)</p>
                            <p>Grouping is a prerequisite for <a class="reference internal" href="#streams-developer-guide-dsl-aggregating"><span class="std std-ref">aggregating a stream or a table</span></a>
                                and ensures that data is properly partitioned (&#8220;keyed&#8221;) for subsequent operations.</p>
                            <p><strong>When to set explicit Serdes:</strong>
                                Variants of <code class="docutils literal"><span class="pre">groupByKey</span></code> exist to override the configured default Serdes of your application, which <strong>you</strong>
                                <strong>must do</strong> if the key and/or value types of the resulting <code class="docutils literal"><span class="pre">KGroupedStream</span></code> do not match the configured default
                                Serdes.</p>
                            <div class="admonition note">
                                <p><b>Note</b></p>
                                <p class="last"><strong>Grouping vs. Windowing:</strong>
                                    A related operation is <a class="reference internal" href="#streams-developer-guide-dsl-windowing"><span class="std std-ref">windowing</span></a>, which lets you control how to
                                    &#8220;sub-group&#8221; the grouped records <em>of the same key</em> into so-called <em>windows</em> for stateful operations such as
                                    windowed <a class="reference internal" href="#streams-developer-guide-dsl-aggregating"><span class="std std-ref">aggregations</span></a> or
                                    windowed <a class="reference internal" href="#streams-developer-guide-dsl-joins"><span class="std std-ref">joins</span></a>.</p>
                            </div>
                            <p><strong>Causes data re-partitioning if and only if the stream was marked for re-partitioning.</strong>
                                <code class="docutils literal"><span class="pre">groupByKey</span></code> is preferable to <code class="docutils literal"><span class="pre">groupBy</span></code> because it re-partitions data only if the stream was already marked
                                for re-partitioning. However, <code class="docutils literal"><span class="pre">groupByKey</span></code> does not allow you to modify the key or key type like <code class="docutils literal"><span class="pre">groupBy</span></code>
                                does.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream = ...;

// Group by the existing key, using the application&#39;s configured
// default serdes for keys and values.
KGroupedStream&lt;byte[], String&gt; groupedStream = stream.groupByKey();

// When the key and/or value types do not match the configured
// default serdes, we must explicitly specify serdes.
KGroupedStream&lt;byte[], String&gt; groupedStream = stream.groupByKey(
    Grouped.with(
      Serdes.ByteArray(), /* key */
      Serdes.String())     /* value */
  );</code></pre>
                        </td>
                    </tr>
                    <tr class="row-even"><td><p class="first"><strong>GroupBy</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KGroupedStream</li>
                            <li>KTable &rarr; KGroupedTable</li>
                        </ul>
                    </td>
                        <td><p class="first">Groups the records by a <em>new</em> key, which may be of a different key type.
                            When grouping a table, you may also specify a new value and value type.
                            <code class="docutils literal"><span class="pre">groupBy</span></code> is a shorthand for <code class="docutils literal"><span class="pre">selectKey(...).groupByKey()</span></code>.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#groupBy-org.apache.kafka.streams.kstream.KeyValueMapper-">KStream details</a>,
                            <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KTable.html#groupBy-org.apache.kafka.streams.kstream.KeyValueMapper-">KTable details</a>)</p>
                            <p>Grouping is a prerequisite for <a class="reference internal" href="#streams-developer-guide-dsl-aggregating"><span class="std std-ref">aggregating a stream or a table</span></a>
                                and ensures that data is properly partitioned (&#8220;keyed&#8221;) for subsequent operations.</p>
                            <p><strong>When to set explicit Serdes:</strong>
                                Variants of <code class="docutils literal"><span class="pre">groupBy</span></code> exist to override the configured default Serdes of your application, which <strong>you must</strong>
                                <strong>do</strong> if the key and/or value types of the resulting <code class="docutils literal"><span class="pre">KGroupedStream</span></code> or <code class="docutils literal"><span class="pre">KGroupedTable</span></code> do not match the
                                configured default Serdes.</p>
                            <div class="admonition note">
                                <p><b>Note</b></p>
                                <p class="last"><strong>Grouping vs. Windowing:</strong>
                                    A related operation is <a class="reference internal" href="#streams-developer-guide-dsl-windowing"><span class="std std-ref">windowing</span></a>, which lets you control how to
                                    &#8220;sub-group&#8221; the grouped records <em>of the same key</em> into so-called <em>windows</em> for stateful operations such as
                                    windowed <a class="reference internal" href="#streams-developer-guide-dsl-aggregating"><span class="std std-ref">aggregations</span></a> or
                                    windowed <a class="reference internal" href="#streams-developer-guide-dsl-joins"><span class="std std-ref">joins</span></a>.</p>
                            </div>
                            <p><strong>Always causes data re-partitioning:</strong>  <code class="docutils literal"><span class="pre">groupBy</span></code> always causes data re-partitioning.
                                If possible use <code class="docutils literal"><span class="pre">groupByKey</span></code> instead, which will re-partition data only if required.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream = ...;
KTable&lt;byte[], String&gt; table = ...;

// Group the stream by a new key and key type
KGroupedStream&lt;String, String&gt; groupedStream = stream.groupBy(
    (key, value) -&gt; value,
    Grouped.with(
      Serdes.String(), /* key (note: type was modified) */
      Serdes.String())  /* value */
  );

// Group the table by a new key and key type, and also modify the value and value type.
KGroupedTable&lt;String, Integer&gt; groupedTable = table.groupBy(
    (key, value) -&gt; KeyValue.pair(value, value.length()),
    Grouped.with(
      Serdes.String(), /* key (note: type was modified) */
      Serdes.Integer()) /* value (note: type was modified) */
  );

</code></pre>
                        </td>
                    </tr>
                    <tr class="row-odd"><td><p class="first"><strong>Cogroup</strong></p>
                        <ul class="last simple">
                            <li>KGroupedStream &rarr; CogroupedKStream</li>
                            <li>CogroupedKStream &rarr; CogroupedKStream</li>
                        </ul>
                    </td>
                        <td><p class="first">Cogrouping allows to aggregate multiple input streams in a single operation.
                            The different (already grouped) input streams must have the same key type and may have different values types.
                            <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KGroupedStream.html#cogroup">KGroupedStream#cogroup()</a> creates a new cogrouped stream with a single input stream, while <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/CogroupedKStream.html#cogroup">CogroupedKStream#cogroup()</a> adds a grouped stream to an existing cogrouped stream.
                            A <code>CogroupedKStream</code> may be <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/CogroupedKStream.html#windowedBy">windowed</a> before it is <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/CogroupedKStream.html#aggregate">aggregated</a>.

                            <p class="first">Cogroup does not cause a repartition as it has the prerequisite that the input streams are grouped. In the process of creating these groups they will have already been repartitioned if the stream was already marked for repartitioning.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream = ...;
                        KStream&lt;byte[], String&gt; stream2 = ...;

// Group by the existing key, using the application&#39;s configured
// default serdes for keys and values.
KGroupedStream&lt;byte[], String&gt; groupedStream = stream.groupByKey();
KGroupedStream&lt;byte[], String&gt; groupedStream2 = stream2.groupByKey();
CogroupedKStream&lt;byte[], String&gt; cogroupedStream = groupedStream.cogroup(aggregator1).cogroup(groupedStream2, aggregator2);

KTable&lt;byte[], String&gt; table = cogroupedStream.aggregate(initializer);

KTable&lt;byte[], String&gt; table2 = cogroupedStream.windowedBy(TimeWindows.ofSizeWithNoGrace(Duration.ofMillis(500))).aggregate(initializer);</code></pre>
                        </td>
                    </tr>
                    <tr class="row-even"><td><p class="first"><strong>Map</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KStream</li>
                        </ul>
                    </td>
                        <td><p class="first">Takes one record and produces one record.  You can modify the record key and value, including their types.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#map-org.apache.kafka.streams.kstream.KeyValueMapper-">details</a>)</p>
                            <p><strong>Marks the stream for data re-partitioning:</strong>
                                Applying a grouping or a join after <code class="docutils literal"><span class="pre">map</span></code> will result in re-partitioning of the records.
                                If possible use <code class="docutils literal"><span class="pre">mapValues</span></code> instead, which will not cause data re-partitioning.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream = ...;

// Note how we change the key and the key type (similar to `selectKey`)
// as well as the value and the value type.
KStream&lt;String, Integer&gt; transformed = stream.map(
    (key, value) -&gt; KeyValue.pair(value.toLowerCase(), value.length()));
</code></pre>
                        </td>
                    </tr>
                    <tr class="row-odd"><td><p class="first"><strong>Map (values only)</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KStream</li>
                            <li>KTable &rarr; KTable</li>
                        </ul>
                    </td>
                        <td><p class="first">Takes one record and produces one record, while retaining the key of the original record.
                            You can modify the record value and the value type.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#mapValues-org.apache.kafka.streams.kstream.ValueMapper-">KStream details</a>,
                            <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KTable.html#mapValues-org.apache.kafka.streams.kstream.ValueMapper-">KTable details</a>)</p>
                            <p><code class="docutils literal"><span class="pre">mapValues</span></code> is preferable to <code class="docutils literal"><span class="pre">map</span></code> because it will not cause data re-partitioning.  However, it does not
                                allow you to modify the key or key type like <code class="docutils literal"><span class="pre">map</span></code> does.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream = ...;

KStream&lt;byte[], String&gt; uppercased = stream.mapValues(value -&gt; value.toUpperCase());
</code></pre>
                        </td>
                    </tr>
                    <tr class="row-even"><td><p class="first"><strong>Merge</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KStream</li>
                        </ul>
                    </td>
                        <td><p class="first">Merges records of two streams into one larger stream.
                            (<a class="reference external"
                            href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#merge-org.apache.kafka.streams.kstream.KStream-">details</a>)
                            <p>There is no ordering guarantee between records
                            from different streams in the merged stream. Relative order is preserved within each input stream though (ie, records within the same input stream are processed in order)</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream1 = ...;

KStream&lt;byte[], String&gt; stream2 = ...;

KStream&lt;byte[], String&gt; merged = stream1.merge(stream2);</code></pre>
                        </td>
                    </tr>
                    <tr class="row-odd"><td><p class="first"><strong>Peek</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KStream</li>
                        </ul>
                    </td>
                        <td><p class="first">Performs a stateless action on each record, and returns an unchanged stream.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#peek-org.apache.kafka.streams.kstream.ForeachAction-">details</a>)</p>
                            <p>You would use <code class="docutils literal"><span class="pre">peek</span></code> to cause <em>side effects</em> based on the input data (similar to <code class="docutils literal"><span class="pre">foreach</span></code>) and <em>continue</em>
                                <em>processing</em> the input data (unlike <code class="docutils literal"><span class="pre">foreach</span></code>, which is a terminal operation).  <code class="docutils literal"><span class="pre">peek</span></code> returns the input
                                stream as-is;  if you need to modify the input stream, use <code class="docutils literal"><span class="pre">map</span></code> or <code class="docutils literal"><span class="pre">mapValues</span></code> instead.</p>
                            <p><code class="docutils literal"><span class="pre">peek</span></code> is helpful for use cases such as logging or tracking metrics or for debugging and troubleshooting.</p>
                            <p><strong>Note on processing guarantees:</strong> Any side effects of an action (such as writing to external systems) are not
                                trackable by Kafka, which means they will typically not benefit from Kafka&#8217;s processing guarantees.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream = ...;

KStream&lt;byte[], String&gt; unmodifiedStream = stream.peek(
    (key, value) -&gt; System.out.println(&quot;key=&quot; + key + &quot;, value=&quot; + value));
</code></pre>
                        </td>
                    </tr>
                    <tr class="row-even"><td><p class="first"><strong>Print</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; void</li>
                        </ul>
                    </td>
                        <td><p class="first"><strong>Terminal operation.</strong>  Prints the records to <code class="docutils literal"><span class="pre">System.out</span></code>.  See Javadocs for serde and <code class="docutils literal"><span class="pre">toString()</span></code>
                            caveats.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#print--">details</a>)</p>
                            <p>Calling <code class="docutils literal"><span class="pre">print()</span></code> is the same as calling <code class="docutils literal"><span class="pre">foreach((key,</span> <span class="pre">value)</span> <span class="pre">-&gt;</span> <span class="pre">System.out.println(key</span> <span class="pre">+</span> <span class="pre">&quot;,</span> <span class="pre">&quot;</span> <span class="pre">+</span> <span class="pre">value))</span></code></p>
                            <p><code class="docutils literal"><span class="pre">print</span></code> is mainly for debugging/testing purposes, and it will try to flush on each record print. Hence it <strong>should not</strong> be used for production usage if performance requirements are concerned.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream = ...;
// print to sysout
stream.print();

// print to file with a custom label
stream.print(Printed.toFile(&quot;streams.out&quot;).withLabel(&quot;streams&quot;));</code></pre>
                        </td>
                    </tr>
                    <tr class="row-odd"><td><p class="first"><strong>SelectKey</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KStream</li>
                        </ul>
                    </td>
                        <td><p class="first">Assigns a new key &#8211; possibly of a new key type &#8211; to each record.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#selectKey-org.apache.kafka.streams.kstream.KeyValueMapper-">details</a>)</p>
                            <p>Calling <code class="docutils literal"><span class="pre">selectKey(mapper)</span></code> is the same as calling <code class="docutils literal"><span class="pre">map((key,</span> <span class="pre">value)</span> <span class="pre">-&gt;</span> <span class="pre">mapper(key,</span> <span class="pre">value),</span> <span class="pre">value)</span></code>.</p>
                            <p><strong>Marks the stream for data re-partitioning:</strong>
                                Applying a grouping or a join after <code class="docutils literal"><span class="pre">selectKey</span></code> will result in re-partitioning of the records.</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream = ...;

// Derive a new record key from the record&#39;s value.  Note how the key type changes, too.
KStream&lt;String, String&gt; rekeyed = stream.selectKey((key, value) -&gt; value.split(&quot; &quot;)[0])
</code></pre>
                        </td>
                    </tr>
                    <tr class="row-even"><td><p class="first"><strong>Table to Stream</strong></p>
                        <ul class="last simple">
                            <li>KTable &rarr; KStream</li>
                        </ul>
                    </td>
                        <td><p class="first">Get the changelog stream of this table.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KTable.html#toStream--">details</a>)</p>
                            <pre class="line-numbers"><code class="language-java">KTable&lt;byte[], String&gt; table = ...;

// Also, a variant of `toStream` exists that allows you
// to select a new key for the resulting stream.
KStream&lt;byte[], String&gt; stream = table.toStream();</code></pre>
                        </td>
                    </tr>
                    <tr class="row-odd"><td><p class="first"><strong>Stream to Table</strong></p>
                        <ul class="last simple">
                            <li>KStream &rarr; KTable</li>
                        </ul>
                    </td>
                        <td><p class="first">Convert an event stream into a table, or say a changelog stream.
                            (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#toTable--">details</a>)</p>
                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream = ...;

KTable&lt;byte[], String&gt; table = stream.toTable();</code></pre>
                        </td>
                    </tr>
                    <tr class="row-odd">
                        <td><p class="first"><strong>Repartition</strong></p>
                            <ul class="last simple">
                                <li>KStream &rarr; KStream</li>
                            </ul>
                        </td>
                        <td>
                            <p class="first">Manually trigger repartitioning of the stream with desired number of partitions. (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#repartition--">details</a>)</p>

                            <code><span class="pre">repartition()</span></code> is similar to <code><span class="pre">through()</span></code> however Kafka Streams will manage the topic for you.
                            Generated topic is treated as internal topic, as a result data will be purged automatically as any other internal repartition topic.
                            In addition, you can specify the desired number of partitions, which allows to easily scale in/out downstream sub-topologies.
                            <code><span class="pre">repartition()</span></code> operation always triggers repartitioning of the stream, as a result it can be used with embedded Processor API methods (like <code><span class="pre">transform()</span></code> et al.) that do not trigger auto repartitioning when key changing operation is performed beforehand.

                            <pre class="line-numbers"><code class="language-java">KStream&lt;byte[], String&gt; stream = ... ;
KStream&lt;byte[], String&gt; repartitionedStream = stream.repartition(Repartitioned.numberOfPartitions(10));</code></pre>
                        </td>
                    </tr>
                    </tbody>
                </table>
            </div>
            <div class="section" id="stateful-transformations">
                <span id="streams-developer-guide-dsl-transformations-stateful"></span><h3><a class="toc-backref" href="#id11">Stateful transformations</a><a class="headerlink" href="#stateful-transformations" title="Permalink to this headline"></a></h3>
                <p id="streams-developer-guide-dsl-transformations-stateful-overview">Stateful transformations depend on state for processing inputs and producing outputs and require a <a class="reference internal" href="../architecture.html#streams_architecture_state"><span class="std std-ref">state store</span></a> associated with the stream processor. For example, in aggregating operations, a windowing state store is used to collect the latest aggregation results per
                    window. In join operations, a windowing state store is used to collect all of the records received so far within the
                    defined window boundary.</p>
		<p><b>Note:</b> Following store types are used regardless of the possibly specified type (via the parameter <code class="docutils literal"><span class="pre">materialized</span></code>):
		<ul class="simple">
		    <li>non-windowed aggregations and non-windowed KTables use <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/state/TimestampedKeyValueStore.html">TimestampedKeyValueStore</a>s
                or <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/state/VersionedKeyValueStore.html">VersionedKeyValueStore</a>s,
                depending on whether the parameter <code class="docutils literal"><span class="pre">materialized</span></code> is versioned</li>
		    <li>time-windowed aggregations and KStream-KStream joins use <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/state/TimestampedWindowStore.html">TimestampedWindowStore</a>s</li>
		    <li>session windowed aggregations use <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/state/SessionStore.html">SessionStore</a>s (there is no timestamped session store as of now)</li>
		</ul>
                <p>Note, that state stores are fault-tolerant.
                    In case of failure, Kafka Streams guarantees to fully restore all state stores prior to resuming the processing.
                    See <a class="reference internal" href="../architecture.html#streams_architecture_recovery"><span class="std std-ref">Fault Tolerance</span></a> for further information.</p>
                <p>Available stateful transformations in the DSL include:</p>
                <ul class="simple">
                    <li><a class="reference internal" href="#streams-developer-guide-dsl-aggregating"><span class="std std-ref">Aggregating</span></a></li>
                    <li><a class="reference internal" href="#streams-developer-guide-dsl-joins"><span class="std std-ref">Joining</span></a></li>
                    <li><a class="reference internal" href="#streams-developer-guide-dsl-windowing"><span class="std std-ref">Windowing</span></a> (as part of aggregations and joins)</li>
                    <li><a class="reference internal" href="#streams-developer-guide-dsl-process"><span class="std std-ref">Applying custom processors and transformers</span></a>, which may be stateful, for
                        Processor API integration</li>
                </ul>
                <p>The following diagram shows their relationships:</p>
                <div class="figure align-center" id="id2">
                    <img class="centered" src="/{{version}}/images/streams-stateful_operations.png">
                    <p class="caption"><span class="caption-text">Stateful transformations in the DSL.</span></p>
                </div>
                <p>Here is an example of a stateful application: the WordCount algorithm.</p>
                <p>WordCount example:</p>
                <pre class="line-numbers"><code class="language-java">// Assume the record values represent lines of text.  For the sake of this example, you can ignore
// whatever may be stored in the record keys.
KStream&lt;String, String&gt; textLines = ...;

KStream&lt;String, Long&gt; wordCounts = textLines
    // Split each text line, by whitespace, into words.  The text lines are the record
    // values, i.e. you can ignore whatever data is in the record keys and thus invoke
    // `flatMapValues` instead of the more generic `flatMap`.
    .flatMapValues(value -&gt; Arrays.asList(value.toLowerCase().split(&quot;\\W+&quot;)))
    // Group the stream by word to ensure the key of the record is the word.
    .groupBy((key, word) -&gt; word)
    // Count the occurrences of each word (record key).
    //
    // This will change the stream type from `KGroupedStream&lt;String, String&gt;` to
    // `KTable&lt;String, Long&gt;` (word -&gt; count).
    .count()
    // Convert the `KTable&lt;String, Long&gt;` into a `KStream&lt;String, Long&gt;`.
    .toStream();</code></pre>

                <div class="section" id="aggregating">
                    <span id="streams-developer-guide-dsl-aggregating"></span><h4><a class="toc-backref" href="#id12">Aggregating</a><a class="headerlink" href="#aggregating" title="Permalink to this headline"></a></h4>
                    <p>After records are <a class="reference internal" href="#streams-developer-guide-dsl-transformations-stateless"><span class="std std-ref">grouped</span></a> by key via <code class="docutils literal"><span class="pre">groupByKey</span></code> or
                        <code class="docutils literal"><span class="pre">groupBy</span></code> &#8211; and thus represented as either a <code class="docutils literal"><span class="pre">KGroupedStream</span></code> or a <code class="docutils literal"><span class="pre">KGroupedTable</span></code>, they can be aggregated
                        via an operation such as <code class="docutils literal"><span class="pre">reduce</span></code>.  Aggregations are key-based operations, which means that they always operate over records
                        (notably record values) of the same key.
                        You can perform aggregations on <a class="reference internal" href="#streams-developer-guide-dsl-windowing"><span class="std std-ref">windowed</span></a> or non-windowed data.</p>
                    <table border="1" class="non-scrolling-table width-100-percent docutils">
                        <colgroup>
                            <col width="22%" />
                            <col width="78%" />
                        </colgroup>
                        <thead valign="bottom">
                        <tr class="row-odd"><th class="head">Transformation</th>
                            <th class="head">Description</th>
                        </tr>
                        </thead>
                        <tbody valign="top">
                        <tr class="row-even"><td><p class="first"><strong>Aggregate</strong></p>
                            <ul class="last simple">
                                <li>KGroupedStream &rarr; KTable</li>
                                <li>KGroupedTable &rarr; KTable</li>
                            </ul>
                        </td>
                            <td><p class="first"><strong>Rolling aggregation.</strong> Aggregates the values of (non-windowed) records by the grouped key or cogrouped.
                                Aggregating is a generalization of <code class="docutils literal"><span class="pre">reduce</span></code> and allows, for example, the aggregate value to have a different
                                type than the input values.
                                (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KGroupedStream.html">KGroupedStream details</a>,
                                <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KGroupedTable.html">KGroupedTable details</a>
                                <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/CogroupedKStream.html">KGroupedTable details</a>)</p>
                                <p>When aggregating a <em>grouped stream</em>, you must provide an initializer (e.g., <code class="docutils literal"><span class="pre">aggValue</span> <span class="pre">=</span> <span class="pre">0</span></code>) and an &#8220;adder&#8221;
                                    aggregator (e.g., <code class="docutils literal"><span class="pre">aggValue</span> <span class="pre">+</span> <span class="pre">curValue</span></code>).  When aggregating a <em>grouped table</em>, you must additionally provide a
                                    &#8220;subtractor&#8221; aggregator (think: <code class="docutils literal"><span class="pre">aggValue</span> <span class="pre">-</span> <span class="pre">oldValue</span></code>).</p>
                                <p>When aggregating a <em>cogrouped stream</em>, the actual aggregators are provided for each input stream in the prior <code>cogroup()</code>calls, and thus you only need to provide an initializer (e.g., <code class="docutils literal"><span class="pre">aggValue</span> <span class="pre">=</span> <span class="pre">0</span></code>)

                                <p>Several variants of <code class="docutils literal"><span class="pre">aggregate</span></code> exist, see Javadocs for details.</p>
                                <pre class="line-numbers"><code class="language-java">KGroupedStream&lt;byte[], String&gt; groupedStream = ...;
KGroupedTable&lt;byte[], String&gt; groupedTable = ...;

// Aggregating a KGroupedStream (note how the value type changes from String to Long)
KTable&lt;byte[], Long&gt; aggregatedStream = groupedStream.aggregate(
    () -&gt; 0L, /* initializer */
    (aggKey, newValue, aggValue) -&gt; aggValue + newValue.length(), /* adder */
    Materialized.&lt;String, Long, KeyValueStore&lt;Bytes, byte[]&gt;&gt;as(&quot;aggregated-stream-store&quot;) /* state store name */
        .withValueSerde(Serdes.Long()); /* serde for aggregate value */

// Aggregating a KGroupedTable (note how the value type changes from String to Long)
KTable&lt;byte[], Long&gt; aggregatedTable = groupedTable.aggregate(
    () -&gt; 0L, /* initializer */
    (aggKey, newValue, aggValue) -&gt; aggValue + newValue.length(), /* adder */
    (aggKey, oldValue, aggValue) -&gt; aggValue - oldValue.length(), /* subtractor */
    Materialized.&lt;String, Long, KeyValueStore&lt;Bytes, byte[]&gt;&gt;as(&quot;aggregated-table-store&quot;) /* state store name */
	.withValueSerde(Serdes.Long()) /* serde for aggregate value */
</code></pre>
                                <p>Detailed behavior of <code class="docutils literal"><span class="pre">KGroupedStream</span></code>:</p>
                                <ul class="simple">
                                    <li>Input records with <code class="docutils literal"><span class="pre">null</span></code> keys are ignored.</li>
                                    <li>When a record key is received for the first time, the initializer is called (and called before the adder).</li>
                                    <li>Whenever a record with a non-<code class="docutils literal"><span class="pre">null</span></code> value is received, the adder is called.</li>
                                </ul>
                                <p>Detailed behavior of <code class="docutils literal"><span class="pre">KGroupedTable</span></code>:</p>
                                <ul class="simple">
                                    <li>Input records with <code class="docutils literal"><span class="pre">null</span></code> keys are ignored.</li>
                                    <li>When a record key is received for the first time, the initializer is called (and called before the adder
                                        and subtractor).  Note that, in contrast to <code class="docutils literal"><span class="pre">KGroupedStream</span></code>, over time the initializer may be called
                                        more than once for a key as a result of having received input tombstone records for that key (see below).</li>
                                    <li>When the first non-<code class="docutils literal"><span class="pre">null</span></code> value is received for a key (e.g.,  INSERT), then only the adder is called.</li>
                                    <li>When subsequent non-<code class="docutils literal"><span class="pre">null</span></code> values are received for a key (e.g.,  UPDATE), then (1) the subtractor is
                                        called with the old value as stored in the table and (2) the adder is called with the new value of the
                                        input record that was just received. The subtractor is guaranteed to be called before the adder if the extracted grouping key of the old and new value is the same.
                                        The detection of this case depends on the correct implementation of the equals() method of the extracted key type. Otherwise, the order of execution for the subtractor
                                        and adder is not defined.</li>
                                    <li>When a tombstone record &#8211; i.e. a record with a <code class="docutils literal"><span class="pre">null</span></code> value &#8211; is received for a key (e.g.,  DELETE),
                                        then only the subtractor is called.  Note that, whenever the subtractor returns a <code class="docutils literal"><span class="pre">null</span></code> value itself,
                                        then the corresponding key is removed from the resulting <code class="docutils literal"><span class="pre">KTable</span></code>.  If that happens, any next input
                                        record for that key will trigger the initializer again.</li>
                                </ul>
                                <p class="last">See the example at the bottom of this section for a visualization of the aggregation semantics.</p>
                            </td>
                        </tr>
                        <tr class="row-even"><td><p class="first"><strong>Aggregate (windowed)</strong></p>
                            <ul class="last simple">
                                <li>KGroupedStream &rarr; KTable</li>
                            </ul>
                        </td>
                            <td><p class="first"><strong>Windowed aggregation.</strong>
                                Aggregates the values of records, <a class="reference internal" href="#streams-developer-guide-dsl-windowing"><span class="std std-ref">per window</span></a>, by the grouped key.
                                Aggregating is a generalization of <code class="docutils literal"><span class="pre">reduce</span></code> and allows, for example, the aggregate value to have a different
                                type than the input values.
                                (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/TimeWindowedKStream.html">TimeWindowedKStream details</a>,
                                <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/SessionWindowedKStream.html">SessionWindowedKStream details</a>)</p>
                                <p>You must provide an initializer (e.g.,  <code class="docutils literal"><span class="pre">aggValue</span> <span class="pre">=</span> <span class="pre">0</span></code>), &#8220;adder&#8221; aggregator (e.g.,  <code class="docutils literal"><span class="pre">aggValue</span> <span class="pre">+</span> <span class="pre">curValue</span></code>),
                                    and a window.  When windowing based on sessions, you must additionally provide a &#8220;session merger&#8221; aggregator
                                    (e.g.,  <code class="docutils literal"><span class="pre">mergedAggValue</span> <span class="pre">=</span> <span class="pre">leftAggValue</span> <span class="pre">+</span> <span class="pre">rightAggValue</span></code>).</p>
                                <p>The windowed <code class="docutils literal"><span class="pre">aggregate</span></code> turns a <code class="docutils literal"><span class="pre">TimeWindowedKStream&lt;K,</span> <span class="pre">V&gt;</span></code> or <code class="docutils literal"><span class="pre">SessionWindowedKStream&lt;K,</span> <span class="pre">V&gt;</span></code>
                                    into a windowed <code class="docutils literal"><span class="pre">KTable&lt;Windowed&lt;K&gt;,</span> <span class="pre">V&gt;</span></code>.</p>
                                <p>Several variants of <code class="docutils literal"><span class="pre">aggregate</span></code> exist, see Javadocs for details.</p>
                                <pre class="line-numbers"><code class="language-java">import java.time.Duration;
KGroupedStream&lt;String, Long&gt; groupedStream = ...;

// Aggregating with time-based windowing (here: with 5-minute tumbling windows)
KTable&lt;Windowed&lt;String&gt;, Long&gt; timeWindowedAggregatedStream = groupedStream.windowedBy(Duration.ofMinutes(5))
    .aggregate(
        () -&gt; 0L, /* initializer */
        (aggKey, newValue, aggValue) -&gt; aggValue + newValue, /* adder */
        Materialized.&lt;String, Long, WindowStore&lt;Bytes, byte[]&gt;&gt;as(&quot;time-windowed-aggregated-stream-store&quot;) /* state store name */
        .withValueSerde(Serdes.Long())); /* serde for aggregate value */

// Aggregating with time-based windowing (here: with 5-minute sliding windows and 30-minute grace period)
KTable&lt;Windowed&lt;String&gt;, Long&gt; timeWindowedAggregatedStream = groupedStream.windowedBy(SlidingWindows.ofTimeDifferenceAndGrace(Duration.ofMinutes(5), Duration.ofMinutes(30)))
    .aggregate(
        () -&gt; 0L, /* initializer */
        (aggKey, newValue, aggValue) -&gt; aggValue + newValue, /* adder */
        Materialized.&lt;String, Long, WindowStore&lt;Bytes, byte[]&gt;&gt;as(&quot;time-windowed-aggregated-stream-store&quot;) /* state store name */
        .withValueSerde(Serdes.Long())); /* serde for aggregate value */

// Aggregating with session-based windowing (here: with an inactivity gap of 5 minutes)
KTable&lt;Windowed&lt;String&gt;, Long&gt; sessionizedAggregatedStream = groupedStream.windowedBy(SessionWindows.ofInactivityGapWithNoGrace(Duration.ofMinutes(5)).
    aggregate(
    	() -&gt; 0L, /* initializer */
    	(aggKey, newValue, aggValue) -&gt; aggValue + newValue, /* adder */
        (aggKey, leftAggValue, rightAggValue) -&gt; leftAggValue + rightAggValue, /* session merger */
        Materialized.&lt;String, Long, SessionStore&lt;Bytes, byte[]&gt;&gt;as(&quot;sessionized-aggregated-stream-store&quot;) /* state store name */
        .withValueSerde(Serdes.Long())); /* serde for aggregate value */
</code></pre>
                                <p>Detailed behavior:</p>
                                <ul class="simple">
                                    <li>The windowed aggregate behaves similar to the rolling aggregate described above.  The additional twist is that
                                        the behavior applies <em>per window</em>.</li>
                                    <li>Input records with <code class="docutils literal"><span class="pre">null</span></code> keys are ignored in general.</li>
                                    <li>When a record key is received for the first time for a given window, the initializer is called (and called
                                        before the adder).</li>
                                    <li>Whenever a record with a non-<code class="docutils literal"><span class="pre">null</span></code> value is received for a given window, the adder is called.</li>
                                    <li>When using session windows: the session merger is called whenever two sessions are being merged.</li>
                                </ul>
                                <p class="last">See the example at the bottom of this section for a visualization of the aggregation semantics.</p>
                            </td>
                        </tr>
                        <tr class="row-odd"><td><p class="first"><strong>Count</strong></p>
                            <ul class="last simple">
                                <li>KGroupedStream &rarr; KTable</li>
                                <li>KGroupedTable &rarr; KTable</li>
                            </ul>
                        </td>
                            <td><p class="first"><strong>Rolling aggregation.</strong> Counts the number of records by the grouped key.
                                (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KGroupedStream.html">KGroupedStream details</a>,
                                <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KGroupedTable.html">KGroupedTable details</a>)</p>
                                <p>Several variants of <code class="docutils literal"><span class="pre">count</span></code> exist, see Javadocs for details.</p>
                                <pre class="line-numbers"><code class="language-java">KGroupedStream&lt;String, Long&gt; groupedStream = ...;
KGroupedTable&lt;String, Long&gt; groupedTable = ...;

// Counting a KGroupedStream
KTable&lt;String, Long&gt; aggregatedStream = groupedStream.count();

// Counting a KGroupedTable
KTable&lt;String, Long&gt; aggregatedTable = groupedTable.count();</code></pre>
                                <p>Detailed behavior for <code class="docutils literal"><span class="pre">KGroupedStream</span></code>:</p>
                                <ul class="simple">
                                    <li>Input records with <code class="docutils literal"><span class="pre">null</span></code> keys or values are ignored.</li>
                                </ul>
                                <p>Detailed behavior for <code class="docutils literal"><span class="pre">KGroupedTable</span></code>:</p>
                                <ul class="last simple">
                                    <li>Input records with <code class="docutils literal"><span class="pre">null</span></code> keys are ignored.  Records with <code class="docutils literal"><span class="pre">null</span></code> values are not ignored but interpreted
                                        as &#8220;tombstones&#8221; for the corresponding key, which indicate the deletion of the key from the table.</li>
                                </ul>
                            </td>
                        </tr>
                        <tr class="row-even"><td><p class="first"><strong>Count (windowed)</strong></p>
                            <ul class="last simple">
                                <li>KGroupedStream &rarr; KTable</li>
                            </ul>
                        </td>
                            <td><p class="first"><strong>Windowed aggregation.</strong>
                                Counts the number of records, <a class="reference internal" href="#streams-developer-guide-dsl-windowing"><span class="std std-ref">per window</span></a>, by the grouped key.
                                (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/TimeWindowedKStream.html">TimeWindowedKStream details</a>,
                                <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/SessionWindowedKStream.html">SessionWindowedKStream details</a>)</p>
                                <p>The windowed <code class="docutils literal"><span class="pre">count</span></code> turns a <code class="docutils literal"><span class="pre">TimeWindowedKStream&lt;K,</span> <span class="pre">V&gt;</span></code> or <code class="docutils literal"><span class="pre">SessionWindowedKStream&lt;K,</span> <span class="pre">V&gt;</span></code>
                                    into a windowed <code class="docutils literal"><span class="pre">KTable&lt;Windowed&lt;K&gt;,</span> <span class="pre">V&gt;</span></code>.</p>
                                <p>Several variants of <code class="docutils literal"><span class="pre">count</span></code> exist, see Javadocs for details.</p>
                                <pre class="line-numbers"><code class="language-java">import java.time.Duration;
KGroupedStream&lt;String, Long&gt; groupedStream = ...;

// Counting a KGroupedStream with time-based windowing (here: with 5-minute tumbling windows)
KTable&lt;Windowed&lt;String&gt;, Long&gt; aggregatedStream = groupedStream.windowedBy(
    TimeWindows.ofSizeWithNoGrace(Duration.ofMinutes(5))) /* time-based window */
    .count();

// Counting a KGroupedStream with time-based windowing (here: with 5-minute sliding windows and 30-minute grace period)
KTable&lt;Windowed&lt;String&gt;, Long&gt; aggregatedStream = groupedStream.windowedBy(
    SlidingWindows.ofTimeDifferenceAndGrace(Duration.ofMinutes(5), Duration.ofMinutes(30))) /* time-based window */
    .count();

// Counting a KGroupedStream with session-based windowing (here: with 5-minute inactivity gaps)
KTable&lt;Windowed&lt;String&gt;, Long&gt; aggregatedStream = groupedStream.windowedBy(
    SessionWindows.ofInactivityGapWithNoGrace(Duration.ofMinutes(5))) /* session window */
    .count();</code></pre>
                                <p>Detailed behavior:</p>
                                <ul class="last simple">
                                    <li>Input records with <code class="docutils literal"><span class="pre">null</span></code> keys or values are ignored.</li>
                                </ul>
                            </td>
                        </tr>
                        <tr class="row-odd"><td><p class="first"><strong>Reduce</strong></p>
                            <ul class="last simple">
                                <li>KGroupedStream &rarr; KTable</li>
                                <li>KGroupedTable &rarr; KTable</li>
                            </ul>
                        </td>
                            <td><p class="first"><strong>Rolling aggregation.</strong> Combines the values of (non-windowed) records by the grouped key.
                                The current record value is combined with the last reduced value, and a new reduced value is returned.
                                The result value type cannot be changed, unlike <code class="docutils literal"><span class="pre">aggregate</span></code>.
                                (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KGroupedStream.html">KGroupedStream details</a>,
                                <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KGroupedTable.html">KGroupedTable details</a>)</p>
                                <p>When reducing a <em>grouped stream</em>, you must provide an &#8220;adder&#8221; reducer (e.g.,  <code class="docutils literal"><span class="pre">aggValue</span> <span class="pre">+</span> <span class="pre">curValue</span></code>).
                                    When reducing a <em>grouped table</em>, you must additionally provide a &#8220;subtractor&#8221; reducer (e.g.,
                                    <code class="docutils literal"><span class="pre">aggValue</span> <span class="pre">-</span> <span class="pre">oldValue</span></code>).</p>
                                <p>Several variants of <code class="docutils literal"><span class="pre">reduce</span></code> exist, see Javadocs for details.</p>
                                <pre class="line-numbers"><code class="language-java">KGroupedStream&lt;String, Long&gt; groupedStream = ...;
KGroupedTable&lt;String, Long&gt; groupedTable = ...;

// Reducing a KGroupedStream
KTable&lt;String, Long&gt; aggregatedStream = groupedStream.reduce(
    (aggValue, newValue) -&gt; aggValue + newValue /* adder */);

// Reducing a KGroupedTable
KTable&lt;String, Long&gt; aggregatedTable = groupedTable.reduce(
    (aggValue, newValue) -&gt; aggValue + newValue, /* adder */
    (aggValue, oldValue) -&gt; aggValue - oldValue /* subtractor */);
</code></pre>
                                <p>Detailed behavior for <code class="docutils literal"><span class="pre">KGroupedStream</span></code>:</p>
                                <ul class="simple">
                                    <li>Input records with <code class="docutils literal"><span class="pre">null</span></code> keys are ignored in general.</li>
                                    <li>When a record key is received for the first time, then the value of that record is used as the initial
                                        aggregate value.</li>
                                    <li>Whenever a record with a non-<code class="docutils literal"><span class="pre">null</span></code> value is received, the adder is called.</li>
                                </ul>
                                <p>Detailed behavior for <code class="docutils literal"><span class="pre">KGroupedTable</span></code>:</p>
                                <ul class="simple">
                                    <li>Input records with <code class="docutils literal"><span class="pre">null</span></code> keys are ignored in general.</li>
                                    <li>When a record key is received for the first time, then the value of that record is used as the initial
                                        aggregate value.
                                        Note that, in contrast to <code class="docutils literal"><span class="pre">KGroupedStream</span></code>, over time this initialization step may happen more than once
                                        for a key as a result of having received input tombstone records for that key (see below).</li>
                                    <li>When the first non-<code class="docutils literal"><span class="pre">null</span></code> value is received for a key (e.g.,  INSERT), then only the adder is called.</li>
                                    <li>When subsequent non-<code class="docutils literal"><span class="pre">null</span></code> values are received for a key (e.g.,  UPDATE), then (1) the subtractor is
                                        called with the old value as stored in the table and (2) the adder is called with the new value of the
                                        input record that was just received. The subtractor is guaranteed be called before the adder if the extracted grouping key of the old and new value is the same.
                                        The detection of this case depends on the correct implementation of the equals() method of the extracted key type. Otherwise, the order of execution for the subtractor
                                        and adder is not defined.</li>
                                    <li>When a tombstone record &#8211; i.e. a record with a <code class="docutils literal"><span class="pre">null</span></code> value &#8211; is received for a key (e.g.,  DELETE),
                                        then only the subtractor is called.  Note that, whenever the subtractor returns a <code class="docutils literal"><span class="pre">null</span></code> value itself,
                                        then the corresponding key is removed from the resulting <code class="docutils literal"><span class="pre">KTable</span></code>.  If that happens, any next input
                                        record for that key will re-initialize its aggregate value.</li>
                                </ul>
                                <p class="last">See the example at the bottom of this section for a visualization of the aggregation semantics.</p>
                            </td>
                        </tr>
                        <tr class="row-even"><td><p class="first"><strong>Reduce (windowed)</strong></p>
                            <ul class="last simple">
                                <li>KGroupedStream &rarr; KTable</li>
                            </ul>
                        </td>
                            <td><p class="first"><strong>Windowed aggregation.</strong>
                                Combines the values of records, <a class="reference internal" href="#streams-developer-guide-dsl-windowing"><span class="std std-ref">per window</span></a>, by the grouped key.
                                The current record value is combined with the last reduced value, and a new reduced value is returned.
                                Records with <code class="docutils literal"><span class="pre">null</span></code> key or value are ignored.
                                The result value type cannot be changed, unlike <code class="docutils literal"><span class="pre">aggregate</span></code>.
                                (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/TimeWindowedKStream.html">TimeWindowedKStream details</a>,
                                <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/SessionWindowedKStream.html">SessionWindowedKStream details</a>)</p>
                                <p>The windowed <code class="docutils literal"><span class="pre">reduce</span></code> turns a turns a <code class="docutils literal"><span class="pre">TimeWindowedKStream&lt;K,</span> <span class="pre">V&gt;</span></code> or a <code class="docutils literal"><span class="pre">SessionWindowedKStream&lt;K,</span> <span class="pre">V&gt;</span></code>
                                    into a windowed <code class="docutils literal"><span class="pre">KTable&lt;Windowed&lt;K&gt;,</span> <span class="pre">V&gt;</span></code>.</p>
                                <p>Several variants of <code class="docutils literal"><span class="pre">reduce</span></code> exist, see Javadocs for details.</p>
                                <pre class="line-numbers"><code class="language-java">import java.time.Duration;
KGroupedStream&lt;String, Long&gt; groupedStream = ...;

// Aggregating with time-based windowing (here: with 5-minute tumbling windows)
KTable&lt;Windowed&lt;String&gt;, Long&gt; timeWindowedAggregatedStream = groupedStream.windowedBy(
  TimeWindows.ofSizeWithNoGrace(Duration.ofMinutes(5)) /* time-based window */)
  .reduce(
    (aggValue, newValue) -&gt; aggValue + newValue /* adder */
  );

// Aggregating with time-based windowing (here: with 5-minute sliding windows and 30-minute grace)
KTable&lt;Windowed&lt;String&gt;, Long&gt; timeWindowedAggregatedStream = groupedStream.windowedBy(
  SlidingWindows.ofTimeDifferenceAndGrace(Duration.ofMinutes(5), Duration.ofMinutes(30))) /* time-based window */)
  .reduce(
    (aggValue, newValue) -&gt; aggValue + newValue /* adder */
  );

// Aggregating with session-based windowing (here: with an inactivity gap of 5 minutes)
KTable&lt;Windowed&lt;String&gt;, Long&gt; sessionzedAggregatedStream = groupedStream.windowedBy(
  SessionWindows.ofInactivityGapWithNoGrace(Duration.ofMinutes(5))) /* session window */
  .reduce(
    (aggValue, newValue) -&gt; aggValue + newValue /* adder */
  );
</code></pre>
                                <p>Detailed behavior:</p>
                                <ul class="simple">
                                    <li>The windowed reduce behaves similar to the rolling reduce described above.  The additional twist is that the
                                        behavior applies <em>per window</em>.</li>
                                    <li>Input records with <code class="docutils literal"><span class="pre">null</span></code> keys are ignored in general.</li>
                                    <li>When a record key is received for the first time for a given window, then the value of that record is used as
                                        the initial aggregate value.</li>
                                    <li>Whenever a record with a non-<code class="docutils literal"><span class="pre">null</span></code> value is received for a given window, the adder is called.</li>
                                </ul>
                                <p class="last">See the example at the bottom of this section for a visualization of the aggregation semantics.</p>
                            </td>
                        </tr>
                        </tbody>
                    </table>
                    <p><strong>Example of semantics for stream aggregations:</strong>
                        A <code class="docutils literal"><span class="pre">KGroupedStream</span></code> &rarr; <code class="docutils literal"><span class="pre">KTable</span></code> example is shown below.  The streams and the table are initially empty.  Bold
                        font is used in the column for &#8220;KTable <code class="docutils literal"><span class="pre">aggregated</span></code>&#8221; to highlight changed state.  An entry such as <code class="docutils literal"><span class="pre">(hello,</span> <span class="pre">1)</span></code> denotes a
                        record with key <code class="docutils literal"><span class="pre">hello</span></code> and value <code class="docutils literal"><span class="pre">1</span></code>.  To improve the readability of the semantics table you can assume that all records
                        are processed in timestamp order.</p>
                    <pre class="line-numbers"><code class="language-java">// Key: word, value: count
KStream&lt;String, Integer&gt; wordCounts = ...;

KGroupedStream&lt;String, Integer&gt; groupedStream = wordCounts
    .groupByKey(Grouped.with(Serdes.String(), Serdes.Integer()));

KTable&lt;String, Integer&gt; aggregated = groupedStream.aggregate(
    () -&gt; 0, /* initializer */
    (aggKey, newValue, aggValue) -&gt; aggValue + newValue, /* adder */
    Materialized.&lt;String, Long, KeyValueStore&lt;Bytes, byte[]&gt;as(&quot;aggregated-stream-store&quot; /* state store name */)
      .withKeySerde(Serdes.String()) /* key serde */
      .withValueSerde(Serdes.Integer()); /* serde for aggregate value */</code></pre>
                    <div class="admonition note">
                        <p><b>Note</b></p>
                        <p class="last"><strong>Impact of record caches</strong>:
                            For illustration purposes, the column &#8220;KTable <code class="docutils literal"><span class="pre">aggregated</span></code>&#8221; below shows the table&#8217;s state changes over time in a
                            very granular way.  In practice, you would observe state changes in such a granular way only when
                            <a class="reference internal" href="memory-mgmt.html#streams-developer-guide-memory-management-record-cache"><span class="std std-ref">record caches</span></a> are disabled (default: enabled).
                            When record caches are enabled, what might happen for example is that the output results of the rows with timestamps
                            4 and 5 would be <a class="reference internal" href="memory-mgmt.html#streams-developer-guide-memory-management-record-cache"><span class="std std-ref">compacted</span></a>, and there would only be
                            a single state update for the key <code class="docutils literal"><span class="pre">kafka</span></code> in the KTable (here: from <code class="docutils literal"><span class="pre">(kafka</span> <span class="pre">1)</span></code> directly to <code class="docutils literal"><span class="pre">(kafka,</span> <span class="pre">3)</span></code>.
                            Typically, you should only disable record caches for testing or debugging purposes &#8211; under normal circumstances it
                            is better to leave record caches enabled.</p>
                    </div>
                    <table border="1" class="docutils">
                        <thead valign="bottom">
                        <tr class="row-odd"><th class="head">&nbsp;</th>
                            <th class="head" colspan="2">KStream <code class="docutils literal"><span class="pre">wordCounts</span></code></th>
                            <th class="head" colspan="2">KGroupedStream <code class="docutils literal"><span class="pre">groupedStream</span></code></th>
                            <th class="head">KTable <code class="docutils literal"><span class="pre">aggregated</span></code></th>
                        </tr>
                        <tr class="row-even"><th class="head">Timestamp</th>
                            <th class="head">Input record</th>
                            <th class="head">Grouping</th>
                            <th class="head">Initializer</th>
                            <th class="head">Adder</th>
                            <th class="head">State</th>
                        </tr>
                        </thead>
                        <tbody valign="top">
                        <tr class="row-odd"><td>1</td>
                            <td>(hello, 1)</td>
                            <td>(hello, 1)</td>
                            <td>0 (for hello)</td>
                            <td>(hello, 0 + 1)</td>
                            <td><div class="first last line-block">
                                <div class="line"><strong>(hello, 1)</strong></div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-even"><td>2</td>
                            <td>(kafka, 1)</td>
                            <td>(kafka, 1)</td>
                            <td>0 (for kafka)</td>
                            <td>(kafka, 0 + 1)</td>
                            <td><div class="first last line-block">
                                <div class="line">(hello, 1)</div>
                                <div class="line"><strong>(kafka, 1)</strong></div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-odd"><td>3</td>
                            <td>(streams, 1)</td>
                            <td>(streams, 1)</td>
                            <td>0 (for streams)</td>
                            <td>(streams, 0 + 1)</td>
                            <td><div class="first last line-block">
                                <div class="line">(hello, 1)</div>
                                <div class="line">(kafka, 1)</div>
                                <div class="line"><strong>(streams, 1)</strong></div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-even"><td>4</td>
                            <td>(kafka, 1)</td>
                            <td>(kafka, 1)</td>
                            <td>&nbsp;</td>
                            <td>(kafka, 1 + 1)</td>
                            <td><div class="first last line-block">
                                <div class="line">(hello, 1)</div>
                                <div class="line">(kafka, <strong>2</strong>)</div>
                                <div class="line">(streams, 1)</div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-odd"><td>5</td>
                            <td>(kafka, 1)</td>
                            <td>(kafka, 1)</td>
                            <td>&nbsp;</td>
                            <td>(kafka, 2 + 1)</td>
                            <td><div class="first last line-block">
                                <div class="line">(hello, 1)</div>
                                <div class="line">(kafka, <strong>3</strong>)</div>
                                <div class="line">(streams, 1)</div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-even"><td>6</td>
                            <td>(streams, 1)</td>
                            <td>(streams, 1)</td>
                            <td>&nbsp;</td>
                            <td>(streams, 1 + 1)</td>
                            <td><div class="first last line-block">
                                <div class="line">(hello, 1)</div>
                                <div class="line">(kafka, 3)</div>
                                <div class="line">(streams, <strong>2</strong>)</div>
                            </div>
                            </td>
                        </tr>
                        </tbody>
                    </table>
                    <p><strong>Example of semantics for table aggregations:</strong>
                        A <code class="docutils literal"><span class="pre">KGroupedTable</span></code> &rarr; <code class="docutils literal"><span class="pre">KTable</span></code> example is shown below.  The tables are initially empty. Bold font is used in the column
                        for &#8220;KTable <code class="docutils literal"><span class="pre">aggregated</span></code>&#8221; to highlight changed state.  An entry such as <code class="docutils literal"><span class="pre">(hello,</span> <span class="pre">1)</span></code> denotes a record with key
                        <code class="docutils literal"><span class="pre">hello</span></code> and value <code class="docutils literal"><span class="pre">1</span></code>.  To improve the readability of the semantics table you can assume that all records are processed
                        in timestamp order.</p>
                    <pre class="line-numbers"><code class="language-java">// Key: username, value: user region (abbreviated to &quot;E&quot; for &quot;Europe&quot;, &quot;A&quot; for &quot;Asia&quot;)
KTable&lt;String, String&gt; userProfiles = ...;

// Re-group `userProfiles`.  Don&#39;t read too much into what the grouping does:
// its prime purpose in this example is to show the *effects* of the grouping
// in the subsequent aggregation.
KGroupedTable&lt;String, Integer&gt; groupedTable = userProfiles
    .groupBy((user, region) -&gt; KeyValue.pair(region, user.length()), Serdes.String(), Serdes.Integer());

KTable&lt;String, Integer&gt; aggregated = groupedTable.aggregate(
    () -&gt; 0, /* initializer */
    (aggKey, newValue, aggValue) -&gt; aggValue + newValue, /* adder */
    (aggKey, oldValue, aggValue) -&gt; aggValue - oldValue, /* subtractor */
    Materialized.&lt;String, Long, KeyValueStore&lt;Bytes, byte[]&gt;as(&quot;aggregated-table-store&quot; /* state store name */)
      .withKeySerde(Serdes.String()) /* key serde */
      .withValueSerde(Serdes.Integer()); /* serde for aggregate value */</code></pre>
                    <div class="admonition note">
                        <p><b>Note</b></p>
                        <p class="last"><strong>Impact of record caches</strong>:
                            For illustration purposes, the column &#8220;KTable <code class="docutils literal"><span class="pre">aggregated</span></code>&#8221; below shows the table&#8217;s state changes over time in a
                            very granular way.  In practice, you would observe state changes in such a granular way only when
                            <a class="reference internal" href="memory-mgmt.html#streams-developer-guide-memory-management-record-cache"><span class="std std-ref">record caches</span></a> are disabled (default: enabled).
                            When record caches are enabled, what might happen for example is that the output results of the rows with timestamps
                            4 and 5 would be <a class="reference internal" href="memory-mgmt.html#streams-developer-guide-memory-management-record-cache"><span class="std std-ref">compacted</span></a>, and there would only be
                            a single state update for the key <code class="docutils literal"><span class="pre">kafka</span></code> in the KTable (here: from <code class="docutils literal"><span class="pre">(kafka</span> <span class="pre">1)</span></code> directly to <code class="docutils literal"><span class="pre">(kafka,</span> <span class="pre">3)</span></code>.
                            Typically, you should only disable record caches for testing or debugging purposes &#8211; under normal circumstances it
                            is better to leave record caches enabled.</p>
                    </div>
                    <table border="1" class="docutils">
                        <thead valign="bottom">
                        <tr class="row-odd"><th class="head">&nbsp;</th>
                            <th class="head" colspan="3">KTable <code class="docutils literal"><span class="pre">userProfiles</span></code></th>
                            <th class="head" colspan="3">KGroupedTable <code class="docutils literal"><span class="pre">groupedTable</span></code></th>
                            <th class="head">KTable <code class="docutils literal"><span class="pre">aggregated</span></code></th>
                        </tr>
                        <tr class="row-even"><th class="head">Timestamp</th>
                            <th class="head">Input record</th>
                            <th class="head">Interpreted as</th>
                            <th class="head">Grouping</th>
                            <th class="head">Initializer</th>
                            <th class="head">Adder</th>
                            <th class="head">Subtractor</th>
                            <th class="head">State</th>
                        </tr>
                        </thead>
                        <tbody valign="top">
                        <tr class="row-odd"><td>1</td>
                            <td>(alice, E)</td>
                            <td>INSERT alice</td>
                            <td>(E, 5)</td>
                            <td>0 (for E)</td>
                            <td>(E, 0 + 5)</td>
                            <td>&nbsp;</td>
                            <td><div class="first last line-block">
                                <div class="line"><strong>(E, 5)</strong></div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-even"><td>2</td>
                            <td>(bob, A)</td>
                            <td>INSERT bob</td>
                            <td>(A, 3)</td>
                            <td>0 (for A)</td>
                            <td>(A, 0 + 3)</td>
                            <td>&nbsp;</td>
                            <td><div class="first last line-block">
                                <div class="line"><strong>(A, 3)</strong></div>
                                <div class="line">(E, 5)</div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-odd"><td>3</td>
                            <td>(charlie, A)</td>
                            <td>INSERT charlie</td>
                            <td>(A, 7)</td>
                            <td>&nbsp;</td>
                            <td>(A, 3 + 7)</td>
                            <td>&nbsp;</td>
                            <td><div class="first last line-block">
                                <div class="line">(A, <strong>10</strong>)</div>
                                <div class="line">(E, 5)</div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-even"><td>4</td>
                            <td>(alice, A)</td>
                            <td>UPDATE alice</td>
                            <td>(A, 5)</td>
                            <td>&nbsp;</td>
                            <td>(A, 10 + 5)</td>
                            <td>(E, 5 - 5)</td>
                            <td><div class="first last line-block">
                                <div class="line">(A, <strong>15</strong>)</div>
                                <div class="line">(E, <strong>0</strong>)</div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-odd"><td>5</td>
                            <td>(charlie, null)</td>
                            <td>DELETE charlie</td>
                            <td>(null, 7)</td>
                            <td>&nbsp;</td>
                            <td>&nbsp;</td>
                            <td>(A, 15 - 7)</td>
                            <td><div class="first last line-block">
                                <div class="line">(A, <strong>8</strong>)</div>
                                <div class="line">(E, 0)</div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-even"><td>6</td>
                            <td>(null, E)</td>
                            <td><em>ignored</em></td>
                            <td>&nbsp;</td>
                            <td>&nbsp;</td>
                            <td>&nbsp;</td>
                            <td>&nbsp;</td>
                            <td><div class="first last line-block">
                                <div class="line">(A, 8)</div>
                                <div class="line">(E, 0)</div>
                            </div>
                            </td>
                        </tr>
                        <tr class="row-odd"><td>7</td>
                            <td>(bob, E)</td>
                            <td>UPDATE bob</td>
                            <td>(E, 3)</td>
                            <td>&nbsp;</td>
                            <td>(E, 0 + 3)</td>
                            <td>(A, 8 - 3)</td>
                            <td><div class="first last line-block">
                                <div class="line">(A, <strong>5</strong>)</div>
                                <div class="line">(E, <strong>3</strong>)</div>
                            </div>
                            </td>
                        </tr>
                        </tbody>
                    </table>
                </div>
                <div class="section" id="joining">
                    <span id="streams-developer-guide-dsl-joins"></span><h4><a class="toc-backref" href="#id13">Joining</a><a class="headerlink" href="#joining" title="Permalink to this headline"></a></h4>
                    <p id="streams-developer-guide-dsl-joins-overview">Streams and tables can also be joined.  Many stream processing applications in practice are coded as streaming joins.
                        For example, applications backing an online shop might need to access multiple, updating database tables (e.g. sales
                        prices, inventory, customer information) in order to enrich a new data record (e.g. customer transaction) with context
                        information.  That is, scenarios where you need to perform table lookups at very large scale and with a low processing
                        latency.  Here, a popular pattern is to make the information in the databases available in Kafka through so-called
                        <em>change data capture</em> in combination with <a class="reference internal" href="../../#connect"><span class="std std-ref">Kafka&#8217;s Connect API</span></a>, and then implementing
                        applications that leverage the Streams API to perform very fast and efficient local joins
                        of such tables and streams, rather than requiring the application to make a query to a remote database over the network
                        for each record.  In this example, the KTable concept in Kafka Streams would enable you to track the latest state
                        (e.g.,  snapshot) of each table in a local state store, thus greatly reducing the processing latency as well as
                        reducing the load of the remote databases when doing such streaming joins.</p>
                    <p>The following join operations are supported, see also the diagram in the
                        <a class="reference internal" href="#streams-developer-guide-dsl-transformations-stateful-overview"><span class="std std-ref">overview section</span></a> of
                        <a class="reference internal" href="#streams-developer-guide-dsl-transformations-stateful"><span class="std std-ref">Stateful Transformations</span></a>.
                        Depending on the operands, joins are either <a class="reference internal" href="#streams-developer-guide-dsl-windowing"><span class="std std-ref">windowed</span></a> joins or
                        non-windowed joins.</p>
                    <table border="1" class="docutils">
                        <thead valign="bottom">
                        <tr class="row-odd"><th class="head">Join operands</th>
                            <th class="head">Type</th>
                            <th class="head">(INNER) JOIN</th>
                            <th class="head">LEFT JOIN</th>
                            <th class="head">OUTER JOIN</th>
                        </tr>
                        </thead>
                        <tbody valign="top">
                        <tr class="row-even"><td>KStream-to-KStream</td>
                            <td>Windowed</td>
                            <td>Supported</td>
                            <td>Supported</td>
                            <td>Supported</td>
                        </tr>
                        <tr class="row-odd"><td>KTable-to-KTable</td>
                            <td>Non-windowed</td>
                            <td>Supported</td>
                            <td>Supported</td>
                            <td>Supported</td>
                        </tr>
                        <tr class="row-even"><td>KTable-to-KTable Foreign-Key Join</td>
                            <td>Non-windowed</td>
                            <td>Supported</td>
                            <td>Supported</td>
                            <td>Not Supported</td>
                        </tr>
                        <tr class="row-odd"><td>KStream-to-KTable</td>
                            <td>Non-windowed</td>
                            <td>Supported</td>
                            <td>Supported</td>
                            <td>Not Supported</td>
                        </tr>
                        <tr class="row-even"><td>KStream-to-GlobalKTable</td>
                            <td>Non-windowed</td>
                            <td>Supported</td>
                            <td>Supported</td>
                            <td>Not Supported</td>
                        </tr>
                        <tr class="row-odd"><td>KTable-to-GlobalKTable</td>
                            <td>N/A</td>
                            <td>Not Supported</td>
                            <td>Not Supported</td>
                            <td>Not Supported</td>
                        </tr>
                        </tbody>
                    </table>
                    <p>Each case is explained in more detail in the subsequent sections.</p>
                    <div class="section" id="join-co-partitioning-requirements">
                        <span id="streams-developer-guide-dsl-joins-co-partitioning"></span><h5><a class="toc-backref" href="#id14">Join co-partitioning requirements</a><a class="headerlink" href="#join-co-partitioning-requirements" title="Permalink to this headline"></a></h5>
                        <p>For equi-joins, input data must be co-partitioned when joining. This ensures that input records with the same key from both sides of the
                            join, are delivered to the same stream task during processing.
                            <strong>It is your responsibility to ensure data co-partitioning when joining</strong>.
                            Co-partitioning is not required when performing <a class="reference internal" href="#ktable-ktable-fk-join"><span class="std std-ref">KTable-KTable Foreign-Key joins</span></a> and <a class="reference internal" href="#streams_concepts_globalktable"><span class="std std-ref">Global KTable joins</span></a>.
                            </p>
                        <p>The requirements for data co-partitioning are:</p>
                        <ul class="simple">
                            <li>The input topics of the join (left side and right side) must have the <strong>same number of partitions</strong>.</li>
                            <li>All applications that <em>write</em> to the input topics must have the <strong>same partitioning strategy</strong> so that records with
                                the same key are delivered to same partition number.  In other words, the keyspace of the input data must be
                                distributed across partitions in the same manner.
                                This means that, for example, applications that use Kafka&#8217;s <a class="reference internal" href="../../#producerapi"><span class="std std-ref">Java Producer API</span></a> must use the
                                same partitioner (cf. the producer setting <code class="docutils literal"><span class="pre">&quot;partitioner.class&quot;</span></code> aka <code class="docutils literal"><span class="pre">ProducerConfig.PARTITIONER_CLASS_CONFIG</span></code>),
                                and applications that use the Kafka&#8217;s Streams API must use the same <code class="docutils literal"><span class="pre">StreamPartitioner</span></code> for operations such as
                                <code class="docutils literal"><span class="pre">KStream#to()</span></code>.  The good news is that, if you happen to use the default partitioner-related settings across all
                                applications, you do not need to worry about the partitioning strategy.</li>
                        </ul>
                        <p>Why is data co-partitioning required?  Because
                            <a class="reference internal" href="#streams-developer-guide-dsl-joins-kstream-kstream"><span class="std std-ref">KStream-KStream</span></a>,
                            <a class="reference internal" href="#streams-developer-guide-dsl-joins-ktable-ktable"><span class="std std-ref">KTable-KTable</span></a>, and
                            <a class="reference internal" href="#streams-developer-guide-dsl-joins-kstream-ktable"><span class="std std-ref">KStream-KTable</span></a> joins
                            are performed based on the keys of records (e.g.,  <code class="docutils literal"><span class="pre">leftRecord.key</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>), it is required that the
                            input streams/tables of a join are co-partitioned by key.</p>
                        <p>There are two exceptions where co-partitioning is not required. For
                            <a class="reference internal" href="#streams-developer-guide-dsl-joins-kstream-globalktable"><span class="std std-ref">KStream-GlobalKTable joins</span></a> joins, co-partitioning is
                            not required because <em>all</em> partitions of the <code class="docutils literal"><span class="pre">GlobalKTable</span></code>&#8216;s underlying changelog stream are made available to
                             each <code class="docutils literal"><span class="pre">KafkaStreams</span></code> instance. That is, each instance has a full copy of the changelog stream.  Further, a
                            <code class="docutils literal"><span class="pre">KeyValueMapper</span></code> allows for non-key based joins from the <code class="docutils literal"><span class="pre">KStream</span></code> to the <code class="docutils literal"><span class="pre">GlobalKTable</span></code>.
                            <a class="reference internal" href="#ktable-ktable-fk-join"><span class="std std-ref">KTable-KTable Foreign-Key joins</span></a> also do not require co-partitioning. Kafka Streams internally ensures co-partitioning for Foreign-Key joins.
                            </p>

                        <div class="admonition note">
                            <p><b>Note</b></p>
                            <p class="last"><strong>Kafka Streams partly verifies the co-partitioning requirement:</strong>
                                During the partition assignment step, i.e. at runtime, Kafka Streams verifies whether the number of partitions for
                                both sides of a join are the same.  If they are not, a <code class="docutils literal"><span class="pre">TopologyBuilderException</span></code> (runtime exception) is being
                                thrown.  Note that Kafka Streams cannot verify whether the partitioning strategy matches between the input
                                streams/tables of a join &#8211; it is up to the user to ensure that this is the case.</p>
                        </div>
                        <p><strong>Ensuring data co-partitioning:</strong> If the inputs of a join are not co-partitioned yet, you must ensure this manually.
                            You may follow a procedure such as outlined below.
                            It is recommended to repartition the topic with fewer partitions to match the larger partition number of avoid bottlenecks.
                            Technically it would also be possible to repartition the topic with more partitions to the smaller partition number.
                            For stream-table joins, it's recommended to repartition the KStream because repartitioning a KTable might result in a second state store.
                            For table-table joins, you might also consider to size of the KTables and repartition the smaller KTable.</p>
                        <ol class="arabic">
                            <li><p class="first">Identify the input KStream/KTable in the join whose underlying Kafka topic has the smaller number of partitions.
                                Let&#8217;s call this stream/table &#8220;SMALLER&#8221;, and the other side of the join &#8220;LARGER&#8221;.  To learn about the number of
                                partitions of a Kafka topic you can use, for example, the CLI tool <code class="docutils literal"><span class="pre">bin/kafka-topics</span></code> with the <code class="docutils literal"><span class="pre">--describe</span></code>
                                option.</p>
                            </li>
                            <li><p class="first">Within your application, re-partition the data of &#8220;SMALLER&#8221;.  You must ensure that, when repartitioning
                                the data with <code class="docutils literal"><span class="pre">repartition</span></code>, the same partitioner is used as for &#8220;LARGER&#8221;.</p>
                                <blockquote>
                                    <div><ul class="simple">
                                        <li>If &#8220;SMALLER&#8221; is a KStream: <code class="docutils literal"><span class="pre">KStream#repartition(Repartitioned.numberOfPartitions(...))</span></code>.</li>
                                        <li>If &#8220;SMALLER&#8221; is a KTable: <code class="docutils literal"><span class="pre">KTable#toStream#repartition(Repartitioned.numberOfPartitions(...).toTable())</span></code>.</li>
                                    </ul>
                                    </div></blockquote>
                            </li>
                            <li><p class="first">Within your application, perform the join between &#8220;LARGER&#8221; and the new stream/table.</p>
                            </li>
                        </ol>
                    </div>
                    <div class="section" id="kstream-kstream-join">
                        <span id="streams-developer-guide-dsl-joins-kstream-kstream"></span><h5><a class="toc-backref" href="#id15">KStream-KStream Join</a><a class="headerlink" href="#kstream-kstream-join" title="Permalink to this headline"></a></h5>
                        <p>KStream-KStream joins are always <a class="reference internal" href="#windowing-sliding"><span class="std std-ref">windowed</span></a> joins, because otherwise the size of the
                            internal state store used to perform the join &#8211; e.g.,  a <a class="reference internal" href="#windowing-sliding"><span class="std std-ref">sliding window</span></a> or &#8220;buffer&#8221; &#8211; would
                            grow indefinitely.  For stream-stream joins it&#8217;s important to highlight that a new input record on one side will
                            produce a join output <em>for each</em> matching record on the other side, and there can be <em>multiple</em> such matching records
                            in a given join window (cf. the row with timestamp 15 in the join semantics table below, for example).</p>
                        <p>Join output records are effectively created as follows, leveraging the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code>:</p>
                        <pre class="line-numbers"><code class="language-java">KeyValue&lt;K, LV&gt; leftRecord = ...;
KeyValue&lt;K, RV&gt; rightRecord = ...;
ValueJoiner&lt;LV, RV, JV&gt; joiner = ...;

KeyValue&lt;K, JV&gt; joinOutputRecord = KeyValue.pair(
    leftRecord.key, /* by definition, leftRecord.key == rightRecord.key */
    joiner.apply(leftRecord.value, rightRecord.value)
  );</code></pre>
                        <table border="1" class="non-scrolling-table width-100-percent docutils">
                            <colgroup>
                                <col width="15%" />
                                <col width="85%" />
                            </colgroup>
                            <thead valign="bottom">
                            <tr class="row-odd"><th class="head">Transformation</th>
                                <th class="head">Description</th>
                            </tr>
                            </thead>
                            <tbody valign="top">
                            <tr class="row-even"><td><p class="first"><strong>Inner Join (windowed)</strong></p>
                                <ul class="last simple">
                                    <li>(KStream, KStream)
                                        &rarr; KStream</li>
                                </ul>
                            </td>
                                <td><p class="first">Performs an INNER JOIN of this stream with another stream.
                                    Even though this operation is windowed, the joined stream will be of type <code class="docutils literal"><span class="pre">KStream&lt;K,</span> <span class="pre">...&gt;</span></code> rather than <code class="docutils literal"><span class="pre">KStream&lt;Windowed&lt;K&gt;,</span> <span class="pre">...&gt;</span></code>.
                                    <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#join-org.apache.kafka.streams.kstream.KStream-org.apache.kafka.streams.kstream.ValueJoiner-org.apache.kafka.streams.kstream.JoinWindows-">(details)</a></p>
                                    <p><strong>Data must be co-partitioned</strong>: The input data for both sides must be <a class="reference internal" href="#streams-developer-guide-dsl-joins-co-partitioning"><span class="std std-ref">co-partitioned</span></a>.</p>
                                    <p><strong>Causes data re-partitioning of a stream if and only if the stream was marked for re-partitioning (if both are marked, both are re-partitioned).</strong></p>
                                    <p>Several variants of <code class="docutils literal"><span class="pre">join</span></code> exists, see the Javadocs for details.</p>
                                    <pre class="line-numbers"><code class="language-java">import java.time.Duration;
KStream&lt;String, Long&gt; left = ...;
KStream&lt;String, Double&gt; right = ...;

KStream&lt;String, String&gt; joined = left.join(right,
    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue, /* ValueJoiner */
    JoinWindows.ofTimeDifferenceWithNoGrace(Duration.ofMinutes(5)),
    Joined.with(
      Serdes.String(), /* key */
      Serdes.Long(),   /* left value */
      Serdes.Double())  /* right value */
  );
</code></pre>
                                    <p>Detailed behavior:</p>
                                    <ul>
                                        <li><p class="first">The join is <em>key-based</em>, i.e. with the join predicate <code class="docutils literal"><span class="pre">leftRecord.key</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>, and <em>window-based</em>, i.e. two input records are joined if and only if their
                                            timestamps are &#8220;close&#8221; to each other as defined by the user-supplied <code class="docutils literal"><span class="pre">JoinWindows</span></code>, i.e. the window defines an additional join predicate over the record timestamps.</p>
                                        </li>
                                        <li><p class="first">The join will be triggered under the conditions listed below whenever new input is received.  When it is triggered, the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called to produce
                                            join output records.</p>
                                            <blockquote>
                                                <div><ul class="simple">
                                                    <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> key or a <code class="docutils literal"><span class="pre">null</span></code> value are ignored and do not trigger the join.</li>
                                                </ul>
                                                </div></blockquote>
                                        </li>
                                    </ul>
                                    <p class="last">See the semantics overview at the bottom of this section for a detailed description.</p>
                                </td>
                            </tr>
                            <tr class="row-odd"><td><p class="first"><strong>Left Join (windowed)</strong></p>
                                <ul class="last simple">
                                    <li>(KStream, KStream)
                                        &rarr; KStream</li>
                                </ul>
                            </td>
                                <td><p class="first">Performs a LEFT JOIN of this stream with another stream.
                                    Even though this operation is windowed, the joined stream will be of type <code class="docutils literal"><span class="pre">KStream&lt;K,</span> <span class="pre">...&gt;</span></code> rather than <code class="docutils literal"><span class="pre">KStream&lt;Windowed&lt;K&gt;,</span> <span class="pre">...&gt;</span></code>.
                                    <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#leftJoin-org.apache.kafka.streams.kstream.KStream-org.apache.kafka.streams.kstream.ValueJoiner-org.apache.kafka.streams.kstream.JoinWindows-">(details)</a></p>
                                    <p><strong>Data must be co-partitioned</strong>: The input data for both sides must be <a class="reference internal" href="#streams-developer-guide-dsl-joins-co-partitioning"><span class="std std-ref">co-partitioned</span></a>.</p>
                                    <p><strong>Causes data re-partitioning of a stream if and only if the stream was marked for re-partitioning (if both are marked, both are re-partitioned).</strong></p>
                                    <p>Several variants of <code class="docutils literal"><span class="pre">leftJoin</span></code> exists, see the Javadocs for details.</p>
                                    <pre class="line-numbers"><code class="language-java">import java.time.Duration;
KStream&lt;String, Long&gt; left = ...;
KStream&lt;String, Double&gt; right = ...;

KStream&lt;String, String&gt; joined = left.leftJoin(right,
    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue, /* ValueJoiner */
    JoinWindows.ofTimeDifferenceWithNoGrace(Duration.ofMinutes(5)),
    Joined.with(
      Serdes.String(), /* key */
      Serdes.Long(),   /* left value */
      Serdes.Double())  /* right value */
  );
</code></pre>
                                    <p>Detailed behavior:</p>
                                    <ul>
                                        <li><p class="first">The join is <em>key-based</em>, i.e. with the join predicate <code class="docutils literal"><span class="pre">leftRecord.key</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>, and <em>window-based</em>, i.e. two input records are joined if and only if their
                                            timestamps are &#8220;close&#8221; to each other as defined by the user-supplied <code class="docutils literal"><span class="pre">JoinWindows</span></code>, i.e. the window defines an additional join predicate over the record timestamps.</p>
                                        </li>
                                        <li><p class="first">The join will be triggered under the conditions listed below whenever new input is received.  When it is triggered, the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called to produce
                                            join output records.</p>
                                            <blockquote>
                                                <div><ul class="simple">
                                                    <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> value are ignored and do not trigger the join.</li>
                                                </ul>
                                                </div></blockquote>
                                        </li>
                                        <li><p class="first">For each input record on the left side that does not have any match on the right side, the <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called with <code class="docutils literal"><span class="pre">ValueJoiner#apply(leftRecord.value,</span> <span class="pre">null)</span></code>;
                                            this explains the row with timestamp=60 and timestampe=80 in the table below, which lists <code class="docutils literal"><span class="pre">[E,</span> <span class="pre">null]</span></code> and <code class="docutils literal"><span class="pre">[F,</span> <span class="pre">null]</span></code>in the LEFT JOIN column.
                                            Note that these left results are emitted after the specified grace period passed. <strong>Caution:</strong> using the deprecated <code class="docutils literal"><span class="pre">JoinWindows.of(...).grace(...)</span></code> API might result in eagerly emitted spurious left results.</p>
                                        </li>
                                    </ul>
                                    <p class="last">See the semantics overview at the bottom of this section for a detailed description.</p>
                                </td>
                            </tr>
                            <tr class="row-even"><td><p class="first"><strong>Outer Join (windowed)</strong></p>
                                <ul class="last simple">
                                    <li>(KStream, KStream)
                                        &rarr; KStream</li>
                                </ul>
                            </td>
                                <td><p class="first">Performs an OUTER JOIN of this stream with another stream.
                                    Even though this operation is windowed, the joined stream will be of type <code class="docutils literal"><span class="pre">KStream&lt;K,</span> <span class="pre">...&gt;</span></code> rather than <code class="docutils literal"><span class="pre">KStream&lt;Windowed&lt;K&gt;,</span> <span class="pre">...&gt;</span></code>.
                                    <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#outerJoin-org.apache.kafka.streams.kstream.KStream-org.apache.kafka.streams.kstream.ValueJoiner-org.apache.kafka.streams.kstream.JoinWindows-">(details)</a></p>
                                    <p><strong>Data must be co-partitioned</strong>: The input data for both sides must be <a class="reference internal" href="#streams-developer-guide-dsl-joins-co-partitioning"><span class="std std-ref">co-partitioned</span></a>.</p>
                                    <p><strong>Causes data re-partitioning of a stream if and only if the stream was marked for re-partitioning (if both are marked, both are re-partitioned).</strong></p>
                                    <p>Several variants of <code class="docutils literal"><span class="pre">outerJoin</span></code> exists, see the Javadocs for details.</p>
                                    <pre class="line-numbers"><code class="language-java">import java.time.Duration;
KStream&lt;String, Long&gt; left = ...;
KStream&lt;String, Double&gt; right = ...;

KStream&lt;String, String&gt; joined = left.outerJoin(right,
    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue, /* ValueJoiner */
    JoinWindows.ofTimeDifferenceWithNoGrace(Duration.ofMinutes(5)),
    Joined.with(
      Serdes.String(), /* key */
      Serdes.Long(),   /* left value */
      Serdes.Double())  /* right value */
  );
</code></pre>
                                    <p>Detailed behavior:</p>
                                    <ul>
                                        <li><p class="first">The join is <em>key-based</em>, i.e. with the join predicate <code class="docutils literal"><span class="pre">leftRecord.key</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>, and <em>window-based</em>, i.e. two input records are joined if and only if their
                                            timestamps are &#8220;close&#8221; to each other as defined by the user-supplied <code class="docutils literal"><span class="pre">JoinWindows</span></code>, i.e. the window defines an additional join predicate over the record timestamps.</p>
                                        </li>
                                        <li><p class="first">The join will be triggered under the conditions listed below whenever new input is received.  When it is triggered, the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called to produce
                                            join output records.</p>
                                            <blockquote>
                                                <div><ul class="simple">
                                                    <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> value are ignored and do not trigger the join.</li>
                                                </ul>
                                                </div></blockquote>
                                        </li>
                                        <li><p class="first">For each input record on one side that does not have any match on the other side, the <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called with <code class="docutils literal"><span class="pre">ValueJoiner#apply(leftRecord.value,</span> <span class="pre">null)</span></code> or
                                            <code class="docutils literal"><span class="pre">ValueJoiner#apply(null,</span> <span class="pre">rightRecord.value)</span></code>, respectively; this explains the row with timestamp=60, timestamp=80, and timestamp=100 in the table below, which lists <code class="docutils literal"><span class="pre">[E,</span> <span class="pre">null]</span></code>,
                                            <code class="docutils literal"><span class="pre">[F,</span> <span class="pre">null]</span></code>, and <code class="docutils literal"><span class="pre">[null,</span> <span class="pre">f]</span></code> in the OUTER JOIN column.
                                            Note that these left and right results are emitted after the specified grace period passed. <strong>Caution:</strong> using the deprecated <code class="docutils literal"><span class="pre">JoinWindows.of(...).grace(...)</span></code> API might result in eagerly emitted spurious left/right results.</p>
                                        </li>
                                    </ul>
                                    <p class="last">See the semantics overview at the bottom of this section for a detailed description.</p>
                                </td>
                            </tr>
                            </tbody>
                        </table>
                        <p><strong>Semantics of stream-stream joins:</strong>
                            The semantics of the various stream-stream join variants are explained below.
                            To improve the readability of the table, assume that (1) all records have the same key (and thus the key in the table is omitted), and (2) all records are processed in timestamp order.
                            We assume a join window size of 15 seconds with a grace period of 5 seconds.</p>
                        <p><b>Note:</b> If you use the old and now deprecated API to specify the grace period, i.e., <code class="docutils literal"><span class="pre">JoinWindows.of(...).grace(...)</span></code>,
                            left/outer join results are emitted eagerly, and the observed result might differ from the result shown below.</p>
                        <p>The columns INNER JOIN, LEFT JOIN, and OUTER JOIN denote what is passed as arguments to the user-supplied
                            <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/ValueJoiner.html">ValueJoiner</a> for the <code class="docutils literal"><span class="pre">join</span></code>, <code class="docutils literal"><span class="pre">leftJoin</span></code>, and
                            <code class="docutils literal"><span class="pre">outerJoin</span></code> methods, respectively, whenever a new input record is received on either side of the join.  An empty table
                            cell denotes that the <code class="docutils literal"><span class="pre">ValueJoiner</span></code> is not called at all.</p>
                        <table border="1" class="docutils">
                            <thead valign="bottom">
                            <tr class="row-odd"><th class="head">Timestamp</th>
                                <th class="head">Left (KStream)</th>
                                <th class="head">Right (KStream)</th>
                                <th class="head">(INNER) JOIN</th>
                                <th class="head">LEFT JOIN</th>
                                <th class="head">OUTER JOIN</th>
                            </tr>
                            </thead>
                            <tbody valign="top">
                            <tr class="row-even"><td>1</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-odd"><td>2</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>3</td>
                                <td>A</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td> </td>
                                <td> </td>
                            </tr>
                            <tr class="row-odd"><td>4</td>
                                <td>&nbsp;</td>
                                <td>a</td>
                                <td>[A, a]</td>
                                <td>[A, a]</td>
                                <td>[A, a]</td>
                            </tr>
                            <tr class="row-even"><td>5</td>
                                <td>B</td>
                                <td>&nbsp;</td>
                                <td>[B, a]</td>
                                <td>[B, a]</td>
                                <td>[B, a]</td>
                            </tr>
                            <tr class="row-odd"><td>6</td>
                                <td>&nbsp;</td>
                                <td>b</td>
                                <td>[A, b], [B, b]</td>
                                <td>[A, b], [B, b]</td>
                                <td>[A, b], [B, b]</td>
                            </tr>
                            <tr class="row-even"><td>7</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-odd"><td>8</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>9</td>
                                <td>C</td>
                                <td>&nbsp;</td>
                                <td>[C, a], [C, b]</td>
                                <td>[C, a], [C, b]</td>
                                <td>[C, a], [C, b]</td>
                            </tr>
                            <tr class="row-odd"><td>10</td>
                                <td>&nbsp;</td>
                                <td>c</td>
                                <td>[A, c], [B, c], [C, c]</td>
                                <td>[A, c], [B, c], [C, c]</td>
                                <td>[A, c], [B, c], [C, c]</td>
                            </tr>
                            <tr class="row-even"><td>11</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-odd"><td>12</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>13</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-odd"><td>14</td>
                                <td>&nbsp;</td>
                                <td>d</td>
                                <td>[A, d], [B, d], [C, d]</td>
                                <td>[A, d], [B, d], [C, d]</td>
                                <td>[A, d], [B, d], [C, d]</td>
                            </tr>
                            <tr class="row-even"><td>15</td>
                                <td>D</td>
                                <td>&nbsp;</td>
                                <td>[D, a], [D, b], [D, c], [D, d]</td>
                                <td>[D, a], [D, b], [D, c], [D, d]</td>
                                <td>[D, a], [D, b], [D, c], [D, d]</td>
                            </tr>
                            <tr class="row-odd"><td> ... </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                            </tr>
                            <tr class="even-row"><td>40</td>
                                <td>E</td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                            </tr>
                            <tr class="row-odd"><td> ... </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                            </tr>
                            <tr class="even-row"><td>60</td>
                                <td>F</td>
                                <td> </td>
                                <td> </td>
                                <td>[E, null]</td>
                                <td>[E, null]</td>
                            </tr>
                            <tr class="row-odd"><td> ... </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                            </tr>
                            <tr class="even-row"><td>80</td>
                                <td> </td>
                                <td>f</td>
                                <td> </td>
                                <td>[F, null]</td>
                                <td>[F, null]</td>
                            </tr>
                            <tr class="row-odd"><td> ... </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                            </tr>
                            <tr class="even-row"><td>100</td>
                                <td>G</td>
                                <td> </td>
                                <td> </td>
                                <td> </td>
                                <td>[null, f]</td>
                            </tr>
                            </tbody>
                        </table>
                    </div>
                    <div class="section" id="ktable-ktable-equi-join">
                        <span id="streams-developer-guide-dsl-joins-ktable-ktable"></span><h5><a class="toc-backref" href="#id16">KTable-KTable Equi-Join</a><a class="headerlink" href="#ktable-ktable-equi-join" title="Permalink to this headline"></a></h5>
                        <p>KTable-KTable equi-joins are always <em>non-windowed</em> joins.  They are designed to be consistent with their counterparts in
                            relational databases.  The changelog streams of both KTables are materialized into local state stores to represent the
                            latest snapshot of their <a class="reference internal" href="#streams_concepts_ktable"><span class="std std-ref">table duals</span></a>.
                            The join result is a new KTable that represents the changelog stream of the join operation.</p>
                        <p>Join output records are effectively created as follows, leveraging the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code>:</p>
                        <pre class="line-numbers"><code class="language-java">KeyValue&lt;K, LV&gt; leftRecord = ...;
KeyValue&lt;K, RV&gt; rightRecord = ...;
ValueJoiner&lt;LV, RV, JV&gt; joiner = ...;

KeyValue&lt;K, JV&gt; joinOutputRecord = KeyValue.pair(
    leftRecord.key, /* by definition, leftRecord.key == rightRecord.key */
    joiner.apply(leftRecord.value, rightRecord.value)
  );</code></pre>
                        <table border="1" class="non-scrolling-table width-100-percent docutils">
                            <colgroup>
                                <col width="15%" />
                                <col width="85%" />
                            </colgroup>
                            <thead valign="bottom">
                            <tr class="row-odd"><th class="head">Transformation</th>
                                <th class="head">Description</th>
                            </tr>
                            </thead>
                            <tbody valign="top">
                            <tr class="row-even"><td><p class="first"><strong>Inner Join</strong></p>
                                <ul class="last simple">
                                    <li>(KTable, KTable)
                                        &rarr; KTable</li>
                                </ul>
                            </td>
                                <td><p class="first">Performs an INNER JOIN of this table with another table.
                                    The result is an ever-updating KTable that represents the &quot;current&quot; result of the join.
                                    <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KTable.html#join-org.apache.kafka.streams.kstream.KTable-org.apache.kafka.streams.kstream.ValueJoiner-">(details)</a></p>
                                    <p><strong>Data must be co-partitioned</strong>: The input data for both sides must be <a class="reference internal" href="#streams-developer-guide-dsl-joins-co-partitioning"><span class="std std-ref">co-partitioned</span></a>.</p>
                                    <pre class="line-numbers"><code class="language-java">KTable&lt;String, Long&gt; left = ...;
KTable&lt;String, Double&gt; right = ...;

KTable&lt;String, String&gt; joined = left.join(right,
    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue /* ValueJoiner */
  );
</code></pre>
                                    <p>Detailed behavior:</p>
                                    <ul>
                                        <li><p class="first">The join is <em>key-based</em>, i.e. with the join predicate <code class="docutils literal"><span class="pre">leftRecord.key</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>.</p>
                                        </li>
                                        <li><p class="first">The join will be triggered under the conditions listed below whenever new input is received.  When it is triggered, the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called to produce
                                            join output records.</p>
                                            <blockquote>
                                                <div><ul class="simple">
                                                    <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> key are ignored and do not trigger the join.</li>
                                                    <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the deletion of the key from the table.  Tombstones do not
                                                        trigger the join.  When an input tombstone is received, then an output tombstone is forwarded directly to the join result KTable if required (i.e. only if the corresponding
                                                        key actually exists already in the join result KTable).</li>
                                                    <li>When joining <a class="reference internal" href="#versioned-state-stores"><span class="std std-ref">versioned tables</span></a>,
                                                        out-of-order input records, i.e., those for which another record from the same table, with the same key and a larger timestamp,
                                                        has already been processed, are ignored and do not trigger the join.</li>
                                                </ul>
                                                </div></blockquote>
                                        </li>
                                    </ul>
                                    <p class="last">See the semantics overview at the bottom of this section for a detailed description.</p>
                                </td>
                            </tr>
                            <tr class="row-odd"><td><p class="first"><strong>Left Join</strong></p>
                                <ul class="last simple">
                                    <li>(KTable, KTable)
                                        &rarr; KTable</li>
                                </ul>
                            </td>
                                <td><p class="first">Performs a LEFT JOIN of this table with another table.
                                    <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KTable.html#leftJoin-org.apache.kafka.streams.kstream.KTable-org.apache.kafka.streams.kstream.ValueJoiner-">(details)</a></p>
                                    <p><strong>Data must be co-partitioned</strong>: The input data for both sides must be <a class="reference internal" href="#streams-developer-guide-dsl-joins-co-partitioning"><span class="std std-ref">co-partitioned</span></a>.</p>
                                    <pre class="line-numbers"><code class="language-java">KTable&lt;String, Long&gt; left = ...;
KTable&lt;String, Double&gt; right = ...;

KTable&lt;String, String&gt; joined = left.leftJoin(right,
    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue /* ValueJoiner */
  );
</code></pre>
                                    <p>Detailed behavior:</p>
                                    <ul>
                                        <li><p class="first">The join is <em>key-based</em>, i.e. with the join predicate <code class="docutils literal"><span class="pre">leftRecord.key</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>.</p>
                                        </li>
                                        <li><p class="first">The join will be triggered under the conditions listed below whenever new input is received.  When it is triggered, the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called to produce
                                            join output records.</p>
                                            <blockquote>
                                                <div><ul class="simple">
                                                    <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> key are ignored and do not trigger the join.</li>
                                                    <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the deletion of the key from the table.  Right-tombstones trigger the join,
                                                        but left-tombstones don't: when an input tombstone is received, an output tombstone is forwarded directly to the join result KTable if required (i.e. only if the corresponding
                                                        key actually exists already in the join result KTable).</li>
                                                    <li>When joining <a class="reference internal" href="#versioned-state-stores"><span class="std std-ref">versioned tables</span></a>,
                                                        out-of-order input records, i.e., those for which another record from the same table, with the same key and a larger timestamp,
                                                        has already been processed, are ignored and do not trigger the join.</li>
                                                </ul>
                                                </div></blockquote>
                                        </li>
                                        <li><p class="first">For each input record on the left side that does not have any match on the right side, the <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called with <code class="docutils literal"><span class="pre">ValueJoiner#apply(leftRecord.value,</span> <span class="pre">null)</span></code>;
                                            this explains the row with timestamp=3 in the table below, which lists <code class="docutils literal"><span class="pre">[A,</span> <span class="pre">null]</span></code> in the LEFT JOIN column.</p>
                                        </li>
                                    </ul>
                                    <p class="last">See the semantics overview at the bottom of this section for a detailed description.</p>
                                </td>
                            </tr>
                            <tr class="row-even"><td><p class="first"><strong>Outer Join</strong></p>
                                <ul class="last simple">
                                    <li>(KTable, KTable)
                                        &rarr; KTable</li>
                                </ul>
                            </td>
                                <td><p class="first">Performs an OUTER JOIN of this table with another table.
                                    <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KTable.html#outerJoin-org.apache.kafka.streams.kstream.KTable-org.apache.kafka.streams.kstream.ValueJoiner-">(details)</a></p>
                                    <p><strong>Data must be co-partitioned</strong>: The input data for both sides must be <a class="reference internal" href="#streams-developer-guide-dsl-joins-co-partitioning"><span class="std std-ref">co-partitioned</span></a>.</p>
                                    <pre class="line-numbers"><code class="language-java">KTable&lt;String, Long&gt; left = ...;
KTable&lt;String, Double&gt; right = ...;

KTable&lt;String, String&gt; joined = left.outerJoin(right,
    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue /* ValueJoiner */
  );
</code></pre>
                                    <p>Detailed behavior:</p>
                                    <ul>
                                        <li><p class="first">The join is <em>key-based</em>, i.e. with the join predicate <code class="docutils literal"><span class="pre">leftRecord.key</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>.</p>
                                        </li>
                                        <li><p class="first">The join will be triggered under the conditions listed below whenever new input is received.  When it is triggered, the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called to produce
                                            join output records.</p>
                                            <blockquote>
                                                <div><ul class="simple">
                                                    <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> key are ignored and do not trigger the join.</li>
                                                    <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the deletion of the key from the table. Tombstones may trigger joins,
                                                        depending on the content in the left and right tables. When an input tombstone is received, an output tombstone is forwarded directly to the join result KTable if required (i.e. only if the corresponding
                                                        key actually exists already in the join result KTable).</li>
                                                    <li>When joining <a class="reference internal" href="#versioned-state-stores"><span class="std std-ref">versioned tables</span></a>,
                                                        out-of-order input records, i.e., those for which another record from the same table, with the same key and a larger timestamp,
                                                        has already been processed, are ignored and do not trigger the join.</li>
                                                </ul>
                                                </div></blockquote>
                                        </li>
                                        <li><p class="first">For each input record on one side that does not have any match on the other side, the <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called with <code class="docutils literal"><span class="pre">ValueJoiner#apply(leftRecord.value,</span> <span class="pre">null)</span></code> or
                                            <code class="docutils literal"><span class="pre">ValueJoiner#apply(null,</span> <span class="pre">rightRecord.value)</span></code>, respectively; this explains the rows with timestamp=3 and timestamp=7 in the table below, which list <code class="docutils literal"><span class="pre">[A,</span> <span class="pre">null]</span></code> and
                                            <code class="docutils literal"><span class="pre">[null,</span> <span class="pre">b]</span></code>, respectively, in the OUTER JOIN column.</p>
                                        </li>
                                    </ul>
                                    <p class="last">See the semantics overview at the bottom of this section for a detailed description.</p>
                                </td>
                            </tr>
                            </tbody>
                        </table>
                        <p><strong>Semantics of table-table equi-joins:</strong>
                            The semantics of the various table-table equi-join variants are explained below.
                            To improve the readability of the table, you can assume that (1) all records have the same key (and thus the key in the table is omitted) and that (2) all records are processed in timestamp order.
                            The columns INNER JOIN, LEFT JOIN, and OUTER JOIN denote what is passed as arguments to the user-supplied
                            <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/ValueJoiner.html">ValueJoiner</a> for the <code class="docutils literal"><span class="pre">join</span></code>, <code class="docutils literal"><span class="pre">leftJoin</span></code>, and
                            <code class="docutils literal"><span class="pre">outerJoin</span></code> methods, respectively, whenever a new input record is received on either side of the join.  An empty table
                            cell denotes that the <code class="docutils literal"><span class="pre">ValueJoiner</span></code> is not called at all.</p>
                        <table border="1" class="docutils">
                            <colgroup>
                                <col width="8%" />
                                <col width="13%" />
                                <col width="13%" />
                                <col width="22%" />
                                <col width="22%" />
                                <col width="22%" />
                            </colgroup>
                            <thead valign="bottom">
                            <tr class="row-odd"><th class="head">Timestamp</th>
                                <th class="head">Left (KTable)</th>
                                <th class="head">Right (KTable)</th>
                                <th class="head">(INNER) JOIN</th>
                                <th class="head">LEFT JOIN</th>
                                <th class="head">OUTER JOIN</th>
                            </tr>
                            </thead>
                            <tbody valign="top">
                            <tr class="row-even"><td>1</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-odd"><td>2</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>3</td>
                                <td>A</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>[A, null]</td>
                                <td>[A, null]</td>
                            </tr>
                            <tr class="row-odd"><td>4</td>
                                <td>&nbsp;</td>
                                <td>a</td>
                                <td>[A, a]</td>
                                <td>[A, a]</td>
                                <td>[A, a]</td>
                            </tr>
                            <tr class="row-even"><td>5</td>
                                <td>B</td>
                                <td>&nbsp;</td>
                                <td>[B, a]</td>
                                <td>[B, a]</td>
                                <td>[B, a]</td>
                            </tr>
                            <tr class="row-odd"><td>6</td>
                                <td>&nbsp;</td>
                                <td>b</td>
                                <td>[B, b]</td>
                                <td>[B, b]</td>
                                <td>[B, b]</td>
                            </tr>
                            <tr class="row-even"><td>7</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>null</td>
                                <td>[null, b]</td>
                            </tr>
                            <tr class="row-odd"><td>8</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                            </tr>
                            <tr class="row-even"><td>9</td>
                                <td>C</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>[C, null]</td>
                                <td>[C, null]</td>
                            </tr>
                            <tr class="row-odd"><td>10</td>
                                <td>&nbsp;</td>
                                <td>c</td>
                                <td>[C, c]</td>
                                <td>[C, c]</td>
                                <td>[C, c]</td>
                            </tr>
                            <tr class="row-even"><td>11</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>null</td>
                                <td>[C, null]</td>
                                <td>[C, null]</td>
                            </tr>
                            <tr class="row-odd"><td>12</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>null</td>
                            </tr>
                            <tr class="row-even"><td>13</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-odd"><td>14</td>
                                <td>&nbsp;</td>
                                <td>d</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>[null, d]</td>
                            </tr>
                            <tr class="row-even"><td>15</td>
                                <td>D</td>
                                <td>&nbsp;</td>
                                <td>[D, d]</td>
                                <td>[D, d]</td>
                                <td>[D, d]</td>
                            </tr>
                            </tbody>
                        </table>
                    </div>
                    <div class="section" id="ktable-ktable-fk-join"> <span
                        id="streams-developer-guide-dsl-joins-ktable-ktable-fk"></span>
                      <h5><a class="toc-backref" href="#id34">KTable-KTable Foreign-Key
                          Join</a></h5>
                      <p>KTable-KTable foreign-key joins are always <em>non-windowed</em>
                        joins. Foreign-key joins are analogous to joins in SQL. As a rough example: 
                        <div><code class="docutils literal"><span class="pre">
                        SELECT ... FROM {this KTable} 
                        JOIN {other KTable} 
                        ON {other.key} = {result of foreignKeyExtractor(this.value)} ... 
                        </span></code></div>
                        The output of the operation is a new KTable containing the join result.
                        </p>
                        <p> The changelog streams of
                        both KTables are materialized into local state stores to
                        represent the latest snapshot of their <a class="reference
                          internal" href="#streams_concepts_ktable"><span class="std
                            std-ref">table duals</span></a>. A foreign-key extractor
                        function is applied to the left record, with a new intermediate
                        record created and is used to lookup and join with the corresponding 
                        primary key on the right hand side table.
                        The result is a new KTable that represents the changelog stream
                        of the join operation.</p>
                      The left KTable can have multiple records which map to the same
                      key on the right KTable. An update to a single left KTable entry
                      may result in a single output event, provided the corresponding
                      key exists in the right KTable. Consequently, a single update to a
                      right KTable entry will result in an update for each record in the
                      left KTable that has the same foreign key.<br>
                      <br>
                      <div class="highlight-java"> </div>
                      <table class="non-scrolling-table width-100-percent docutils"
                        border="1">
                        <colgroup> <col width="15%"> <col width="85%"> </colgroup> <thead
                          valign="bottom"> <tr class="row-odd">
                            <th class="head">Transformation</th>
                            <th class="head">Description</th>
                          </tr>
                        </thead> <tbody valign="top">
                          <tr class="row-even">
                            <td>
                              <p class="first"><strong>Inner Join</strong></p>
                              <ul class="last simple">
                                <li>(KTable, KTable) &rarr; KTable</li>
                              </ul>
                            </td>
                            <td>
                              <p class="first">Performs a foreign-key INNER JOIN of this
                                table with another table. The result is an ever-updating
                                KTable that represents the &quot;current&quot; result of the join.
                                <a class="reference external"
                href="/%7B%7Bversion%7D%7D/javadoc/org/apache/kafka/streams/kstream/KTable.html#join-org.apache.kafka.streams.kstream.KTable-org.apache.kafka.streams.kstream.ValueJoiner-">(details)</a></p>
                                <pre class="line-numbers"><code class="language-java">KTable&lt;String, Long&gt; left = ...;
                KTable&lt;Long, Double&gt; right = ...;
//This foreignKeyExtractor simply uses the left-value to map to the right-key.
Function&lt;Long, Long&gt; foreignKeyExtractor = (v) -&gt; v;
//Alternative: with access to left table key
BiFunction&lt;String, Long, Long&gt; foreignKeyExtractor = (k, v) -&gt; v;

                KTable&lt;String, String&gt; joined = left.join(right, foreignKeyExtractor,
                    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue /* ValueJoiner */
                  );</code></pre>
                              <p>Detailed behavior:</p>
                              <ul>
                                <li>
                                  <p class="first">The join is <em>key-based</em>, i.e.
                                    with the join predicate: </p>
                                    <pre class="line-numbers"><code class="language-java">foreignKeyExtractor.apply(leftRecord.value) == rightRecord.key</code></pre>
                                </li>
                                <li>
                                  <p class="first">The join will be triggered under the
                                    conditions listed below whenever new input is
                                    received. When it is triggered, the user-supplied <code
                                      class="docutils literal"><span class="pre">ValueJoiner</span></code>
                                    will be called to produce join output records.</p>
                                  <blockquote>
                                    <div>
                                      <ul class="simple">
                                        <li>
                                            Records for which the <code class="docutils literal"><span class="pre">foreignKeyExtractor</span></code> produces <code class="docutils literal"><span class="pre">null</span></code> are ignored and do not trigger a join.
                                            If you want to join with <code class="docutils literal"><span class="pre">null</span></code> foreign keys, use a suitable sentinel value to do so (i.e. <code class="docutils literal"><span class="pre">"NULL"</span></code> for a String field, or <code class="docutils literal"><span class="pre">-1</span></code> for an auto-incrementing integer field).
                                        </li>
                                        <li>Input records with a <code class="docutils
                                            literal"><span class="pre">null</span></code>
                                          value are interpreted as <em>tombstones</em>
                                          for the corresponding key, which indicate the
                                          deletion of the key from the table. Tombstones do not
                                          trigger the join.  When an input
                                          tombstone is received, then an output
                                          tombstone is forwarded directly to the join
                                          result KTable if required (i.e. only if the
                                          corresponding key actually exists already in
                                          the join result KTable).</li>
                                        <li>When joining <a class="reference internal" href="#versioned-state-stores"><span class="std std-ref">versioned tables</span></a>,
                                            out-of-order input records, i.e., those for which another record from the same table, with the same key and a larger timestamp,
                                            has already been processed, are ignored and do not trigger the join.</li>
                                      </ul>
                                    </div>
                                  </blockquote>
                                </li>
                              </ul>
                              <p class="last">See the semantics overview at the bottom
                                of this section for a detailed description.</p>
                            </td>
                          </tr>
                          <tr class="row-odd">
                            <td>
                              <p class="first"><strong>Left Join</strong></p>
                              <ul class="last simple">
                                <li>(KTable, KTable) &rarr; KTable</li>
                              </ul>
                            </td>
                            <td>
                              <p class="first">Performs a foreign-key LEFT JOIN of this
                                table with another table. <a class="reference external"
                href="/%7B%7Bversion%7D%7D/javadoc/org/apache/kafka/streams/kstream/KTable.html#leftJoin-org.apache.kafka.streams.kstream.KTable-org.apache.kafka.streams.kstream.ValueJoiner-">(details)</a></p>
                                <pre class="line-numbers"><code class="language-java">KTable&lt;String, Long&gt; left = ...;
                KTable&lt;Long, Double&gt; right = ...;
//This foreignKeyExtractor simply uses the left-value to map to the right-key.
Function&lt;Long, Long&gt; foreignKeyExtractor = (v) -&gt; v;
//Alternative: with access to left table key
BiFunction&lt;String, Long, Long&gt; foreignKeyExtractor = (k, v) -&gt; v;

                KTable&lt;String, String&gt; joined = left.leftJoin(right, foreignKeyExtractor,
                    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue /* ValueJoiner */
                  );</code></pre>
                              <p>Detailed behavior:</p>
                              <ul>
                                <li>
                                  <p class="first">The join is <em>key-based</em>, i.e.
                                    with the join predicate: </p>
                                    <pre class="line-numbers"><code class="language-java">foreignKeyExtractor.apply(leftRecord.value) == rightRecord.key</code></pre>
                                </li>
                                <li>
                                  <p class="first">The join will be triggered under the
                                    conditions listed below whenever new input is
                                    received. When it is triggered, the user-supplied <code
                                      class="docutils literal"><span class="pre">ValueJoiner</span></code>
                                    will be called to produce join output records.</p>
                                  <blockquote>
                                    <div>
                                      <ul class="simple">
                                        <li>Input records with a <code class="docutils
                                            literal"><span class="pre">null</span></code>
                                          value are interpreted as <em>tombstones</em>
                                          for the corresponding key, which indicate the
                                          deletion of the key from the table. Right-tombstones
                                          trigger the join, but left-tombstones don't:
                                          when an input tombstone is received, then an output
                                          tombstone is forwarded directly to the join
                                          result KTable if required (i.e. only if the
                                          corresponding key actually exists already in
                                          the join result KTable).</li>
                                        <li>When joining <a class="reference internal" href="#versioned-state-stores"><span class="std std-ref">versioned tables</span></a>,
                                            out-of-order input records, i.e., those for which another record from the same table, with the same key and a larger timestamp,
                                            has already been processed, are ignored and do not trigger the join.</li>
                                      </ul>
                                    </div>
                                  </blockquote>
                                </li>
                                <li>
                                  <p class="first">For each input record on the left
                                    side that does not have any match on the right side,
                                    the <code class="docutils literal"><span
                                        class="pre">ValueJoiner</span></code> will be
                                    called with <code class="docutils literal"><span
                                        class="pre">ValueJoiner#apply(leftRecord.value,</span>
                                      <span class="pre">null)</span></code>; this
                                    explains the row with timestamp=7 &amp; 8 in the
                                    table below, which lists <code class="docutils
                                      literal"><span class="pre">(q,10,null) and (r,10,null)</span></code>
                                    in the LEFT JOIN column.</p>
                                </li>
                              </ul>
                              <p class="last">See the semantics overview at the bottom
                                of this section for a detailed description.</p>
                            </td>
                          </tr>
                        </tbody>
                      </table>
                      <p><strong>Semantics of table-table foreign-key joins:</strong>
                        The semantics of the table-table foreign-key INNER and LEFT JOIN
                        variants are demonstrated below.
                        The key is shown alongside the value for each record.
                        Records are processed in incrementing offset order.
                        The columns INNER JOIN and LEFT JOIN denote what is
                        passed as arguments to the user-supplied <a class="reference
                          external"
                href="/%7B%7Bversion%7D%7D/javadoc/org/apache/kafka/streams/kstream/ValueJoiner.html">ValueJoiner</a>
                        for the <code class="docutils literal"><span class="pre">join</span></code>
                        and <code class="docutils literal"><span class="pre">leftJoin</span></code>
                        methods, respectively, whenever a new input record is received
                        on either side of the join. An empty table cell denotes that the
                        <code class="docutils literal"><span class="pre">ValueJoiner</span></code>
                        is not called at all. For the purpose of this example, <code
                          class="docutils literal"><span class="pre">Function
                            foreignKeyExtractor</span></code> simply uses the left-value
                        as the output. </p>
                      <table class="docutils" border="1">
                        <colgroup> <col width="12%"> <col width="13%"> <col
                            width="13%"> <col width="31%"> <col width="31%"> </colgroup>
                        <thead valign="bottom"> <tr class="row-odd">
                            <th class="head">Record Offset</th>
                            <th class="head">Left KTable (K, extracted-FK)</th>
                            <th class="head">Right KTable (FK, VR)</th>
                            <th class="head">(INNER) JOIN</th>
                            <th class="head">LEFT JOIN</th>
                          </tr>
                        </thead> <tbody valign="top">
                          <tr class="row-even">
                            <td>1</td>
                            <td>(k,1)</td>
                            <td>&nbsp;(1,foo)</td>
                            <td>
                              <meta http-equiv="content-type" content="text/html;
                                charset=UTF-8">
                              (k,1,foo) <br>
                            </td>
                            <td>
                              <meta http-equiv="content-type" content="text/html;
                                charset=UTF-8">
                              (k,1,foo)</td>
                          </tr>
                          <tr class="row-odd">
                            <td>2</td>
                            <td>(k,2)
                              <meta http-equiv="content-type" content="text/html;
                                charset=UTF-8">
                            </td>
                            <td>
                              <meta http-equiv="content-type" content="text/html;
                                charset=UTF-8">
                              <br>
                            </td>
                            <td>(k,null)</td>
                            <td>(k,2,null) <br>
                            </td>
                          </tr>
                          <tr class="row-even">
                            <td>3</td>
                            <td>(k,3)<br>
                            </td>
                            <td>&nbsp;</td>
                            <td>(k,null)</td>
                            <td>(k,3,null)<br>
                            </td>
                          </tr>
                          <tr class="row-odd">
                            <td>4</td>
                            <td>&nbsp;</td>
                            <td>(3,bar)<br>
                            </td>
                            <td>(k,3,bar)<br>
                            </td>
                            <td>(k,3,bar)<br>
                            </td>
                          </tr>
                          <tr class="row-even">
                            <td>5</td>
                            <td>(k,null)<br>
                            </td>
                            <td>&nbsp;</td>
                            <td>(k,null)<br>
                            </td>
                            <td>(k,null,null)
                              <meta http-equiv="content-type" content="text/html;
                                charset=UTF-8">
                            </td>
                          </tr>
                          <tr class="row-odd">
                            <td>6</td>
                            <td>(k,1)</td>
                            <td><br>
                            </td>
                            <td>(k,1,foo)<br>
                            </td>
                            <td>(k,1,foo)<br>
                            </td>
                          </tr>
                          <tr class="row-even">
                            <td>7</td>
                            <td>(q,10)<br>
                            </td>
                            <td>&nbsp;</td>
                            <td><br>
                            </td>
                            <td>(q,10,null) </td>
                          </tr>
                          <tr class="row-odd">
                            <td>8</td>
                            <td>(r,10)</td>
                            <td><br>
                            </td>
                            <td>&nbsp;</td>
                            <td>(r,10,null)</td>
                          </tr>
                          <tr class="row-even">
                            <td>9</td>
                            <td><br>
                            </td>
                            <td>(10,baz)</td>
                            <td>(q,10,baz), (r,10,baz)</td>
                            <td>(q,10,baz), (r,10,baz)</td>
                          </tr>
                        </tbody>
                      </table>
                    </div>
                    <div class="section" id="kstream-ktable-join">
                        <span id="streams-developer-guide-dsl-joins-kstream-ktable"></span><h5><a class="toc-backref" href="#id17">KStream-KTable Join</a><a class="headerlink" href="#kstream-ktable-join" title="Permalink to this headline"></a></h5>
                        <p>KStream-KTable joins are always <em>non-windowed</em> joins.  They allow you to perform <em>table lookups</em> against a KTable
                            (changelog stream) upon receiving a new record from the KStream (record stream).  An example use case would be to enrich
                            a stream of user activities (KStream) with the latest user profile information (KTable).</p>
                        <p>Join output records are effectively created as follows, leveraging the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code>:</p>
                        <pre class="line-numbers"><code class="language-java">KeyValue&lt;K, LV&gt; leftRecord = ...;
KeyValue&lt;K, RV&gt; rightRecord = ...;
ValueJoiner&lt;LV, RV, JV&gt; joiner = ...;

KeyValue&lt;K, JV&gt; joinOutputRecord = KeyValue.pair(
    leftRecord.key, /* by definition, leftRecord.key == rightRecord.key */
    joiner.apply(leftRecord.value, rightRecord.value)
  );</code></pre>
                        <table border="1" class="non-scrolling-table width-100-percent docutils">
                            <colgroup>
                                <col width="15%" />
                                <col width="85%" />
                            </colgroup>
                            <thead valign="bottom">
                            <tr class="row-odd"><th class="head">Transformation</th>
                                <th class="head">Description</th>
                            </tr>
                            </thead>
                            <tbody valign="top">
                            <tr class="row-even"><td><p class="first"><strong>Inner Join</strong></p>
                                <ul class="last simple">
                                    <li>(KStream, KTable)
                                        &rarr; KStream</li>
                                </ul>
                            </td>
                                <td><p class="first">Performs an INNER JOIN of this stream with the table, effectively doing a table lookup.
                                    <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#join-org.apache.kafka.streams.kstream.KTable-org.apache.kafka.streams.kstream.ValueJoiner-">(details)</a></p>
                                    <p><strong>Data must be co-partitioned</strong>: The input data for both sides must be <a class="reference internal" href="#streams-developer-guide-dsl-joins-co-partitioning"><span class="std std-ref">co-partitioned</span></a>.</p>
                                    <p><strong>Causes data re-partitioning of the stream if and only if the stream was marked for re-partitioning.</strong></p>
                                    <p>Several variants of <code class="docutils literal"><span class="pre">join</span></code> exists, see the Javadocs for details.</p>
                                    <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; left = ...;
KTable&lt;String, Double&gt; right = ...;

KStream&lt;String, String&gt; joined = left.join(right,
    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue, /* ValueJoiner */
    Joined.keySerde(Serdes.String()) /* key */
      .withValueSerde(Serdes.Long()) /* left value */
      .withGracePeriod(Duration.ZERO) /* grace period */
  );
</code></pre>
                                    <p>Detailed behavior:</p>
                                    <ul>
                                        <li><p class="first">The join is <em>key-based</em>, i.e. with the join predicate <code class="docutils literal"><span class="pre">leftRecord.key</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>.</p>
                                        </li>
                                        <li><p class="first">The join will be triggered under the conditions listed below whenever new input is received.  When it is triggered, the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called to produce
                                            join output records.</p>
                                            <blockquote>
                                                <div><ul class="simple">
                                                    <li>Only input records for the left side (stream) trigger the join.  Input records for the right side (table) update only the internal right-side join state.</li>
                                                    <li>Input records for the stream with a <code class="docutils literal"><span class="pre">null</span></code> key or a <code class="docutils literal"><span class="pre">null</span></code> value are ignored and do not trigger the join.</li>
                                                    <li>Input records for the table with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the deletion of the key from the table.
                                                        Tombstones do not trigger the join.</li>
                                                </ul>
                                                </div></blockquote>
                                        </li>
                                        <li>When the table is <a class="reference internal" href="#versioned-state-stores"><span class="std std-ref">versioned</span></a>,
                                            the table record to join with is determined by performing a timestamped lookup, i.e., the table record which is joined will be the latest-by-timestamp record with timestamp
                                            less than or equal to the stream record timestamp. If the stream record timestamp is older than the table's history retention, then the record is dropped.</li>
                                        <li>To use the grace period, the table needs to be <a class="reference internal" href="#versioned-state-stores"><span class="std std-ref">versioned</span></a>.
                                            This will cause the stream to buffer for the specified grace period before trying to find a matching record with the right timestamp in the table.
                                            The case where the grace period would be used for is if a record in the table has a timestamp less than or equal to the stream record timestamp but arrives after the stream record.
                                            If the table record arrives within the grace period the join will still occur.
                                            If the table record does not arrive before the grace period the join will continue as normal.
                                        </li>
                                    </ul>
                                    <p class="last">See the semantics overview at the bottom of this section for a detailed description.</p>
                                </td>
                            </tr>
                            <tr class="row-odd"><td><p class="first"><strong>Left Join</strong></p>
                                <ul class="last simple">
                                    <li>(KStream, KTable)
                                        &rarr; KStream</li>
                                </ul>
                            </td>
                                <td><p class="first">Performs a LEFT JOIN of this stream with the table, effectively doing a table lookup.
                                    <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#leftJoin-org.apache.kafka.streams.kstream.KTable-org.apache.kafka.streams.kstream.ValueJoiner-">(details)</a></p>
                                    <p><strong>Data must be co-partitioned</strong>: The input data for both sides must be <a class="reference internal" href="#streams-developer-guide-dsl-joins-co-partitioning"><span class="std std-ref">co-partitioned</span></a>.</p>
                                    <p><strong>Causes data re-partitioning of the stream if and only if the stream was marked for re-partitioning.</strong></p>
                                    <p>Several variants of <code class="docutils literal"><span class="pre">leftJoin</span></code> exists, see the Javadocs for details.</p>
                                    <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; left = ...;
KTable&lt;String, Double&gt; right = ...;

KStream&lt;String, String&gt; joined = left.leftJoin(right,
    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue, /* ValueJoiner */
    Joined.keySerde(Serdes.String()) /* key */
      .withValueSerde(Serdes.Long()) /* left value */
      .withGracePeriod(Duration.ZERO) /* grace period */
  );
</code></pre>
                                    <p>Detailed behavior:</p>
                                    <ul>
                                        <li><p class="first">The join is <em>key-based</em>, i.e. with the join predicate <code class="docutils literal"><span class="pre">leftRecord.key</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>.</p>
                                        </li>
                                        <li><p class="first">The join will be triggered under the conditions listed below whenever new input is received.  When it is triggered, the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called to produce
                                            join output records.</p>
                                            <blockquote>
                                                <div><ul class="simple">
                                                    <li>Only input records for the left side (stream) trigger the join.  Input records for the right side (table) update only the internal right-side join state.</li>
                                                    <li>Input records for the stream with a <code class="docutils literal"><span class="pre">null</span></code> value are ignored and do not trigger the join.</li>
                                                    <li>Input records for the table with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the deletion of the key from the table.
                                                        Tombstones do not trigger the join.</li>
                                                </ul>
                                                </div></blockquote>
                                        </li>
                                        <li><p class="first">For each input record on the left side that does not have any match on the right side, the <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called with <code class="docutils literal"><span class="pre">ValueJoiner#apply(leftRecord.value,</span> <span class="pre">null)</span></code>;
                                            this explains the row with timestamp=3 in the table below, which lists <code class="docutils literal"><span class="pre">[A,</span> <span class="pre">null]</span></code> in the LEFT JOIN column.</p>
                                        </li>
                                        <li>When the table is <a class="reference internal" href="#versioned-state-stores"><span class="std std-ref">versioned</span></a>,
                                            the table record to join with is determined by performing a timestamped lookup, i.e., the table record which is joined will be the latest-by-timestamp record with timestamp
                                            less than or equal to the stream record timestamp. If the stream record timestamp is older than the table's history retention, then the record that is joined will be <code class="docutils literal"><span class="pre">null</span></code>.</li>
                                        <li>To use the grace period, the table needs to be <a class="reference internal" href="#versioned-state-stores"><span class="std std-ref">versioned</span></a>.
                                            This will cause the stream to buffer for the specified grace period before trying to find a matching record with the right timestamp in the table.
                                            The case where the grace period would be used for is if a record in the table has a timestamp less than or equal to the stream record timestamp but arrives after the stream record.
                                            If the table record arrives within the grace period the join will still occur.
                                            If the table record does not arrive before the grace period the join will continue as normal.
                                        </li>
                                    </ul>
                                    <p class="last">See the semantics overview at the bottom of this section for a detailed description.</p>
                                </td>
                            </tr>
                            </tbody>
                        </table>
                        <p><strong>Semantics of stream-table joins:</strong>
                            The semantics of the various stream-table join variants are explained below.
                            To improve the readability of the table we assume that (1) all records have the same key (and thus we omit the key in
                            the table) and that (2) all records are processed in timestamp order.
                            The columns INNER JOIN and LEFT JOIN denote what is passed as arguments to the user-supplied
                            <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/ValueJoiner.html">ValueJoiner</a> for the <code class="docutils literal"><span class="pre">join</span></code> and <code class="docutils literal"><span class="pre">leftJoin</span></code>
                            methods, respectively, whenever a new input record is received on either side of the join.  An empty table
                            cell denotes that the <code class="docutils literal"><span class="pre">ValueJoiner</span></code> is not called at all.</p>
                        <table border="1" class="docutils">
                            <colgroup>
                                <col>
                                <col>
                                <col>
                                <col>
                                <col>
                            </colgroup>
                            <thead valign="bottom">
                            <tr class="row-odd"><th class="head">Timestamp</th>
                                <th class="head">Left (KStream)</th>
                                <th class="head">Right (KTable)</th>
                                <th class="head">(INNER) JOIN</th>
                                <th class="head">LEFT JOIN</th>
                            </tr>
                            </thead>
                            <tbody valign="top">
                            <tr class="row-even"><td>1</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-odd"><td>2</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>3</td>
                                <td>A</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>[A, null]</td>
                            </tr>
                            <tr class="row-odd"><td>4</td>
                                <td>&nbsp;</td>
                                <td>a</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>5</td>
                                <td>B</td>
                                <td>&nbsp;</td>
                                <td>[B, a]</td>
                                <td>[B, a]</td>
                            </tr>
                            <tr class="row-odd"><td>6</td>
                                <td>&nbsp;</td>
                                <td>b</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>7</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-odd"><td>8</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>9</td>
                                <td>C</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>[C, null]</td>
                            </tr>
                            <tr class="row-odd"><td>10</td>
                                <td>&nbsp;</td>
                                <td>c</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>11</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-odd"><td>12</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>13</td>
                                <td>&nbsp;</td>
                                <td>null</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-odd"><td>14</td>
                                <td>&nbsp;</td>
                                <td>d</td>
                                <td>&nbsp;</td>
                                <td>&nbsp;</td>
                            </tr>
                            <tr class="row-even"><td>15</td>
                                <td>D</td>
                                <td>&nbsp;</td>
                                <td>[D, d]</td>
                                <td>[D, d]</td>
                            </tr>
                            </tbody>
                        </table>
                    </div>
                    <div class="section" id="kstream-globalktable-join">
                        <span id="streams-developer-guide-dsl-joins-kstream-globalktable"></span><h5><a class="toc-backref" href="#id18">KStream-GlobalKTable Join</a><a class="headerlink" href="#kstream-globalktable-join" title="Permalink to this headline"></a></h5>
                        <p>KStream-GlobalKTable joins are always <em>non-windowed</em> joins.  They allow you to perform <em>table lookups</em> against a
                            <a class="reference internal" href="#streams_concepts_globalktable"><span class="std std-ref">GlobalKTable</span></a> (entire changelog stream) upon receiving a new record from the
                            KStream (record stream).  An example use case would be &#8220;star queries&#8221; or &#8220;star joins&#8221;, where you would enrich a stream
                            of user activities (KStream) with the latest user profile information (GlobalKTable) and further context information
                            (further GlobalKTables). However, because GlobalKTables have no notion of time, a KStream-GlobalKTable join is not a temporal join, and there is no event-time synchronization between updates to a GlobalKTable and processing of KStream records.</p>
                        <p>At a high-level, KStream-GlobalKTable joins are very similar to
                            <a class="reference internal" href="#streams-developer-guide-dsl-joins-kstream-ktable"><span class="std std-ref">KStream-KTable joins</span></a>.  However, global tables provide you
                            with much more flexibility at the <a class="reference internal" href="#streams_concepts_globalktable"><span class="std std-ref">some expense</span></a> when compared to partitioned
                            tables:</p>
                        <ul class="simple">
                            <li>They do not require <a class="reference internal" href="#streams-developer-guide-dsl-joins-co-partitioning"><span class="std std-ref">data co-partitioning</span></a>.</li>
                            <li>They allow for efficient &#8220;star joins&#8221;; i.e., joining a large-scale &#8220;facts&#8221; stream against &#8220;dimension&#8221; tables</li>
                            <li>They allow for joining against foreign keys; i.e., you can lookup data in the table not just by the keys of records in the
                                stream, but also by data in the record values.</li>
                            <li>They make many use cases feasible where you must work on heavily skewed data and thus suffer from hot partitions.</li>
                            <li>They are often more efficient than their partitioned KTable counterpart when you need to perform multiple joins in
                                succession.</li>
                        </ul>
                        <p>Join output records are effectively created as follows, leveraging the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code>:</p>
                        <pre class="line-numbers"><code class="language-java">KeyValue&lt;K, LV&gt; leftRecord = ...;
KeyValue&lt;K, RV&gt; rightRecord = ...;
ValueJoiner&lt;LV, RV, JV&gt; joiner = ...;

KeyValue&lt;K, JV&gt; joinOutputRecord = KeyValue.pair(
    leftRecord.key, /* by definition, leftRecord.key == rightRecord.key */
    joiner.apply(leftRecord.value, rightRecord.value)
  );</code></pre>
                        <table border="1" class="non-scrolling-table width-100-percent docutils">
                            <colgroup>
                                <col width="15%" />
                                <col width="85%" />
                            </colgroup>
                            <thead valign="bottom">
                            <tr class="row-odd"><th class="head">Transformation</th>
                                <th class="head">Description</th>
                            </tr>
                            </thead>
                            <tbody valign="top">
                            <tr class="row-even"><td><p class="first"><strong>Inner Join</strong></p>
                                <ul class="last simple">
                                    <li>(KStream, GlobalKTable)
                                        &rarr; KStream</li>
                                </ul>
                            </td>
                                <td><p class="first">Performs an INNER JOIN of this stream with the global table, effectively doing a table lookup.
                                    <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#join-org.apache.kafka.streams.kstream.GlobalKTable-org.apache.kafka.streams.kstream.KeyValueMapper-org.apache.kafka.streams.kstream.ValueJoiner-">(details)</a></p>
                                    <p>The <code class="docutils literal"><span class="pre">GlobalKTable</span></code> is fully bootstrapped upon (re)start of a <code class="docutils literal"><span class="pre">KafkaStreams</span></code> instance, which means the table is fully populated with all the data in the underlying topic that is
                                        available at the time of the startup.  The actual data processing begins only once the bootstrapping has completed.</p>
                                    <p><strong>Causes data re-partitioning of the stream if and only if the stream was marked for re-partitioning.</strong></p>
                                    <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; left = ...;
GlobalKTable&lt;Integer, Double&gt; right = ...;

KStream&lt;String, String&gt; joined = left.join(right,
    (leftKey, leftValue) -&gt; leftKey.length(), /* derive a (potentially) new key by which to lookup against the table */
    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue /* ValueJoiner */
  );
</code></pre>
                                    <p>Detailed behavior:</p>
                                    <ul class="last">
                                        <li><p class="first">The join is indirectly <em>key-based</em>, i.e. with the join predicate <code class="docutils literal"><span class="pre">KeyValueMapper#apply(leftRecord.key,</span> <span class="pre">leftRecord.value)</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>.</p>
                                        </li>
                                        <li><p class="first">The join will be triggered under the conditions listed below whenever new input is received.  When it is triggered, the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called to produce
                                            join output records.</p>
                                            <blockquote>
                                                <div><ul class="simple">
                                                    <li>Only input records for the left side (stream) trigger the join.  Input records for the right side (table) update only the internal right-side join state.</li>
                                                    <li>Input records for the stream with a <code class="docutils literal"><span class="pre">null</span></code> key or a <code class="docutils literal"><span class="pre">null</span></code> value are ignored and do not trigger the join.</li>
                                                    <li>Input records for the table with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em>, which indicate the deletion of a record key from the table.  Tombstones do not trigger the
                                                        join.</li>
                                                </ul>
                                                </div></blockquote>
                                        </li>
                                    </ul>
                                </td>
                            </tr>
                            <tr class="row-odd"><td><p class="first"><strong>Left Join</strong></p>
                                <ul class="last simple">
                                    <li>(KStream, GlobalKTable)
                                        &rarr; KStream</li>
                                </ul>
                            </td>
                                <td><p class="first">Performs a LEFT JOIN of this stream with the global table, effectively doing a table lookup.
                                    <a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#leftJoin-org.apache.kafka.streams.kstream.GlobalKTable-org.apache.kafka.streams.kstream.KeyValueMapper-org.apache.kafka.streams.kstream.ValueJoiner-">(details)</a></p>
                                    <p>The <code class="docutils literal"><span class="pre">GlobalKTable</span></code> is fully bootstrapped upon (re)start of a <code class="docutils literal"><span class="pre">KafkaStreams</span></code> instance, which means the table is fully populated with all the data in the underlying topic that is
                                        available at the time of the startup.  The actual data processing begins only once the bootstrapping has completed.</p>
                                    <p><strong>Causes data re-partitioning of the stream if and only if the stream was marked for re-partitioning.</strong></p>
                                    <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; left = ...;
GlobalKTable&lt;Integer, Double&gt; right = ...;

KStream&lt;String, String&gt; joined = left.leftJoin(right,
    (leftKey, leftValue) -&gt; leftKey.length(), /* derive a (potentially) new key by which to lookup against the table */
    (leftValue, rightValue) -&gt; &quot;left=&quot; + leftValue + &quot;, right=&quot; + rightValue /* ValueJoiner */
  );
</code></pre>
                                    <p>Detailed behavior:</p>
                                    <ul class="last">
                                        <li><p class="first">The join is indirectly <em>key-based</em>, i.e. with the join predicate <code class="docutils literal"><span class="pre">KeyValueMapper#apply(leftRecord.key,</span> <span class="pre">leftRecord.value)</span> <span class="pre">==</span> <span class="pre">rightRecord.key</span></code>.</p>
                                        </li>
                                        <li><p class="first">The join will be triggered under the conditions listed below whenever new input is received.  When it is triggered, the user-supplied <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called to produce
                                            join output records.</p>
                                            <blockquote>
                                                <div><ul class="simple">
                                                    <li>Only input records for the left side (stream) trigger the join.  Input records for the right side (table) update only the internal right-side join state.</li>
                                                    <li>Input records for the stream with a <code class="docutils literal"><span class="pre">null</span></code> value are ignored and do not trigger the join.</li>
                                                    <li>Input records for the table with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em>, which indicate the deletion of a record key from the table.  Tombstones do not trigger the
                                                        join.</li>
                                                </ul>
                                                </div></blockquote>
                                        </li>
                                        <li><p class="first">For each input record on the left side that does not have any match on the right side, the <code class="docutils literal"><span class="pre">ValueJoiner</span></code> will be called with <code class="docutils literal"><span class="pre">ValueJoiner#apply(leftRecord.value,</span> <span class="pre">null)</span></code>.</p>
                                        </li>
                                    </ul>
                                </td>
                            </tr>
                            </tbody>
                        </table>
                        <p><strong>Semantics of stream-global-table joins:</strong>
                            The join semantics are different to <a class="reference internal" href="#streams-developer-guide-dsl-joins-kstream-ktable"><span class="std std-ref">KStream-KTable joins</span></a> because it's not a temporal join.
                            Another difference is that, for KStream-GlobalKTable joins, the left input record is first &#8220;mapped&#8221; with
                            a user-supplied <code class="docutils literal"><span class="pre">KeyValueMapper</span></code> into the table&#8217;s keyspace prior to the table lookup.</p>
                    </div>
                </div>
                <div class="section" id="windowing">
                    <span id="streams-developer-guide-dsl-windowing"></span><h4><a class="toc-backref" href="#id19">Windowing</a><a class="headerlink" href="#windowing" title="Permalink to this headline"></a></h4>
                    <p>Windowing lets you control how to group records that have the same key for stateful operations such as
                        <a class="reference internal" href="#streams-developer-guide-dsl-aggregating"><span class="std std-ref">aggregations</span></a> or <a class="reference internal" href="#streams-developer-guide-dsl-joins"><span class="std std-ref">joins</span></a> into
                        so-called windows.  Windows are tracked per record key.</p>
                    <div class="admonition note">
                        <p><b>Note</b></p>
                        <p class="last">A related operation is <a class="reference internal" href="#streams-developer-guide-dsl-transformations-stateless"><span class="std std-ref">grouping</span></a>, which groups all
                            records that have the same key to ensure that data is properly partitioned (&#8220;keyed&#8221;) for subsequent operations.
                            Once grouped, windowing allows you to further sub-group the records of a key.</p>
                    </div>
                    <p>For example, in join operations, a windowing state store is used to store all the records received so far within the
                        defined window boundary.  In aggregating operations, a windowing state store is used to store the latest aggregation
                        results per window.
                        Old records in the state store are purged after the specified
                        <a class="reference internal" href="../core-concepts.html#streams_concepts_windowing"><span class="std std-ref">window retention period</span></a>.
                        Kafka Streams guarantees to keep a window for at least this specified time; the default value is one day and can be
                        changed via <code class="docutils literal"><span class="pre">Materialized#withRetention()</span></code>.</p>
                    <p>The DSL supports the following types of windows:</p>
                    <table border="1" class="docutils">
                        <colgroup>
                            <col width="34%" />
                            <col width="10%" />
                            <col width="56%" />
                        </colgroup>
                        <thead valign="bottom">
                        <tr class="row-odd"><th class="head">Window name</th>
                            <th class="head">Behavior</th>
                            <th class="head">Short description</th>
                        </tr>
                        </thead>
                        <tbody valign="top">
                        <tr class="row-even"><td><a class="reference internal" href="#windowing-hopping"><span class="std std-ref">Hopping time window</span></a></td>
                            <td>Time-based</td>
                            <td>Fixed-size, overlapping windows</td>
                        </tr>
                        <tr class="row-odd"><td><a class="reference internal" href="#windowing-tumbling"><span class="std std-ref">Tumbling time window</span></a></td>
                            <td>Time-based</td>
                            <td>Fixed-size, non-overlapping, gap-less windows</td>
                        </tr>
                        <tr class="row-even"><td><a class="reference internal" href="#windowing-sliding"><span class="std std-ref">Sliding time window</span></a></td>
                            <td>Time-based</td>
                            <td>Fixed-size, overlapping windows that work on differences between record timestamps</td>
                        </tr>
                        <tr class="row-odd"><td><a class="reference internal" href="#windowing-session"><span class="std std-ref">Session window</span></a></td>
                            <td>Session-based</td>
                            <td>Dynamically-sized, non-overlapping, data-driven windows</td>
                        </tr>
                        </tbody>
                    </table>
                    <div class="section" id="hopping-time-windows">
                        <span id="windowing-hopping"></span><h5><a class="toc-backref" href="#id21">Hopping time windows</a><a class="headerlink" href="#hopping-time-windows" title="Permalink to this headline"></a></h5>
                        <p>Hopping time windows are windows based on time intervals.  They model fixed-sized, (possibly) overlapping windows.
                            A hopping window is defined by two properties: the window&#8217;s <em>size</em> and its <em>advance interval</em> (aka &#8220;hop&#8221;).  The advance
                            interval specifies by how much a window moves forward relative to the previous one.  For example, you can configure a
                            hopping window with a size 5 minutes and an advance interval of 1 minute.  Since hopping windows can overlap &#8211; and in
                            general they do &#8211; a data record may belong to more than one such windows.</p>
                        <div class="admonition note">
                            <p><b>Note</b></p>
                            <p class="last"><strong>Hopping windows vs. sliding windows:</strong>
                                Hopping windows are sometimes called &#8220;sliding windows&#8221; in other stream processing tools.  Kafka Streams follows the
                                terminology in academic literature, where the semantics of sliding windows are different to those of hopping windows.</p>
                        </div>
                        <p>The following code defines a hopping window with a size of 5 minutes and an advance interval of 1 minute:</p>
                        <pre class="line-numbers"><code class="language-java">import java.time.Duration;
import org.apache.kafka.streams.kstream.TimeWindows;

// A hopping time window with a size of 5 minutes and an advance interval of 1 minute.
// The window&#39;s name -- the string parameter -- is used to e.g. name the backing state store.
Duration windowSize = Duration.ofMinutes(5);
Duration advance = Duration.ofMinutes(1);
TimeWindows.ofSizeWithNoGrace(windowSize).advanceBy(advance);</code></pre>
                        <div class="figure align-center" id="id4">
                            <img class="centered" src="/{{version}}/images/streams-time-windows-hopping.png">
                            <p class="caption"><span class="caption-text">This diagram shows windowing a stream of data records with hopping windows.  In this diagram the time numbers
represent minutes; e.g. t=5 means &#8220;at the five-minute mark&#8221;.  In reality, the unit of time in Kafka Streams is
milliseconds, which means the time numbers would need to be multiplied with 60 * 1,000 to convert from minutes to
milliseconds (e.g. t=5 would become t=300,000).</span></p>
                        </div>
                        <p>Hopping time windows are <em>aligned to the epoch</em>, with the lower interval bound being inclusive and the upper bound
                            being exclusive.  &#8220;Aligned to the epoch&#8221; means that the first window starts at timestamp zero.  For example, hopping
                            windows with a size of 5000ms and an advance interval (&#8220;hop&#8221;) of 3000ms have predictable window boundaries
                            <code class="docutils literal"><span class="pre">[0;5000),[3000;8000),...</span></code> &#8212; and <strong>not</strong> <code class="docutils literal"><span class="pre">[1000;6000),[4000;9000),...</span></code> or even something &#8220;random&#8221; like
                            <code class="docutils literal"><span class="pre">[1452;6452),[4452;9452),...</span></code>.</p>
                        <p>Unlike non-windowed aggregates that we have seen previously, windowed aggregates return a <em>windowed KTable</em> whose keys
                            type is <code class="docutils literal"><span class="pre">Windowed&lt;K&gt;</span></code>.  This is to differentiate aggregate values with the same key from different windows.  The
                            corresponding window instance and the embedded key can be retrieved as <code class="docutils literal"><span class="pre">Windowed#window()</span></code> and <code class="docutils literal"><span class="pre">Windowed#key()</span></code>,
                            respectively.</p>
                    </div>
                    <div class="section" id="tumbling-time-windows">
                        <span id="windowing-tumbling"></span><h5><a class="toc-backref" href="#id20">Tumbling time windows</a><a class="headerlink" href="#tumbling-time-windows" title="Permalink to this headline"></a></h5>
                        <p>Tumbling time windows are a special case of hopping time windows and, like the latter, are windows based on time
                            intervals.  They model fixed-size, non-overlapping, gap-less windows.
                            A tumbling window is defined by a single property: the window&#8217;s <em>size</em>.
                            A tumbling window is a hopping window whose window size is equal to its advance interval.
                            Since tumbling windows never overlap, a data record will belong to one and only one window.</p>
                        <div class="figure align-center" id="id3">
                            <img class="centered" src="/{{version}}/images/streams-time-windows-tumbling.png">
                            <p class="caption"><span class="caption-text">This diagram shows windowing a stream of data records with tumbling windows.  Windows do not overlap because, by
definition, the advance interval is identical to the window size.  In this diagram the time numbers represent minutes;
e.g. t=5 means &#8220;at the five-minute mark&#8221;.  In reality, the unit of time in Kafka Streams is milliseconds, which means
the time numbers would need to be multiplied with 60 * 1,000 to convert from minutes to milliseconds (e.g. t=5 would
become t=300,000).</span></p>
                        </div>
                        <p>Tumbling time windows are <em>aligned to the epoch</em>, with the lower interval bound being inclusive and the upper bound
                            being exclusive.  &#8220;Aligned to the epoch&#8221; means that the first window starts at timestamp zero.  For example, tumbling
                            windows with a size of 5000ms have predictable window boundaries <code class="docutils literal"><span class="pre">[0;5000),[5000;10000),...</span></code> &#8212; and <strong>not</strong>
                            <code class="docutils literal"><span class="pre">[1000;6000),[6000;11000),...</span></code> or even something &#8220;random&#8221; like <code class="docutils literal"><span class="pre">[1452;6452),[6452;11452),...</span></code>.</p>
                        <p>The following code defines a tumbling window with a size of 5 minutes:</p>
                        <pre class="line-numbers"><code class="language-java">import java.time.Duration;
import org.apache.kafka.streams.kstream.TimeWindows;

// A tumbling time window with a size of 5 minutes (and, by definition, an implicit
// advance interval of 5 minutes), and grace period of 1 minute.
Duration windowSize = Duration.ofMinutes(5);
Duration gracePeriod = Duration.ofMinutes(1);
TimeWindows.ofSizeAndGrace(windowSize, gracePeriod);

// The above is equivalent to the following code:
TimeWindows.ofSizeAndGrace(windowSize, gracePeriod).advanceBy(windowSize);</code></pre>
                    </div>
                    <div class="section" id="sliding-time-windows">
                        <span id="windowing-sliding"></span><h5><a class="toc-backref" href="#id22">Sliding time windows</a><a class="headerlink" href="#sliding-time-windows" title="Permalink to this headline"></a></h5>
                        <p>Sliding windows are actually quite different from hopping and tumbling windows.  In Kafka Streams, sliding windows
                            are used for <a class="reference internal" href="#streams-developer-guide-dsl-joins"><span class="std std-ref">join operations</span></a>, specified by using the
                            <code class="docutils literal"><span class="pre">JoinWindows</span></code> class, and windowed aggregations, specified by using the <code class="docutils literal"><span class="pre">SlidingWindows</span></code> class.</p>
                        <p>A sliding window models a fixed-size window that slides continuously over the time axis. In this model, two data records are
                            said to be included in the same window if (in the case of symmetric windows) the difference of their timestamps is
                            within the window size. As a sliding window moves along the time axis, records may fall into multiple snapshots of
                            the sliding window, but each unique combination of records appears only in one sliding window snapshot.</p>
                        <p>The following code defines a sliding window with a time difference of 10 minutes and a grace period of 30 minutes:</p>
                        <pre class="line-numbers"><code class="language-java">import org.apache.kafka.streams.kstream.SlidingWindows;

// A sliding time window with a time difference of 10 minutes and grace period of 30 minutes
Duration timeDifference = Duration.ofMinutes(10);
Duration gracePeriod = Duration.ofMinutes(30);
SlidingWindows.ofTimeDifferenceAndGrace(timeDifference, gracePeriod);</code></pre>
                         <div class="figure align-center" id="id35">
                             <img class="centered" src="/{{version}}/images/streams-sliding-windows.png">
                             <p class="caption"><span class="caption-text">This diagram shows windowing a stream of data records with sliding windows. The overlap of
                                 the sliding window snapshots varies depending on the record times. In this diagram, the time numbers represent milliseconds. For example,
                                 t=5 means &#8220;at the five millisecond mark&#8220;.</span></p>
                         </div>
                         <p>Sliding windows are aligned to the data record timestamps, not to the epoch. In contrast to hopping and tumbling windows,
                             the lower and upper window time interval bounds of sliding windows are both inclusive.</p>
                    </div>
                    <div class="section" id="session-windows">
                        <span id="windowing-session"></span><h5><a class="toc-backref" href="#id23">Session Windows</a><a class="headerlink" href="#session-windows" title="Permalink to this headline"></a></h5>
                        <p>Session windows are used to aggregate key-based events into so-called <em>sessions</em>, the process of which is referred to
                            as <em>sessionization</em>.  Sessions represent a <strong>period of activity</strong> separated by a defined <strong>gap of inactivity</strong> (or
                            &#8220;idleness&#8221;).  Any events processed that fall within the inactivity gap of any existing sessions are merged into the
                            existing sessions.  If an event falls outside of the session gap, then a new session will be created.</p>
                        <p>Session windows are different from the other window types in that:</p>
                        <ul class="simple">
                            <li>all windows are tracked independently across keys &#8211; e.g. windows of different keys typically have different start
                                and end times</li>
                            <li>their window sizes sizes vary &#8211; even windows for the same key typically have different sizes</li>
                        </ul>
                        <p>The prime area of application for session windows is <strong>user behavior analysis</strong>.  Session-based analyses can range from
                            simple metrics (e.g. count of user visits on a news website or social platform) to more complex metrics (e.g. customer
                            conversion funnel and event flows).</p>
                        <p>The following code defines a session window with an inactivity gap of 5 minutes:</p>
                        <pre class="line-numbers"><code class="language-java">import java.time.Duration;
import org.apache.kafka.streams.kstream.SessionWindows;

// A session window with an inactivity gap of 5 minutes.
SessionWindows.ofInactivityGapWithNoGrace(Duration.ofMinutes(5));</code></pre>
                        <p>Given the previous session window example, here&#8217;s what would happen on an input stream of six records.
                            When the first three records arrive (upper part of in the diagram below), we&#8217;d have three sessions (see lower part)
                            after having processed those records: two for the green record key, with one session starting and ending at the
                            0-minute mark (only due to the illustration it looks as if the session goes from 0 to 1), and another starting and
                            ending at the 6-minute mark; and one session for the blue record key, starting and ending at the 2-minute mark.</p>
                        <div class="figure align-center" id="id5">
                            <img class="centered" src="/{{version}}/images/streams-session-windows-01.png">
                            <p class="caption"><span class="caption-text">Detected sessions after having received three input records: two records for the green record key at t=0 and t=6, and
one record for the blue record key at t=2.
In this diagram the time numbers represent minutes; e.g.  t=5 means &#8220;at the five-minute mark&#8221;.  In reality, the unit
of time in Kafka Streams is milliseconds, which means the time numbers would need to be multiplied with 60 * 1,000 to
convert from minutes to milliseconds (e.g. t=5 would become t=300,000).</span></p>
                        </div>
                        <p>If we then receive three additional records (including two out-of-order records), what would happen is that the two
                            existing sessions for the green record key will be merged into a single session starting at time 0 and ending at time 6,
                            consisting of a total of three records.  The existing session for the blue record key will be extended to end at time 5,
                            consisting of a total of two records.  And, finally, there will be a new session for the blue key starting and ending at
                            time 11.</p>
                        <div class="figure align-center" id="id6">
                            <img class="centered" src="/{{version}}/images/streams-session-windows-02.png">
                            <p class="caption"><span class="caption-text">Detected sessions after having received six input records.  Note the two out-of-order data records at t=4 (green) and
t=5 (blue), which lead to a merge of sessions and an extension of a session, respectively.</span></p>
                        </div>
                    </div>
		    <div class="section" id="window-final-results">
			    <span id="windowing-final-results"></span><h5><a class="toc-backref" href="#id31">Window Final Results</a><a class="headerlink" href="#window-final-results" title="Permalink to this headline"></a></h5>
			    <p>In Kafka Streams, windowed computations update their results continuously.
			       As new data arrives for a window, freshly computed results are emitted downstream.
			       For many applications, this is ideal, since fresh results are always available.
			       and Kafka Streams is designed to make programming continuous computations seamless.
			       However, some applications need to take action <strong>only</strong> on the final result of a windowed computation.
			       Common examples of this are sending alerts or delivering results to a system that doesn't support updates.
			    </p>
			    <p>Suppose that you have an hourly windowed count of events per user.
			       If you want to send an alert when a user has <em>less than</em> three events in an hour, you have a real challenge.
			       All users would match this condition at first, until they accrue enough events, so you cannot simply
			       send an alert when someone matches the condition; you have to wait until you know you won't see any more events for a particular window
			       and <em>then</em> send the alert.
			    </p>
                            <p>Kafka Streams offers a clean way to define this logic: after defining your windowed computation, you can
			       <span class="pre">suppress</span> the intermediate results, emitting the final count for each user when the window is <strong>closed</strong>.
			    </p>
			    <p>For example:</p>
                <pre class="line-numbers"><code class="language-java">KGroupedStream&lt;UserId, Event&gt; grouped = ...;
grouped
    .windowedBy(TimeWindows.ofSizeAndGrace(Duration.ofHours(1), Duration.ofMinutes(10)))
    .count()
    .suppress(Suppressed.untilWindowCloses(unbounded()))
    .filter((windowedUserId, count) -&gt; count &lt; 3)
    .toStream()
    .foreach((windowedUserId, count) -&gt; sendAlert(windowedUserId.window(), windowedUserId.key(), count));</code></pre>
			    </div></div>
			    <p>The key parts of this program are:
			    <dl>
				    <dt><code>ofSizeAndGrace(Duration.ofHours(1), Duration.ofMinutes(10))</code></dt>
				    <dd>The specified grace period of 10 minutes (i.e., the <code>Duration.ofMinutes(10)</code> argument) allows us to bound the lateness of events the window will accept.
				        For example, the 09:00 to 10:00 window will accept out-of-order records until 10:10, at which point, the window is <strong>closed</strong>.
				    </dd>
				    <dt><code>.suppress(Suppressed.untilWindowCloses(...))</code></dt>
				    <dd>This configures the suppression operator to emit nothing for a window until it closes, and then emit the final result.
				        For example, if user <code>U</code> gets 10 events between 09:00 and 10:10, the <code>filter</code> downstream of the suppression
					will get no events for the windowed key <code>U@09:00-10:00</code> until 10:10, and then it will get exactly one with the value <code>10</code>.
					This is the final result of the windowed count.
				    </dd>
				    <dt><code>unbounded()</code></dt>
				    <dd>
				      This configures the buffer used for storing events
				      until their windows close.
				      Production code is able to put a cap on the amount
				      of memory to use for the buffer,
				      but this simple example creates a buffer with no
				      upper bound.
				    </dd>
			    </dl>
			    </p>
			    <p>
			      One thing to note is that suppression is just like any other
			      Kafka Streams operator, so you can build a topology with two
			      branches emerging from the <code>count</code>,
			      one suppressed, and one not, or even multiple differently
			      configured suppressions.
			      This allows you to apply suppressions where they are needed
			      and otherwise rely on the default continuous update behavior.
			    </p>
			    <p>For more detailed information, see the JavaDoc on the <code>Suppressed</code> config object
	                       and <a href="https://cwiki.apache.org/confluence/x/sQU0BQ" title="KIP-328">KIP-328</a>.
			    </p>
		    </div>
                </div>
            </div>
            <div class="section" id="applying-processors-processor-api-integration">
                <a class="headerlink" href="#applying-processors-processor-api-integration" title="Permalink to this headline">
                    <h3>
                        <a class="toc-backref" href="#id24">Applying processors (Processor API integration)</a>
                    </h3>
                </a>
                <p>Beyond the aforementioned <a class="reference internal"
                        href="#streams-developer-guide-dsl-transformations-stateless">
                        <span class="std std-ref">stateless</span></a> and
                    <a class="reference internal" href="#streams-developer-guide-dsl-transformations-stateless"> <span
                            class="std std-ref">stateful</span></a> transformations, you may also leverage the Processor API from the
                    DSL. There are a number of scenarios where this may be helpful:
                </p>
                <ul>
                    <li><strong>Customization:</strong> You need to implement special, customized logic that is not or not yet
                        available
                        in the DSL.</li>
                    <li><strong>Combining ease-of-use with full flexibility where it's needed:</strong> Even though you generally
                        prefer
                        to use the expressiveness of the DSL, there are certain steps in your processing that require more
                        flexibility and tinkering than the DSL provides. For example, only the Processor API provides access to a
                        record's metadata such as its topic, partition, and offset information. However, you don't want to switch
                        completely to the Processor API just because of that; and</li>
                    <li><strong>Migrating from other tools:</strong> You are migrating from other stream processing technologies
                        that
                        provide an imperative API, and migrating some of your legacy code to the Processor API was faster and/or
                        easier than to migrate completely to the DSL right away.</li>
                </ul>
                <h4>Operations and concepts</h4>
                <ul>
                    <li><code>KStream#process</code>: Process all records in a stream, one record at a time, by applying a
                        <code>Processor</code> (provided by a given <code>ProcessorSupplier</code>);
                    </li>
                    <li><code>KStream#processValues</code>: Process all records in a stream, one record at a time, by applying a
                        <code>FixedKeyProcessor</code> (provided by a given <code>FixedKeyProcessorSupplier</code>);
                    </li>
                    <li><code>Processor</code>: A processor of key-value pair records;</li>
                    <li><code>ContextualProcessor</code>: An abstract implementation of <code>Processor</code> that manages the
                        <code>ProcessorContext</code> instance.
                    </li>
                    <li><code>FixedKeyProcessor</code>: A processor of key-value pair records where keys are immutable;</li>
                    <li><code>ContextualFixedKeyProcessor</code>: An abstract implementation of <code>FixedKeyProcessor</code> that
                        manages the <code>FixedKeyProcessorContext</code> instance.
                    </li>
                    <li><code>ProcessorSupplier</code>: A processor supplier that can create one or more <code>Processor</code>
                        instances; and</li>
                    <li><code>FixedKeyProcessorSupplier</code>: A processor supplier that can create one or more
                        <code>FixedKeyProcessor</code> instances.
                    </li>
                </ul>
                <h4>Examples</h4>
                <p>Follow the examples below to learn how to apply <code>process</code> and <code>processValues</code> to your
                    <code>KStream</code>.
                </p>
                <table>
                    <thead>
                        <tr>
                            <th>Example</th>
                            <th>Operation</th>
                            <th>State Type</th>
                        </tr>
                    </thead>
                    <tbody>
                        <tr>
                            <td><a href="#categorizing-logs-by-severity">Categorizing Logs by Severity</a></td>
                            <td><code>process</code></td>
                            <td>Stateless</td>
                        </tr>
                        <tr>
                            <td><a href="#replacing-slang-in-text-messages">Replacing Slang in Text Messages</a></td>
                            <td><code>processValues</code></td>
                            <td>Stateless</td>
                        </tr>
                        <tr>
                            <td><a href="#cumulative-discounts-for-a-loyalty-program">Cumulative Discounts for a Loyalty Program</a>
                            </td>
                            <td><code>process</code></td>
                            <td>Stateful</td>
                        </tr>
                        <tr>
                            <td><a href="#traffic-radar-monitoring-car-count">Traffic Radar Monitoring Car Count</a></td>
                            <td><code>processValues</code></td>
                            <td>Stateful</td>
                        </tr>
                    </tbody>
                </table>
                <h5 id="categorizing-logs-by-severity">Categorizing Logs by Severity</h5>
                <ul>
                    <li><strong>Idea:</strong> You have a stream of log messages. Each message contains a severity level (e.g.,
                        INFO,
                        WARN, ERROR) in the value. The processor filters messages, routing ERROR messages to a dedicated topic and
                        discarding INFO messages. The rest (WARN) are forwarded to a dedicated topic too.</li>
                    <li><strong>Real-World Context:</strong> In a production monitoring system, categorizing logs by severity
                        ensures
                        ERROR logs are sent to a critical incident management system, WARN logs are analyzed for potential risks,
                        and
                        INFO logs are stored for basic reporting purposes.</li>
                </ul>
                <pre class="line-numbers"><code class="language-java">public class CategorizingLogsBySeverityExample {
    private static final String ERROR_LOGS_TOPIC = &quot;error-logs-topic&quot;;
    private static final String INPUT_LOGS_TOPIC = &quot;input-logs-topic&quot;;
    private static final String UNKNOWN_LOGS_TOPIC = &quot;unknown-logs-topic&quot;;
    private static final String WARN_LOGS_TOPIC = &quot;warn-logs-topic&quot;;

    public static void categorizeWithProcess(final StreamsBuilder builder) {
        final KStream&lt;String, String&gt; logStream = builder.stream(INPUT_LOGS_TOPIC);
        logStream.process(LogSeverityProcessor::new)
                .to((key, value, recordContext) -&gt; {
                    // Determine the target topic dynamically
                    if (&quot;ERROR&quot;.equals(key)) return ERROR_LOGS_TOPIC;
                    if (&quot;WARN&quot;.equals(key)) return WARN_LOGS_TOPIC;
                    return UNKNOWN_LOGS_TOPIC;
                });
    }

    private static class LogSeverityProcessor extends ContextualProcessor&lt;String, String, String, String&gt; {
        @Override
        public void process(final Record&lt;String, String&gt; record) {
            if (record.value() == null) {
                return; // Skip null values
            }

            // Assume the severity is the first word in the log message
            // For example: &quot;ERROR: Disk not found&quot; -&gt; &quot;ERROR&quot;
            final int colonIndex = record.value().indexOf(&#39;:&#39;);
            final String severity = colonIndex &gt; 0 ? record.value().substring(0, colonIndex).trim() : &quot;UNKNOWN&quot;;

            // Route logs based on severity
            switch (severity) {
                case &quot;ERROR&quot;:
                    context().forward(record.withKey(ERROR_LOGS_TOPIC));
                    break;
                case &quot;WARN&quot;:
                    context().forward(record.withKey(WARN_LOGS_TOPIC));
                    break;
                case &quot;INFO&quot;:
                    // INFO logs are ignored
                    break;
                default:
                    // Forward to an &quot;unknown&quot; topic for logs with unrecognized severities
                    context().forward(record.withKey(UNKNOWN_LOGS_TOPIC));
            }
        }
    }
}</code></pre>
                <h5 id="replacing-slang-in-text-messages">Replacing Slang in Text Messages</h5>
                <ul>
                    <li><strong>Idea:</strong> A messaging stream contains user-generated content, and you want to replace slang
                        words
                        with their formal equivalents (e.g., &quot;u&quot; becomes &quot;you&quot;, &quot;brb&quot; becomes &quot;be
                        right back&quot;). The operation only modifies the message value and keeps the key intact.</li>
                    <li><strong>Real-World Context:</strong> In customer support chat systems, normalizing text by replacing slang
                        with
                        formal equivalents ensures that automated sentiment analysis tools work accurately and provide reliable
                        insights.</li>
                </ul>
                <pre class="line-numbers"><code class="language-java">public class ReplacingSlangTextInMessagesExample {
    private static final Map&lt;String, String&gt; SLANG_DICTIONARY = Map.of(
            &quot;u&quot;, &quot;you&quot;,
            &quot;brb&quot;, &quot;be right back&quot;,
            &quot;omg&quot;, &quot;oh my god&quot;,
            &quot;btw&quot;, &quot;by the way&quot;
    );
    private static final String INPUT_MESSAGES_TOPIC = &quot;input-messages-topic&quot;;
    private static final String OUTPUT_MESSAGES_TOPIC = &quot;output-messages-topic&quot;;

    public static void replaceWithProcessValues(final StreamsBuilder builder) {
        KStream&lt;String, String&gt; messageStream = builder.stream(INPUT_MESSAGES_TOPIC);
        messageStream.processValues(SlangReplacementProcessor::new).to(OUTPUT_MESSAGES_TOPIC);
    }

    private static class SlangReplacementProcessor extends ContextualFixedKeyProcessor&lt;String, String, String&gt; {
        @Override
        public void process(final FixedKeyRecord&lt;String, String&gt; record) {
            if (record.value() == null) {
                return; // Skip null values
            }

            // Replace slang words in the message
            final String[] words = record.value().split(&quot;\\s+&quot;);
            for (final String word : words) {
                String replacedWord = SLANG_DICTIONARY.getOrDefault(word, word);
                context().forward(record.withValue(replacedWord));
            }
        }
    }
}</code></pre>
                <h5 id="cumulative-discounts-for-a-loyalty-program">Cumulative Discounts for a Loyalty Program</h5>
                <ul>
                    <li><strong>Idea:</strong> A stream of purchase events contains user IDs and transaction amounts. Use a state
                        store
                        to accumulate the total spending of each user. When their total crosses a threshold, apply a discount on
                        their next transaction and update their accumulated total.</li>
                    <li><strong>Real-World Context:</strong> In a retail loyalty program, tracking cumulative customer spending
                        enables
                        dynamic rewards, such as issuing a discount when a customer's total purchases exceed a predefined limit.
                    </li>
                </ul>
                <pre class="line-numbers"><code class="language-java">public class CumulativeDiscountsForALoyaltyProgramExample {
    private static final double DISCOUNT_THRESHOLD = 100.0;
    private static final String CUSTOMER_SPENDING_STORE = &quot;customer-spending-store&quot;;
    private static final String DISCOUNT_NOTIFICATION_MESSAGE =
            &quot;Discount applied! You have received a reward for your purchases.&quot;;
    private static final String DISCOUNT_NOTIFICATIONS_TOPIC = &quot;discount-notifications-topic&quot;;
    private static final String PURCHASE_EVENTS_TOPIC = &quot;purchase-events-topic&quot;;

    public static void applyDiscountWithProcess(final StreamsBuilder builder) {
        // Define the state store for tracking cumulative spending
        builder.addStateStore(
                Stores.keyValueStoreBuilder(
                        Stores.inMemoryKeyValueStore(CUSTOMER_SPENDING_STORE),
                        Serdes.String(),
                        Serdes.Double()
                )
        );
        final KStream&lt;String, Double&gt; purchaseStream = builder.stream(PURCHASE_EVENTS_TOPIC);
        // Apply the Processor with the state store
        final KStream&lt;String, String&gt; notificationStream =
                purchaseStream.process(CumulativeDiscountProcessor::new, CUSTOMER_SPENDING_STORE);
        // Send the notifications to the output topic
        notificationStream.to(DISCOUNT_NOTIFICATIONS_TOPIC);
    }

    private static class CumulativeDiscountProcessor implements Processor&lt;String, Double, String, String&gt; {
        private KeyValueStore&lt;String, Double&gt; spendingStore;
        private ProcessorContext&lt;String, String&gt; context;

        @Override
        public void init(final ProcessorContext&lt;String, String&gt; context) {
            this.context = context;
            // Retrieve the state store for cumulative spending
            spendingStore = context.getStateStore(CUSTOMER_SPENDING_STORE);
        }

        @Override
        public void process(final Record&lt;String, Double&gt; record) {
            if (record.value() == null) {
                return; // Skip null purchase amounts
            }

            // Get the current spending total for the customer
            Double currentSpending = spendingStore.get(record.key());
            if (currentSpending == null) {
                currentSpending = 0.0;
            }
            // Update the cumulative spending
            currentSpending += record.value();
            spendingStore.put(record.key(), currentSpending);

            // Check if the customer qualifies for a discount
            if (currentSpending &gt;= DISCOUNT_THRESHOLD) {
                // Reset the spending after applying the discount
                spendingStore.put(record.key(), currentSpending - DISCOUNT_THRESHOLD);
                // Send a discount notification
                context.forward(record.withValue(DISCOUNT_NOTIFICATION_MESSAGE));
            }
        }
    }
}</code></pre>
                <h5 id="traffic-radar-monitoring-car-count">Traffic Radar Monitoring Car Count</h5>
                <ul>
                    <li><strong>Idea:</strong> A radar monitors cars passing along a road stretch. A system counts the cars for each
                        day, maintaining a cumulative total for the current day in a state store. At the end of the day, the count
                        is
                        emitted and the state is cleared for the next day.</li>
                    <li><strong>Real-World Context:</strong> A car counting system can be useful for determining measures for
                        widening
                        or controlling traffic depending on the number of cars passing through the monitored stretch.</li>
                </ul>
                <pre class="line-numbers"><code class="language-java">public class TrafficRadarMonitoringCarCountExample {
    private static final String DAILY_COUNT_STORE = &quot;price-state-store&quot;;
    private static final String DAILY_COUNT_TOPIC = &quot;price-state-topic&quot;;
    private static final String RADAR_COUNT_TOPIC = &quot;car-radar-topic&quot;;

    public static void countWithProcessValues(final StreamsBuilder builder) {
        // Define a state store for tracking daily car counts
        builder.addStateStore(
                Stores.keyValueStoreBuilder(
                        Stores.inMemoryKeyValueStore(DAILY_COUNT_STORE),
                        Serdes.String(),
                        Serdes.Long()
                )
        );
        final KStream&lt;Void, String&gt; radarStream = builder.stream(RADAR_COUNT_TOPIC);
        // Apply the FixedKeyProcessor with the state store
        radarStream.processValues(DailyCarCountProcessor::new, DAILY_COUNT_STORE)
                .to(DAILY_COUNT_TOPIC);
    }

    private static class DailyCarCountProcessor implements FixedKeyProcessor&lt;Void, String, String&gt; {
        private FixedKeyProcessorContext&lt;Void, String&gt; context;
        private KeyValueStore&lt;String, Long&gt; stateStore;
        private static final DateTimeFormatter DATE_FORMATTER =
                DateTimeFormatter.ofPattern(&quot;yyyy-MM-dd&quot;).withZone(ZoneId.systemDefault());

        @Override
        public void init(final FixedKeyProcessorContext&lt;Void, String&gt; context) {
            this.context = context;
            stateStore = context.getStateStore(DAILY_COUNT_STORE);
        }

        @Override
        public void process(final FixedKeyRecord&lt;Void, String&gt; record) {
            if (record.value() == null) {
                return; // Skip null events
            }

            // Derive the current day from the event timestamp
            final long timestamp = System.currentTimeMillis(); // Use system time for simplicity
            final String currentDay = DATE_FORMATTER.format(Instant.ofEpochMilli(timestamp));
            // Retrieve the current count for the day
            Long dailyCount = stateStore.get(currentDay);
            if (dailyCount == null) {
                dailyCount = 0L;
            }
            // Increment the count
            dailyCount++;
            stateStore.put(currentDay, dailyCount);

            // Emit the current day&#39;s count
            context.forward(record.withValue(String.format(&quot;Day: %s, Car Count: %s&quot;, currentDay, dailyCount)));
        }
    }
}</code></pre>
                
                <h4>Keynotes</h4>
                <ul>
                    <li><strong>Type Safety and Flexibility:</strong> The process and processValues APIs utilize
                        <code>ProcessorContext</code> and <code>Record</code> or <code>FixedKeyRecord</code> objects for better type
                        safety and flexibility of custom processing logic.
                    </li>
                    <li><strong>Clear State and Logic Management:</strong> Implementations for <code>Processor</code> or
                        <code>FixedKeyProcessor</code> should manage state and logic clearly. Use <code>context().forward()</code>
                        for emitting records downstream.
                    </li>
                    <li><strong>Unified API:</strong> Consolidates multiple methods into a single, versatile API.</li>
                    <li><strong>Future-Proof:</strong> Ensures compatibility with the latest Kafka Streams releases.</li>
                </ul>
            </div>
            <div class="section" id="transformers-removal-and-migration-to-processors">
                <a class="headerlink" href="#transformers-removal-and-migration-to-processors" title="Permalink to this headline">
                    <h3>
                        <a class="toc-backref" href="#id37">Transformers removal and migration to processors</a>
                    </h3>
                </a>
                <p>As of Kafka 4.0, several deprecated methods in the Kafka Streams API, such as <code>transform</code>,
                    <code>flatTransform</code>, <code>transformValues</code>, <code>flatTransformValues</code>, and
                    <code>process</code> have been removed. These methods have been replaced with the more versatile Processor API.
                    This guide provides detailed steps for migrating existing code to use the new Processor API and explains the
                    benefits of the changes.</p>
                <p>The following deprecated methods are no longer available in Kafka Streams:</p>
                <ul>
                    <li><code>KStream#transform</code></li>
                    <li><code>KStream#flatTransform</code></li>
                    <li><code>KStream#transformValues</code></li>
                    <li><code>KStream#flatTransformValues</code></li>
                    <li><code>KStream#process</code></li>
                </ul>
                <p>The Processor API now serves as a unified replacement for all these methods. It simplifies the API surface
                    while maintaining support for both stateless and stateful operations.</p>
                <h4>Migration Examples</h4>
                <p>To migrate from the deprecated <code>transform</code>, <code>transformValues</code>, <code>flatTransform</code>, and
                    <code>flatTransformValues</code> methods to the Processor API (PAPI) in Kafka Streams, let&#39;s resume the
                    previouss examples. The new <code>process</code> and <code>processValues</code> methods enable a more flexible
                    and reusable approach by requiring implementations of the <code>Processor</code>
                    or <code>FixedKeyProcessor</code> interfaces.</p>
                <table>
                    <thead>
                        <tr>
                            <th>Example</th>
                            <th>Migrating from</th>
                            <th>Migrating to</th>
                            <th>State Type</th>
                        </tr>
                    </thead>
                    <tbody>
                        <tr>
                            <td><a href="#categorizing-logs-by-severity-removal">Categorizing Logs by Severity</a></td>
                            <td><code>flatTransform</code></td>
                            <td><code>process</code></td>
                            <td>Stateless</td>
                        </tr>
                        <tr>
                            <td><a href="#replacing-slang-in-text-messages-removal">Replacing Slang in Text Messages</a></td>
                            <td><code>flatTransformValues</code></td>
                            <td><code>processValues</code></td>
                            <td>Stateless</td>
                        </tr>
                        <tr>
                            <td><a href="#cumulative-discounts-for-a-loyalty-program-removal">Cumulative Discounts for a Loyalty Program</a>
                            </td>
                            <td><code>transform</code></td>
                            <td><code>process</code></td>
                            <td>Stateful</td>
                        </tr>
                        <tr>
                            <td><a href="#traffic-radar-monitoring-car-count-removal">Traffic Radar Monitoring Car Count</a></td>
                            <td><code>transformValues</code></td>
                            <td><code>processValues</code></td>
                            <td>Stateful</td>
                        </tr>
                    </tbody>
                </table>
                <h5 id="categorizing-logs-by-severity-removal">Categorizing Logs by Severity</h5>
                <p>Below, methods <code>categorizeWithFlatTransform</code> and <code>categorizeWithProcess</code> show how you can
                    migrate from <code>flatTransform</code> to <code>process</code>.</p>
                <pre class="line-numbers"><code class="language-java">public class CategorizingLogsBySeverityExample {
    private static final String ERROR_LOGS_TOPIC = &quot;error-logs-topic&quot;;
    private static final String INPUT_LOGS_TOPIC = &quot;input-logs-topic&quot;;
    private static final String UNKNOWN_LOGS_TOPIC = &quot;unknown-logs-topic&quot;;
    private static final String WARN_LOGS_TOPIC = &quot;warn-logs-topic&quot;;

    public static void categorizeWithFlatTransform(final StreamsBuilder builder) {
        final KStream&lt;String, String&gt; logStream = builder.stream(INPUT_LOGS_TOPIC);
        logStream.flatTransform(LogSeverityTransformer::new)
                .to((key, value, recordContext) -&gt; {
                    // Determine the target topic dynamically
                    if (&quot;ERROR&quot;.equals(key)) return ERROR_LOGS_TOPIC;
                    if (&quot;WARN&quot;.equals(key)) return WARN_LOGS_TOPIC;
                    return UNKNOWN_LOGS_TOPIC;
                });
    }

    public static void categorizeWithProcess(final StreamsBuilder builder) {
        final KStream&lt;String, String&gt; logStream = builder.stream(INPUT_LOGS_TOPIC);
        logStream.process(LogSeverityProcessor::new)
                .to((key, value, recordContext) -&gt; {
                    // Determine the target topic dynamically
                    if (&quot;ERROR&quot;.equals(key)) return ERROR_LOGS_TOPIC;
                    if (&quot;WARN&quot;.equals(key)) return WARN_LOGS_TOPIC;
                    return UNKNOWN_LOGS_TOPIC;
                });
    }

    private static class LogSeverityTransformer implements Transformer&lt;String, String, Iterable&lt;KeyValue&lt;String, String&gt;&gt;&gt; {
        @Override
        public void init(org.apache.kafka.streams.processor.ProcessorContext context) {
        }

        @Override
        public Iterable&lt;KeyValue&lt;String, String&gt;&gt; transform(String key, String value) {
            if (value == null) {
                return Collections.emptyList(); // Skip null values
            }

            // Assume the severity is the first word in the log message
            // For example: &quot;ERROR: Disk not found&quot; -&gt; &quot;ERROR&quot;
            int colonIndex = value.indexOf(&#39;:&#39;);
            String severity = colonIndex &gt; 0 ? value.substring(0, colonIndex).trim() : &quot;UNKNOWN&quot;;

            // Create appropriate KeyValue pair based on severity
            return switch (severity) {
                case &quot;ERROR&quot; -&gt; List.of(new KeyValue&lt;&gt;(&quot;ERROR&quot;, value));
                case &quot;WARN&quot; -&gt; List.of(new KeyValue&lt;&gt;(&quot;WARN&quot;, value));
                case &quot;INFO&quot; -&gt; Collections.emptyList(); // INFO logs are ignored
                default -&gt; List.of(new KeyValue&lt;&gt;(&quot;UNKNOWN&quot;, value));
            };
        }

        @Override
        public void close() {
        }
    }

    private static class LogSeverityProcessor extends ContextualProcessor&lt;String, String, String, String&gt; {
        @Override
        public void process(final Record&lt;String, String&gt; record) {
            if (record.value() == null) {
                return; // Skip null values
            }

            // Assume the severity is the first word in the log message
            // For example: &quot;ERROR: Disk not found&quot; -&gt; &quot;ERROR&quot;
            final int colonIndex = record.value().indexOf(&#39;:&#39;);
            final String severity = colonIndex &gt; 0 ? record.value().substring(0, colonIndex).trim() : &quot;UNKNOWN&quot;;

            // Route logs based on severity
            switch (severity) {
                case &quot;ERROR&quot;:
                    context().forward(record.withKey(ERROR_LOGS_TOPIC));
                    break;
                case &quot;WARN&quot;:
                    context().forward(record.withKey(WARN_LOGS_TOPIC));
                    break;
                case &quot;INFO&quot;:
                    // INFO logs are ignored
                    break;
                default:
                    // Forward to an &quot;unknown&quot; topic for logs with unrecognized severities
                    context().forward(record.withKey(UNKNOWN_LOGS_TOPIC));
            }
        }
    }
}</code></pre>
                <h5 id="replacing-slang-in-text-messages-removal">Replacing Slang in Text Messages</h5>
                <p>Below, methods <code>replaceWithFlatTransformValues</code> and <code>replaceWithProcessValues</code> show how you can
                    migrate from <code>flatTransformValues</code> to <code>processValues</code>.</p>
                <pre class="line-numbers"><code class="language-java">public class ReplacingSlangTextInMessagesExample {
    private static final Map&lt;String, String&gt; SLANG_DICTIONARY = Map.of(
            &quot;u&quot;, &quot;you&quot;,
            &quot;brb&quot;, &quot;be right back&quot;,
            &quot;omg&quot;, &quot;oh my god&quot;,
            &quot;btw&quot;, &quot;by the way&quot;
    );
    private static final String INPUT_MESSAGES_TOPIC = &quot;input-messages-topic&quot;;
    private static final String OUTPUT_MESSAGES_TOPIC = &quot;output-messages-topic&quot;;

    public static void replaceWithFlatTransformValues(final StreamsBuilder builder) {
        KStream&lt;String, String&gt; messageStream = builder.stream(INPUT_MESSAGES_TOPIC);
        messageStream.flatTransformValues(SlangReplacementTransformer::new).to(OUTPUT_MESSAGES_TOPIC);
    }

    public static void replaceWithProcessValues(final StreamsBuilder builder) {
        KStream&lt;String, String&gt; messageStream = builder.stream(INPUT_MESSAGES_TOPIC);
        messageStream.processValues(SlangReplacementProcessor::new).to(OUTPUT_MESSAGES_TOPIC);
    }

    private static class SlangReplacementTransformer implements ValueTransformer&lt;String, Iterable&lt;String&gt;&gt; {

        @Override
        public void init(final org.apache.kafka.streams.processor.ProcessorContext context) {
        }

        @Override
        public Iterable&lt;String&gt; transform(final String value) {
            if (value == null) {
                return Collections.emptyList(); // Skip null values
            }

            // Replace slang words in the message
            final String[] words = value.split(&quot;\\s+&quot;);
            return Arrays.asList(
                    Arrays.stream(words)
                            .map(word -&gt; SLANG_DICTIONARY.getOrDefault(word, word))
                            .toArray(String[]::new)
            );
        }

        @Override
        public void close() {
        }
    }

    private static class SlangReplacementProcessor extends ContextualFixedKeyProcessor&lt;String, String, String&gt; {
        @Override
        public void process(final FixedKeyRecord&lt;String, String&gt; record) {
            if (record.value() == null) {
                return; // Skip null values
            }

            // Replace slang words in the message
            final String[] words = record.value().split(&quot;\\s+&quot;);
            for (final String word : words) {
                String replacedWord = SLANG_DICTIONARY.getOrDefault(word, word);
                context().forward(record.withValue(replacedWord));
            }
        }
    }
}</code></pre>
                <h5 id="cumulative-discounts-for-a-loyalty-program-removal">Cumulative Discounts for a Loyalty Program</h5>
                <pre class="line-numbers"><code class="language-java">public class CumulativeDiscountsForALoyaltyProgramExample {
    private static final double DISCOUNT_THRESHOLD = 100.0;
    private static final String CUSTOMER_SPENDING_STORE = &quot;customer-spending-store&quot;;
    private static final String DISCOUNT_NOTIFICATION_MESSAGE =
            &quot;Discount applied! You have received a reward for your purchases.&quot;;
    private static final String DISCOUNT_NOTIFICATIONS_TOPIC = &quot;discount-notifications-topic&quot;;
    private static final String PURCHASE_EVENTS_TOPIC = &quot;purchase-events-topic&quot;;

    public static void applyDiscountWithTransform(final StreamsBuilder builder) {
        // Define the state store for tracking cumulative spending
        builder.addStateStore(
                Stores.keyValueStoreBuilder(
                        Stores.inMemoryKeyValueStore(CUSTOMER_SPENDING_STORE),
                        Serdes.String(),
                        Serdes.Double()
                )
        );
        final KStream&lt;String, Double&gt; purchaseStream = builder.stream(PURCHASE_EVENTS_TOPIC);
        // Apply the Transformer with the state store
        final KStream&lt;String, String&gt; notificationStream =
                purchaseStream.transform(CumulativeDiscountTransformer::new, CUSTOMER_SPENDING_STORE);
        // Send the notifications to the output topic
        notificationStream.to(DISCOUNT_NOTIFICATIONS_TOPIC);
    }

    public static void applyDiscountWithProcess(final StreamsBuilder builder) {
        // Define the state store for tracking cumulative spending
        builder.addStateStore(
                Stores.keyValueStoreBuilder(
                        Stores.inMemoryKeyValueStore(CUSTOMER_SPENDING_STORE),
                        org.apache.kafka.common.serialization.Serdes.String(),
                        org.apache.kafka.common.serialization.Serdes.Double()
                )
        );
        final KStream&lt;String, Double&gt; purchaseStream = builder.stream(PURCHASE_EVENTS_TOPIC);
        // Apply the Processor with the state store
        final KStream&lt;String, String&gt; notificationStream =
                purchaseStream.process(CumulativeDiscountProcessor::new, CUSTOMER_SPENDING_STORE);
        // Send the notifications to the output topic
        notificationStream.to(DISCOUNT_NOTIFICATIONS_TOPIC);
    }

    private static class CumulativeDiscountTransformer implements Transformer&lt;String, Double, KeyValue&lt;String, String&gt;&gt; {
        private KeyValueStore&lt;String, Double&gt; spendingStore;

        @Override
        public void init(final org.apache.kafka.streams.processor.ProcessorContext context) {
            // Retrieve the state store for cumulative spending
            spendingStore = context.getStateStore(CUSTOMER_SPENDING_STORE);
        }

        @Override
        public KeyValue&lt;String, String&gt; transform(final String key, final Double value) {
            if (value == null) {
                return null; // Skip null purchase amounts
            }

            // Get the current spending total for the customer
            Double currentSpending = spendingStore.get(key);
            if (currentSpending == null) {
                currentSpending = 0.0;
            }
            // Update the cumulative spending
            currentSpending += value;
            spendingStore.put(key, currentSpending);

            // Check if the customer qualifies for a discount
            if (currentSpending &gt;= DISCOUNT_THRESHOLD) {
                // Reset the spending after applying the discount
                spendingStore.put(key, currentSpending - DISCOUNT_THRESHOLD);
                // Return a notification message
                return new KeyValue&lt;&gt;(key, DISCOUNT_NOTIFICATION_MESSAGE);
            }
            return null; // No discount, so no output for this record
        }

        @Override
        public void close() {
        }
    }

    private static class CumulativeDiscountProcessor implements Processor&lt;String, Double, String, String&gt; {
        private KeyValueStore&lt;String, Double&gt; spendingStore;
        private ProcessorContext&lt;String, String&gt; context;

        @Override
        public void init(final ProcessorContext&lt;String, String&gt; context) {
            this.context = context;
            // Retrieve the state store for cumulative spending
            spendingStore = context.getStateStore(CUSTOMER_SPENDING_STORE);
        }

        @Override
        public void process(final Record&lt;String, Double&gt; record) {
            if (record.value() == null) {
                return; // Skip null purchase amounts
            }

            // Get the current spending total for the customer
            Double currentSpending = spendingStore.get(record.key());
            if (currentSpending == null) {
                currentSpending = 0.0;
            }
            // Update the cumulative spending
            currentSpending += record.value();
            spendingStore.put(record.key(), currentSpending);

            // Check if the customer qualifies for a discount
            if (currentSpending &gt;= DISCOUNT_THRESHOLD) {
                // Reset the spending after applying the discount
                spendingStore.put(record.key(), currentSpending - DISCOUNT_THRESHOLD);
                // Send a discount notification
                context.forward(record.withValue(DISCOUNT_NOTIFICATION_MESSAGE));
            }
        }
    }
}</code></pre>
                <h5 id="traffic-radar-monitoring-car-count-removal">Traffic Radar Monitoring Car Count</h5>
                <p>Below, methods <code>countWithTransformValues</code> and <code>countWithProcessValues</code> show how you can migrate
                    from <code>transformValues</code> to <code>processValues</code>.</p>
                <pre class="line-numbers"><code class="language-java">public class TrafficRadarMonitoringCarCountExample {
    private static final String DAILY_COUNT_STORE = &quot;price-state-store&quot;;
    private static final String DAILY_COUNT_TOPIC = &quot;price-state-topic&quot;;
    private static final String RADAR_COUNT_TOPIC = &quot;car-radar-topic&quot;;

    public static void countWithTransformValues(final StreamsBuilder builder) {
        // Define a state store for tracking daily car counts
        builder.addStateStore(
                Stores.keyValueStoreBuilder(
                        Stores.inMemoryKeyValueStore(DAILY_COUNT_STORE),
                        org.apache.kafka.common.serialization.Serdes.String(),
                        org.apache.kafka.common.serialization.Serdes.Long()
                )
        );
        final KStream&lt;Void, String&gt; radarStream = builder.stream(RADAR_COUNT_TOPIC);
        // Apply the ValueTransformer with the state store
        radarStream.transformValues(DailyCarCountTransformer::new, DAILY_COUNT_STORE)
                .to(DAILY_COUNT_TOPIC);
    }

    public static void countWithProcessValues(final StreamsBuilder builder) {
        // Define a state store for tracking daily car counts
        builder.addStateStore(
                Stores.keyValueStoreBuilder(
                        Stores.inMemoryKeyValueStore(DAILY_COUNT_STORE),
                        org.apache.kafka.common.serialization.Serdes.String(),
                        org.apache.kafka.common.serialization.Serdes.Long()
                )
        );
        final KStream&lt;Void, String&gt; radarStream = builder.stream(RADAR_COUNT_TOPIC);
        // Apply the FixedKeyProcessor with the state store
        radarStream.processValues(DailyCarCountProcessor::new, DAILY_COUNT_STORE)
                .to(DAILY_COUNT_TOPIC);
    }

    private static class DailyCarCountTransformer implements ValueTransformerWithKey&lt;Void, String, String&gt; {
        private KeyValueStore&lt;String, Long&gt; stateStore;
        private static final DateTimeFormatter DATE_FORMATTER =
                DateTimeFormatter.ofPattern(&quot;yyyy-MM-dd&quot;).withZone(ZoneId.systemDefault());

        @Override
        public void init(final org.apache.kafka.streams.processor.ProcessorContext context) {
            // Access the state store
            stateStore = context.getStateStore(DAILY_COUNT_STORE);
        }

        @Override
        public String transform(Void readOnlyKey, String value) {
            if (value == null) {
                return null; // Skip null events
            }

            // Derive the current day from the event timestamp
            final long timestamp = System.currentTimeMillis(); // Use system time for simplicity
            final String currentDay = DATE_FORMATTER.format(Instant.ofEpochMilli(timestamp));
            // Retrieve the current count for the day
            Long dailyCount = stateStore.get(currentDay);
            if (dailyCount == null) {
                dailyCount = 0L;
            }
            // Increment the count
            dailyCount++;
            stateStore.put(currentDay, dailyCount);

            // Return the current day&#39;s count
            return String.format(&quot;Day: %s, Car Count: %s&quot;, currentDay, dailyCount);
        }

        @Override
        public void close() {
        }
    }

    private static class DailyCarCountProcessor implements FixedKeyProcessor&lt;Void, String, String&gt; {
        private FixedKeyProcessorContext&lt;Void, String&gt; context;
        private KeyValueStore&lt;String, Long&gt; stateStore;
        private static final DateTimeFormatter DATE_FORMATTER =
                DateTimeFormatter.ofPattern(&quot;yyyy-MM-dd&quot;).withZone(ZoneId.systemDefault());

        @Override
        public void init(final FixedKeyProcessorContext&lt;Void, String&gt; context) {
            this.context = context;
            stateStore = context.getStateStore(DAILY_COUNT_STORE);
        }

        @Override
        public void process(final FixedKeyRecord&lt;Void, String&gt; record) {
            if (record.value() == null) {
                return; // Skip null events
            }

            // Derive the current day from the event timestamp
            final long timestamp = System.currentTimeMillis(); // Use system time for simplicity
            final String currentDay = DATE_FORMATTER.format(Instant.ofEpochMilli(timestamp));
            // Retrieve the current count for the day
            Long dailyCount = stateStore.get(currentDay);
            if (dailyCount == null) {
                dailyCount = 0L;
            }
            // Increment the count
            dailyCount++;
            stateStore.put(currentDay, dailyCount);

            // Emit the current day&#39;s count
            context.forward(record.withValue(String.format(&quot;Day: %s, Car Count: %s&quot;, currentDay, dailyCount)));
        }
    }
}</code></pre>
                <h4>Keynotes</h4>
                <ul>
                    <li><strong>Type Safety and Flexibility:</strong> The process and processValues APIs utilize
                        <code>ProcessorContext</code> and <code>Record</code> or <code>FixedKeyRecord</code> objects for better type
                        safety and flexibility of custom processing logic.</li>
                    <li><strong>Clear State and Logic Management:</strong> Implementations for <code>Processor</code> or
                        <code>FixedKeyProcessor</code> should manage state and logic clearly. Use <code>context().forward()</code>
                        for emitting records downstream.</li>
                    <li><strong>Unified API:</strong> Consolidates multiple methods into a single, versatile API.</li>
                    <li><strong>Future-Proof:</strong> Ensures compatibility with the latest Kafka Streams releases.</li>
                </ul>
                <h4>Removal of Old <code>process</code> Method</h4>
                <p>It is worth mentioning that, in addition to the methods mentioned above, the <code>process</code> method, which
                    integrated the &#39;old&#39; Processor API (i.e., <code>Processor</code> as opposed to the new
                    <code>api.Processor</code>) into the DSL, has also been removed. The following example shows how to migrate to the
                    new <code>process</code>.
                </p>
                <h5>Example</h5>
                <ul>
                    <li>
                        <p><strong>Idea:</strong> The system monitors page views for a website in real-time. When a page reaches a
                            predefined popularity threshold (e.g., 1000 views), the system automatically sends an email alert to the
                            site administrator or marketing team to notify them of the page&#39;s success. This helps teams quickly
                            identify high-performing content and act on it, such as promoting the page further or analyzing the
                            traffic source.</p>
                    </li>
                    <li>
                        <p><strong>Real-World Context:</strong> In a content management system (CMS) for a news or blogging platform,
                            it&#39;s crucial to track the popularity of articles or posts. For example:</p>
                        <ul>
                            <li><strong>Marketing Teams:</strong> Use the notification to highlight trending content on social media or
                                email newsletters.</li>
                            <li><strong>Operations Teams:</strong> Use the alert to ensure the site can handle increased traffic for
                                popular pages.</li>
                            <li><strong>Ad Managers:</strong> Identify pages where additional ad placements might maximize revenue.</li>
                        </ul>
                        <p>By automating the detection of popular pages, the system eliminates the need for manual monitoring and
                            ensures timely actions to capitalize on the content&#39;s performance.</p>
                    </li>
                </ul>
                <pre class="line-numbers"><code class="language-java">public class PopularPageEmailAlertExample {
    private static final String ALERTS_EMAIL = &quot;alerts@yourcompany.com&quot;;
    private static final String PAGE_VIEWS_TOPIC = &quot;page-views-topic&quot;;

    public static void alertWithOldProcess(StreamsBuilder builder) {
        KStream&lt;String, Long&gt; pageViews = builder.stream(PAGE_VIEWS_TOPIC);
        // Filter pages with exactly 1000 views and process them using the old API
        pageViews.filter((pageId, viewCount) -&gt; viewCount == 1000)
                .process(PopularPageEmailAlertOld::new);
    }

    public static void alertWithNewProcess(StreamsBuilder builder) {
        KStream&lt;String, Long&gt; pageViews = builder.stream(PAGE_VIEWS_TOPIC);
        // Filter pages with exactly 1000 views and process them using the new API
        pageViews.filter((pageId, viewCount) -&gt; viewCount == 1000)
                .process(PopularPageEmailAlertNew::new);
    }

    private static class PopularPageEmailAlertOld extends AbstractProcessor&lt;String, Long&gt; {
        @Override
        public void init(org.apache.kafka.streams.processor.ProcessorContext context) {
            super.init(context);
            System.out.println(&quot;Initialized email client for: &quot; + ALERTS_EMAIL);
        }

        @Override
        public void process(String key, Long value) {
            if (value == null) return;

            if (value == 1000) {
                // Send an email alert
                System.out.printf(&quot;ALERT (Old API): Page %s has reached 1000 views. Sending email to %s%n&quot;, key, ALERTS_EMAIL);
            }
        }

        @Override
        public void close() {
            System.out.println(&quot;Tearing down email client for: &quot; + ALERTS_EMAIL);
        }
    }

    private static class PopularPageEmailAlertNew implements Processor&lt;String, Long, Void, Void&gt; {
        @Override
        public void init(ProcessorContext&lt;Void, Void&gt; context) {
            System.out.println(&quot;Initialized email client for: &quot; + ALERTS_EMAIL);
        }

        @Override
        public void process(Record&lt;String, Long&gt; record) {
            if (record.value() == null) return;

            if (record.value() == 1000) {
                // Send an email alert
                System.out.printf(&quot;ALERT (New API): Page %s has reached 1000 views. Sending email to %s%n&quot;, record.key(), ALERTS_EMAIL);
            }
        }

        @Override
        public void close() {
            System.out.println(&quot;Tearing down email client for: &quot; + ALERTS_EMAIL);
        }
    }
}</code></pre>
            </div>
        <div class="section" id="naming-a-streams-app">
            <a class="headerlink" href="#naming-a-streams-app" title="Permalink to this headline"><h2><a class="toc-backref" href="#id33">Naming Operators in a Streams DSL application</a></h2></a>
            Kafka Streams allows you to <a class="reference internal" href="dsl-topology-naming.html">name processors</a> created via the Streams DSL
        </div>
	<div class="section" id="controlling-emit-rate">
            <span id="streams-developer-guide-dsl-suppression"></span><h2><a class="toc-backref" href="#id32">Controlling KTable emit rate</a><a class="headerlink" href="#controlling-emit-rate" title="Permalink to this headline"></a></h2>
	    <p>A KTable is logically a continuously updated table.
	       These updates make their way to downstream operators whenever new data is available, ensuring that the whole computation is as fresh as possible.
	       Logically speaking, most programs describe a series of transformations, and the update rate is not a factor in the program behavior.
	       In these cases, the rate of update is more of a performance concern.
	       Operators are able to optimize both the network traffic (to the Kafka brokers) and the disk traffic (to the local state stores) by adjusting
	       commit interval and batch size configurations.
	    </p>
	    <p>However, some applications need to take other actions, such as calling out to external systems,
	       and therefore need to exercise some control over the rate of invocations, for example of <code>KStream#foreach</code>.
	    </p>
	    <p>Rather than achieving this as a side-effect of the  <a class="reference internal" href="memory-mgmt.html#streams-developer-guide-memory-management-record-cache"><span class="std std-ref">KTable record cache</span></a>,
	       you can directly impose a rate limit via the <code>KTable#suppress</code> operator.
	    </p>
	    <p>For example:
	    </p>
        <pre class="line-numbers"><code class="language-java">KGroupedTable&lt;String, String&gt; groupedTable = ...;
groupedTable
    .count()
    .suppress(untilTimeLimit(ofMinutes(5), maxBytes(1_000_000L).emitEarlyWhenFull()))
    .toStream()
    .foreach((key, count) -&gt; updateCountsDatabase(key, count));</code></pre>
	    </div></div>
	    <p>This configuration ensures that <code>updateCountsDatabase</code> gets events for each <code>key</code> no more than once every 5 minutes.
	       Note that the latest state for each key has to be buffered in memory for that 5-minute period.
	       You have the option to control the maximum amount of memory to use for this buffer (in this case, 1MB).
	       There is also an option to impose a limit in terms of number of records (or to leave both limits unspecified).
	    </p>
	    <p>Additionally, it is possible to choose what happens if the buffer fills up.
	       This example takes a relaxed approach and just emits the oldest records before their 5-minute time limit to bring the buffer back down to size.
	       Alternatively, you can choose to stop processing and shut the application down.
	       This may seem extreme, but it gives you a guarantee that the 5-minute time limit will be absolutely enforced.
	       After the application shuts down, you could allocate more memory for the buffer and resume processing.
	       Emitting early is preferable for most applications.
	    </p>
	    <p>For more detailed information, see the JavaDoc on the <code>Suppressed</code> config object
	       and <a href="https://cwiki.apache.org/confluence/x/sQU0BQ" title="KIP-328">KIP-328</a>.
	    </p>
	</div>
    <div class="section" id="versioned-state-stores">
        <h2><a class="headerlink" href="#versioned-state-stores" title="Permalink to this headline">Using timestamp-based semantics for table processors</a></h2>
        <p>By default, tables in Kafka Streams use offset-based semantics. When multiple records arrive for the same key, the one with the largest record offset
            is considered the latest record for the key, and is the record that appears in aggregation and join results computed on the table. This is true even
            in the event of <a href="/{{version}}/documentation/streams/core-concepts.html#streams_out_of_ordering">out-of-order data</a>. The record with the
            largest offset is considered to be the latest record for the key, even if this record does not have the largest timestamp.</p>
        <p>An alternative to offset-based semantics is timestamp-based semantics. With timestamp-based semantics, the record with the largest timestamp is
            considered the latest record, even if there is another record with a larger offset (and smaller timestamp). If there is no out-of-order data (per key),
            then offset-based semantics and timestamp-based semantics are equivalent; the difference only appears when there is out-of-order data.</p>
        <p>Starting with Kafka Streams 3.5, Kafka Streams supports timestamp-based semantics through the use of
            <a href="/{{version}}/documentation/streams/developer-guide/processor-api.html#versioned-state-stores">versioned state stores</a>.
            When a table is materialized with a versioned state store, it is a versioned table and will result in different processor semantics in the presence of
            out-of-order data.</p>
        <ul class="simple">
            <li>When performing a stream-table join, stream-side records will join with the latest-by-timestamp table record which has a timestamp less than or equal to
                the stream record's timestamp. This is in contrast to joining a stream to an unversioned table, in which case the latest-by-offset table record will
                be joined, even if the stream-side record is out-of-order and has a lower timestamp.</li>
            <li>Aggregations computed on the table will include the latest-by-timestamp record for each key, instead of the latest-by-offset record. Out-of-order
                updates (per key) will not trigger a new aggregation result. This is true for <code class="docutils literal"><span class="pre">count</span></code>
                and <code class="docutils literal"><span class="pre">reduce</span></code> operations as well, in addition to
                <code class="docutils literal"><span class="pre">aggregate</span></code> operations.</li>
            <li>Table joins will use the latest-by-timestamp record for each key, instead of the latest-by-offset record. Out-of-order updates (per key) will not
                trigger a new join result. This is true for both primary-key table-table joins and also foreign-key table-table joins. If a
                versioned table is joined with an unversioned table, the result will be the join of the latest-by-timestamp record from the versioned table with
                the latest-by-offset record from the unversioned table.</li>
            <li>Table filter operations will no longer suppress consecutive tombstones, so users may observe more <code class="docutils literal"><span class="pre">null</span></code>
                records downstream of the filter than compared to when filtering an unversioned table. This is done in order to preserve a complete version history downstream,
                in the event of out-of-order data.</li>
            <li><code class="docutils literal"><span class="pre">suppress</span></code> operations are not allowed on versioned tables, as this would collapse the version history
                and lead to undefined behavior.</li>
        </ul>
        <p>Once a table is materialized with a versioned store, downstream tables are also considered versioned until any of the following occurs:</p>
        <ul class="simple">
            <li>A downstream table is explicitly materialized, either with an unversioned store supplier or with no store supplier (all stores are unversioned by default, including the default store supplier)</li>
            <li>Any stateful transformation occurs, including aggregations and joins</li>
            <li>A table is converted to a stream and back.</li>
        </ul>
        <p>The results of certain processors should not be materialized with versioned stores, as these processors do not produce a complete older version history,
            and therefore materialization as a versioned table would lead to unpredictable results:</p>
        <ul class="simple">
            <li>Aggregate processors, for both table and stream aggregations. This includes <code class="docutils literal"><span class="pre">aggregate</span></code>,
                <code class="docutils literal"><span class="pre">count</span></code> and <code class="docutils literal"><span class="pre">reduce</span></code> operations.</li>
            <li>Table-table join processors, including both primary-key and foreign-key joins.</li>
        </ul>
        <p>For more on versioned stores and how to start using them in your application, see <a href="/{{version}}/documentation/streams/developer-guide/processor-api.html#versioned-state-stores">here</a>.</p>
    </div>
        <div class="section" id="writing-streams-back-to-kafka">
            <span id="streams-developer-guide-dsl-destinations"></span><h2><a class="toc-backref" href="#id25">Writing streams back to Kafka</a><a class="headerlink" href="#writing-streams-back-to-kafka" title="Permalink to this headline"></a></h2>
            <p>Any streams and tables may be (continuously) written back to a Kafka topic.  As we will describe in more detail below, the output data might be
                re-partitioned on its way to Kafka, depending on the situation.</p>
            <table border="1" class="non-scrolling-table width-100-percent docutils">
                <colgroup>
                    <col width="22%" />
                    <col width="78%" />
                </colgroup>
                <thead valign="bottom">
                <tr class="row-odd"><th class="head">Writing to Kafka</th>
                    <th class="head">Description</th>
                </tr>
                </thead>
                <tbody valign="top">
                <tr class="row-even"><td><p class="first"><strong>To</strong></p>
                    <ul class="last simple">
                        <li>KStream -&gt; void</li>
                    </ul>
                </td>
                    <td><p class="first"><strong>Terminal operation.</strong>  Write the records to Kafka topic(s).
                        (<a class="reference external" href="/{{version}}/javadoc/org/apache/kafka/streams/kstream/KStream.html#to(java.lang.String)">KStream details</a>)</p>
                        <p>When to provide serdes explicitly:</p>
                        <ul class="simple">
                            <li>If you do not specify Serdes explicitly, the default Serdes from the
                                <a class="reference internal" href="config-streams.html#streams-developer-guide-configuration"><span class="std std-ref">configuration</span></a> are used.</li>
                            <li>You <strong>must specify Serdes explicitly</strong> via the <code class="docutils literal"><span class="pre">Produced</span></code> class if the key and/or value types of the
                                <code class="docutils literal"><span class="pre">KStream</span></code> do not match the configured default Serdes.</li>
                            <li>See <a class="reference internal" href="datatypes.html#streams-developer-guide-serdes"><span class="std std-ref">Data Types and Serialization</span></a> for information about configuring default Serdes, available Serdes,
                                and implementing your own custom Serdes.</li>
                        </ul>
                        <p>A variant of <code class="docutils literal"><span class="pre">to</span></code> exists that enables you to specify how the data is produced by using a <code class="docutils literal"><span class="pre">Produced</span></code>
                            instance to specify, for example, a <code class="docutils literal"><span class="pre">StreamPartitioner</span></code> that gives you control over
                            how output records are distributed across the partitions of the output topic.</p>
                        <p>Another variant of <code class="docutils literal"><span class="pre">to</span></code> exists that enables you to dynamically choose which topic to send to for each record via a <code class="docutils literal"><span class="pre">TopicNameExtractor</span></code>
                            instance.</p>
                        <pre class="line-numbers"><code class="language-java">KStream&lt;String, Long&gt; stream = ...;

// Write the stream to the output topic, using the configured default key
// and value serdes.
stream.to(&quot;my-stream-output-topic&quot;);

// Write the stream to the output topic, using explicit key and value serdes,
// (thus overriding the defaults in the config properties).
stream.to(&quot;my-stream-output-topic&quot;, Produced.with(Serdes.String(), Serdes.Long());</code></pre>
                        <p><strong>Causes data re-partitioning if any of the following conditions is true:</strong></p>
                        <ol class="last arabic simple">
                            <li>If the output topic has a different number of partitions than the stream/table.</li>
                            <li>If the <code class="docutils literal"><span class="pre">KStream</span></code> was marked for re-partitioning.</li>
                            <li>If you provide a custom <code class="docutils literal"><span class="pre">StreamPartitioner</span></code> to explicitly control how to distribute the output records
                                across the partitions of the output topic.</li>
                            <li>If the key of an output record is <code class="docutils literal"><span class="pre">null</span></code>.</li>
                        </ol>
                    </td>
                </tr>
                </tbody>
            </table>
            <div class="admonition note">
                <p><b>Note</b></p>
                <p class="last"><strong>When you want to write to systems other than Kafka:</strong>
                    Besides writing the data back to Kafka, you can also apply a
                    <a class="reference internal" href="#streams-developer-guide-dsl-process"><span class="std std-ref">custom processor</span></a> as a stream sink at the end of the processing to, for
                    example, write to external databases.  First, doing so is not a recommended pattern &#8211; we strongly suggest to use the
                    <a class="reference internal" href="../../connect/index.html#kafka-connect"><span class="std std-ref">Kafka Connect API</span></a> instead.  However, if you do use such a sink processor, please be aware that
                    it is now your responsibility to guarantee message delivery semantics when talking to such external systems (e.g., to
                    retry on delivery failure or to prevent message duplication).</p>
            </div>
        </div>
        <div class="section" id="testing-a-streams-app">
            <h2><a class="headerlink" href="#testing-a-streams-app" title="Permalink to this headline">Testing a Streams application</a></h2>
            Kafka Streams comes with a <code>test-utils</code> module to help you test your application <a href="testing.html">here</a>.
            </div>
        </div>
        <div class="section" id="scala-dsl">
            <span id="streams-developer-guide-dsl-scala-dsl"></span><h2><a class="toc-backref" href="#id27">Kafka Streams DSL for Scala</a><a class="headerlink" href="#scala-dsl" title="Permalink to this headline"></a></h2>
            <p id="scala-dsl-motivation">The Kafka Streams DSL Java APIs are based on the Builder design pattern, which allows users to incrementally build the target functionality using lower level compositional fluent APIs.  These APIs can be called from Scala, but there are several issues:</p>
            <ol class="last arabic simple">
              <li><strong>Additional type annotations</strong> - The Java APIs use Java generics in a way that are not fully compatible with the type inferencer of the Scala compiler. Hence the user has to add type annotations to the Scala code, which seems rather non-idiomatic in Scala.</li>
              <li><strong>Verbosity</strong> - In some cases the Java APIs appear too verbose compared to idiomatic Scala.</li>
              <li><strong>Type Unsafety</strong> - The Java APIs offer some options where the compile time type safety is sometimes subverted and can result in runtime errors. This stems from the fact that the Serdes defined as part of config are not type checked during compile time. Hence any missing Serdes can result in runtime errors.</li>
            </ol>
            <p id="scala-dsl-overview">The Kafka Streams DSL for Scala library is a wrapper over the existing Java APIs for Kafka Streams DSL that addresses the concerns raised above.
              It does not attempt to provide idiomatic Scala APIs that one would implement in a Scala library developed from scratch. The intention is to make the Java APIs more usable in Scala through better type inferencing, enhanced expressiveness, and lesser boilerplates.
            </p>
            <p>The library wraps Java Stream DSL APIs in Scala thereby providing:</p>
            <ol class="last arabic simple">
              <li>Better type inference in Scala.</li>
              <li>Less boilerplate in application code.</li>
              <li>The usual builder-style composition that developers get with the original Java API.</li>
              <li>Implicit serializers and de-serializers leading to better abstraction and less verbosity.</li>
              <li>Better type safety during compile time.</li>
            </ol>
            <p>All functionality provided by Kafka Streams DSL for Scala are under the root package name of <code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala</span></code>.</p>
            <p>Many of the public facing types from the Java API are wrapped. The following Scala abstractions are available to the user:</p>
            <ul>
              <li><code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.StreamsBuilder</span></code></li>
              <li><code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.kstream.KStream</span></code></li>
              <li><code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.kstream.KTable</span></code></li>
              <li><code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.kstream.KGroupedStream</span></code></li>
              <li><code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.kstream.KGroupedTable</span></code></li>
              <li><code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.kstream.SessionWindowedKStream</span></code></li>
              <li><code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.kstream.TimeWindowedKStream</span></code></li>
            </ul>
            <p>The library also has several utility abstractions and modules that the user needs to use for proper semantics.</p>
            <ul>
              <li><code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.ImplicitConversions</span></code>: Module that brings into scope the implicit conversions between the Scala and Java classes.</li>
              <li><code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.serialization.Serdes</span></code>: Module that contains all primitive Serdes that can be imported as implicits and a helper to create custom Serdes.</li>
            </ul>
            <p>The library is cross-built with Scala 2.12 and 2.13. To reference the library compiled against Scala {{scalaVersion}} include the following in your maven <code>pom.xml</code> add the following:</p>
            <pre class="line-numbers"><code class="language-xml">&lt;dependency&gt;
  &lt;groupId&gt;org.apache.kafka&lt;/groupId&gt;
  &lt;artifactId&gt;kafka-streams-scala_{{scalaVersion}}&lt;/artifactId&gt;
  &lt;version&gt;{{fullDotVersion}}&lt;/version&gt;
&lt;/dependency&gt;</code></pre>
            <p>To use the library compiled against Scala 2.12 replace the <code class="docutils literal"><span class="pre">artifactId</span></code> with <code class="docutils literal"><span class="pre">kafka-streams-scala_2.12</span></code>.</p>
            <p>When using SBT then you can reference the correct library using the following:</p>
            <pre class="line-numbers"><code class="language-scala">libraryDependencies += "org.apache.kafka" %% "kafka-streams-scala" % "{{fullDotVersion}}"</code></pre>
            <div class="section" id="scala-dsl-sample-usage">
              <span id="streams-developer-guide-dsl-sample-usage"></span><h3><a class="toc-backref" href="#id28">Sample Usage</a><a class="headerlink" href="#scala-dsl-sample-usage" title="Permalink to this headline"></a></h3>
              <p>The library works by wrapping the original Java abstractions of Kafka Streams within a Scala wrapper object and then using implicit conversions between them. All the Scala abstractions are named identically as the corresponding Java abstraction, but they reside in a different package of the library e.g. the Scala class <code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.StreamsBuilder</span></code> is a wrapper around <code class="docutils literal"><span class="pre">org.apache.kafka.streams.StreamsBuilder</span></code>, <code class="docutils literal"><span class="pre">org.apache.kafka.streams.scala.kstream.KStream</span></code> is a wrapper around <code class="docutils literal"><span class="pre">org.apache.kafka.streams.kstream.KStream</span></code>, and so on.</p>
              <p>Here's an example of the classic WordCount program that uses the Scala <code class="docutils literal"><span class="pre">StreamsBuilder</span></code> that builds an instance of <code class="docutils literal"><span class="pre">KStream</span></code> which is a wrapper around Java <code class="docutils literal"><span class="pre">KStream</span></code>. Then we reify to a table and get a <code class="docutils literal"><span class="pre">KTable</span></code>, which, again is a wrapper around Java <code class="docutils literal"><span class="pre">KTable</span></code>.</p>
              <p>The net result is that the following code is structured just like using the Java API, but with Scala and with far fewer type annotations compared to using the Java API directly from Scala. The difference in type annotation usage is more obvious when given an example.  Below is an example WordCount implementation that will be used to demonstrate the differences between the Scala and Java API.</p>
              <pre class="line-numbers"><code class="language-scala">import java.time.Duration
import java.util.Properties

import org.apache.kafka.streams.kstream.Materialized
import org.apache.kafka.streams.scala.ImplicitConversions._
import org.apache.kafka.streams.scala._
import org.apache.kafka.streams.scala.kstream._
import org.apache.kafka.streams.{KafkaStreams, StreamsConfig}

object WordCountApplication extends App {
  import Serdes._

  val props: Properties = {
    val p = new Properties()
    p.put(StreamsConfig.APPLICATION_ID_CONFIG, "wordcount-application")
    p.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "kafka-broker1:9092")
    p
  }

  val builder: StreamsBuilder = new StreamsBuilder
  val textLines: KStream[String, String] = builder.stream[String, String]("TextLinesTopic")
  val wordCounts: KTable[String, Long] = textLines
    .flatMapValues(textLine => textLine.toLowerCase.split("\\W+"))
    .groupBy((_, word) => word)
    .count(Materialized.as("counts-store"))
  wordCounts.toStream.to("WordsWithCountsTopic")

  val streams: KafkaStreams = new KafkaStreams(builder.build(), props)
  streams.start()

  sys.ShutdownHookThread {
     streams.close(Duration.ofSeconds(10))
  }
}</code></pre>
              <p>In the above code snippet, we don't have to provide any Serdes, <code class="docutils literal"><span class="pre">Grouped</span></code>, <code class="docutils literal"><span class="pre">Produced</span></code>, <code class="docutils literal"><span class="pre">Consumed</span></code> or <code class="docutils literal"><span class="pre">Joined</span></code> explicitly. They will also not be dependent on any Serdes specified in the config.  <strong>In fact all Serdes specified in the config will be ignored by the Scala APIs</strong>. All Serdes and <code class="docutils literal"><span class="pre">Grouped</span></code>, <code class="docutils literal"><span class="pre">Produced</span></code>, <code class="docutils literal"><span class="pre">Consumed</span></code> or <code class="docutils literal"><span class="pre">Joined</span></code> will be handled through implicit Serdes as discussed later in the <a href="#scala-dsl-implicit-serdes">Implicit Serdes</a> section. The complete independence from configuration based Serdes is what makes this library completely typesafe.  Any missing instances of Serdes, <code class="docutils literal"><span class="pre">Grouped</span></code>, <code class="docutils literal"><span class="pre">Produced</span></code>, <code class="docutils literal"><span class="pre">Consumed</span></code> or <code class="docutils literal"><span class="pre">Joined</span></code> will be flagged as a compile time error.</p>
            </div>
            <div class="section" id="scala-dsl-implicit-serdes">
              <span id="streams-developer-guide-dsl-scala-dsl-implicit-serdes"></span><h3><a class="toc-backref" href="#id29">Implicit Serdes</a><a class="headerlink" href="#scala-dsl-implicit-serdes" title="Permalink to this headline"></a></h3>
              <p>One of the common complaints of Scala users with the Java API has been the repetitive usage of the Serdes in API invocations. Many of the APIs need to take the Serdes through abstractions like <code class="docutils literal"><span class="pre">Grouped</span></code>, <code class="docutils literal"><span class="pre">Produced</span></code>, <code class="docutils literal"><span class="pre">Repartitioned</span></code>, <code class="docutils literal"><span class="pre">Consumed</span></code> or <code class="docutils literal"><span class="pre">Joined</span></code>. And the user has to supply them every time through the with function of these classes.</p>
              <p>The library uses the power of <a href="https://docs.scala-lang.org/tour/implicit-parameters.html">Scala implicit parameters</a> to alleviate this concern. As a user you can provide implicit Serdes or implicit values of <code class="docutils literal"><span class="pre">Grouped</span></code>, <code class="docutils literal"><span class="pre">Produced</span></code>, <code class="docutils literal"><span class="pre">Repartitioned</span></code>, <code class="docutils literal"><span class="pre">Consumed</span></code> or <code class="docutils literal"><span class="pre">Joined</span></code> once and make your code less verbose. In fact you can just have the implicit Serdes in scope and the library will make the instances of <code class="docutils literal"><span class="pre">Grouped</span></code>, <code class="docutils literal"><span class="pre">Produced</span></code>, <code class="docutils literal"><span class="pre">Consumed</span></code> or <code class="docutils literal"><span class="pre">Joined</span></code> available in scope.</p>
              <p>The library also bundles all implicit Serdes of the commonly used primitive types in a Scala module - so just import the module vals and have all Serdes in scope.  A similar strategy of modular implicits can be adopted for any user-defined Serdes as well (User-defined Serdes are discussed in the next section).</p>
              <p>Here's an example:</p>
              <pre class="line-numbers"><code class="language-scala">// DefaultSerdes brings into scope implicit Serdes (mostly for primitives)
// that will set up all Grouped, Produced, Consumed and Joined instances.
// So all APIs below that accept Grouped, Produced, Consumed or Joined will
// get these instances automatically
import Serdes._

val builder = new StreamsBuilder()

val userClicksStream: KStream[String, Long] = builder.stream(userClicksTopic)

val userRegionsTable: KTable[String, String] = builder.table(userRegionsTopic)

// The following code fragment does not have a single instance of Grouped,
// Produced, Consumed or Joined supplied explicitly.
// All of them are taken care of by the implicit Serdes imported by DefaultSerdes
val clicksPerRegion: KTable[String, Long] =
  userClicksStream
    .leftJoin(userRegionsTable)((clicks, region) => (if (region == null) "UNKNOWN" else region, clicks))
    .map((_, regionWithClicks) => regionWithClicks)
    .groupByKey
    .reduce(_ + _)

clicksPerRegion.toStream.to(outputTopic)</code></pre>
              <p>Quite a few things are going on in the above code snippet that may warrant a few lines of elaboration:</p>
              <ol>
                <li>The code snippet does not depend on any config defined Serdes. In fact any Serdes defined as part of the config will be ignored.</li>
                <li>All Serdes are picked up from the implicits in scope. And <code class="docutils literal"><span class="pre">import Serdes._</span></code> brings all necessary Serdes in scope.</li>
                <li>This is an example of compile time type safety that we don't have in the Java APIs.</li>
                <li>The code looks less verbose and more focused towards the actual transformation that it does on the data stream.</li>
              </ol>
            </div>
            <div class="section" id="scala-dsl-user-defined-serdes">
              <span id="streams-developer-guide-dsl-scala-dsl-user-defined-serdes"></span><h3><a class="toc-backref" href="#id30">User-Defined Serdes</a><a class="headerlink" href="#scala-dsl-user-defined-serdes" title="Permalink to this headline"></a></h3>
              <p>When the default primitive Serdes are not enough and we need to define custom Serdes, the usage is exactly the same as above. Just define the implicit Serdes and start building the stream transformation. Here's an example with <code class="docutils literal"><span class="pre">AvroSerde</span></code>:</p>
              <pre class="line-numbers"><code class="language-scala">// domain object as a case class
case class UserClicks(clicks: Long)

// An implicit Serde implementation for the values we want to
// serialize as avro
implicit val userClicksSerde: Serde[UserClicks] = new AvroSerde

// Primitive Serdes
import Serdes._

// And then business as usual ..

val userClicksStream: KStream[String, UserClicks] = builder.stream(userClicksTopic)

val userRegionsTable: KTable[String, String] = builder.table(userRegionsTopic)

// Compute the total per region by summing the individual click counts per region.
val clicksPerRegion: KTable[String, Long] =
 userClicksStream

   // Join the stream against the table.
   .leftJoin(userRegionsTable)((clicks, region) => (if (region == null) "UNKNOWN" else region, clicks.clicks))

   // Change the stream from &lt;user&gt; -&gt; &lt;region, clicks&gt; to &lt;region&gt; -&gt; &lt;clicks&gt;
   .map((_, regionWithClicks) => regionWithClicks)

   // Compute the total per region by summing the individual click counts per region.
   .groupByKey
   .reduce(_ + _)

// Write the (continuously updating) results to the output topic.
clicksPerRegion.toStream.to(outputTopic)</code></pre>
              <p>A complete example of user-defined Serdes can be found in a test class within the library.</p>
            </div>
        </div>
</div>


               </div>
              </div>
  <div class="pagination">
    <a href="/{{version}}/documentation/streams/developer-guide/config-streams" class="pagination__btn pagination__btn__prev">Previous</a>
    <a href="/{{version}}/documentation/streams/developer-guide/processor-api" class="pagination__btn pagination__btn__next">Next</a>
  </div>
</script>

<!--#include virtual="../../../includes/_header.htm" -->
<!--#include virtual="../../../includes/_top.htm" -->
<div class="content documentation ">
  <!--#include virtual="../../../includes/_nav.htm" -->
  <div class="right">
    <!--//#include virtual="../../../includes/_docs_banner.htm" -->
    <ul class="breadcrumbs">
      <li><a href="/documentation">Documentation</a></li>
      <li><a href="/documentation/streams">Kafka Streams</a></li>
      <li><a href="/documentation/streams/developer-guide/">Developer Guide</a></li>
    </ul>
    <div class="p-content"></div>
  </div>
</div>
<!--#include virtual="../../../includes/_footer.htm" -->
<script>
    $(function() {
        // Show selected style on nav item
        $('.b-nav__streams').addClass('selected');

        //sticky secondary nav
        var $navbar = $(".sub-nav-sticky"),
            y_pos = $navbar.offset().top,
            height = $navbar.height();

        $(window).scroll(function() {
            var scrollTop = $(window).scrollTop();

            if (scrollTop > y_pos - height) {
                $navbar.addClass("navbar-fixed")
            } else if (scrollTop <= y_pos) {
                $navbar.removeClass("navbar-fixed")
            }
        });

        // Display docs subnav items
        $('.b-nav__docs').parent().toggleClass('nav__item__with__subs--expanded');
    });
</script>