62、Spark Streaming:容错机制以及事务语义

一、 容错机制

1、背景

要理解Spark Streaming提供的容错机制,先回忆一下Spark RDD的基础容错语义:

1、RDD,Ressilient Distributed Dataset,是不可变的、确定的、可重新计算的、分布式的数据集。每个RDD都会记住确定好的计算操作的血缘关系,
(val lines = sc.textFile(hdfs file);
val words = lines.flatMap();
val pairs = words.map();
val wordCounts = pairs.reduceByKey())这些操作应用在一个容错的数据集上来创建RDD。

2、如果因为某个Worker节点的失败(挂掉、进程终止、进程内部报错),导致RDD的某个partition数据丢失了,那么那个partition可以通过对原始的
容错数据集应用操作血缘,来重新计算出来。

3、所有的RDD transformation操作都是确定的,最后一个被转换出来的RDD的数据,一定是不会因为Spark集群的失败而丢失的。

Spark操作的通常是容错文件系统中的数据,比如HDFS。因此,所有通过容错数据生成的RDD也是容错的。然而,对于Spark Streaming来说,这却行不通,
因为在大多数情况下,数据都是通过网络接收的(除了使用fileStream数据源)。要让Spark Streaming程序中,所有生成的RDD,都达到与普通Spark程序
的RDD,相同的容错性,接收到的数据必须被复制到多个Worker节点上的Executor内存中,默认的复制因子是2。

基于上述理论,在出现失败的事件时,有两种数据需要被恢复:

1、数据接收到了,并且已经复制过——这种数据在一个Worker节点挂掉时,是可以继续存活的,因为在其他Worker节点上,还有它的一份副本。

2、数据接收到了,但是正在缓存中,等待复制的——因为还没有复制该数据,因此恢复它的唯一办法就是重新从数据源获取一份。

此外,还有两种失败是我们需要考虑的:

1、Worker节点的失败——任何一个运行了Executor的Worker节点的挂掉,都会导致该节点上所有在内存中的数据都丢失。如果有Receiver运行在
该Worker节点上的Executor中,那么缓存的,待复制的数据,都会丢失。

2、Driver节点的失败——如果运行Spark Streaming应用程序的Driver节点失败了,那么显然SparkContext会丢失,那么该Application的所有Executor的数据都会丢失。

二、 Spark Streaming容错语义

1、定义

流式计算系统的容错语义,通常是以一条记录能够被处理多少次来衡量的。有三种类型的语义可以提供:

1、最多一次:每条记录可能会被处理一次,或者根本就不会被处理。可能有数据丢失。
2、至少一次:每条记录会被处理一次或多次,这种语义比最多一次要更强,因为它确保零数据丢失。但是可能会导致记录被重复处理几次。
3、一次且仅一次:每条记录只会被处理一次——没有数据会丢失,并且没有数据会处理多次。这是最强的一种容错语义。

2、Spark Streaming的基础容错语义

在Spark Streaming中,处理数据都有三个步骤:

1、接收数据:使用Receiver或其他方式接收数据。
2、计算数据:使用DStream的transformation操作对数据进行计算和处理。
3、推送数据:最后计算出来的数据会被推送到外部系统,比如文件系统、数据库等。

如果应用程序要求必须有一次且仅一次的语义,那么上述三个步骤都必须提供一次且仅一次的语义。每条数据都得保证,只能接收一次、只能计算一次、只能推送一次。

Spark Streaming中实现这些语义的步骤如下:

1、接收数据:不同的数据源提供不同的语义保障。
2、计算数据:所有接收到的数据一定只会被计算一次,这是基于RDD的基础语义所保障的。即使有失败,只要接收到的数据还是可访问的,最后一个计算出来的数据一定是相同的。
3、推送数据:output操作默认能确保至少一次的语义,因为它依赖于output操作的类型,以及底层系统的语义支持(比如是否有事务支持等),但是用户可以实现它们自己的事务
机制来确保一次且仅一次的语义。

3、接收数据的容错语义

1、基于文件的数据源
如果所有的输入数据都在一个容错的文件系统中,比如HDFS,Spark Streaming一定可以从失败进行恢复,并且处理所有数据。这就提供了一次且仅一次的语义,
意味着所有的数据只会处理一次。

2、基于Receiver的数据源

对于基于Receiver的数据源,容错语义依赖于失败的场景和Receiver类型。

