Spark1.1.0 Spark Streaming Programming Guide

青旅半醒 2022-08-12 01:23 199阅读 0赞

# Spark Streaming Programming Guide #

*  [Overview][]
 *  [A Quick Example][]
 *  [Basic Concepts][]
    
     *  [Linking][]
     *  [Initializing StreamingContext][]
     *  [Discretized Streams (DStreams)][Discretized Streams _DStreams]
     *  [Input DStreams][]
     *  [Transformations on DStreams][]
     *  [Output Operations on DStreams][]
     *  [Caching / Persistence][Caching _ Persistence]
     *  [Checkpointing][]
     *  [Deploying Applications][]
     *  [Monitoring Applications][]
 *  [Performance Tuning][]
    
     *  [Reducing the Processing Time of each Batch][]
     *  [Setting the Right Batch Size][]
     *  [Memory Tuning][]
 *  [Fault-tolerance Properties][]
    
     *  [Failure of a Worker Node][]
     *  [Failure of the Driver Node][]
 *  [Migration Guide from 0.9.1 or below to 1.x][]
 *  [Where to Go from Here][]

# Overview #

Spark Streaming is an extension of the core Spark API that allows enables scalable, high-throughput, fault-tolerant stream processing of live data streams. Data can be ingested from many sources like Kafka, Flume, Twitter, ZeroMQ, Kinesis or plain old TCP sockets and be processed using complex algorithms expressed with high-level functions like `map`, `reduce`, `join` and `window`. Finally, processed data can be pushed out to filesystems, databases, and live dashboards. In fact, you can apply Spark’s [machine learning][] algorithms, and [graph processing][] algorithms on data streams.

![Spark Streaming][]

Internally, it works as follows. Spark Streaming receives live input data streams and divides the data into batches, which are then processed by the Spark engine to generate the final stream of results in batches.

![Spark Streaming][Spark Streaming 1]

Spark Streaming provides a high-level abstraction called *discretized stream* or *DStream*, which represents a continuous stream of data. DStreams can be created either from input data stream from sources such as Kafka, Flume, and Kinesis, or by applying high-level operations on other DStreams. Internally, a DStream is represented as a sequence of [RDDs][].

This guide shows you how to start writing Spark Streaming programs with DStreams. You can write Spark Streaming programs in Scala or Java, both of which are presented in this guide. You will find tabs throughout this guide that let you choose between Scala and Java code snippets.

--------------------

# A Quick Example #

Before we go into the details of how to write your own Spark Streaming program, let’s take a quick look at what a simple Spark Streaming program looks like. Let’s say we want to count the number of words in text data received from a data server listening on a TCP socket. All you need to do is as follows.

*  [**Scala**][Scala]
 *  [**Java**][Java]

First, we import the names of the Spark Streaming classes, and some implicit conversions from StreamingContext into our environment, to add useful methods to other classes we need (like DStream). [StreamingContext][] is the main entry point for all streaming functionality. We create a local StreamingContext with two execution threads, and batch interval of 1 second.

import org.apache.spark._
    import org.apache.spark.streaming._
    import org.apache.spark.streaming.StreamingContext._
    
    // Create a local StreamingContext with two working thread and batch interval of 1 second
    val conf = new SparkConf().setMaster("local[2]").setAppName("NetworkWordCount")
    val ssc = new StreamingContext(conf, Seconds(1))

Using this context, we can create a DStream that represents streaming data from a TCP source hostname, e.g. `localhost`, and port, e.g. `9999`

// Create a DStream that will connect to hostname:port, like localhost:9999
    val lines = ssc.socketTextStream("localhost", 9999)

This `lines` DStream represents the stream of data that will be received from the data server. Each record in this DStream is a line of text. Next, we want to split the lines by space into words.

// Split each line into words
    val words = lines.flatMap(_.split(" "))

`flatMap` is a one-to-many DStream operation that creates a new DStream by generating multiple new records from each record in the source DStream. In this case, each line will be split into multiple words and the stream of words is represented as the `words` DStream. Next, we want to count these words.

import org.apache.spark.streaming.StreamingContext._
    // Count each word in each batch
    val pairs = words.map(word => (word, 1))
    val wordCounts = pairs.reduceByKey(_ + _)
    
    // Print the first ten elements of each RDD generated in this DStream to the console
    wordCounts.print()

The `words` DStream is further mapped (one-to-one transformation) to a DStream of `(word, 1)` pairs, which is then reduced to get the frequency of words in each batch of data. Finally, `wordCounts.print()` will print a few of the counts generated every second.

Note that when these lines are executed, Spark Streaming only sets up the computation it will perform when it is started, and no real processing has started yet. To start the processing after all the transformations have been setup, we finally call

ssc.start()             // Start the computation
    ssc.awaitTermination()  // Wait for the computation to terminate

The complete code can be found in the Spark Streaming example [NetworkWordCount][].

If you have already [downloaded][] and [built][] Spark, you can run this example as follows. You will first need to run Netcat (a small utility found in most Unix-like systems) as a data server by using

$ nc -lk 9999

Then, in a different terminal, you can start the example by using

*  [**Scala**][Scala 1]
 *  [**Java**][Java 1]

$ ./bin/run-example streaming.NetworkWordCount localhost 9999

Then, any lines typed in the terminal running the netcat server will be counted and printed on screen every second. It will look something like this.

<table style="max-width:100%; border-collapse:collapse; border-spacing:0px; color:rgb(51,51,51); font-family:'Helvetica Neue',Helvetica,Arial,sans-serif; font-size:14px; line-height:22.399999618530273px"> 
 <tbody> 
 <tr> 
 <td> 
 <div> 
 <pre style="padding:9.5px; font-family:Menlo,'Lucida Console',monospace; font-size:13px; margin-top:0px; margin-bottom:10px; line-height:20px; word-break:break-all; word-wrap:break-word; white-space:pre-wrap; background-color:rgb(245,245,245)"><code style="padding:0px; font-family:Menlo,'Lucida Console',monospace; font-size:12px; color:inherit; background-color:transparent; border:0px"># TERMINAL 1:
# Running Netcat

$ nc -lk 9999

hello world

...
</code></pre> 
 </div> </td> 
 <td>&nbsp;</td> 
 <td> 
 <div> 
 <pre style="padding:9.5px; font-family:Menlo,'Lucida Console',monospace; font-size:13px; margin-top:0px; margin-bottom:10px; line-height:20px; word-break:break-all; word-wrap:break-word; white-space:pre-wrap; background-color:rgb(245,245,245)"><code style="padding:0px; font-family:Menlo,'Lucida Console',monospace; font-size:12px; color:inherit; background-color:transparent; border:0px"># TERMINAL 2: RUNNING NetworkWordCount or JavaNetworkWordCount

$ ./bin/run-example streaming.NetworkWordCount localhost 9999
...
-------------------------------------------
Time: 1357008430000 ms
-------------------------------------------
(hello,1)
(world,1)
...
</code></pre> 
 </div> </td> 
 </tr> 
 </tbody> 
</table>

--------------------

# Basic Concepts #

Next, we move beyond the simple example and elaborate on the basics of Spark Streaming that you need to know to write your streaming applications.

## Linking ##

Similar to Spark, Spark Streaming is available through Maven Central. To write your own Spark Streaming program, you will have to add the following dependency to your SBT or Maven project.

*  [**Maven**][Maven]
 *  [**SBT**][SBT]

<dependency>
 <groupId>org.apache.spark</groupId>
 <artifactId>spark-streaming_2.10</artifactId>
 <version>1.1.0-SNAPSHOT</version>
 </dependency>

