Spark Streaming源码解读之Executor容错安全性

本期内容 :

  • Executor的WAL
  • 消息重放

数据安全的角度来考虑整个Spark Streaming :

  1、 Spark Streaming会不断次序的接收数据并不断的产生Job ,不断的提交Job到集群运行,至关重要的问题接收数据安全性

  2、 由于Spark Streaming是基于Spark Core基础之上的,即是说运行过程中出现错误或者故障,Spark Streaming也可以借助

  Spark Core中RDD的容错的能力自动的进行恢复,恢复的前提是数据的安全可靠。

    所以Executor接收数据时的安全容错至关重要,在这个数据的安全容错的基础之上进行调度级别的容错基本靠Spark Core,

  对于Executor的安全容错主要是数据的安全容错,计算的时候Spark Streaming是借助于Spark Core上的RDD的容错。

数据的安全容错:

  1、 最天然的安全容错是副本,处理数据的时候先复制一个副本

  2、接收数据时不使用副本,数据源支持重放,可以反复读取数据,如读取过去10S中的数据,出现错误可以再次读取过去10S中的数据

  

一、 Executor的WAL

    Spark Core的BlockManager负责具体Executor上的数据读写操作,并且也是个MsteaStorageLevel的结构

  借助Spark底层的存储系统BlockManager做备份的StorageLevel 。

  

  

  

  

  

 

  1、BlockManagerBasedBlockHandler 副本机制

    

    

    

    

  2、 WriteAheadLogBasedBlockHandler WAL日志方式

    在其具体目录下会做一份日志,后续处理过程中出现问题可以基于日志恢复,日志需要写在目录下:

    需要先设置写在CheckPoint的目录,目录可以有很多目录: StreamingContext.CheckPoint 在上下文中指定具体目录,

    一般情况下会放在HDFS中,优势是安全,多份副本,缺点是影响性能,浪费存储空间 。

    

    

    

   同时在WAL及BlockManager中放数据:

    

    

    

    

    

  Executor写数据时是按照顺序的写,由于是做WAL使用不会修改数据,一般是根据索引读取,不需要全盘搜索所以读取速度非常快。

    

   

  3. 具体的实现 :管理具体的WAL文件,周期性的写文件,输出时写文件,清理旧文件

    

    

    

    

    

  

  备份存储总结 :

    1、 基于BlockManager ,比如说两台机器中都有数据,其中一台出错了就切换到另外一台

    2、 WAL方式,WAL方式比较耗时,假如你对性能要求非常苛刻的话WAL一般不是一个很好的选择,如果你能够容忍1分钟以上的延迟的话WAL往往比较安全

    注意: 如果还没有来得及进行WAL的话数据可能也会丢失。

  

二、 支持消息重放 :

  主要基于Kafka,天然就是有副本与容错的,已经作为一个存储系统了。

  Kafka有Receiver的方式,Direct的方式 :

  1、Receiver方式:是交给zookeeper管理的Mtdata的偏移量的如果失效后Kafka会基于Offset重新的读取,如果你读取失败此时不会给zookeeper发送ACK信号,

  zookeeper就让我你并没有消费这个数据,这个是zookeeper保证的,还有个数据重复消费的问题,就是消费完了但是还没有来得及给zookeeper进行同步,可能会重复。

  2、Direct方式:直接去操作Kafka ,而且是自己管理Offset ,Kafka本身就有Offset ,这种方式可以确保有且一次的操作处理,这个需要进行CheckPoint操作,较耗时间。

    

  管理这个Offset ,Bach会调用这个方法,上次的Offset减去这次的值就可以确定此次Offset的范围数据。

    

原文地址:https://www.cnblogs.com/yinpin2011/p/5522134.html