流式处理：数据源源不断的产生 并且不断的处理
采样时间：每隔一段时间去拿一次数据
2.原理与架构
1.原理
2.sparkstreaming数据处理流程特点
3.sparkstreaming的数据容错
4.实时性
对于目前版本的Spark Streaming而言，其最小的Batch Size的选取在0.1秒钟之间（Storm目前最小的延迟是100ms左右），所以Spark Streaming能够满足除对实时性要求非常高（如高频实时交易）之外的所有流式准实时计算场景。
对比storm，storm实时性非常高，数据来一条处理一条
针对于实时性非常高的业务场景可以选择storm或者flink
针对于实时性不是非常高的业务场景，允许有一点点延迟，可以选用Sparkstreaming
5.spark的架构
3.DStream
3.1什么是Dstream？（Dstream就是包含了一堆的小RDD）
Discretized Stream是Spark Streaming的基础抽象，代表持续性的数据流和经过各种Spark算子操作后的结果数据流。在内部实现上，DStream是一系列连续的RDD来表示。每个RDD含有一段时间间隔内的数据，
4.Dstream相关操作
4.1：Transformations on DStreams
比较特殊的算子：
（updateStateByKey有缺点，工作中不常用）
|
transform(func) |
通过RDD-to-RDD函数作用于DStream中的各个RDD，可以是任意的RDD操作，从而返回一个新的RDD |
|
updateStateByKey(func) |
根据key的之前状态值和key的新值，对key进行更新，返回一个新状态的DStream |
transform算子
（1）UpdateStateByKey Operation
UpdateStateByKey用于记录历史记录，保存上次的状态
（2）Window Operations(开窗函数)
窗口函数：需要两个参数（窗口长度，滑动距离）
窗口长度和滑动距离必须是采样时间的整数倍
滑动窗口转换操作:
4.2：Output Operations on DStreams
kafka中的topic的分区和sparkstreaming中生成的rdd没有啥关系，早kafkaUtils.createStream中增加分区
|
foreachRDD(func) |
对Dstream里面的每个RDD执行func |
开窗函数
开窗函数：需要两个参数（窗口长度，滑动距离)
kafka与streaming的集成
支持两种消费方式：
Receiver DStream（使用spark中高层次的api）
Direct DStream（使用spark中低层次的api）
kafka中：0.8版本在zookeeper中维护
0.10版本在broker中维护
kafka集成streaming 0.8 与 kafka集成streaming 0.10 的区别
Kafka direct 跟receiver 方式接收数据的区别?
Receiver是使用Kafka的高层次Consumer API来实现的。
Receiver从Kafka中获取的数据都是存储在Spark Executor的内存中的，然后Spark Streaming启动的job会去处理那些数据。
然而，在默认的配置下，这种方式可能会因为底层的失败而丢失数据。
如果要启用高可靠机制，让数据零丢失，就必须启用Spark Streaming的预写日志机制（Write Ahead Log，WAL）。
该机制会同步地将接收到的Kafka数据写入分布式文件系统（比如HDFS）上的预写日志中。
所以，即使底层节点出现了失败，也可以使用预写日志中的数据进行恢复，但是效率会下降。
Direct这种方式会周期性地查询Kafka，来获得每个topic+partition的最新的offset，从而定义每个batch的offset的范围。
当处理数据的job启动时，就会使用Kafka的简单consumer api来获取Kafka指定offset范围的数据。
这种方式有如下优点：
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，SparkStreaming自己就负责追踪消费的offset，并保存在checkpoint中。
Spark自己一定是同步的，因此可以保证数据是消费一次且仅消费一次。
