SparkStreaming

一、flume整合 sparkStreaming 问题

　　1、如何实现 sparkStreaming 读取 flume 中的数据

　　　 sparkStreaming 整合 flume 有 2 中模式， 一种是拉模式， 一种是推模式。比较两种模式的特点， 如何部署。

　　　推模式：Flume将数据 Push 推给 Spark Streaming

　　　拉模式：Spark Streaming 从 flume 中 Poll 拉取数据

　　2、在实际开发的时候是如何保证数据不丢失的。

　　　　1. flume 采用 channel 是将数据落地到磁盘中，保证数据源端的安全性

　　　　　　flume 这里的 channel 可以设置为 memory 内存中，提高数据接收处理的效率，但是由于数据在内存中，安全机制保证不了，故选择的 channel 为磁盘储存。整个流程运行会有一点延迟性。

　　　　2. sparkStreaming 通过拉模式整合的时候，使用了 FlumeUtils 这样一个类，该类需要依赖一个额外的 jar 包（spark-streaming-flume_2.10） 　　

　　　　3. 想要保证数据不丢失，数据的准确性，可以在构建 StreamingContext 的时候，利用StreamingContext.getOrCreate（checkpoint，creatingFunc：() => StreamingContext ）来创建一个 StreamingContext，使用 StreamingContext 来创建 StreamingContext 对象，传入的第一个参数是 checkpoint 的存放目录，第二个参数是生成 StreamingContext对象的用户自定义函数。 如果 checkpoint 的存放目录存在， 则从这个目录中生成 StreamingContext 对象；如果不存在，才会调用第二个函数来生成新的 StreamingContext 对象。 在 creatingFunc函数中，除了生成一个新的 StreamingContext 操作，还需要完成各种操作， 然后调用 ssc.checkpoint(checkpointDirectory) 来初始化 checkpoint 功能，最后再返回 StreamingContext 对象。这样，在 StreamingContext.getOrCreate 之后， 就可以直接调用 start() 函数来启动（或者是从中断点继续运行）流式应用了。如果有其他在启动或继续运行都要做的工作，可以在start() 调用前执行。

　　　　4. 流式计算中使用 checkpoint 的作用

　　　　　　1. 保存元数据，包括流式应用的配置，流式没崩溃之前定义的各种操作，未完成所有操作的 batch 。元数据被存储到可能失败的存储系统上，如 HDFS 。这种 checkpoint 主要针对 driver失败后的修复。

　　　　　　2. 保存流式数据    存储到可能失败的存储系统上，如 HDFS 。这种checkpoint 主要针对 window operation 有状态的操作。 无论是 driver 失败，还是 worker 失败，这种 checkpoint 都能快速修复， 不用将很长的数据重新计算一遍。（得到当前状态）。

　　　　　　3. 设置流式数据checkpoint的周期

　　　　　　　　对于一个需要做 checkpoint 的 DStream 结构，可以通过调用 DStream.checkpoint(checkpointInterval)来设置checkpoint的周期，一般将 checkpoint 周期设置成 batch 周期的 5 至 10 倍。

　　　　　　4. 使用 write ahead logs 功能

　　　　　　　　这是个可选的功能， 建议加上。作用是： 使输入数据写到之前配置的 checkpoint 目录。这样有状态的数据可以从上一个 checkpoint 开始计算。

　　　　　　　　开启方法： 把 spark.streaming.receiver.writeAheadLogs.enable 这个 property 设置为 true 。 由于输入RDD的默认 StorageLlevel 是 MEMORY_AND_DISK_2，即数据会在两台 worker 上做 replication 。 实际上， Spark Streaming 模式下，任何从网络输入数据的 Receiver （如 kafka  flume  socket）都会在两台机器上做备份。 如果开启 write ahead logs 的功能，建议把 StorageLevel 改成 MEMORY_AND_DISK_SER。   修改的方法   在创建RDD 时，由参数传入。

　　　　　　总结： 使用 checkpoint 机制，确实可以保证数据不丢失， 但是前提条件是  数据发送端必须有缓存功能， 这样才能保证 spark 应用重启期间，数据发送端不会因为 spark streaming 服务不可用而把数据丢弃。 flume，kafka都具备这个特性

　　3、Spark Streaming 的数据可靠性

　　　　有 checkpoint 机制， write ahead log 机制， Receiver缓存机器， 可靠的Receiver（即数据接收并备份成功后发送ack），可以保证 worker 失效还是 driver 失效，数据不会丢失

　　　　原因：  如果没有 Receiver 服务的 worker 失效了，RDD数据可以依赖血统来重新计算； 如果Receiver所在的 worker 失效了，由于Reciever 是可靠的， 并有 write ahead log 机制， 则收到的数据可以保证不丢； 如果 driver 失效了，可以从 checkpoint 中恢复数据重新构建。

二、kafka 整合 sparkStreaming 问题

　　1、如何实现SparkStreaming 读取 kafka 中的数据

　　　　有两种方式： 一种是基于 receiver  一种是 direct

　　　　基于 receiver：

　　　　　　采用 kafka 高级 api，利用 receiver 接收器来接受 kafka topic 中的数据， 从 kafka 接受来的数据会存储到 spark 的executor中， 之后 spark streaming 提交的 job 会处理这些数据，kafka 中 topic 的偏移量是保存在 zk 中的。

　　　　　　基本使用规则：

　　　　　　val kafkaStream = KafkaUtils.createStream(streamingContext, [ZK  quorum]，[consumer  group  id]，[per-topic number of Kafka partitions to consume])

　　　　　　还有几个需注意的点：

　　　　　　　　1. 在 Receiver 的方式中，Spark 中的 partition 和 kafka 中的 partition 并不是相关的，所以如果我们增加每个topic 的 partition 数量，仅仅增加线程来处理由单一 Receiver 消费的主题， 但是这并没有增加 Spark 在处理数据上的并行度。

　　　　　　　　2. 对于不同的 Group 和 topic 我们可以使用多个 Receiver 创建不同的 Dstream 来并行接受数据，之后可以利用 union 来统一一个 Dstream。

　　　　　　　　3. 在默配置下， 这种方式可能因为底层的失败而丢失数据， 因为 receiver一直在接受数据， 在其