第4课:Spark Streaming的Exactly Once的事务处理

原创 2016年05月08日 11:06:56

本期内容:

Exactly once

输出不重复


Exactly once

1,事务一定会被处理,且只被处理一次;

2,输出能够输出且只会被输出。


  • Receiver:数据通过BlockManager写入内存+磁盘或者通过WAL来保证数据的安全性。
  • WAL机制:写数据时先通过WAL写入文件系统然后存储的Executor(存储在内存和磁盘中,由StorageLevel设定),假设前面没有写成功后面一定不会存储在Executor,如不存在Executor中的话,汇报Driver数据一定不被处理。WAL能对要写入的数据,能保证其安全,失败的可能性不大。
  • 注意点:Receiver会把数据积累到一定程度才能写入内存磁盘或WAL,如果还没积累到一定程度,Executor或Receiver崩溃了怎么办?答案是数据还是可能会丢失几条。因为尚未做备份,根本没有准备好数据块。
  • SparkStreaming说白了就两点:获取数据和产生作业。作业是通过SparkContext来执行的。
  • 关于恢复:Driver级别的恢复:直接在Driver进行Checkpoint文件系统把数据读入,内部则重启SparkContext。InputDStream是Driver端产生的(因为是框架调度层面的),这是在逻辑级别而言的。恢复过数据后,重新构建StreamingContext其实也就是构建SparkContext,恢复出的源数据再次产生RDD。恢复时根据上次的Job执行,所以恢复对应的Job,再次提交至Spark集群,再次执行。另一方面,Receiver重新恢复,在以前的数据基础上接收数据,曾经接收的数据根据WAL之类的机制从磁盘中恢复回来。通过这种方式 ,SparkStreaming是个相对可靠的系统,Driver发生故障后重新启动可以在原有基础上继续执行,这样我们就可以继续原有任务而不丢失数据。
  • Receiver只接收几条,没有及时WAL其实还是会丢失数据的,这是从整体SparkStreaming考虑而言的;而和Kafka结合的话不会有上面这种问题。
  • 我们要做SparkStreaming的话,必须从生产作业流水线考虑输入和输出。外部数据源输入Kafka,然后通过Kafka再交给SparkStreaming,SparkStreaming通过处理后将数据交给离线存储系统或继续交给Kafka或交给实时消费系统

Exactly Once的事务处理:

1,数据零丢失:必须有可靠的数据来源和可靠的Receiver,且整个应用程序的metadata必须进行checkpoint,且通过WAL来保证数据安全;

2,Spark Streaming 1.3的时候为了避免WAL的性能损失和实现Exactly Once而提供了Kafka Direct API,Kafka作为文件存储系统!!!

      此时兼具有流的优势和文件系统的优势,至此,Spark Streaming+Kafka就构建了完美的流处理世界!!!

      所有的Executors通过Kafka API直接消费数据,直接管理Offset,所以也不会重复消费数据;事务实现啦!!!

数据丢失及其具体的解决方式:

在Receiver收到数据且通过Driver的调度Executor开始计算数据的时候如果Driver突然崩溃,则此时Executor会被Kill掉,那么Executor中的数据就会丢失,此时就必须通过例如WAL的方式让所有的数据都通过例如HDFS的方式首先进行安全性容错处理,此时如果Executor中的数据丢失的话就可以通过WAL恢复回来;

数据重复读取的情况:

在Receiver收到数据且保存到了HDFS等持久化引擎但是没有来得及进行updateOffsets,此时Receiver崩溃后重新启动就会通过管理Kafka的ZooKeeper中元数据再次重复读取数据,但是此时SparkStreaming认为是成功的,但是Kafka认为是失败的(因为没有更新offset到ZooKeeper中),此时就会导致数据重新消费的情况。

性能损失:
1,通过WAL方式会极大的损伤Spark Streaming中Receivers接受数据的性能;
2,如果通过Kafka的作为数据来源的话,Kafka中有数据,然后Receiver接受的时候又会有数据副本,这个时候其实是存储资源的浪费;

