SparkStreaming 的Exactly Once实现方式总结

克念

已于 2022-01-28 20:53:00 修改

阅读量2.1k

点赞数

分类专栏： spark 文章标签： kafka java spark streaming 大数据

于 2022-01-24 19:07:07 首次发布

本文链接：https://blog.csdn.net/shikenian520/article/details/122673310

版权

spark 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

SparkStreaming 的Exactly Once实现方式总结

什么是唯一一次

唯一一次，也叫ECO（Exactly once）语义是流式处理程序的重要话题，也是很多流式处理程序问题的关键所在。

为了保证每个消息在系统或网络故障的情况下，被处理一次且仅处理一次。这首先需要流式处理框架需要提供这种功能的支持，然后在消息传递、数据输出存储（比如到MySQL落库）以及具体的代码编写等等各个方面整体考虑和配合，才最终能够保证消息的ECO。

GIT上面有个不错的项目，里面有一些相关的样例代码https://github.com/jizhang/spark-sandbox

一个简单的样例代码

下面的代码实现了从Kafka获取访问数据，然后统计错误日志数量，然后每分钟一次把统计的结果插入到Mysql数据库。

源数据样例：

2017-07-30 14:09:08 ERROR some message
2017-07-30 14:09:20 INFO some message
2017-07-30 14:10:50 ERROR some message

Mysql结果表：

create table error_log (
 log_time datetime primary key, -- 具体到分钟粒度，来自源数据中到秒的时间值
 log_count int not null default 0 -- 行数
);

部分关键代码：

// 初始化MySQL 连接池
ConnectionPool.singleton("jdbc:mysql://localhost:3306/spark", "root", "")
// 初始化SparkStreaming 的context 
val conf = new SparkConf().setAppName("ExactlyOnce").setIfMissing("spark.master", "local[2]")
val ssc = new StreamingContext(conf, Seconds(5))

// 通过Direct API连接Kafka，这种方式方便我们控制偏移量
val messages = KafkaUtils.createDirectStream[String, String](ssc,
   LocationStrategies.PreferConsistent,
   ConsumerStrategies.Subscribe[String, String](Seq("alog"), kafkaParams))

//遍历 DSStream中的每个RDD，每个RDD都是一个SparkStreaming 的 微批次(micro batch)
messages.foreachRDD { rdd =>
  // 数据统计，具体逻辑
  // 取源数据中的日期和日志类型，然后过滤ERROR日志，然后截取日期到分钟粒度，然后统计行数入库
  val result = rdd.map(_.value)
    .flatMap(parseLog) // utility function to parse log line into case class
    .filter(_.level == "ERROR")
    .map(log => log.time.truncatedTo(ChronoUnit.MINUTES) -> 1)
    .reduceByKey(_ + _)
    .collect() //这里需要特别注意，数据全部通过collect() 方法回到了Driver进程中，不在各个分区

  // 在Driver中对每条数据进行Merge插入，相同时间的数据更新，不存在的时间则插入。
  DB.autoCommit { implicit session =>
    result.foreach { case (time, count) =>
      sql"""
      insert into error_log (log_time, log_count)
      value (${time}, ${count})
      on duplicate key update log_count = log_count + values(log_count)
      """.update.apply()
    }
  }
}

流式处理语义

流式处理，一共分为三个阶段，分别是 接收数据、处理数据和输出数据

这三个阶段都需要相互配合来保证ECO。

接收数据

接收数据过程，比较依赖具体的数据源。不同的数据源有不同的处理方式来保证每条消息的ECO。

比如，对HDFS这种可容错的文件系统，可以和SparkStreaming 整合保证ECO

对于有反馈的消息队列，如 RabbitMQ，可以结合 Spark 的 Write Ahead Log 来保证ECO

对于不可靠的接收器，比如 SocketTextStream，很容易因为Driver的故障导致数据丢失。

对于Kakfa，通过Direct API，也就是直接操作偏移量的，也可以提供ECO支持

处理数据

SparkStreaming 通过 DSStream，底层是一个个连续的Spark 微批次 RDD。对该数据结构操作，本身就是直接提供ECO支持的。

因此在数据处理这块，即RDD操作这块，本身就可以提供错误重启和ECO。

输出数据

默认SparkStreaming提供At Least Once的输出。当某个Excutor正在执行数据输出时发生故障，Driver重新启动一个Excutor，然后会再次进行数据输出。

这个过程，可能回导致同样的数据多次输出。

有两种方式可以解决这种重复输出的问题

基于幂等的更新方式
基于事务的更新方式

幂等输出和ECO

对于固定的一份源数据，重复经过相同逻辑处理并进行写入操作，且产生相同的结果。一般这种操作就被认为是幂等更新。

举个例子，saveAsTextFile操作，被认为是典型的幂等操作。多次对一个RDD和同一个文件调用该操作，结果值是固定不变的。上次操作和下次操作之间是互不相关的。

如果message是由 unique key的，那么message在写入database的时候，可以通过相同key执行update，不存在的key执行insert，来实现幂等更新。

但是，幂等更新一般适合于map型的sparkStreaming逻辑。举个例子：