可靠的Receiver:这种Receiver会在接收到了数据,并且将数据复制之后,对数据源执行确认操作。如果Receiver在数据接收和复制完成之前,就失败了,那么
数据源对于缓存的数据会接收不到确认,此时,当Receiver重启之后,数据源会重新发送数据,没有数据会丢失。

不可靠的Receiver:这种Receiver不会发送确认操作,因此当Worker或者Driver节点失败的时候,可能会导致数据丢失。

不同的Receiver,提供了不同的语义。如果Worker节点失败了,那么使用的是可靠的Receiver的话,没有数据会丢失。使用的是不可靠的Receiver的话,
接收到,但是还没复制的数据,可能会丢失。如果Driver节点失败的话,所有过去接收到的,和复制过缓存在内存中的数据,全部会丢失。

要避免这种过去接收的所有数据都丢失的问题,Spark从1.2版本开始,引入了预写日志机制,可以将Receiver接收到的数据保存到容错存储中。如果使用
可靠的Receiver,并且还开启了预写日志机制,那么可以保证数据零丢失。这种情况下,会提供至少一次的保障。(Kafka是可以实现可靠Receiver的)

从Spark 1.3版本开始,引入了新的Kafka Direct API,可以保证,所有从Kafka接收到的数据,都是一次且仅一次。基于该语义保障,
如果自己再实现一次且仅一次语义的output操作,那么就可以获得整个Spark Streaming应用程序的一次且仅一次的语义。

4、输出数据的容错语义

output操作,比如foreachRDD,可以提供至少一次的语义。那意味着,当Worker节点失败时,转换后的数据可能会被写入外部系统一次或多次。对于写入文件系统来说,
这还是可以接收的,因为会覆盖数据。但是要真正获得一次且仅一次的语义,有两个方法:

1、幂等更新:多次写操作,都是写相同的数据,例如saveAs系列方法,总是写入相同的数据。
2、事务更新:所有的操作都应该做成事务的,从而让写入操作执行一次且仅一次。给每个batch的数据都赋予一个唯一的标识,然后更新的时候判定,如果数据库中还
没有该唯一标识,那么就更新,如果有唯一标识,那么就不更新。

dstream.foreachRDD { (rdd, time) =>
  rdd.foreachPartition { partitionIterator =>
    val partitionId = TaskContext.get.partitionId()
    val uniqueId = generateUniqueId(time.milliseconds, partitionId)
    // partitionId和foreachRDD传入的时间,可以构成一个唯一的标识
  }
}

5、Storm的容错语义

就输出数据这一点来看,网上有些同学,特别的挺Spark Streaming,踩Storm。问题是,他们真的对这两种实时计算技术都很精通吗?都对它们所有的高级特性掌握的非常彻底吗?

Storm首先,它可以实现消息的高可靠性,就是说,它有一个机制,叫做Acker机制,可以保证,如果消息处理失败,那么就重新发送。保证了,至少一次的容错语义。
但是光靠这个,还是不行,数据可能会重复。

Storm提供了非常非常完善的事务机制,可以实现一次且仅一次的事务机制。事务Topology、透明的事务Topology、非透明的事务Topology,可以应用各种各样的情况。
对实现一次且仅一次的这种语义的支持,做的非常非常好。用事务机制,可以获得它内部提供的一个唯一的id,然后基于这个id,就可以实现,output操作,输出,
推送数据的时候,先判断,该数据是否更新过,如果没有的话,就更新;如果更新过,就不要重复更新了。

所以,至少,在容错 / 事务机制方面,我觉得Spark Streaming还有很大的空间可以发展。特别是对于output操作的一次且仅一次的语义支持!

原文地址:https://www.cnblogs.com/weiyiming007/p/11382499.html

时间: 2024-10-09 04:36:58

62、Spark Streaming:容错机制以及事务语义的相关文章

2.Spark Streaming运行机制和架构

1 解密Spark Streaming运行机制 上节课我们谈到了技术界的寻龙点穴.这就像过去的风水一样,每个领域都有自己的龙脉,Spark就是龙脉之所在,它的龙穴或者关键点就是SparkStreaming.这是上一节课我们非常清晰知道的结论之一.而且上一节课,我们采用了降维的方式.所谓降维的方式,是指把时间放大,就是把时间变长的情况下,我们做SparkStreaming的案例演示的实战,实战的结果是,我们发现在特定的时间段里面,确实是具体的RDD在工作,那么这一节课有必要在上一节课的基础上去谈一

Spark定制班第2课:通过案例对Spark Streaming透彻理解三板斧之二:解密Spark Streaming运行机制和架构