For ingesting data from sources like Kafka, Flume, and Kinesis that are not present in the Spark Streaming core API, you will have to add the corresponding artifact `spark-streaming-xyz_2.10` to the dependencies. For example, some of the common ones are as follows.

For an up-to-date list, please refer to the [Apache repository][] for the full list of supported sources and artifacts.

--------------------

## Initializing StreamingContext ##

To initialize a Spark Streaming program, a **StreamingContext** object has to be created which is the main entry point of all Spark Streaming functionality.

*  [**Scala**][Scala 2]
 *  [**Java**][Java 2]

A [StreamingContext][] object can be created from a [SparkConf][] object.

import org.apache.spark._
    import org.apache.spark.streaming._
    
    val conf = new SparkConf().setAppName(appName).setMaster(master)
    val ssc = new StreamingContext(conf, Seconds(1))

The `appName` parameter is a name for your application to show on the cluster UI. `master` is a [Spark, Mesos or YARN cluster URL][Spark_ Mesos or YARN cluster URL], or a special**“local\[\*\]”** string to run in local mode. In practice, when running on a cluster, you will not want to hardcode `master` in the program, but rather[launch the application with `spark-submit`][launch the application with_spark-submit] and receive it there. However, for local testing and unit tests, you can pass “local\[\*\]” to run Spark Streaming in-process (detects the number of cores in the local system). Note that this internally creates a [SparkContext][] (starting point of all Spark functionality) which can be accessed as `ssc.sparkContext`.

The batch interval must be set based on the latency requirements of your application and available cluster resources. See the [Performance Tuning][Setting the Right Batch Size] section for more details.

A `StreamingContext` object can also be created from an existing `SparkContext` object.

import org.apache.spark.streaming._
    
    val sc = ...                // existing SparkContext
    val ssc = new StreamingContext(sc, Seconds(1))

After a context is defined, you have to do the follow steps. 1. Define the input sources. 1. Setup the streaming computations. 1. Start the receiving and procesing of data using `streamingContext.start()`. 1. The processing will continue until `streamingContext.stop()` is called.

##### Points to remember: #####

*  Once a context has been started, no new streaming computations can be setup or added to it.
 *  Once a context has been stopped, it cannot be started (that is, re-used) again.
 *  Only one StreamingContext can be active in a JVM at the same time.
 *  stop() on StreamingContext also stops the SparkContext. To stop only the StreamingContext, set optional parameter of `stop()` called`stopSparkContext` to false.
 *  A SparkContext can be re-used to create multiple StreamingContexts, as long as the previous StreamingContext is stopped (without stopping the SparkContext) before the next StreamingContext is created.

--------------------

## Discretized Streams (DStreams) ##

**Discretized Stream** or **DStream** is the basic abstraction provided by Spark Streaming. It represents a continuous stream of data, either the input data stream received from source, or the processed data stream generated by transforming the input stream. Internally, a DStream is represented by a continuous series of RDDs, which is Spark’s abstraction of an immutable, distributed dataset (see [Spark Programming Guide][]for more details). Each RDD in a DStream contains data from a certain interval, as shown in the following figure.

![Spark Streaming][Spark Streaming 2]

Any operation applied on a DStream translates to operations on the underlying RDDs. For example, in the [earlier example][A Quick Example] of converting a stream of lines to words, the `flatMap` operation is applied on each RDD in the `lines` DStream to generate the RDDs of the `words` DStream. This is shown in the following figure.

![Spark Streaming][Spark Streaming 3]

These underlying RDD transformations are computed by the Spark engine. The DStream operations hide most of these details and provide the developer with higher-level API for convenience. These operations are discussed in detail in later sections.

--------------------

## Input DStreams ##

Input DStreams are DStreams representing the stream of raw data received from streaming sources. Spark Streaming has two categories of streaming sources.

*  *Basic sources*: Sources directly available in the StreamingContext API. Example: file systems, socket connections, and Akka actors.
 *  *Advanced sources*: Sources like Kafka, Flume, Kinesis, Twitter, etc. are available through extra utility classes. These require linking against extra dependencies as discussed in the [linking][Linking] section.

Every input DStream (except file stream) is associated with a single [Receiver][] object which receives the data from a source and stores it in Spark’s memory for processing. So every input DStream receives a single stream of data. Note that in a streaming application, you can create multiple input DStreams to receive multiple streams of data in parallel. This is discussed later in the [Performance Tuning][Performance Tuning 1] section.

A receiver is run within a Spark worker/executor as a long-running task, hence it occupies one of the cores allocated to the Spark Streaming application. Hence, it is important to remember that Spark Streaming application needs to be allocated enough cores to process the received data, as well as, to run the receiver(s). Therefore, few important points to remember are:

##### Points to remember: #####

*  If the number of cores allocated to the application is less than or equal to the number of input DStreams / receivers, then the system will receive data, but not be able to process them.
 *  When running locally, if you master URL is set to “local”, then there is only one core to run tasks. That is insufficient for programs with even one input DStream (file streams are okay) as the receiver will occupy that core and there will be no core left to process the data.

### Basic Sources ###

We have already taken a look at the `ssc.socketTextStream(...)` in the [quick example][A Quick Example] which creates a DStream from text data received over a TCP socket connection. Besides sockets, the StreamingContext API provides methods for creating DStreams from files and Akka actors as input sources.

*  **File Streams:** For reading data from files on any file system compatible with the HDFS API (that is, HDFS, S3, NFS, etc.), a DStream can be created as
    
     *  [**Scala**][Scala 3]
     *  [**Java**][Java 3]
    
        streamingContext.fileStream[keyClass, valueClass, inputFormatClass](dataDirectory)
    
    Spark Streaming will monitor the directory `dataDirectory` and process any files created in that directory (files written in nested directories not supported). Note that
    
     *  The files must have the same data format.
     *  The files must be created in the `dataDirectory` by atomically *moving* or *renaming* them into the data directory.
     *  Once moved, the files must not be changed. So if the files are being continuously appended, the new data will not be read.
    
    For simple text files, there is an easier method `streamingContext.textFileStream(dataDirectory)`. And file streams do not require running a receiver, hence does not require allocating cores.
 *  **Streams based on Custom Actors:** DStreams can be created with data streams received through Akka actors by using`streamingContext.actorStream(actorProps, actor-name)`. See the [Custom Receiver Guide][] for more details.
 *  **Queue of RDDs as a Stream:** For testing a Spark Streaming application with test data, one can also create a DStream based on a queue of RDDs, using `streamingContext.queueStream(queueOfRDDs)`. Each RDD pushed into the queue will be treated as a batch of data in the DStream, and processed like a stream.

For more details on streams from sockets, files, and actors, see the API documentations of the relevant functions in [StreamingContext][] for Scala and [JavaStreamingContext][] for Java.

### Advanced Sources ###

This category of sources require interfacing with external non-Spark libraries, some of them with complex dependencies (e.g., Kafka and Flume). Hence, to minimize issues related to version conflicts of dependencies, the functionality to create DStreams from these sources have been moved to separate libraries, that can be [linked to][Linking] explicitly as necessary. For example, if you want to create a DStream using data from Twitter’s stream of tweets, you have to do the following.

1.  *Linking*: Add the artifact `spark-streaming-twitter_2.10` to the SBT/Maven project dependencies.
2.  *Programming*: Import the `TwitterUtils` class and create a DStream with `TwitterUtils.createStream` as shown below.
3.  *Deploying*: Generate an uber JAR with all the dependencies (including the dependency `spark-streaming-twitter_2.10` and its transitive dependencies) and then deploy the application. This is further explained in the [Deploying section][Deploying Applications].

*  [**Scala**][Scala 4]
 *  [**Java**][Java 4]

import org.apache.spark.streaming.twitter._
    
    TwitterUtils.createStream(ssc)

