Spark Streaming事务

一：传统事务概念

事务(Transaction)是访问并可能更新数据库中各类数据项的一个程序执行单元(unit)。事务一般由高级数据库操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引发，并用形如begin transaction和end transaction语句（或函数调用）来界定。事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操做组成。

例如：在关系数据库中，一个事务能够是一条SQL语句，一组SQL语句或整个程序。

 

特性：事务是恢复和并发控制的基本单位。

事务应该具备4个属性：原子性、一致性、隔离性、持久性。这四个属性一般称为ACID特性。

原子性（atomicity）。一个事务是一个不可分割的工做单位，事务中包括的诸操做要么都作，要么都不作。

一致性（consistency）。事务必须是使数据库从一个一致性状态变到另外一个一致性状态。一致性与原子性是密切相关的。

隔离性（isolation）。一个事务的执行不能被其余事务干扰。即一个事务内部的操做及使用的数据对并发的其余事务是隔离的，并发执行的各个事务之间不能互相干扰。

持久性（durability）。持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其余操做或故障不该该对其有任何影响。

二：spark Streaming中的事务

1. Exactly once容错

　　2. 数据输出不重复

一. 事务场景 :

　　以银行转账一次为例，A用户转帐给B用户，如何保证事务的一致性，即A用户可以转出且只能转出一次，B用户可以收到且只能收到一次。　　

二.  Exactly once容错：

　　事务处理中如何保证可以处理且只能处理一次，数据可以输出且只能输出一次。

　　数据丢失的主要场景以下：

　　　　在Receiver收到数据且经过Driver的调度，Executor开始计算数据的时候若是Driver忽然奔溃（致使Executor会被Kill掉），此时Executor会被Kill掉，那么Executor中的数据就会丢失。

　1. 事务处理以下图 :

事务处理过程解析 ： 

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 streaming的后门，能够作任意想象的控制操做！