本期内容: 1 解密Spark Streaming运行机制 2 解密Spark Streaming架构 1 解密Spark Streaming运行机制 我们看看上节课仍没有停下来的Spark Streaming程序运行留下的信息. 这个程序仍然在不断地循环运行.即使没有接收到新数据,日志中也不断循环显示着JobScheduler.BlockManager.MapPartitionsRDD.ShuffledRDD等等信息.这些都是Spark Core相关的信息.其循环的依据,也就是时间这个维度.

Spark Streaming容错的改进和零数据丢失

本文来自Spark Streaming项目带头人 Tathagata Das的博客文章,他现在就职于Databricks公司.过去曾在UC Berkeley的AMPLab实验室进行大数据和Spark Streaming的研究工作.本文主要谈及了Spark Streaming容错的改进和零数据丢失. 以下为原文: 实时流处理系统必须要能在24/7时间内工作,因此它需要具备从各种系统故障中恢复过来的能力.最开始,Spark Streaming就支持从driver和worker故障恢复的能力.然而有些

通过案例对 spark streaming 透彻理解三板斧之三:spark streaming运行机制与架构

本期内容: 1. Spark Streaming Job架构与运行机制 2. Spark Streaming 容错架构与运行机制 事实上时间是不存在的,是由人的感官系统感觉时间的存在而已,是一种虚幻的存在,任何时候宇宙中的事情一直在发生着的. Spark Streaming好比时间,一直遵循其运行机制和架构在不停的在运行,无论你写多或者少的应用程序都跳不出这个范围. 一.   通过案例透视Job执行过程的Spark Streaming机制解析,案例代码如下: import org.apache.

通过案例对 spark streaming 透彻理解三板斧之二:spark streaming运行机制

本期内容: 1. Spark Streaming架构 2. Spark Streaming运行机制 Spark大数据分析框架的核心部件: spark Core.spark  Streaming流计算.GraphX图计算.MLlib机器学习.Spark SQL.Tachyon文件系统.SparkR计算引擎等主要部件. Spark Streaming 其实是构建在spark core之上的一个应用程序,要构建一个强大的Spark应用程序 ,spark  Streaming是一个值得借鉴的参考,spa

第3课:解读spark –streaming运行机制

感谢DT大数据梦工厂支持提供以下内容,DT大数据梦工厂专注于Spark发行版定制.详细信息请查看 联系邮箱[email protected] 电话:18610086859 QQ:1740415547 微信号:18610086859 定制班:第三课 解读spark –streaming运行机制 一 从实战出发 首先我们运行以下的程序,然后通过这个程序的运行过程进一步加深理解Spark Streaming流处理的Job的执行的过程,代码如下:   def main(args: Array[Strin

Spark 定制版:004~Spark Streaming事务处理彻底掌握

本讲内容: a. Exactly Once b. 输出不重复 注:本讲内容基于Spark 1.6.1版本(在2016年5月来说是Spark最新版本)讲解. 上节回顾: 上节课通过案例透视了Spark Streaming Job架构和运行机,并结合源码进行了详细解说:同时也了解了Spark Streaming Job的容错机制,包括 Executor 与 Driver两方面的容错机制. 也就是说Job的事务处理,主要是在Executor 与 Driver两个应用中展开 开讲 首先,我们必须知道什么

4.Spark Streaming事务处理

首先,我们必须知道什么是事务及其一致性? 事务应该具有4个属性:原子性.一致性.隔离性.持久性.这四个属性通常称为ACID特性. 原子性(atomicity).一个事务是一个不可分割的工作单位,事务中包括的诸操作要么都做,要么都不做. 一致性(consistency).事务必须是使数据库从一个一致性状态变到另一个一致性状态.一致性与原子性是密切相关的. 隔离性(isolation).一个事务的执行不能被其他事务干扰.即一个事务内部的操作及使用的数据对并发的其他事务是隔离的,并发执行的各个事务之间

Spark 定制版~Spark Streaming(二)

本讲内容: a. 解密Spark Streaming运行机制 b. 解密Spark Streaming架构 注:本讲内容基于Spark 1.6.1版本(在2016年5月来说是Spark最新版本)讲解. 上节回顾: 上节课谈到技术界的寻龙点穴,Spark就是大数据的龙脉,而Spark Streaming就是Spark的穴位.假如要构建一个强大的Spark应用程序 ,Spark Streaming 是一个值得借鉴的参考,Spark Streaming涉及多个job交叉配合,几乎可以包括spark的所