Note that these advanced sources are not available in the `spark-shell`, hence applications based on these advanced sources cannot be tested in the shell.

Some of these advanced sources are as follows.

*  **Twitter:** Spark Streaming’s TwitterUtils uses Twitter4j 3.0.3 to get the public stream of tweets using [Twitter’s Streaming API][Twitter_s Streaming API]. Authentication information can be provided by any of the [methods][] supported by Twitter4J library. You can either get the public stream, or get the filtered stream based on a keywords. See the API documentation ([Scala][Scala 5], [Java][Java 5]) and examples ([TwitterPopularTags][] and [TwitterAlgebirdCMS][]).
 *  **Flume:** Spark Streaming 1.1.0 can received data from Flume 1.4.0. See the [Flume Integration Guide][] for more details.
 *  **Kafka:** Spark Streaming 1.1.0 can receive data from Kafka 0.8.0. See the [Kafka Integration Guide][] for more details.
 *  **Kinesis:** See the [Kinesis Integration Guide][] for more details.

### Custom Sources ###

Input DStreams can also be created out of custom data sources. All you have to do is implement an user-defined **receiver** (see next section to understand what that is) that can receive data from the custom sources and push it into Spark. See the [Custom Receiver Guide][Custom Receiver Guide 1] for details.

--------------------

## Transformations on DStreams ##

Similar to that of RDDs, transformations allow the data from the input DStream to be modified. DStreams support many of the transformations available on normal Spark RDD’s. Some of the common ones are as follows.

<table style="max-width:100%; border-collapse:collapse; border-spacing:0px; width:914px; margin-bottom:20px; color:rgb(51,51,51); font-family:'Helvetica Neue',Helvetica,Arial,sans-serif; font-size:14px; line-height:22.399999618530273px"> 
 <tbody> 
 <tr> 
 <th style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221); width:212px"> Transformation</th> 
 <th style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Meaning</th> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> map(func)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Return a new DStream by passing each element of the source DStream through a function&nbsp;func.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> flatMap(func)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Similar to map, but each input item can be mapped to 0 or more output items.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> filter(func)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Return a new DStream by selecting only the records of the source DStream on which&nbsp;func&nbsp;returns true.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> repartition(numPartitions)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Changes the level of parallelism in this DStream by creating more or fewer partitions.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> union(otherStream)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Return a new DStream that contains the union of the elements in the source DStream and&nbsp;otherDStream.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> count()</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Return a new DStream of single-element RDDs by counting the number of elements in each RDD of the source DStream.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> reduce(func)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Return a new DStream of single-element RDDs by aggregating the elements in each RDD of the source DStream using a function&nbsp;func&nbsp;(which takes two arguments and returns one). The function should be associative so that it can be computed in parallel.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> countByValue()</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> When called on a DStream of elements of type K, return a new DStream of (K, Long) pairs where the value of each key is its frequency in each RDD of the source DStream.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> reduceByKey(func, [numTasks])</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> When called on a DStream of (K, V) pairs, return a new DStream of (K, V) pairs where the values for each key are aggregated using the given reduce function.&nbsp;Note:&nbsp;By default, this uses Spark's default number of parallel tasks (2 for local mode, and in cluster mode the number is determined by the config property<code style="padding:0px; font-family:Menlo,'Lucida Console',monospace; font-size:12px; color:rgb(68,68,68); border:none">spark.default.parallelism</code>) to do the grouping. You can pass an optional&nbsp;<code style="padding:0px; font-family:Menlo,'Lucida Console',monospace; font-size:12px; color:rgb(68,68,68); border:none">numTasks</code>&nbsp;argument to set a different number of tasks.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> join(otherStream, [numTasks])</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> When called on two DStreams of (K, V) and (K, W) pairs, return a new DStream of (K, (V, W)) pairs with all pairs of elements for each key.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> cogroup(otherStream, [numTasks])</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> When called on DStream of (K, V) and (K, W) pairs, return a new DStream of (K, Seq[V], Seq[W]) tuples.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> transform(func)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Return a new DStream by applying a RDD-to-RDD function to every RDD of the source DStream. This can be used to do arbitrary RDD operations on the DStream.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> updateStateByKey(func)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Return a new "state" DStream where the state for each key is updated by applying the given function on the previous state of the key and the new values for the key. This can be used to maintain arbitrary state data for each key.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> &nbsp;</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> &nbsp;</td> 
 </tr> 
 </tbody> 
</table>

The last two transformations are worth highlighting again.

#### UpdateStateByKey Operation ####

The `updateStateByKey` operation allows you to maintain arbitrary state while continuously updating it with new information. To use this, you will have to do two steps.

1.  Define the state - The state can be of arbitrary data type.
2.  Define the state update function - Specify with a function how to update the state using the previous state and the new values from input stream.

Let’s illustrate this with an example. Say you want to maintain a running count of each word seen in a text data stream. Here, the running count is the state and it is an integer. We define the update function as

*  [**Scala**][Scala 6]
 *  [**Java**][Java 6]

def updateFunction(newValues: Seq[Int], runningCount: Option[Int]): Option[Int] = { 
        val newCount = ...  // add the new values with the previous running count to get the new count
        Some(newCount)
    }

This is applied on a DStream containing words (say, the `pairs` DStream containing `(word, 1)` pairs in the [earlier example][A Quick Example]).

val runningCounts = pairs.updateStateByKey[Int](updateFunction _)

The update function will be called for each word, with `newValues` having a sequence of 1’s (from the `(word, 1)` pairs) and the `runningCount`having the previous count. For the complete Scala code, take a look at the example [StatefulNetworkWordCount][].

#### Transform Operation ####

The `transform` operation (along with its variations like `transformWith`) allows arbitrary RDD-to-RDD functions to be applied on a DStream. It can be used to apply any RDD operation that is not exposed in the DStream API. For example, the functionality of joining every batch in a data stream with another dataset is not directly exposed in the DStream API. However, you can easily use `transform` to do this. This enables very powerful possibilities. For example, if you want to do real-time data cleaning by joining the input data stream with precomputed spam information (maybe generated with Spark as well) and then filtering based on it.

*  [**Scala**][Scala 7]
 *  [**Java**][Java 7]

val spamInfoRDD = ssc.sparkContext.newAPIHadoopRDD(...) // RDD containing spam information
    
    val cleanedDStream = wordCounts.transform(rdd => { 
      rdd.join(spamInfoRDD).filter(...) // join data stream with spam information to do data cleaning
      ...
    })

In fact, you can also use [machine learning][] and [graph computation][graph processing] algorithms in the `transform` method.

#### Window Operations ####

Finally, Spark Streaming also provides *windowed computations*, which allow you to apply transformations over a sliding window of data. This following figure illustrates this sliding window.

![Spark Streaming][Spark Streaming 4]

As shown in the figure, every time the window *slides* over a source DStream, the source RDDs that fall within the window are combined and operated upon to produce the RDDs of the windowed DStream. In this specific case, the operation is applied over last 3 time units of data, and slides by 2 time units. This shows that any window operation needs to specify two parameters.

*  *window length* - The duration of the window (3 in the figure)
 *  *sliding interval* - The interval at which the window operation is performed (2 in the figure).

These two parameters must be multiples of the batch interval of the source DStream (1 in the figure).

Let’s illustrate the window operations with an example. Say, you want to extend the [earlier example][A Quick Example] by generating word counts over last 30 seconds of data, every 10 seconds. To do this, we have to apply the `reduceByKey` operation on the `pairs` DStream of `(word, 1)` pairs over the last 30 seconds of data. This is done using the operation `reduceByKeyAndWindow`.

