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

本期内容:

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定制班
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