DStream：

实际上，DStream代表一系列持续的RDD
每一个在DStream中的RDD都代表着某个批次

一个DStream由多个RDD构成，对于DStream的操作底层都是基于RDD；

对DStream操作算子，比如map/flatMap，其实底层会被翻译为对DStream中的每个RDD都做相同的操作；
因为一个DStream是由不同批次的RDD所构成的。

参考：https://www.jianshu.com/p/8c3908fe9ffa

Input DStreams和Receivers：

每个输入DStream（文件流除外）都与Receiver对象相关联，该对象从源接收数据并将其存储在Spark的内存中进行处理。
基本输入源：file systems, and socket connections
高级输入源：Kafka, Flume, Kinesis等

Transformation和Output Operations

DStreams支持Spark Spark RDD的许多转换
一些常见的如下：map、flatMap、filter、repartition、count、countByValue、reduceByKey等
Output Operations：saveAsTextFiles、saveAsObjectFiles、saveAsHadoopFiles、foreachRDD等

带状态的算子：UpdateStateByKey

例如：统计到目前为止累计出现的单词的个数(需要保持住以前的状态)
定义状态——状态可以是任意的数据类型。
定义状态更新功能——用一个函数指定如何使用前一个状态更新状态，以及来自输入流的新值。

备注：
// 如果使用了stateful的算子，必须设置checkpoint
// 在生产环境中，建议大家把checkpoint设置到HDFS的某个文件夹中

窗口函数的使用

window：定时的进行一个时间段内的数据处理

window length ： 窗口的长度
sliding interval： 窗口的间隔

Spark Streaming整合Kafka的两种方式

参考：Spark-Streaming获取kafka数据的两种方式：Receiver与Direct的方式

Receive-based：基于接收者
算子：KafkaUtils.createStream
方法：PUSH，从topic中去推送数据，将数据推送过来
API：调用的Kafka高级API
效果：

SparkStreaming中的Receivers，恰好Kafka有发布/订阅 ，然而：此种方式企业不常用，说明有BUG，不符合企业需求。因为：接收到的数据存储在Executor的内存，会出现数据漏处理或者多处理状况

解释：

使用Kafka的高层次Consumer API来实现。receiver从Kafka中获取的数据都存储在Spark Executor的内存中，然后Spark Streaming启动的job会去处理那些数据。然而，在默认的配置下，这种方式可能会因为底层的失败而丢失数据。如果要启用高可靠机制，让数据零丢失，就必须启用Spark Streaming的预写日志机制（Write Ahead Log，WAL）。该机制会同步地将接收到的Kafka数据写入分布式文件系统（比如HDFS）上的预写日志中。所以，即使底层节点出现了失败，也可以使用预写日志中的数据进行恢复。

缺点：

1、Kafka中topic的partition与Spark中RDD的partition是没有关系的，因此，在KafkaUtils.createStream()中，提高partition的数量，只会增加Receiver的数量，也就是读取Kafka中topic partition的线程数量，不会增加Spark处理数据的并行度。

2、可以创建多个Kafka输入DStream，使用不同的consumer group和topic，来通过多个receiver并行接收数据。

3、如果基于容错的文件系统，比如HDFS，启用了预写日志机制，接收到的数据都会被复制一份到预写日志中。因此，在KafkaUtils.createStream()中，设置的持久化级别是StorageLevel.MEMORY_AND_DISK_SER。

Direct Approach：直接方法
算子：KafkaUtils.createDirectStream
方式：PULL，到topic中去拉取数据。
API：kafka低级API
效果：

每次到Topic的每个分区依据偏移量进行获取数据，拉取数据以后进行处理，可以实现高可用

解释：

在Spark 1.3中引入了这种新的无接收器“直接”方法，以确保更强大的端到端保证。这种方法不是使用接收器来接收数据，而是定期查询Kafka在每个topic+分partition中的最新偏移量，并相应地定义要在每个批次中处理的偏移量范围。当处理数据的作业启动时，Kafka简单的客户API用于读取Kafka中定义的偏移范围（类似于从文件系统读取文件）。请注意，此功能在Spark 1.3中为Scala和Java API引入，在Spark 1.4中针对Python API引入。

优势：

1、简化并行读取：如果要读取多个partition，不需要创建多个输入DStream，然后对它们进行union操作。Spark会创建跟Kafka partition一样多的RDD partition，并且会并行从Kafka中读取数据。所以在Kafka partition和RDD partition之间，有一个一对一的映射关系。

2、高性能：如果要保证零数据丢失，在基于receiver的方式中，需要开启WAL机制。这种方式其实效率低下，因为数据实际上被复制了两份，Kafka自己本身就有高可靠的机制会对数据复制一份，而这里又会复制一份到WAL中。而基于direct的方式，不依赖Receiver，不需要开启WAL机制，只要Kafka中作了数据的复制，那么就可以通过Kafka的副本进行恢复。

3、一次且仅一次的事务机制：基于receiver的方式，是使用Kafka的高阶API来在ZooKeeper中保存消费过的offset的。这是消费Kafka数据的传统方式。这种方式配合着WAL机制可以保证数据零丢失的高可靠性，但是却无法保证数据被处理一次且仅一次，可能会处理两次。因为Spark和ZooKeeper之间可能是不同步的。基于direct的方式，使用kafka的简单api，Spark Streaming自己就负责追踪消费的offset，并保存在checkpoint中。Spark自己一定是同步的，因此可以保证数据是消费一次且仅消费一次。

由于数据消费偏移量是保存在checkpoint中，因此，如果后续想使用kafka高级API消费数据，需要手动的更新zookeeper中的偏移量