*  [**Scala**][Scala 8]
 *  [**Java**][Java 8]

// Reduce last 30 seconds of data, every 10 seconds
    val windowedWordCounts = pairs.reduceByKeyAndWindow((a:Int,b:Int) => (a + b), Seconds(30), Seconds(10))

Some of the common window operations are as follows. All of these operations take the said two parameters - *windowLength* and *slideInterval*.

<table style="max-width:100%; border-collapse:collapse; border-spacing:0px; width:914px; margin-bottom:20px; color:rgb(51,51,51); font-family:'Helvetica Neue',Helvetica,Arial,sans-serif; font-size:14px; line-height:22.399999618530273px"> 
 <tbody> 
 <tr> 
 <th style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221); width:276px"> Transformation</th> 
 <th style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Meaning</th> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> window(windowLength,&nbsp;slideInterval)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Return a new DStream which is computed based on windowed batches of the source DStream.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> countByWindow(windowLength,slideInterval)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Return a sliding window count of elements in the stream.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> reduceByWindow(func,&nbsp;windowLength,slideInterval)</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Return a new single-element stream, created by aggregating elements in the stream over a sliding interval using&nbsp;func. The function should be associative so that it can be computed correctly in parallel.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> reduceByKeyAndWindow(func,windowLength,&nbsp;slideInterval, [numTasks])</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> When called on a DStream of (K, V) pairs, returns a new DStream of (K, V) pairs where the values for each key are aggregated using the given reduce function&nbsp;func&nbsp;over batches in a sliding window.&nbsp;Note:&nbsp;By default, this uses Spark's default number of parallel tasks (2 for local mode, and in cluster mode the number is determined by the config property<code style="padding:0px; font-family:Menlo,'Lucida Console',monospace; font-size:12px; color:rgb(68,68,68); border:none">spark.default.parallelism</code>) to do the grouping. You can pass an optional&nbsp;<code style="padding:0px; font-family:Menlo,'Lucida Console',monospace; font-size:12px; color:rgb(68,68,68); border:none">numTasks</code>&nbsp;argument to set a different number of tasks.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> reduceByKeyAndWindow(func,&nbsp;invFunc,windowLength,&nbsp;slideInterval, [numTasks])</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> A more efficient version of the above&nbsp;<code style="padding:0px; font-family:Menlo,'Lucida Console',monospace; font-size:12px; color:rgb(68,68,68); border:none">reduceByKeyAndWindow()</code>&nbsp;where the reduce value of each window is calculated incrementally using the reduce values of the previous window. This is done by reducing the new data that enter the sliding window, and "inverse reducing" the old data that leave the window. An example would be that of "adding" and "subtracting" counts of keys as the window slides. However, it is applicable to only "invertible reduce functions", that is, those reduce functions which have a corresponding "inverse reduce" function (taken as parameterinvFunc. Like in&nbsp;<code style="padding:0px; font-family:Menlo,'Lucida Console',monospace; font-size:12px; color:rgb(68,68,68); border:none">reduceByKeyAndWindow</code>, the number of reduce tasks is configurable through an optional argument.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> countByValueAndWindow(windowLength,slideInterval, [numTasks])</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> When called on a DStream of (K, V) pairs, returns a new DStream of (K, Long) pairs where the value of each key is its frequency within a sliding window. Like in&nbsp;<code style="padding:0px; font-family:Menlo,'Lucida Console',monospace; font-size:12px; color:rgb(68,68,68); border:none">reduceByKeyAndWindow</code>, the number of reduce tasks is configurable through an optional argument.</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> &nbsp;</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> &nbsp;</td> 
 </tr> 
 </tbody> 
</table>

The complete list of DStream transformations is available in the API documentation. For the Scala API, see [DStream][] and [PairDStreamFunctions][]. For the Java API, see [JavaDStream][] and [JavaPairDStream][].

--------------------

## Output Operations on DStreams ##

Output operations allow DStream’s data to be pushed out external systems like a database or a file systems. Since the output operations actually allow the transformed data to be consumed by external systems, they trigger the actual execution of all the DStream transformations (similar to actions for RDDs). Currently, the following output operations are defined:

### Design Patterns for using foreachRDD ###

`dstream.foreachRDD` is a powerful primitive that allows data to sent out to external systems. However, it is important to understand how to use this primitive correctly and efficiently. Some of the common mistakes to avoid are as follows.

*  Often writing data to external system requires creating a connection object (e.g. TCP connection to a remote server) and using it to send data to a remote system. For this purpose, a developer may inadvertantly try creating a connection object at the Spark driver, but try to use it in a Spark worker to save records in the RDDs. For example (in Scala),
    
        dstream.foreachRDD(rdd => {
              val connection = createNewConnection()  // executed at the driver
              rdd.foreach(record => {
                  connection.send(record) // executed at the worker
              })
          })
    
    This is incorrect as this requires the connection object to be serialized and sent from the driver to the worker. Such connection objects are rarely transferrable across machines. This error may manifest as serialization errors (connection object not serializable), initialization errors (connection object needs to be initialized at the workers), etc. The correct solution is to create the connection object at the worker.
 *  However, this can lead to another common mistake - creating a new connection for every record. For example,
    
        dstream.foreachRDD(rdd => {
              rdd.foreach(record => {
                  val connection = createNewConnection()
                  connection.send(record)
                  connection.close()
              })
          })
    
    Typically, creating a connection object has time and resource overheads. Therefore, creating and destroying a connection object for each record can incur unnecessarily high overheads and can significantly reduce the overall throughput of the system. A better solution is to use`rdd.foreachPartition` - create a single connection object and send all the records in a RDD partition using that connection.
    
        dstream.foreachRDD(rdd => {
              rdd.foreachPartition(partitionOfRecords => {
                  val connection = createNewConnection()
                  partitionOfRecords.foreach(record => connection.send(record))
                  connection.close()
              })
          })
    
    This amortizes the connection creation overheads over many records.
 *  Finally, this can be further optimized by reusing connection objects across multiple RDDs/batches. One can maintain a static pool of connection objects than can be reused as RDDs of multiple batches are pushed to the external system, thus further reducing the overheads.
    
        dstream.foreachRDD(rdd => {
              rdd.foreachPartition(partitionOfRecords => {
                  // ConnectionPool is a static, lazily initialized pool of connections
                  val connection = ConnectionPool.getConnection()
                  partitionOfRecords.foreach(record => connection.send(record))
                  ConnectionPool.returnConnection(connection)  // return to the pool for future reuse
              })
          })
    
    Note that the connections in the pool should be lazily created on demand and timed out if not used for a while. This achieves the most efficient sending of data to external systems.

##### Other points to remember: #####

*  DStreams are executed lazily by the output operations, just like RDDs are lazily executed by RDD actions. Specifically, RDD actions inside the DStream output operations force the processing of the received data. Hence, if your application does not have any output operation, or has output operations like `dstream.foreachRDD()` without any RDD action inside them, then nothing will get executed. The system will simply receive the data and discard it.
 *  By default, output operations are executed one-at-a-time. And they are executed in the order they are defined in the application.

--------------------

## Caching / Persistence ##

Similar to RDDs, DStreams also allow developers to persist the stream’s data in memory. That is, using `persist()` method on a DStream would automatically persist every RDD of that DStream in memory. This is useful if the data in the DStream will be computed multiple times (e.g., multiple operations on the same data). For window-based operations like `reduceByWindow` and `reduceByKeyAndWindow` and state-based operations like `updateStateByKey`, this is implicitly true. Hence, DStreams generated by window-based operations are automatically persisted in memory, without the developer calling `persist()`.

For input streams that receive data over the network (such as, Kafka, Flume, sockets, etc.), the default persistence level is set to replicate the data to two nodes for fault-tolerance.

