spark-streaming

==> Dstream

Dstream是sparkStreaming的数据模型，本质就是一连串不间断的RDD，但是它是一个时间段的RDD.这些时间段的RDD源源不断的连接在一起。
这个时间可以自己设置，时间设置的越短，实时性越高，但是性能消耗也越大。

==>spark streaming从kafka获取数据，有哪几种方式？

有两种方式：
1.通过receiver的方式，
2，通过direct的方式，dirrect的方式需要自己来管理偏移量。
偏移量自己管理，有两种方式：
1.写入到checkPoint
2.写入到ZK,考虑参数的问题，使用zk的javaAPI,把偏移量写入到ZK,从ZK读取偏移量

==> sparkStreaming和storm的区别

sparkStreaming是spark里面的一个做流式准实时计算的组件，它使用的数据结构是Dstream，Dstream里面是一连串时间片的rdd。
相比于storm，sparkStreaming在实时性，保证数据不丢失方面都不占用优势，spark streaming在spark支持者眼中的优势是spark Streaming具有高吞吐性，最本质来说，sparkStreaming相比于storm的优势是sparkStreaming可以和spark core，spark SQL无缝整合。

对于需要多次引用的，并且这个dstream计算时间特别耗时，数据特别重要，那么我们就需要对dstream进行checkpoint，（只有多次引用的，进行持久化就可以了），因为即使对这个dstream进行持久化，数据也可能会丢失，而checkpoint数据丢失的可能性小，但是这样会影响spark-streaming的数据吞吐量，因为在做计算的同时，还需要将数据写入到外部存储系统中，会降低spark性能，影响吞吐量，非必要情况下不建议使用

==>如何对dstream做checkpoint

首先设置还原点目录，其次调用dstream的checkpoint方法
【注意】：dstream的checkpoint的周期一定要是产生batch时间的整数倍，同时spark官方建议将checkpoint的时间设置为至少10秒。通常来说，将checkpoint间隔设置为窗口操作的滑动间隔的5-10倍

spark程序在启动时，会去这个checkpointPath目录下查看是否有保存的driver的元数据（1.dstream的操作转换关系，2.未处理完的batch）信息，当spark-streaming程序在二次启动后就会去checkpointPath目录下还原这个程序，加载未处理的batch元数据信息在内存中恢复，继续进行任务处理

==>为了保证spark-streaming程序7*24小时运行，那么我们程序应该具备高可靠性，怎样具备高可靠性？

a.程序出现故障，driver死掉了，流式程序应该具备自动重启的功能
b.没有计算完成的rdd在程序异常停止后，下次启动后还会将未处理的rdd进行处理
【注意】：要在spark_submit中，添加–deploy-mode参数，默认其值为client，即在提交应用的机器上启动driver，但是要能够自动重启driver，就必须将其值设置为cluster；此外，需要添加–supervise参数，失败后自动重启
//spark_submit --executor-memory 1g --total-execute-cores 5 --deploy-model cluster --supervise

==>启用预写机制
a.预写日志机制，简写为WAL，全称为Write Ahead Log，从spark1.2版本开始，就引入了基于容错的文件系统的WAL机制。如果启用该机制，Receiver接收到的所有数据都会写入配置的checkpoint目录中的预写日志。这中机制可以让driver在恢复的时候，避免数据丢失，并且可以确保整个实时计算过程中零数据丢失

b.要配置该机制，首先调用StreamingContext的checkpoint()方法设置一个checkpoint目录，然后需要将spark.streaming.receiver.writeAheadLog.enable参数设置为true
然而，这种极强的可靠性机制，会导致Receiver的吞吐量大幅度下降，因为单位时间内，有相当一部分时间需要将数据写入预写日志。如果又希望开启预写日志机制，确保数据零损失，又不希望影响系统的吞吐量，那么可以创建多个输入DStream，启动多个Receiver
此外，在启用了预写日志机制之后，推荐将复制持久化机制禁用掉，因为所有数据已经保存在容错的文件系统中，不需要在用复制机制进行持久化，保存一份副本，只要将输入的DStream的持久化机制设置一下即可，persist（StorageLevel.MEMORY_AND_DISK_SER）。

==>spark-Streaming checkpoint概述

每一个spark-streaming应用，正常来说，都是7*24小时运转的，这就是实时计算程序的特点，因为要持续不断的对数据进行计算，因此，对实时计算应用的要求，应该是必须要能够对与应用程序逻辑无关的失败，进行容错
如果要实现这个目标，Spark Streaming程序就必须将足够的信息checkpoint到容错的存储系统上，从而让它能够从失败中进行恢复
有两种数据需要被进行checkpoint
1.元数据checkpoint-将定义了流式计算逻辑的信息，保存到容错的存储系统上，比如HDFS，当运行spark Streaming应用程序的Driver进程所在的节点失败时，该信息可以用于进行恢复，元数据信息包括：
a.配置信息—创建spark Streaming应用程序的配置信息，比如sparkConf中的信息
b.DStream的操作信息—定义了spark Stream应用程序的计算逻辑的DStream操作信息
c.未处理的batch信息—那些job正在排队，还没处理的batch信息

2.数据checkpoint—将实时计算过程中产生的RDD的数据保存到可靠的存储系统中。对于一些将多个batch的数据进行聚合，有状态的transformation操作，这是非常有用的，在这种transformation操作中，生成的RDD是依赖于之前batch的RDD的，这会导致随着时间的推移，RDD的依赖链条变得越来越长，要避免由于依赖链条越来越长，导致的一起变得越来越长的失败恢复时间，有状态的transformation操作执行过程中中间产生的RDD,会定期被checkpoint到可靠的存储系统上，比如HDFS，从而削减RDD的依赖链条进而缩短失败恢复时，RDD的恢复时间。一句话概括，元数据checkpoint主要是为了从driver失败中进行恢复；而RDD checkpoint主要是为了使用到有状态的transformation操作时，能够在其生产出的数据丢失时，进行快速的失败恢复

==>何时启用checkpoint机制？

a.使用了有状态的transformation操作----比如updateStateByKey，或者reduceByKeyAndWindow操作被使用了，那么checkpoint目录要求必须提供的，也就是必须开启checkpoint机制，从而进行周期性的RDD checkpoint
b.要保证可以从Driver失败中进行恢复-----元数据checkpoint需要启用，来进行这种情况的恢复
【注意】并不是说，所有的spark streaming应用程序，都要启用checkpoint机制，如果既不强制要求从Driver失败中自动进行恢复，又没使用有状态的transformation操作，那么就不需要启用checkpoint，事实上，这么做反而是有助于提升性能的

==>如何自动从Driver失败中恢复过来

要能够自动从Driver失败中恢复过来运行spark Streaming应用程序的集群，就必须监控Driver运行的过程，并且在他失败时将他重启，对于spark自身的standalone模式，需要进行一些配置去supervise driver，在他失败时将其重启

首先，要在spark-submit中，添加–deploy-mode参数，默认其值为client，即在提交应用的机器上启动Driver，但是，要能够自动重启Driver，就必须将其值设置为cluster，此外，需要添加–supervise参数