一个message进入sparkStreaming计算引擎，经过一系列计算，最终出来的结果也是一个message，且这个message的一个或者两个字段是unique的。这种类型的处理可以通过insert on duplicate update的语法保证幂等更新。

如果sparkStreaming执行了reduceByKey或者Count等操作，这个时候，比较难以通过这种方式保证幂等更新。

幂等更新需要对kafka做一些配置

设置enable.auto.commit为false，默认情况下，DStream读取kafka数据时，会在接收到数据后，立马就提交offsets。把这个参数设置为false之后，是为了能够在一个批次执行完成后再提交offset.
打开SparkStreaming的checkpoint进行kafka 的 offsets存储，不过，如果更改过了代码之后，checkpoint会失效，因此，还需要通过下面的方式进一步的存储offsets作为补充：
结果输出到target以后，再提交offsets。kafka提供了commitAsync API，用来异步提交offsets。同时，提供了HasOffsetRangers类来从RDD中抽取kafka的Offsets值。

messages.foreachRDD { rdd =>
  // 抽取RDD中的kafka offsets，以每个微批次（micro btch）RDD为单位进行获取
  val offsetRanges = rdd.asInstanceOf[HasOffsetRanges].offsetRanges 
  rdd.foreachPartition { iter =>
    //遍历微批次RDD的每个分区，然后输出都数据库
    //注意，这次没有把所有数据collect()到Driver后再输出
    // 注意，因为这次插入操作时幂等插入，类似于 insert or update on duplicate key这种，
    //所以即使部分分区失败，或者整个任务失败重启，都不会产生多余错误的数据
  }
  //把每个分区的数据插入到数据库之后，再提交
  //如果之前输出出现任何问题，则不会提交偏移量，那么则会从之前的偏移量重新计算
  messages.asInstanceOf[CanCommitOffsets].commitAsync(offsetRanges)
}

这里如果有人由疑问：如果某些个分区输出到数据库失败重跑，或者，整个任务挂掉需要重跑，会不会导致重复数据？或者一个数据被计算多次？

答案是：不会

要注意，上一段代码，是基于幂等输出的结果之上的，比如说，saveAsTextFile，或者是对数据库进行 insert on duplicate key update更新。

所以，对于一个微批次来说，不管失败多少次，只要重启后的微批次还是通过之前的offsets去kafka取数，计算的结果永远是一致的，那么输出的结果也永远是一致的，那么通过幂等更新的方式，最终数据库中或者结果文件中的内容也是一致的！！！

幂等更新天生对于重复型输出可以保证ECO

事务输出和ECO

幂等型更新，很多时候是不能保证的，因为我们会对流式数据进行各种维度的统计和计算，那么这个时候，就没法保证数据的幂等更新。

事务型输出，对于map型计算和aggregation类型的计算都有很好的支持，基本原理就是在同一个事务中，同时执行数据输出和更新kafka offsets，做到一起成功或者一起失败。

在SparkStreaming的模型中，offset的粒度是到partition粒度的，也就是一个分区都有自己的一个offsets信息。然后对于一个RDD来说，所有分区的offset范围之和，就是RDD的offsets范围。

对于map型操作，因为SparkStreaming的一个分区对应一个kafka的分区，因此我们可以获取到每个分区的offsets信息。这样，可以在输出时，做到更细粒度的控制。

messages.foreachRDD { rdd =>
    //获取整个RDD的offsets信息
  val offsetRanges = rdd.asInstanceOf[HasOffsetRanges].offsetRanges
  rdd.foreachPartition { iter =>
      // 获取到每个分区粒度的offsets信息，做更细力度的事务控制。之前事务都是控制到RDD级别的offsets记录，现在可以控制到partition级别的记录
    val offsetRange = offsetRanges(TaskContext.get.partitionId)
  }
}

但是map型操作毕竟还是比较少的，更多的是aggregate类型的操作，这种操作设计到shffule。经过shuffle以后，RDD的partition就和Kafka的patition没有对应关系了。因此这个时候，就需要对整个RDD放在一个事务中进行数据插入和offset更新

messages.foreachRDD { rdd =>
    //获取整个RDD的所有offsets信息信息
  val offsetRanges = rdd.asInstanceOf[HasOffsetRanges].offsetRanges
    // 对RDD进行aggregate操作，并返回结果RDD
  val result = processLogs(rdd).collect() // parse log and count error
    // 开启一个事务（一个RDD就对应一个事务）
  DB.localTx { implicit session =>
    result.foreach { case (time, count) =>
      // 对RDD结果值进行入库，注意，此刻还未提交事务，下一步需要提交各分区的offsets
    }
      // 取出各个partition的offsets信息，并且按照 topic + partition 作为唯一键，进行offsets的更新存储
      // kafka在建立topic的时候，就已经指定好了分区个数
      // 此刻取到的分区partiton就是对应的是kafka topic的分区
    offsetRanges.foreach { offsetRange =>
      val affectedRows = sql"""
      update kafka_offset set offset = ${offsetRange.untilOffset}
      where topic = ${topic} and `partition` = ${offsetRange.partition}
      and offset = ${offsetRange.fromOffset}
      """.update.apply()

      if (affectedRows != 1) {
          // 如果更新失败，说明程序出现问题，需要抛出异常
        throw new Exception("fail to update offset")
      }
    }
  }
}