Note that, unlike RDDs, the default persistence level of DStreams keeps the data serialized in memory. This is further discussed in the[Performance Tuning][Memory Tuning] section. More information on different persistence levels can be found in [Spark Programming Guide][Spark Programming Guide 1].

--------------------

## Checkpointing ##

A *stateful operation* is one which operates over multiple batches of data. This includes all window-based operations and the `updateStateByKey`operation. Since stateful operations have a dependency on previous batches of data, they continuously accumulate metadata over time. To clear this metadata, streaming supports periodic *checkpointing* by saving intermediate data to HDFS. Note that checkpointing also incurs the cost of saving to HDFS which may cause the corresponding batch to take longer to process. Hence, the interval of checkpointing needs to be set carefully. At small batch sizes (say 1 second), checkpointing every batch may significantly reduce operation throughput. Conversely, checkpointing too slowly causes the lineage and task sizes to grow which may have detrimental effects. Typically, a checkpoint interval of 5 - 10 times of sliding interval of a DStream is good setting to try.

To enable checkpointing, the developer has to provide the HDFS path to which RDD will be saved. This is done by using

ssc.checkpoint(hdfsPath) // assuming ssc is the StreamingContext or JavaStreamingContext

The interval of checkpointing of a DStream can be set by using

dstream.checkpoint(checkpointInterval)

For DStreams that must be checkpointed (that is, DStreams created by `updateStateByKey` and `reduceByKeyAndWindow` with inverse function), the checkpoint interval of the DStream is by default set to a multiple of the DStream’s sliding interval such that its at least 10 seconds.

--------------------

## Deploying Applications ##

A Spark Streaming application is deployed on a cluster in the same way as any other Spark application. Please refer to the [deployment guide][] for more details.

Note that the applications that use [advanced sources][] (e.g. Kafka, Flume, Twitter) are also required to package the extra artifact they link to, along with their dependencies, in the JAR that is used to deploy the application. For example, an application using `TwitterUtils` will have to include `spark-streaming-twitter_2.10` and all its transitive dependencies in the application JAR.

If a running Spark Streaming application needs to be upgraded (with new application code), then there are two possible mechanism.

*  The upgraded Spark Streaming application is started and run in parallel to the existing application. Once the new one (receiving the same data as the old one) has been warmed up and ready for prime time, the old one be can be brought down. Note that this can be done for data sources that support sending the data to two destinations (i.e., the earlier and upgraded applications).
 *  The existing application is shutdown gracefully (see [`StreamingContext.stop(...)`][StreamingContext] or [`JavaStreamingContext.stop(...)`][JavaStreamingContext] for graceful shutdown options) which ensure data that have been received is completely processed before shutdown. Then the upgraded application can be started, which will start processing from the same point where the earlier application left off. Note that this can be done only with input sources that support source-side buffering (like Kafka, and Flume) as data needs to be buffered while the previous application down and the upgraded application is not yet up.

--------------------

## Monitoring Applications ##

Beyond Spark’s [monitoring capabilities][], there are additional capabilities specific to Spark Streaming. When a StreamingContext is used, the[Spark web UI][] shows an additional `Streaming` tab which shows statistics about running receivers (whether receivers are active, number of records received, receiver error, etc.) and completed batches (batch processing times, queueing delays, etc.). This can be used to monitor the progress of the streaming application.

The following two metrics in web UI is particularly important - *Processing Time* and *Scheduling Delay* (under *Batch Processing Statistics*). The first is the time to process each batch of data, and the second is the time a batch waits in a queue for the processing of previous batches to finish. If the batch processing time is consistently more than the batch interval and/or the queueing delay keeps increasing, then it indicates the system is not able to process the batches as fast they are being generated and falling behind. In that case, consider [reducing][Reducing the Processing Time of each Batch] the batch processing time.

The progress of a Spark Streaming program can also be monitored using the [StreamingListener][] interface, which allows you to get receiver status and processing times. Note that this is a developer API and it is likely to be improved upon (i.e., more information reported) in the future.

--------------------

# Performance Tuning #

Getting the best performance of a Spark Streaming application on a cluster requires a bit of tuning. This section explains a number of the parameters and configurations that can tuned to improve the performance of you application. At a high level, you need to consider two things:

1.  Reducing the processing time of each batch of data by efficiently using cluster resources.
2.  Setting the right batch size such that the batches of data can be processed as fast as they are received (that is, data processing keeps up with the data ingestion).

## Reducing the Processing Time of each Batch ##

There are a number of optimizations that can be done in Spark to minimize the processing time of each batch. These have been discussed in detail in [Tuning Guide][]. This section highlights some of the most important ones.

### Level of Parallelism in Data Receiving ###

Receiving data over the network (like Kafka, Flume, socket, etc.) requires the data to deserialized and stored in Spark. If the data receiving becomes a bottleneck in the system, then consider parallelizing the data receiving. Note that each input DStream creates a single receiver (running on a worker machine) that receives a single stream of data. Receiving multiple data streams can therefore be achieved by creating multiple input DStreams and configuring them to receive different partitions of the data stream from the source(s). For example, a single Kafka input DStream receiving two topics of data can be split into two Kafka input streams, each receiving only one topic. This would run two receivers on two workers, thus allowing data to be received in parallel, and increasing overall throughput. These multiple DStream can be unioned together to create a single DStream. Then the transformations that was being applied on the single input DStream can applied on the unified stream. This is done as follows.

*  [**Scala**][Scala 9]
 *  [**Java**][Java 9]

val numStreams = 5
    val kafkaStreams = (1 to numStreams).map {  i => KafkaUtils.createStream(...) }
    val unifiedStream = streamingContext.union(kafkaStreams)
    unifiedStream.print()

Another parameter that should be considered is the receiver’s blocking interval. For most receivers, the received data is coalesced together into large blocks of data before storing inside Spark’s memory. The number of blocks in each batch determines the number of tasks that will be used to process those the received data in a map-like transformation. This blocking interval is determined by the [configuration parameter][]`spark.streaming.blockInterval` and the default value is 200 milliseconds.

An alternative to receiving data with multiple input streams / receivers is to explicitly repartition the input data stream (using`inputStream.repartition(<number of partitions>)`). This distributes the received batches of data across specified number of machines in the cluster before further processing.

### Level of Parallelism in Data Processing ###

