Spark Streaming程序怎么才能做到不丢数据

Spark Streaming在接收数据的时候有两种模式，第一种是基于Receiver模式，第二种是Kafka Direct模式，两者不丢数据的处理方式不一样，下面我们就来聊聊这两种模式不丢数据的处理策略

基于Receiver模式

在这种模式下，我们可以使用checkpoint + WAL + ReliableReceiver的方式保证不丢失数据，就是说在driver端打开chechpoint，用于定期的保存driver端的状态信息到HDFS上，保证driver端的状态信息不会丢失；在接收数据Receiver所在的Executor上打开WAL，使得接收到的数据保存在HDFS中，保证接收到的数据不会丢失；因为我们使用的是ReliableReceiver，所以在Receiver挂掉的期间，是不会接收数据，当这个Receiver重启的时候，会从上次消费的地方开始消费。
所以Spark Streaming的checkpoint机制包括driver端元数据的checkpoint以及Executor端的数据的checkpoint（WAL以及updateStateByKey等也需要checkpint）,Executor端的checkpoint机制除了保证数据写到HDFS之外，还有切断很长的RDD依赖的功效(因为RDD是一个很长的依赖链,如果有checkpoint机制,那么在某一个依赖链断的时候,就不会从头到尾的去再去计算一次了,只需要从checkpoint的位置重新计算即可)

Kafka Direct模式

这种模式下，因为数据源都是存储在Kafka中的，所以一般不会丢数据，但是有一种情况下可能会丢失数据，就是当Spark Streaming应用失败后或者升级重启的时候因为没有记住重启之前消费的topic的offset，使得重启后Spark Streaming从topic的最新的offset开始消费(这个是默认的行为)，这样就导致Spark Streaming消费不到失败或者重启过程中Kafka接收到的消息，解决这个问题的办法有三个：

1、使用Spark Streaming自带的Driver端checkpoint机制，因为Driver端checkpoint机制会定期的保存Driver端的状态信息，当然也包括当前批次消费的Kafka中topic的offset信息，这样下次重启的时候就可以从checkpoint文件中直接读取上次消费到的offset信息，然后从这个offset开始消费。但是Driver端的checkpoint机制有一个很明显的缺陷，因为Driver端的checkpoint机制保存的Driver端的状态信息还包含DStreamGraph的状态信息，意思就是将Driver端的代码序列化到checkpoint文件中，这样的话，如果我们对代码做了很大的改动或者升级的话，那么升级后的代码和checkpoint文件中的代码不兼容，这样的话会导致重启失败，解决这个问题的方法就是每次升级的时候将checkpoint文件清除掉，但是这样做的话也清除了保存在checkpoint文件中上次消费到的offset信息，这个不是我们想要的，所以这种方式不可取。
2、我们可以在每一个批次开始之前将我们消费到的offset手动的保存到其他第三方存储系统中，可以是zookeeper或者Hbase，如下：

import org.apache.curator.framework.CuratorFrameworkFactory
import org.apache.curator.retry.ExponentialBackoffRetry
import org.apache.kafka.common.TopicPartition
import org.apache.spark.rdd.RDD
import org.apache.spark.streaming.kafka010.HasOffsetRanges
import org.slf4j.LoggerFactory

class Stopwatch {
  // 记录当前时间和开始时间的时间差
  private val start = System.currentTimeMillis()

  override def toString() = (System.currentTimeMillis() - start) + " ms"

}

trait OffsetsStore {

  // 每一个分区消费的数据信息,从数据库中读取出来
  def readOffsets(topic: String): Option[Map[TopicPartition, Long]]

  // 把消费了的offset保存到数据库中去
  def saveOffsets(topic: String, rdd: RDD[_]): Unit

}

/**
  *  将Spark Streaming消费的kafka的offset信息保存到zookeeper中
  * @param zkHosts zookeeper的主机信息
  * @param zkPath offsets存储在zookeeper的路径
  */
class ZooKeeperOffsetsStore(zkHosts: String, zkPath: String) extends OffsetsStore with Serializable {
  private val logger = LoggerFactory.getLogger("ZooKeeperOffsetsStore")

  @transient   // transient意思是在写磁盘的时候会忽略掉这个属性
  private val client = CuratorFrameworkFactory.builder()  // 创建ZK的客户端
    .connectString(zkHosts)
    .connectionTimeoutMs(10000)   // 超时时间
    .sessionTimeoutMs(10000)   // 重试间隔时间
    .retryPolicy(new ExponentialBackoffRetry(1000, 3))
    .build()
  client.start()