关于Spark Streaming数据输出多次重写及其解决方案:

1,为什么会有这个问题,因为SparkStreaming在计算的时候基于SparkCoreSparkCore天生会做以下事情导致SparkStreaming的结果(部分)重复输出:

  Task重试;

  慢任务推测;

  Stage重复;

  Job重试;

2,具体解决方案:

  设置spark.task.maxFailures次数为1;

  设置spark.speculation为关闭状态(因为慢任务推测其实非常消耗性能,所以关闭后可以显著提高Spark Streaming处理性能)

  Spark Streaming on Kafka的话,Job失败后可以设置auto.offset.reset为“largest”的方式。


相关文章推荐

Spark定制班第4课:Spark Streaming的Exactly-Once的事务处理和不重复输出彻底掌握

本期内容 1 Exactly-Once事务处理 2 输出不重复的解决办法 1)什么是Exactly-Once事务? 数据仅处理一次并且仅输出一次,这样才是完整的事务处理。 以银行转帐为例,A用户转账...
  • csdn_zf
  • csdn_zf
  • 2016年05月08日 16:31
  • 1033

Spark Streaming对Exactly Once的实现原理

昨天看到了这篇文章: "为什么Spark Streaming + Kafka很难保证exactly once?"  看过后,对作者对Exactly Once的理解不敢苟同,所以想写这篇文章,阐述一下我...
  • cymvp
  • cymvp
  • 2016年09月21日 11:27
  • 1318

Exactly-once Spark Streaming from Apache Kafka

转 http://blog.cloudera.com/blog/2015/03/exactly-once-spark-streaming-from-apache-kafka/ Than...

Spark Streaming实践和优化

Spark Streaming实践和优化 2016-02-20 徐鑫 hadoop123 点击hadoop123关注我哟 ☀ 最知名的hadoop/spark大数据技术分享基地,分享had...

SparkStringApplication进行升级时保证零丢失

升级SparkStreaming Application代码 在对StreamingApplication项目进行升级时,此时如果代码发生改变的话,有两种方式可以做到。 1. 升级的代码和旧的代码同时...
  • mtj66
  • mtj66
  • 2017年01月16日 12:18
  • 177

Spark Streaming Crash 如何保证Exactly Once Semantics

这篇文章只是为了阐述Spark Streaming 意外Crash掉后,如何保证Exactly Once Semantics。本来这个是可以直接给出答案的,但是我还是啰嗦的讲了一些东西。...

第4课:Spark Streaming的Exactly-One的事务处理和不重复输出彻底掌握

感谢DT大数据梦工厂支持提供以下内容,DT大数据梦工厂专注于Spark发行版定制。详细信息请查看  联系邮箱18610086859@126.com  电话:18610086859  QQ:174...

Spark定制班第4课:Spark Streaming的Exactly-One的事务处理和不重复输出彻底掌握

本篇文章主要从二个方面展开: 本期内容 1 Exactly Once 2 输出不重复 1 Exactly Once   事务:   银行转帐为例,A用户转账给B用户...

第4课版本定制:Spark Streaming事务处理彻底掌握

本期内容 1、Exactly Once 2、输出不重复 事务: 银行转帐为例,A用户转账给B用户,B用户可能收到多笔钱,如何保证事务的一致性,也就是说事务输出,能够输出且只会输出一次,即A只转...
  • lhui798
  • lhui798
  • 2016年05月05日 11:15
  • 735

Spark Streaming的Exactly-One的事务处理和不重复输出彻底掌握

Spark Streaming事务处理图分析: 1. Receiver不断地接收数据,收到数据后汇报给driver,driver收到数据后为了数据安全进行checkpoint,checkpoint中...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:第4课:Spark Streaming的Exactly Once的事务处理
举报原因:
原因补充:

(最多只允许输入30个字)