%md
# [SDS-2.x, Scalable Data Engineering Science](https://lamastex.github.io/scalable-data-science/sds/2/x/)

%md
# Structured Streaming - A Programming Guide Walkthrough

-   [Overview](https://spark.apache.org/docs/2.2.0/index.html)
-   [Programming Guides](structured-streaming-programming-guide.html#)
   

-   [Overview](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#overview)
-   [Quick
    Example](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#quick-example)
-   [Programming
    Model](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#programming-model)
    -   [Basic
        Concepts](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#basic-concepts)
    -   [Handling Event-time and Late
        Data](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#handling-event-time-and-late-data)
    -   [Fault Tolerance
        Semantics](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#fault-tolerance-semantics)
-   [API using Datasets and
    DataFrames](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#api-using-datasets-and-dataframes)
    -   [Creating streaming DataFrames and streaming
        Datasets](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#creating-streaming-dataframes-and-streaming-datasets)
        -   [Input
            Sources](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#input-sources)
        -   [Schema inference and partition of streaming
            DataFrames/Datasets](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#schema-inference-and-partition-of-streaming-dataframesdatasets)
    -   [Operations on streaming
        DataFrames/Datasets](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#operations-on-streaming-dataframesdatasets)
        -   [Basic Operations - Selection, Projection,
            Aggregation](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#basic-operations---selection-projection-aggregation)
        -   [Window Operations on Event
            Time](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#window-operations-on-event-time)
        -   [Handling Late Data and
            Watermarking](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#handling-late-data-and-watermarking)
        -   [Join
            Operations](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#join-operations)
        -   [Streaming
            Deduplication](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#streaming-deduplication)
        -   [Arbitrary Stateful
            Operations](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#arbitrary-stateful-operations)
        -   [Unsupported
            Operations](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#unsupported-operations)
    -   [Starting Streaming
        Queries](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#starting-streaming-queries)
        -   [Output
            Modes](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#output-modes)
        -   [Output
            Sinks](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#output-sinks)
        -   [Using
            Foreach](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#using-foreach)
    -   [Managing Streaming
        Queries](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#managing-streaming-queries)
    -   [Monitoring Streaming
        Queries](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#monitoring-streaming-queries)
        -   [Interactive
            APIs](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#interactive-apis)
        -   [Asynchronous
            API](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#asynchronous-api)
    -   [Recovering from Failures with
        Checkpointing](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#recovering-from-failures-with-checkpointing)
-   [Where to go from
    here](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#where-to-go-from-here)
    - [https://databricks.com/blog/2017/08/24/anthology-of-technical-assets-on-apache-sparks-structured-streaming.html](https://databricks.com/blog/2017/08/24/anthology-of-technical-assets-on-apache-sparks-structured-streaming.html)
    - An authoritative resource: [https://www.gitbook.com/book/jaceklaskowski/spark-structured-streaming/details](https://www.gitbook.com/book/jaceklaskowski/spark-structured-streaming/details)

%md
Overview
========

Structured Streaming is a scalable and fault-tolerant stream processing
engine built on the Spark SQL engine. You can express your streaming
computation the same way you would express a batch computation on static
data. The Spark SQL engine will take care of running it incrementally
and continuously and updating the final result as streaming data
continues to arrive. You can use the [Dataset/DataFrame
API](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html) in
Scala, Java, Python or R to express streaming aggregations, event-time
windows, stream-to-batch joins, etc. The computation is executed on the
same optimized Spark SQL engine. Finally, the system ensures end-to-end
exactly-once fault-tolerance guarantees through checkpointing and Write
Ahead Logs. In short, *Structured Streaming provides fast, scalable,
fault-tolerant, end-to-end exactly-once stream processing without the
user having to reason about streaming.*

In this guide, we are going to walk you through the programming model
and the APIs. First, let’s start with a simple example - a streaming
word count.

%md
Programming Model
=================

The key idea in Structured Streaming is to treat a live data stream as a
table that is being continuously appended. This leads to a new stream
processing model that is very similar to a batch processing model. You
will express your streaming computation as standard batch-like query as
on a static table, and Spark runs it as an *incremental* query on the
*unbounded* input table. Let’s understand this model in more detail.

Basic Concepts
--------------

Consider the input data stream as the “Input Table”. Every data item
that is arriving on the stream is like a new row being appended to the
Input Table.

![Stream as a
Table](https://spark.apache.org/docs/2.2.0/img/structured-streaming-stream-as-a-table.png "Stream as a Table")

A query on the input will generate the “Result Table”. Every trigger
interval (say, every 1 second), new rows get appended to the Input
Table, which eventually updates the Result Table. Whenever the result
table gets updated, we would want to write the changed result rows to an
external sink.

![Model](https://spark.apache.org/docs/2.2.0/img/structured-streaming-model.png)

The “Output” is defined as what gets written out to the external
storage. The output can be defined in a different mode:

-   *Complete Mode* - The entire updated Result Table will be written to
    the external storage. It is up to the storage connector to decide
    how to handle writing of the entire table.

-   *Append Mode* - Only the new rows appended in the Result Table since
    the last trigger will be written to the external storage. This is
    applicable only on the queries where existing rows in the Result
    Table are not expected to change.

-   *Update Mode* - Only the rows that were updated in the Result Table
    since the last trigger will be written to the external storage
    (available since Spark 2.1.1). Note that this is different from the
    Complete Mode in that this mode only outputs the rows that have
    changed since the last trigger. If the query doesn’t contain
    aggregations, it will be equivalent to Append mode.

Note that each mode is applicable on certain types of queries. This is
discussed in detail later on *output-modes*.
To illustrate the use of this model, let’s understand the model in
context of the **Quick Example** above. 

The first `streamingLines` DataFrame is the input table, and the final
`wordCounts` DataFrame is the result table. Note that the query on
`streamingLines` DataFrame to generate `wordCounts` is *exactly the
same* as it would be a static DataFrame. However, when this query is
started, Spark will continuously check for new data from the directory. 
If there is new data, Spark will run an “incremental” query
that combines the previous running counts with the new data to compute
updated counts, as shown below.

![Model](https://spark.apache.org/docs/2.2.0/img/structured-streaming-example-model.png)

This model is significantly different from many other stream processing
engines. Many streaming systems require the user to maintain running
aggregations themselves, thus having to reason about fault-tolerance,
and data consistency (at-least-once, or at-most-once, or exactly-once).
In this model, Spark is responsible for updating the Result Table when
there is new data, thus relieving the users from reasoning about it. As
an example, let’s see how this model handles event-time based processing
and late arriving data.

%md
Quick Example
=============

Let’s say you want to maintain a running word count of text data
received from a file writer that is writing files into a directory 
`datasets/streamingFiles` in the distributed file  system. Let’s see how you
can express this using Structured Streaming. 

Let’s walk through the
example step-by-step and understand how it works. 

**First** we need to start a file writing job in the companion notebook `037a_AnimalNamesStructStreamingFiles` and then return here.

%md
Next, let’s create a streaming DataFrame that represents text data
received from the directory, and transform the
DataFrame to calculate word counts.

%md
This `streamingLines` DataFrame represents an unbounded table containing the
streaming text data. This table contains one column of strings named
“value”, and each line in the streaming text data becomes a row in the
table. Note, that this is not currently receiving any data as we are
just setting up the transformation, and have not yet started it. 

%md
Next, we will convert the DataFrame to a Dataset of String using
`.as[String]`, so that we can apply the `flatMap` operation to split
each line into multiple words. The resultant `words` Dataset contains
all the words. 

%md
Finally, we define the `wordCounts` DataFrame by
grouping by the unique values in the Dataset and counting them. Note
that this is a streaming DataFrame which represents the **running word
counts of the stream**.

%md
We have now set up the query on the streaming data. All that is left is
to actually start receiving data and computing the counts. To do this,
we set it up to print the complete set of counts (specified by
`outputMode("complete")`) to the console every time they are updated.
And then start the streaming computation using `start()`.

%md
After this code is executed, the streaming computation will have started
in the background. The `query` object is a handle to that active
streaming query, and we have decided to wait for the termination of the
query using `awaitTermination()` to prevent the process from exiting
while the query is active.

%md
Handling Event-time and Late Data
---------------------------------

Event-time is the time embedded in the data itself. For many
applications, you may want to operate on this event-time. For example,
if you want to get the number of events generated by IoT devices every
minute, then you probably want to use the time when the data was
generated (that is, event-time in the data), rather than the time Spark
receives them. This event-time is very naturally expressed in this model
– each event from the devices is a row in the table, and event-time is a
column value in the row. This allows window-based aggregations (e.g.
number of events every minute) to be just a special type of grouping and
aggregation on the event-time column – each time window is a group and
each row can belong to multiple windows/groups. Therefore, such
event-time-window-based aggregation queries can be defined consistently
on both a static dataset (e.g. from collected device events logs) as
well as on a data stream, making the life of the user much easier.

Furthermore, this model naturally handles data that has arrived later
than expected based on its event-time. Since Spark is updating the
Result Table, it has full control over updating old aggregates when
there is late data, as well as cleaning up old aggregates to limit the
size of intermediate state data. Since Spark 2.1, we have support for
watermarking which allows the user to specify the threshold of late
data, and allows the engine to accordingly clean up old state. These are
explained later in more detail in the **Window Operations** section below.

Fault Tolerance Semantics
-------------------------

Delivering end-to-end exactly-once semantics was one of key goals behind
the design of Structured Streaming. To achieve that, we have designed
the Structured Streaming sources, the sinks and the execution engine to
reliably track the exact progress of the processing so that it can
handle any kind of failure by restarting and/or reprocessing. Every
streaming source is assumed to have offsets (similar to Kafka offsets,
or Kinesis sequence numbers) to track the read position in the stream.
The engine uses checkpointing and write ahead logs to record the offset
range of the data being processed in each trigger. The streaming sinks
are designed to be idempotent for handling reprocessing. Together, using
replayable sources and idempotent sinks, Structured Streaming can ensure
**end-to-end exactly-once semantics** under any failure.

API using Datasets and DataFrames
=================================

Since Spark 2.0, DataFrames and Datasets can represent static, bounded
data, as well as streaming, unbounded data. Similar to static
Datasets/DataFrames, you can use the common entry point `SparkSession`
([Scala](https://spark.apache.org/docs/2.2.0/api/scala/index.html#org.apache.spark.sql.SparkSession)/[Java](https://spark.apache.org/docs/2.2.0/api/java/org/apache/spark/sql/SparkSession.html)/[Python](https://spark.apache.org/docs/2.2.0/api/python/pyspark.sql.html#pyspark.sql.SparkSession)/[R](https://spark.apache.org/docs/2.2.0/api/R/sparkR.session.html)
docs) to create streaming DataFrames/Datasets from streaming sources,
and apply the same operations on them as static DataFrames/Datasets. If
you are not familiar with Datasets/DataFrames, you are strongly advised
to familiarize yourself with them using the [DataFrame/Dataset
Programming
Guide](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html).

Creating streaming DataFrames and streaming Datasets
----------------------------------------------------

Streaming DataFrames can be created through the `DataStreamReader`
interface
([Scala](https://spark.apache.org/docs/2.2.0/api/scala/index.html#org.apache.spark.sql.streaming.DataStreamReader)/[Java](https://spark.apache.org/docs/2.2.0/api/java/org/apache/spark/sql/streaming/DataStreamReader.html)/[Python](https://spark.apache.org/docs/2.2.0/api/python/pyspark.sql.html#pyspark.sql.streaming.DataStreamReader)
docs) returned by `SparkSession.readStream()`. In
[R](https://spark.apache.org/docs/2.2.0/api/R/read.stream.html), with
the `read.stream()` method. Similar to the read interface for creating
static DataFrame, you can specify the details of the source – data
format, schema, options, etc.

#### Input Sources

In Spark 2.0, there are a few built-in sources.

-   **File source** - Reads files written in a directory as a stream
    of data. Supported file formats are text, csv, json, parquet. See
    the docs of the DataStreamReader interface for a more up-to-date
    list, and supported options for each file format. Note that the
    files must be atomically placed in the given directory, which in
    most file systems, can be achieved by file move operations.

-   **Kafka source** - Poll data from Kafka. It’s compatible with Kafka
    broker versions 0.10.0 or higher. See the [Kafka Integration
    Guide](https://spark.apache.org/docs/2.2.0/structured-streaming-kafka-integration.html)
    for more details.

-   **Socket source (for testing)** - Reads UTF8 text data from a
    socket connection. The listening server socket is at the driver.
    Note that this should be used only for testing as this does not
    provide end-to-end fault-tolerance guarantees.

Some sources are not fault-tolerant because they do not guarantee that
data can be replayed using checkpointed offsets after a failure. See the
earlier section on [fault-tolerance
semantics](structured-streaming-programming-guide.html#fault-tolerance-semantics).
Here are the details of all the sources in Spark.

<table class="table">
  <tr>
    <th>Source</th>
    <th>Options</th>
    <th>Fault-tolerant</th>
    <th>Notes</th>
  </tr>
  <tr>
    <td><b>File source</b></td>
    <td>
        <code>path</code>: path to the input directory, and common to all file formats.
        <br />
        <code>maxFilesPerTrigger</code>: maximum number of new files to be considered in every trigger (default: no max)
        <br />
        <code>latestFirst</code>: whether to processs the latest new files first, useful when there is a large backlog of files (default: false)
        <br />
        <code>fileNameOnly</code>: whether to check new files based on only the filename instead of on the full path (default: false). With this set to `true`, the following files would be considered as the same file, because their filenames, "dataset.txt", are the same:
        <br />
        · "file:///dataset.txt"<br />
        · "s3://a/dataset.txt"<br />
        · "s3n://a/b/dataset.txt"<br />
        · "s3a://a/b/c/dataset.txt"<br />
        <br />

        <br />
        For file-format-specific options, see the related methods in <code>DataStreamReader</code>
        (<a href="https://spark.apache.org/docs/2.2.0/api/scala/index.html#org.apache.spark.sql.streaming.DataStreamReader">Scala</a>/<a href="https://spark.apache.org/docs/2.2.0/api/java/org/apache/spark/sql/streaming/DataStreamReader.html">Java</a>/<a href="https://spark.apache.org/docs/2.2.0/api/python/pyspark.sql.html#pyspark.sql.streaming.DataStreamReader">Python</a>/<a href="https://spark.apache.org/docs/2.2.0/api/R/read.stream.html">R</a>).
        E.g. for "parquet" format options see <code>DataStreamReader.parquet()</code></td>
    <td>Yes</td>
    <td>Supports glob paths, but does not support multiple comma-separated paths/globs.</td>
  </tr>
  <tr>
    <td><b>Socket Source</b></td>
    <td>
        <code>host</code>: host to connect to, must be specified<br />
        <code>port</code>: port to connect to, must be specified
    </td>
    <td>No</td>
    <td></td>
  </tr>
  <tr>
    <td><b>Kafka Source</b></td>
    <td>
        See the <a href="https://spark.apache.org/docs/2.2.0/structured-streaming-kafka-integration.html">Kafka Integration Guide</a>.
    </td>
    <td>Yes</td>
    <td></td>
  </tr>
  <tr>
    <td></td>
    <td></td>
    <td></td>
    <td></td>
  </tr>
</table>

See [https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#input-sources](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#input-sources).

### Schema inference and partition of streaming DataFrames/Datasets

By default, Structured Streaming from file based sources requires you to
specify the schema, rather than rely on Spark to infer it automatically (*this is what we did with `userSchema` above*).
This restriction ensures a consistent schema will be used for the
streaming query, even in the case of failures. For ad-hoc use cases, you
can reenable schema inference by setting
`spark.sql.streaming.schemaInference` to `true`.

Partition discovery does occur when subdirectories that are named
`/key=value/` are present and listing will automatically recurse into
these directories. If these columns appear in the user provided schema,
they will be filled in by Spark based on the path of the file being
read. The directories that make up the partitioning scheme must be
present when the query starts and must remain static. For example, it is
okay to add `/data/year=2016/` when `/data/year=2015/` was present, but
it is invalid to change the partitioning column (i.e. by creating the
directory `/data/date=2016-04-17/`).

Operations on streaming DataFrames/Datasets
-------------------------------------------

You can apply all kinds of operations on streaming DataFrames/Datasets –
ranging from untyped, SQL-like operations (e.g. `select`, `where`,
`groupBy`), to typed RDD-like operations (e.g. `map`, `filter`,
`flatMap`). See the [SQL programming
guide](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html)
for more details. Let’s take a look at a few example operations that you
can use.

### Basic Operations - Selection, Projection, Aggregation

Most of the common operations on DataFrame/Dataset are supported for
streaming. The few operations that are not supported are discussed
later in **unsupported-operations** section.

```%scala
    case class DeviceData(device: String, deviceType: String, signal: Double, time: DateTime)

    val df: DataFrame = ... // streaming DataFrame with IOT device data with schema { device: string, deviceType: string, signal: double, time: string }
    val ds: Dataset[DeviceData] = df.as[DeviceData]    // streaming Dataset with IOT device data

    // Select the devices which have signal more than 10
    df.select("device").where("signal > 10")      // using untyped APIs
    ds.filter(_.signal > 10).map(_.device)         // using typed APIs

    // Running count of the number of updates for each device type
    df.groupBy("deviceType").count()                          // using untyped API

    // Running average signal for each device type
    import org.apache.spark.sql.expressions.scalalang.typed
    ds.groupByKey(_.deviceType).agg(typed.avg(_.signal))    // using typed API

```

## A Quick Mixture Example

We will work below with a file stream that simulates random animal names or a simple mixture of two Normal Random Variables.

The two file streams can be acieved by running the codes in the following two databricks notebooks in the same cluster:

* `037a_AnimalNamesStructStreamingFiles`
* `037b_Mix2NormalsStructStreamingFiles`

%md
You should have the following set of csv files (it won't be exactly the same names depending on when you start the stream of files).

%md
## Static and Streaming DataFrames

Let's check out the files and their contents both via static as well as streaming DataFrames. 

This will also cement the fact that structured streaming allows interoperability between static and streaming data and can be useful for debugging.

%md
Once the above streaming job has processed all the files in the directory, it will continue to "listen" in for new files in the directory. You could for example return to the other notebook `037b_Mix2NormalsStructStreamingFiles` and rerun the cell that writes another lot of newer files into the directory and return to this notebook to watch the above streaming job continue with additional batches.

%md
## Static and Streaming DataSets

These examples generate streaming DataFrames that are untyped, meaning
that the schema of the DataFrame is not checked at compile time, only
checked at runtime when the query is submitted. Some operations like
`map`, `flatMap`, etc. need the type to be known at compile time. To do
those, you can convert these untyped streaming DataFrames to typed
streaming Datasets using the same methods as static DataFrame. See the
[SQL Programming Guide](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html)
for more details. Additionally, more details on the supported streaming
sources are discussed later in the document.

Let us make a `dataset` version of the streaming dataframe.

But first let us try it make the datset from the static dataframe and then apply it to the streming dataframe.

%md
Now let us use the same code for making a streaming dataset.

%md
### Window Operations on Event Time

Aggregations over a sliding event-time window are straightforward with
Structured Streaming and are very similar to grouped aggregations. In a
grouped aggregation, aggregate values (e.g. counts) are maintained for
each unique value in the user-specified grouping column. In case of
window-based aggregations, aggregate values are maintained for each
window the event-time of a row falls into. Let’s understand this with an
illustration.

Imagine our **quick example** is
modified and the stream now contains lines along with the time when the
line was generated. Instead of running word counts, we want to count
words within 10 minute windows, updating every 5 minutes. That is, word
counts in words received between 10 minute windows 
12:00 - 12:10, 12:05 - 12:15, 12:10 - 12:20, etc. Note that 12:00 - 12:10 means data that
arrived after 12:00 but before 12:10. Now, consider a word that was
received at 12:07. This word should increment the counts corresponding
to two windows 12:00 - 12:10 and 12:05 - 12:15. So the counts will be
indexed by both, the grouping key (i.e. the word) and the window (can be
calculated from the event-time).

The result tables would look something like the following.

![Window
Operations](https://spark.apache.org/docs/2.2.0/img/structured-streaming-window.png)

Since this windowing is similar to grouping, in code, you can use
`groupBy()` and `window()` operations to express windowed aggregations.
You can see the full code for the below examples in
[Scala](https://github.com/apache/spark/blob/v2.2.0/examples/src/main/scala/org/apache/spark/examples/sql/streaming/StructuredNetworkWordCountWindowed.scala)/[Java](https://github.com/apache/spark/blob/v2.2.0/examples/src/main/java/org/apache/spark/examples/sql/streaming/JavaStructuredNetworkWordCountWindowed.java)/[Python](https://github.com/apache/spark/blob/v2.2.0/examples/src/main/python/sql/streaming/structured_network_wordcount_windowed.py).

%md
Make sure the streaming job with animal names is running (or finished running) with files in `/datasets/streamingFiles` directory - this is the Quick Example in `037a_FilesForStructuredStreaming` notebook.

%md

### Handling Late Data and Watermarking

Now consider what happens if one of the events arrives late to the
application. For example, say, a word generated at 12:04 (i.e. event
time) could be received by the application at 12:11. The application
should use the time 12:04 instead of 12:11 to update the older counts
for the window `12:00 - 12:10`. This occurs naturally in our
window-based grouping – Structured Streaming can maintain the
intermediate state for partial aggregates for a long period of time such
that late data can update aggregates of old windows correctly, as
illustrated below.

![Handling Late Data](https://spark.apache.org/docs/2.2.0/img/structured-streaming-late-data.png)

However, to run this query for days, it’s necessary for the system to
bound the amount of intermediate in-memory state it accumulates. This
means the system needs to know when an old aggregate can be dropped from
the in-memory state because the application is not going to receive late
data for that aggregate any more. To enable this, in Spark 2.1, we have
introduced **watermarking**, which lets the engine automatically track
the current event time in the data and attempt to clean up old state
accordingly. You can define the watermark of a query by specifying the
event time column and the threshold on how late the data is expected to
be in terms of event time. For a specific window starting at time `T`,
the engine will maintain state and allow late data to update the state
until `(max event time seen by the engine - late threshold > T)`. In
other words, late data within the threshold will be aggregated, but data
later than the threshold will be dropped. Let’s understand this with an
example. We can easily define watermarking on the previous example using
`withWatermark()` as shown below.

%md
In this example, we are defining the watermark of the query on the value
of the column “timestamp”, and also defining “10 minutes” as the
threshold of how late is the data allowed to be. If this query is run in
Update output mode (discussed later in [Output
Modes](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#output-modes)
section), the engine will keep updating counts of a window in the Result
Table until the window is older than the watermark, which lags behind
the current event time in column “timestamp” by 10 minutes. Here is an
illustration.

![Watermarking in Update
Mode](https://spark.apache.org/docs/2.2.0/img/structured-streaming-watermark-update-mode.png)

As shown in the illustration, the maximum event time tracked by the
engine is the *blue dashed line*, and the watermark set as
`(max event time - '10 mins')` at the beginning of every trigger is the
red line For example, when the engine observes the data `(12:14, dog)`,
it sets the watermark for the next trigger as `12:04`. This watermark
lets the engine maintain intermediate state for additional 10 minutes to
allow late data to be counted. For example, the data `(12:09, cat)` is
out of order and late, and it falls in windows `12:05 - 12:15` and
`12:10 - 12:20`. Since, it is still ahead of the watermark `12:04` in
the trigger, the engine still maintains the intermediate counts as state
and correctly updates the counts of the related windows. However, when
the watermark is updated to `12:11`, the intermediate state for window
`(12:00 - 12:10)` is cleared, and all subsequent data (e.g.
`(12:04, donkey)`) is considered “too late” and therefore ignored. Note
that after every trigger, the updated counts (i.e. purple rows) are
written to sink as the trigger output, as dictated by the Update mode.

Some sinks (e.g. files) may not supported fine-grained updates that
Update Mode requires. To work with them, we have also support Append
Mode, where only the *final counts* are written to sink. This is
illustrated below.

Note that using `withWatermark` on a non-streaming Dataset is no-op. As
the watermark should not affect any batch query in any way, we will
ignore it directly.

![Watermarking in Append
Mode](https://spark.apache.org/docs/2.2.0/img/structured-streaming-watermark-append-mode.png)

Similar to the Update Mode earlier, the engine maintains intermediate
counts for each window. However, the partial counts are not updated to
the Result Table and not written to sink. The engine waits for “10 mins”
for late date to be counted, then drops intermediate state of a window
< watermark, and appends the final counts to the Result Table/sink.
For example, the final counts of window `12:00 - 12:10` is appended to
the Result Table only after the watermark is updated to `12:11`.

**Conditions for watermarking to clean aggregation state** It is
important to note that the following conditions must be satisfied for
the watermarking to clean the state in aggregation queries *(as of Spark
2.1.1, subject to change in the future)*.

-   **Output mode must be Append or Update.** Complete mode requires all
    aggregate data to be preserved, and hence cannot use watermarking to
    drop intermediate state. See the [Output
    Modes](https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html#output-modes)
    section for detailed explanation of the semantics of each
    output mode.

-   The aggregation must have either the event-time column, or a
    `window` on the event-time column.

-   `withWatermark` must be called on the same column as the timestamp
    column used in the aggregate. For example,
    `df.withWatermark("time", "1 min").groupBy("time2").count()` is
    invalid in Append output mode, as watermark is defined on a
    different column from the aggregation column.

-   `withWatermark` must be called before the aggregation for the
    watermark details to be used. For example,
    `df.groupBy("time").count().withWatermark("time", "1 min")` is
    invalid in Append output mode.

%md
### Join Operations

Streaming DataFrames can be joined with static DataFrames to create new
streaming DataFrames. Here are a few examples.

%md
```
val staticDf = spark.read. ...
val streamingDf = spark.readStream. ...

streamingDf.join(staticDf, "type")          // inner equi-join with a static DF
streamingDf.join(staticDf, "type", "right_join")  // right outer join with a static DF
```

%md
### Streaming Deduplication

You can deduplicate records in data streams using a unique identifier in
the events. This is exactly same as deduplication on static using a
unique identifier column. The query will store the necessary amount of
data from previous records such that it can filter duplicate records.
Similar to aggregations, you can use deduplication with or without
watermarking.

-   *With watermark* - If there is a upper bound on how late a duplicate
    record may arrive, then you can define a watermark on a event time
    column and deduplicate using both the guid and the event
    time columns. The query will use the watermark to remove old state
    data from past records that are not expected to get any duplicates
    any more. This bounds the amount of the state the query has
    to maintain.

-   *Without watermark* - Since there are no bounds on when a duplicate
    record may arrive, the query stores the data from all the past
    records as state.

```
    val streamingDf = spark.readStream. ...  // columns: guid, eventTime, ...

    // Without watermark using guid column
    streamingDf.dropDuplicates("guid")

    // With watermark using guid and eventTime columns
    streamingDf
      .withWatermark("eventTime", "10 seconds")
      .dropDuplicates("guid", "eventTime")
```

%md
### Arbitrary Stateful Operations

Many uscases require more advanced stateful operations than
aggregations. For example, in many usecases, you have to track sessions
from data streams of events. For doing such sessionization, you will
have to save arbitrary types of data as state, and perform arbitrary
operations on the state using the data stream events in every trigger.
Since Spark 2.2, this can be done using the operation
`mapGroupsWithState` and the more powerful operation
`flatMapGroupsWithState`. Both operations allow you to apply
user-defined code on grouped Datasets to update user-defined state. For
more concrete details, take a look at the API documentation
([Scala](https://spark.apache.org/docs/2.2.0/api/scala/index.html#org.apache.spark.sql.streaming.GroupState)/[Java](https://spark.apache.org/docs/2.2.0/api/java/org/apache/spark/sql/streaming/GroupState.html))
and the examples
([Scala](https://github.com/apache/spark/blob/v2.2.0/examples/src/main/scala/org/apache/spark/examples/sql/streaming/StructuredSessionization.scala)/[Java](https://github.com/apache/spark/blob/v2.2.0/examples/src/main/java/org/apache/spark/examples/sql/streaming/JavaStructuredSessionization.java)).

### Unsupported Operations

There are a few DataFrame/Dataset operations that are not supported with
streaming DataFrames/Datasets. Some of them are as follows.

-   Multiple streaming aggregations (i.e. a chain of aggregations on a
    streaming DF) are not yet supported on streaming Datasets.

-   Limit and take first N rows are not supported on streaming Datasets.

-   Distinct operations on streaming Datasets are not supported.

-   Sorting operations are supported on streaming Datasets only after an
    aggregation and in Complete Output Mode.

-   Outer joins between a streaming and a static Datasets are
    conditionally supported.

    -   Full outer join with a streaming Dataset is not supported

    -   Left outer join with a streaming Dataset on the right is not
        supported

    -   Right outer join with a streaming Dataset on the left is not
        supported

-   Any kind of joins between two streaming Datasets is not
    yet supported.

In addition, there are some Dataset methods that will not work on
streaming Datasets. They are actions that will immediately run queries
and return results, which does not make sense on a streaming Dataset.
Rather, those functionalities can be done by explicitly starting a
streaming query (see the next section regarding that).

-   `count()` - Cannot return a single count from a streaming Dataset.
    Instead, use `ds.groupBy().count()` which returns a streaming
    Dataset containing a running count.

-   `foreach()` - Instead use `ds.writeStream.foreach(...)` (see
    next section).

-   `show()` - Instead use the console sink (see next section).

If you try any of these operations, you will see an `AnalysisException`
like “operation XYZ is not supported with streaming
DataFrames/Datasets”. While some of them may be supported in future
releases of Spark, there are others which are fundamentally hard to
implement on streaming data efficiently. For example, sorting on the
input stream is not supported, as it requires keeping track of all the
data received in the stream. This is therefore fundamentally hard to
execute efficiently.

Starting Streaming Queries
--------------------------

Once you have defined the final result DataFrame/Dataset, all that is
left is for you to start the streaming computation. To do that, you have
to use the `DataStreamWriter`
([Scala](https://spark.apache.org/docs/2.2.0/api/scala/index.html#org.apache.spark.sql.streaming.DataStreamWriter)/[Java](https://spark.apache.org/docs/2.2.0/api/java/org/apache/spark/sql/streaming/DataStreamWriter.html)/[Python](https://spark.apache.org/docs/2.2.0/api/python/pyspark.sql.html#pyspark.sql.streaming.DataStreamWriter)
docs) returned through `Dataset.writeStream()`. You will have to specify
one or more of the following in this interface.

-   *Details of the output sink:* Data format, location, etc.

-   *Output mode:* Specify what gets written to the output sink.

-   *Query name:* Optionally, specify a unique name of the query
    for identification.

-   *Trigger interval:* Optionally, specify the trigger interval. If it
    is not specified, the system will check for availability of new data
    as soon as the previous processing has completed. If a trigger time
    is missed because the previous processing has not completed, then
    the system will attempt to trigger at the next trigger point, not
    immediately after the processing has completed.

-   *Checkpoint location:* For some output sinks where the end-to-end
    fault-tolerance can be guaranteed, specify the location where the
    system will write all the checkpoint information. This should be a
    directory in an HDFS-compatible fault-tolerant file system. The
    semantics of checkpointing is discussed in more detail in the
    next section.

#### Output Modes

There are a few types of output modes.

-   **Append mode (default)** - This is the default mode, where only the
    new rows added to the Result Table since the last trigger will be
    outputted to the sink. This is supported for only those queries
    where rows added to the Result Table is never going to change.
    Hence, this mode guarantees that each row will be output only once
    (assuming fault-tolerant sink). For example, queries with only
    `select`, `where`, `map`, `flatMap`, `filter`, `join`, etc. will
    support Append mode.

-   **Complete mode** - The whole Result Table will be outputted to the
    sink after every trigger. This is supported for aggregation queries.

-   **Update mode** - (*Available since Spark 2.1.1*) Only the rows in
    the Result Table that were updated since the last trigger will be
    outputted to the sink. More information to be added in
    future releases.

Different types of streaming queries support different output modes.
Here is the compatibility matrix.


<table class="table">
  <tr>
    <th>Query Type</th>
    <th></th>
    <th>Supported Output Modes</th>
    <th>Notes</th>        
  </tr>
  <tr>
    <td rowspan="2" style="vertical-align: middle;">Queries with aggregation</td>
    <td style="vertical-align: middle;">Aggregation on event-time with watermark</td>
    <td style="vertical-align: middle;">Append, Update, Complete</td>
    <td>
        Append mode uses watermark to drop old aggregation state. But the output of a 
        windowed aggregation is delayed the late threshold specified in `withWatermark()` as by
        the modes semantics, rows can be added to the Result Table only once after they are 
        finalized (i.e. after watermark is crossed). See the
        <a href="structured-streaming-programming-guide.html#handling-late-data-and-watermarking">Late Data</a> section for more details.
        <br /><br />
        Update mode uses watermark to drop old aggregation state.
        <br /><br />
        Complete mode does not drop old aggregation state since by definition this mode
        preserves all data in the Result Table.
    </td>    
  </tr>
  <tr>
    <td style="vertical-align: middle;">Other aggregations</td>
    <td style="vertical-align: middle;">Complete, Update</td>
    <td>
        Since no watermark is defined (only defined in other category), 
        old aggregation state is not dropped.
        <br /><br />
        Append mode is not supported as aggregates can update thus violating the semantics of 
        this mode.
    </td>  
  </tr>
  <tr>
    <td colspan="2" style="vertical-align: middle;">Queries with <code>mapGroupsWithState</code></td>
    <td style="vertical-align: middle;">Update</td>
    <td style="vertical-align: middle;"></td>
  </tr>
  <tr>
    <td rowspan="2" style="vertical-align: middle;">Queries with <code>flatMapGroupsWithState</code></td>
    <td style="vertical-align: middle;">Append operation mode</td>
    <td style="vertical-align: middle;">Append</td>
    <td style="vertical-align: middle;">
      Aggregations are allowed after <code>flatMapGroupsWithState</code>.
    </td>
  </tr>
  <tr>
    <td style="vertical-align: middle;">Update operation mode</td>
    <td style="vertical-align: middle;">Update</td>
    <td style="vertical-align: middle;">
      Aggregations not allowed after <code>flatMapGroupsWithState</code>.
    </td>
  </tr>
  <tr>
    <td colspan="2" style="vertical-align: middle;">Other queries</td>
    <td style="vertical-align: middle;">Append, Update</td>
    <td style="vertical-align: middle;">
      Complete mode not supported as it is infeasible to keep all unaggregated data in the Result Table.
    </td>
  </tr>
  <tr>
    <td></td>
    <td></td>
    <td></td>
    <td></td>
  </tr>
</table>