  /**
    *  从zookeeper上读取Spark Streaming消费的指定topic的所有的partition的offset信息
    * @param topic
    * @return
    */
  override def readOffsets(topic: String): Option[Map[TopicPartition, Long]] = {
    logger.info("Reading offsets from ZooKeeper")
    val stopwatch = new Stopwatch()

    val offsetsRangesStrOpt = Some(new String(client.getData.forPath(zkPath)))  // 从zkpath去读消费情况的数据
    offsetsRangesStrOpt match {
      case Some(offsetsRangesStr) =>
        logger.info(s"Read offset ranges: ${offsetsRangesStr}")
        if (offsetsRangesStr.isEmpty) {
          None
        } else {  // 不是空的话就对数据进行解析
          val offsets = offsetsRangesStr.split(",")
            .map(s => s.split(":"))
            .map { case Array(partitionStr, offsetStr) => (new TopicPartition(topic, partitionStr.toInt) -> offsetStr.toLong) }
            .toMap

          logger.info("Done reading offsets from ZooKeeper. Took " + stopwatch)

          Some(offsets)
        }
      case _ =>
        logger.info("No offsets found in ZooKeeper. Took " + stopwatch)
        None
    }
  }

  /**
    *  将指定的topic的所有的partition的offset信息保存到zookeeper中
    * @param topic
    * @param rdd
    */
  override def saveOffsets(topic: String, rdd: RDD[_]): Unit = {
    logger.info("Saving offsets to ZooKeeper")
    val stopwatch = new Stopwatch()

    val offsetsRanges = rdd.asInstanceOf[HasOffsetRanges].offsetRanges
    offsetsRanges.foreach(offsetRange => logger.info(s"Using $offsetRange"))

    // 分区和offset进行拼接
    val offsetsRangesStr = offsetsRanges.map(offsetRange => s"${offsetRange.partition}:${offsetRange.fromOffset}")
      .mkString(",") //partition1:220,partition2:320,partition3:10000
    logger.info(s"Writing offsets to ZooKeeper: $offsetsRangesStr")
    client.setData().forPath(zkPath, offsetsRangesStr.getBytes())
    //ZkUtils.updatePersistentPath(zkClient, zkPath, offsetsRangesStr)

    logger.info("Done updating offsets in ZooKeeper. Took " + stopwatch)
  }
}

import org.apache.kafka.clients.consumer.ConsumerRecord
import org.apache.spark.streaming.StreamingContext
import org.apache.spark.streaming.dstream.DStream
import org.apache.spark.streaming.kafka010.{ConsumerStrategies, KafkaUtils, LocationStrategy}

import scala.collection.JavaConversions._

object KafkaSource {
  def createDirectStream[K, V](ssc: StreamingContext, locationStrategy: LocationStrategy,
      kafkaParams: Map[String, Object], zkHosts: String, zkPath: String, topic: String
    ): DStream[ConsumerRecord[K, V]] = {
    val offsetsStore = new ZooKeeperOffsetsStore(zkHosts, zkPath)
    val storedOffsets = offsetsStore.readOffsets(topic)  // 读出数据
    val topicSet = Set(topic)
    val kafkaStream = storedOffsets match {
      case None =>  // 没有数据的话就是第一次启动
        KafkaUtils.createDirectStream[K, V](ssc, locationStrategy,
          ConsumerStrategies.Subscribe[K, V](topicSet, kafkaParams))
      case Some(fromOffsets) =>  // 如果有值的话就把之前的offset告诉程序
        KafkaUtils.createDirectStream[K, V](ssc, locationStrategy,
          ConsumerStrategies.Subscribe[K, V](util.Arrays.asList(topic), kafkaParams, fromOffsets))
    }
    // 保存消费数据,读出来了就直接保存
    kafkaStream.foreachRDD(rdd => offsetsStore.saveOffsets(topic, rdd))

    kafkaStream
  }
}

这样就是实现了手动的保存我们每一个批次消费到的topic的offset信息,数据也不会丢失了

3、也可以直接调用Kafka中高级的API，将消费的offset信息保存到zookeeper中，如下:

当重启Spark Streaming应用的时候，Spark Streaming会自动的从zookeeper中拿到上次消费的offset信息

关于spark streaming batch超时问题

在项目初期就应该按照需求设计,参考http://blog.cloudera.com/blog/2015/03/how-to-tune-your-apache-spark-jobs-part-2,比如:
num_executors取决于如下因素:
1：每一秒接收到的events，尤其是在高峰时间
2：数据源的缓冲能力
3：可以忍受的最大的滞后时间

executor_memory取决于如下因素:
1：每一个batch需要处理的数据的大小
2：transformations API的种类，如果使用的transformations(比如:groupByKey)需要shuffle的话，则需要的内存更大一点
3：使用状态Api的话(updateStateByKey,mapWithState,注意mapWithState虽然性能更好(因为有timeout 超时时间,不需要加更多的判断,会自动的清除超时数据),但是目前还处于试验版本,因此实际中更多的是用updateStateByKey)，需要的内存更加大一点，因为需要内存缓存每一个key的状态

executor_cores:
每一个executor配置3到5个cores是比较好的，因为3到5个并发写HDFS是最优的

backpressure 方向调节接收速率:
receiver_max_rate=1000
receiver_initial_rate=30
–conf spark.streaming.kafka.maxRatePerPartition=${receiver_max_rate} #direct模式读取kafka每一个分区数据的最大速度

关于kafka的积压问题

参考http://xuyangyang.club/articles/2018/07/23/1532348839398.html