Cluster resources can be under-utilized if the number of parallel tasks used in any stage of the computation is not high enough. For example, for distributed reduce operations like `reduceByKey` and `reduceByKeyAndWindow`, the default number of parallel tasks is decided by the \[config property\] (configuration.html\#spark-properties) `spark.default.parallelism`. You can pass the level of parallelism as an argument (see \[`PairDStreamFunctions`\] (api/scala/index.html\#org.apache.spark.streaming.dstream.PairDStreamFunctions) documentation), or set the [config property][] `spark.default.parallelism` to change the default.

### Data Serialization ###

The overhead of data serialization can be significant, especially when sub-second batch sizes are to be achieved. There are two aspects to it.

*  **Serialization of RDD data in Spark**: Please refer to the detailed discussion on data serialization in the [Tuning Guide][]. However, note that unlike Spark, by default RDDs are persisted as serialized byte arrays to minimize pauses related to GC.
 *  **Serialization of input data**: To ingest external data into Spark, data received as bytes (say, from the network) needs to deserialized from bytes and re-serialized into Spark’s serialization format. Hence, the deserialization overhead of input data may be a bottleneck.

### Task Launching Overheads ###

If the number of tasks launched per second is high (say, 50 or more per second), then the overhead of sending out tasks to the slaves maybe significant and will make it hard to achieve sub-second latencies. The overhead can be reduced by the following changes:

*  **Task Serialization**: Using Kryo serialization for serializing tasks can reduce the task sizes, and therefore reduce the time taken to send them to the slaves.
 *  **Execution mode**: Running Spark in Standalone mode or coarse-grained Mesos mode leads to better task launch times than the fine-grained Mesos mode. Please refer to the [Running on Mesos guide][] for more details.

These changes may reduce batch processing time by 100s of milliseconds, thus allowing sub-second batch size to be viable.

--------------------

## Setting the Right Batch Size ##

For a Spark Streaming application running on a cluster to be stable, the system should be able to process data as fast as it is being received. In other words, batches of data should be processed as fast as they are being generated. Whether this is true for an application can be found by[monitoring][] the processing times in the streaming web UI, where the batch processing time should be less than the batch interval.

Depending on the nature of the streaming computation, the batch interval used may have significant impact on the data rates that can be sustained by the application on a fixed set of cluster resources. For example, let us consider the earlier WordCountNetwork example. For a particular data rate, the system may be able to keep up with reporting word counts every 2 seconds (i.e., batch interval of 2 seconds), but not every 500 milliseconds. So the batch interval needs to be set such that the expected data rate in production can be sustained.

A good approach to figure out the right batch size for your application is to test it with a conservative batch interval (say, 5-10 seconds) and a low data rate. To verify whether the system is able to keep up with data rate, you can check the value of the end-to-end delay experienced by each processed batch (either look for “Total delay” in Spark driver log4j logs, or use the [StreamingListener][StreamingListener 1] interface). If the delay is maintained to be comparable to the batch size, then system is stable. Otherwise, if the delay is continuously increasing, it means that the system is unable to keep up and it therefore unstable. Once you have an idea of a stable configuration, you can try increasing the data rate and/or reducing the batch size. Note that momentary increase in the delay due to temporary data rate increases maybe fine as long as the delay reduces back to a low value (i.e., less than batch size).

--------------------

## Memory Tuning ##

Tuning the memory usage and GC behavior of Spark applications have been discussed in great detail in the [Tuning Guide][]. It is recommended that you read that. In this section, we highlight a few customizations that are strongly recommended to minimize GC related pauses in Spark Streaming applications and achieving more consistent batch processing times.

*  **Default persistence level of DStreams**: Unlike RDDs, the default persistence level of DStreams serializes the data in memory (that is,[StorageLevel.MEMORY\_ONLY\_SER][StorageLevel.MEMORY_ONLY_SER] for DStream compared to [StorageLevel.MEMORY\_ONLY][StorageLevel.MEMORY_ONLY_SER] for RDDs). Even though keeping the data serialized incurs higher serialization/deserialization overheads, it significantly reduces GC pauses.
 *  **Clearing persistent RDDs**: By default, all persistent RDDs generated by Spark Streaming will be cleared from memory based on Spark’s built-in policy (LRU). If `spark.cleaner.ttl` is set, then persistent RDDs that are older than that value are periodically cleared. As mentioned[earlier][], this needs to be careful set based on operations used in the Spark Streaming program. However, a smarter unpersisting of RDDs can be enabled by setting the [configuration property][config property] `spark.streaming.unpersist` to `true`. This makes the system to figure out which RDDs are not necessary to be kept around and unpersists them. This is likely to reduce the RDD memory usage of Spark, potentially improving GC behavior as well.
 *  **Concurrent garbage collector**: Using the concurrent mark-and-sweep GC further minimizes the variability of GC pauses. Even though concurrent GC is known to reduce the overall processing throughput of the system, its use is still recommended to achieve more consistent batch processing times.

--------------------

# Fault-tolerance Properties #

In this section, we are going to discuss the behavior of Spark Streaming application in the event of a node failure. To understand this, let us remember the basic fault-tolerance properties of Spark’s RDDs.

1.  An RDD is an immutable, deterministically re-computable, distributed dataset. Each RDD remembers the lineage of deterministic operations that were used on a fault-tolerant input dataset to create it.
2.  If any partition of an RDD is lost due to a worker node failure, then that partition can be re-computed from the original fault-tolerant dataset using the lineage of operations.

Since all data transformations in Spark Streaming are based on RDD operations, as long as the input dataset is present, all intermediate data can recomputed. Keeping these properties in mind, we are going to discuss the failure semantics in more detail.

## Failure of a Worker Node ##

There are two failure behaviors based on which input sources are used.

1.  *Using HDFS files as input source* - Since the data is reliably stored on HDFS, all data can re-computed and therefore no data will be lost due to any failure.
2.  *Using any input source that receives data through a network* - For network-based data sources like Kafka and Flume, the received input data is replicated in memory between nodes of the cluster (default replication factor is 2). So if a worker node fails, then the system can recompute the lost from the the left over copy of the input data. However, if the worker node where a network receiver was running fails, then a tiny bit of data may be lost, that is, the data received by the system but not yet replicated to other node(s). The receiver will be started on a different node and it will continue to receive data.

Since all data is modeled as RDDs with their lineage of deterministic operations, any recomputation always leads to the same result. As a result, all DStream transformations are guaranteed to have *exactly-once* semantics. That is, the final transformed result will be same even if there were was a worker node failure. However, output operations (like `foreachRDD`) have *at-least once* semantics, that is, the transformed data may get written to an external entity more than once in the event of a worker failure. While this is acceptable for saving to HDFS using the `saveAs*Files`operations (as the file will simply get over-written by the same data), additional transactions-like mechanisms may be necessary to achieve exactly-once semantics for output operations.

## Failure of the Driver Node ##

For a streaming application to operate 24/7, Spark Streaming allows a streaming computation to be resumed even after the failure of the driver node. Spark Streaming periodically writes the metadata information of the DStreams setup through the `StreamingContext` to a HDFS directory (can be any Hadoop-compatible filesystem). This periodic *checkpointing* can be enabled by setting the checkpoint directory using`ssc.checkpoint(<checkpoint directory>)` as described [earlier][earlier 1]. On failure of the driver node, the lost `StreamingContext` can be recovered from this information, and restarted.

To allow a Spark Streaming program to be recoverable, it must be written in a way such that it has the following behavior:

1.  When the program is being started for the first time, it will create a new StreamingContext, set up all the streams and then call start().
2.  When the program is being restarted after failure, it will re-create a StreamingContext from the checkpoint data in the checkpoint directory.

*  [**Scala**][Scala 10]
 *  [**Java**][Java 10]

This behavior is made simple by using `StreamingContext.getOrCreate`. This is used as follows.

// Function to create and setup a new StreamingContext
    def functionToCreateContext(): StreamingContext = { 
        val ssc = new StreamingContext(...)   // new context
        val lines = ssc.socketTextStream(...) // create DStreams
        ...
        ssc.checkpoint(checkpointDirectory)   // set checkpoint directory
        ssc
    }
    
    // Get StreamingContext from checkpoint data or create a new one
    val context = StreamingContext.getOrCreate(checkpointDirectory, functionToCreateContext _)
    
    // Do additional setup on context that needs to be done,
    // irrespective of whether it is being started or restarted
    context. ...
    
    // Start the context
    context.start()
    context.awaitTermination()

If the `checkpointDirectory` exists, then the context will be recreated from the checkpoint data. If the directory does not exist (i.e., running for the first time), then the function `functionToCreateContext` will be called to create a new context and set up the DStreams. See the Scala example[RecoverableNetworkWordCount][]. This example appends the word counts of network data into a file.

You can also explicitly create a `StreamingContext` from the checkpoint data and start the computation by using `new StreamingContext(checkpointDirectory)`.

**Note**: If Spark Streaming and/or the Spark Streaming program is recompiled, you *must* create a new `StreamingContext` or `JavaStreamingContext`, not recreate from checkpoint data. This is because trying to load a context from checkpoint data may fail if the data was generated before recompilation of the classes. So, if you are using `getOrCreate`, then make sure that the checkpoint directory is explicitly deleted every time recompiled code needs to be launched.

This failure recovery can be done automatically using Spark’s [standalone cluster mode][], which allows the driver of any Spark application to be launched within the cluster and be restarted on failure (see [supervise mode][]). This can be tested locally by launching the above example using the supervise mode in a local standalone cluster and killing the java process running the driver (will be shown as *DriverWrapper* when `jps` is run to show all active Java processes). The driver should be automatically restarted, and the word counts will cont

For other deployment environments like Mesos and Yarn, you have to restart the driver through other mechanisms.

#### Recovery Semantics ####

There are two different failure behaviors based on which input sources are used.

1.  *Using HDFS files as input source* - Since the data is reliably stored on HDFS, all data can re-computed and therefore no data will be lost due to any failure.
2.  *Using any input source that receives data through a network* - The received input data is replicated in memory to multiple nodes. Since all the data in the Spark worker’s memory is lost when the Spark driver fails, the past input data will not be accessible and driver recovers. Hence, if stateful and window-based operations are used (like `updateStateByKey`, `window`, `countByValueAndWindow`, etc.), then the intermediate state will not be recovered completely.

In future releases, we will support full recoverability for all input sources. Note that for non-stateful transformations like `map`, `count`, and`reduceByKey`, with *all* input streams, the system, upon restarting, will continue to receive and process new data.

To better understand the behavior of the system under driver failure with a HDFS source, let’s consider what will happen with a file input stream. Specifically, in the case of the file input stream, it will correctly identify new files that were created while the driver was down and process them in the same way as it would have if the driver had not failed. To explain further in the case of file input stream, we shall use an example. Let’s say, files are being generated every second, and a Spark Streaming program reads every new file and output the number of lines in the file. This is what the sequence of outputs would be with and without a driver failure.

<table style="max-width:100%; border-collapse:collapse; border-spacing:0px; width:914px; margin-bottom:20px; color:rgb(51,51,51); font-family:'Helvetica Neue',Helvetica,Arial,sans-serif; font-size:14px; line-height:22.399999618530273px"> 
 <tbody> 
 <tr> 
 <th style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Time</th> 
 <th style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Number of lines in input file</th> 
 <th style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Output without driver failure</th> 
 <th style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> Output with driver failure</th> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 1</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 10</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 10</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 10</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 2</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 20</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 20</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 20</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 3</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 30</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 30</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 30</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 4</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 40</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 40</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> [DRIVER FAILS] no output</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 5</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 50</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 50</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> no output</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 6</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 60</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 60</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> no output</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 7</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 70</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 70</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> [DRIVER RECOVERS] 40, 50, 60, 70</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 8</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 80</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 80</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 80</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 9</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 90</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 90</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 90</td> 
 </tr> 
 <tr> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 10</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 100</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 100</td> 
 <td style="padding:8px; line-height:20px; vertical-align:top; border-top-width:1px; border-top-style:solid; border-top-color:rgb(221,221,221)"> 100</td> 
 </tr> 
 </tbody> 
</table>

If the driver had crashed in the middle of the processing of time 3, then it will process time 3 and output 30 after recovery.

--------------------

# Migration Guide from 0.9.1 or below to 1.x #

Between Spark 0.9.1 and Spark 1.0, there were a few API changes made to ensure future API stability. This section elaborates the steps required to migrate your existing code to 1.0.

**Input DStreams**: All operations that create an input stream (e.g., `StreamingContext.socketStream`, `FlumeUtils.createStream`, etc.) now returns[InputDStream][] / [ReceiverInputDStream][] (instead of DStream) for Scala, and [JavaInputDStream][] / [JavaPairInputDStream][] /[JavaReceiverInputDStream][] / [JavaPairReceiverInputDStream][] (instead of JavaDStream) for Java. This ensures that functionality specific to input streams can be added to these classes in the future without breaking binary compatibility. Note that your existing Spark Streaming applications should not require any change (as these new classes are subclasses of DStream/JavaDStream) but may require recompilation with Spark 1.0.

**Custom Network Receivers**: Since the release to Spark Streaming, custom network receivers could be defined in Scala using the class NetworkReceiver. However, the API was limited in terms of error handling and reporting, and could not be used from Java. Starting Spark 1.0, this class has been replaced by [Receiver][] which has the following advantages.

*  Methods like `stop` and `restart` have been added to for better control of the lifecycle of a receiver. See the [custom receiver guide][Custom Receiver Guide 1] for more details.
 *  Custom receivers can be implemented using both Scala and Java.

To migrate your existing custom receivers from the earlier NetworkReceiver to the new Receiver, you have to do the following.

* Make your custom receiver class extend [`org.apache.spark.streaming.receiver.Receiver`][Receiver] instead of`org.apache.spark.streaming.dstream.NetworkReceiver`.
 * Earlier, a BlockGenerator object had to be created by the custom receiver, to which received data was added for being stored in Spark. It had to be explicitly started and stopped from `onStart()` and `onStop()` methods. The new Receiver class makes this unnecessary as it adds a set of methods named `store(<data>)` that can be called to store the data in Spark. So, to migrate your custom network receiver, remove any BlockGenerator object (does not exist any more in Spark 1.0 anyway), and use `store(...)` methods on received data.

**Actor-based Receivers**: Data could have been received using any Akka Actors by extending the actor class with`org.apache.spark.streaming.receivers.Receiver` trait. This has been renamed to [`org.apache.spark.streaming.receiver.ActorHelper`][org.apache.spark.streaming.receiver.ActorHelper] and the`pushBlock(...)` methods to store received data has been renamed to `store(...)`. Other helper classes in the`org.apache.spark.streaming.receivers` package were also moved to [`org.apache.spark.streaming.receiver`][org.apache.spark.streaming.receiver] package and renamed for better clarity.

--------------------

# Where to Go from Here #

*  API documentation
    
     *  Scala docs
        
         *  [StreamingContext][] and [DStream][]
         *  [KafkaUtils][], [FlumeUtils][], [KinesisUtils][], [TwitterUtils][Scala 5], [ZeroMQUtils][], and [MQTTUtils][]
     *  Java docs
        
         *  [JavaStreamingContext][], [JavaDStream][] and [PairJavaDStream][]
         *  [KafkaUtils][KafkaUtils 1], [FlumeUtils][FlumeUtils 1], [KinesisUtils][KinesisUtils 1] [TwitterUtils][Java 5], [ZeroMQUtils][ZeroMQUtils 1], and [MQTTUtils][MQTTUtils 1]
 *  More examples in [Scala][Scala 11] and [Java][Java 11]
 *  [Paper][] and [video][] describing Spark Streaming.

[Overview]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#overview
[A Quick Example]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#a-quick-example
[Basic Concepts]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#basic-concepts
[Linking]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#linking
[Initializing StreamingContext]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#initializing-streamingcontext
[Discretized Streams _DStreams]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#discretized-streams-dstreams
[Input DStreams]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#input-dstreams
[Transformations on DStreams]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#transformations-on-dstreams
[Output Operations on DStreams]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#output-operations-on-dstreams
[Caching _ Persistence]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#caching--persistence
[Checkpointing]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#checkpointing
[Deploying Applications]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#deploying-applications
[Monitoring Applications]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#monitoring-applications
[Performance Tuning]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#performance-tuning
[Reducing the Processing Time of each Batch]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#reducing-the-processing-time-of-each-batch
[Setting the Right Batch Size]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#setting-the-right-batch-size
[Memory Tuning]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#memory-tuning
[Fault-tolerance Properties]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#fault-tolerance-properties
[Failure of a Worker Node]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#failure-of-a-worker-node
[Failure of the Driver Node]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#failure-of-the-driver-node
[Migration Guide from 0.9.1 or below to 1.x]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#migration-guide-from-091-or-below-to-1x
[Where to Go from Here]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#where-to-go-from-here
[machine learning]: http://spark.apache.org/docs/latest/mllib-guide.html
[graph processing]: http://spark.apache.org/docs/latest/graphx-programming-guide.html
[Spark Streaming]: /images/20220810/f63defbb479a47708b8b05f318c24c09.png
[Spark Streaming 1]: /images/20220810/9e3d09fd70324bebaf582490163bc284.png
[RDDs]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.rdd.RDD
[Scala]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_scala_0
[Java]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_java_0
[StreamingContext]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.StreamingContext
[NetworkWordCount]: https://github.com/apache/spark/blob/master/examples/src/main/scala/org/apache/spark/examples/streaming/NetworkWordCount.scala
[downloaded]: http://spark.apache.org/docs/latest/index.html#downloading
[built]: http://spark.apache.org/docs/latest/index.html#building
[Scala 1]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_scala_1
[Java 1]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_java_1
[Maven]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_Maven_2
[SBT]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_SBT_2
[Apache repository]: http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.spark%22%20AND%20v%3A%221.1.0%22
[Scala 2]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_scala_3
[Java 2]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_java_3
[SparkConf]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.SparkConf
[Spark_ Mesos or YARN cluster URL]: http://spark.apache.org/docs/latest/submitting-applications.html#master-urls
[launch the application with_spark-submit]: http://spark.apache.org/docs/latest/submitting-applications.html
[SparkContext]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.SparkContext
[Spark Programming Guide]: http://spark.apache.org/docs/latest/programming-guide.html#resilient-distributed-datasets-rdds
[Spark Streaming 2]: /images/20220810/bff844a7160648fdafbec1c90f11ec7f.png
[Spark Streaming 3]: /images/20220810/8cd16acaecbf4b0baa42ca8ca262ceb4.png
[Receiver]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.receiver.Receiver
[Performance Tuning 1]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#level-of-parallelism-in-data-receiving
[Scala 3]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_scala_4
[Java 3]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_java_4
[Custom Receiver Guide]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#implementing-and-using-a-custom-actor-based-receiver
[JavaStreamingContext]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/api/java/JavaStreamingContext.html
[Scala 4]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_scala_5
[Java 4]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_java_5
[Twitter_s Streaming API]: https://dev.twitter.com/docs/streaming-apis
[methods]: http://twitter4j.org/en/configuration.html
[Scala 5]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.twitter.TwitterUtils$
[Java 5]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/twitter/TwitterUtils.html
[TwitterPopularTags]: https://github.com/apache/spark/blob/master/examples/src/main/scala/org/apache/spark/examples/streaming/TwitterPopularTags.scala
[TwitterAlgebirdCMS]: https://github.com/apache/spark/blob/master/examples/src/main/scala/org/apache/spark/examples/streaming/TwitterAlgebirdCMS.scala
[Flume Integration Guide]: http://spark.apache.org/docs/latest/streaming-flume-integration.html
[Kafka Integration Guide]: http://spark.apache.org/docs/latest/streaming-kafka-integration.html
[Kinesis Integration Guide]: http://spark.apache.org/docs/latest/streaming-kinesis-integration.html
[Custom Receiver Guide 1]: http://spark.apache.org/docs/latest/streaming-custom-receivers.html
[Scala 6]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_scala_6
[Java 6]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_java_6
[StatefulNetworkWordCount]: https://github.com/apache/spark/blob/master/examples/src/main/scala/org/apache/spark/examples/streaming/StatefulNetworkWordCount.scala
[Scala 7]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_scala_7
[Java 7]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_java_7
[Spark Streaming 4]: /images/20220810/7b05d354256c4ca1a495dab2531898b8.png
[Scala 8]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_scala_8
[Java 8]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_java_8
[DStream]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.dstream.DStream
[PairDStreamFunctions]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.dstream.PairDStreamFunctions
[JavaDStream]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/api/java/JavaDStream.html
[JavaPairDStream]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/api/java/JavaPairDStream.html
[Spark Programming Guide 1]: http://spark.apache.org/docs/latest/programming-guide.html#rdd-persistence
[deployment guide]: http://spark.apache.org/docs/latest/cluster-overview.html
[advanced sources]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#advanced-sources
[monitoring capabilities]: http://spark.apache.org/docs/latest/monitoring.html
[Spark web UI]: http://spark.apache.org/docs/latest/monitoring.html#web-interfaces
[StreamingListener]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.scheduler.StreamingListener
[Tuning Guide]: http://spark.apache.org/docs/latest/tuning.html
[Scala 9]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_scala_9
[Java 9]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_java_9
[configuration parameter]: http://spark.apache.org/docs/latest/configuration.html
[config property]: http://spark.apache.org/docs/latest/configuration.html#spark-properties
[Running on Mesos guide]: http://spark.apache.org/docs/latest/running-on-mesos.html
[monitoring]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#monitoring
[StreamingListener 1]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.scheduler.StreamingListener
[StorageLevel.MEMORY_ONLY_SER]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.storage.StorageLevel$
[earlier]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#operation
[earlier 1]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#rdd-checkpointing
[Scala 10]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_scala_10
[Java 10]: http://spark.apache.org/docs/latest/streaming-programming-guide.html#tab_java_10
[RecoverableNetworkWordCount]: https://github.com/apache/spark/tree/master/examples/src/main/scala/org/apache/spark/examples/streaming/RecoverableNetworkWordCount.scala
[standalone cluster mode]: http://spark.apache.org/docs/latest/spark-standalone.html
[supervise mode]: http://spark.apache.org/docs/latest/spark-standalone.html#launching-applications-inside-the-cluster
[InputDStream]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.dstream.InputDStream
[ReceiverInputDStream]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.dstream.ReceiverInputDStream
[JavaInputDStream]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/api/java/JavaInputDStream.html
[JavaPairInputDStream]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/api/java/JavaPairInputDStream.html
[JavaReceiverInputDStream]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/api/java/JavaReceiverInputDStream.html
[JavaPairReceiverInputDStream]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/api/java/JavaPairReceiverInputDStream.html
[org.apache.spark.streaming.receiver.ActorHelper]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.receiver.ActorHelper
[org.apache.spark.streaming.receiver]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.receiver.package
[KafkaUtils]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.kafka.KafkaUtils$
[FlumeUtils]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.flume.FlumeUtils$
[KinesisUtils]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.kinesis.KinesisUtils$
[ZeroMQUtils]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.zeromq.ZeroMQUtils$
[MQTTUtils]: http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.streaming.mqtt.MQTTUtils$
[PairJavaDStream]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/api/java/PairJavaDStream.html
[KafkaUtils 1]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/kafka/KafkaUtils.html
[FlumeUtils 1]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/flume/FlumeUtils.html
[KinesisUtils 1]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/kinesis/KinesisUtils.html
[ZeroMQUtils 1]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/zeromq/ZeroMQUtils.html
[MQTTUtils 1]: http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/streaming/mqtt/MQTTUtils.html
[Scala 11]: https://github.com/apache/spark/tree/master/examples/src/main/scala/org/apache/spark/examples/streaming
[Java 11]: https://github.com/apache/spark/tree/master/examples/src/main/java/org/apache/spark/examples/streaming
[Paper]: http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-259.pdf
[video]: http://youtu.be/g171ndOHgJ0