本期内容:api
1. Exactly once容错安全
2. 数据输出不重复性能
一. 事务场景 :spa
以银行转账一次为例,A用户转帐给B用户,如何保证事务的一致性,即A用户可以转出且只能转出一次,B用户可以收到且只能收到一次。 orm
二. Exactly once容错:blog
事务处理中如何保证可以处理且只能处理一次,数据可以输出且只能输出一次。事务
数据丢失的主要场景以下:内存
在Receiver收到数据且经过Driver的调度,Executor开始计算数据的时候若是Driver忽然奔溃(致使Executor会被Kill掉),此时Executor会被Kill掉,那么Executor中的数据就会丢失。kafka
1. 事务处理以下图 :spark
事务处理过程解析 :
01. InputStream : 输入数据 ;
02. Executor : 经过Receiver接收数据,当接收到数据后向Driver 汇报 ;
03. Driver : 经过StreamingContext接收到数据会启动Job进行操做 ;
2. 解决事务源数据接收的安全性 :
事务处理解析 :
01. Executor : 在Receiver接收来自Kafka数据首先经过BlockManager写入内存+磁盘或者经过WAL来保证数据的安全性;
02. Executor : 经过Replication完成后产生Ack信号;
03. Kafka : 肯定收信息并读取下一条数据,Kafka才会进行updateOffsets操做 ;
04. 经过WAL机制让全部的数据经过相似HDFS的方式进行安全性容错处理,从而解决Executor被Kill掉后致使数据丢失能够经过WAL机制恢复回来。
3. 解决Driver数据输出的安全性 :
数据的处理怎么保证有且仅有被处理一次?
数据零丢失并不能保证Exactly Once,若是Receiver接收且保存起来后没来得及更新updateOffsets时,就会致使数据被重复处理。
01. 经过StreamingContext接收数据经过CheckPoint进行容错 ;
02. logging the updates : 经过记录跟踪全部生成RDD的转换(transformations)也就是记录每一个RDD的lineage(血统)来从新计算生成丢失的分区数据 ;
4. Exactly Once的事务处理 :
0一、 数据零丢失:必须有可靠的数据来源和可靠的Receiver,且整个应用程序的metadata必须进行checkpoint,且经过WAL来保证数据安全;
0二、Spark Streaming 1.3的时候为了不WAL的性能损失和实现Exactly Once而提供了Kafka Direct API,把Kafka做为文件存储系统!!
0三、此时兼具备流的优点和文件系统的优点,Spark Streaming+Kafka就构建了完美的流处理世界!!!
0四、 数据不须要copy副本,不须要WAL性能损耗,不须要Receiver,全部的Executors直接经过kafka direct api直接消费数据,直接管理Offset,因此也不会重复消费数据;
三. Spark Streaming数据输出屡次重写及解决方案:
一、 为何会有这个问题,由于SparkStreaming在计算的时候基于SparkCore,SparkCore天生会作如下事情致使SparkStreaming的结果(部分)重复输出:
一、Task重试;
二、慢任务推测;
三、Stage重复;
四、Job重试;
等会致使数据的丢失。
二、 对应的解决方案:
一、一个任务失败就是job 失败,设置spark.task.maxFailures次数为1;
二、设置spark.speculation为关闭状态(由于慢任务推测其实很是消耗性能,因此关闭后能够显著的提升Spark Streaming处理性能)
三、Spark streaming on kafka的话,假如job失败后能够设置kafka的auto.offset.reset为largest的方式会自动恢复job的执行。
最后再次强调:
能够经过transform和foreachRDD基于业务逻辑代码进行逻辑控制来实现数据不重复消费和输出不重复!这二个方法相似于spark s的后门,能够作任意想象的控制操做!