Spark Streaming的Exactly-One的事务处理

本博文主要内容：

• Exactly once容错

• 数据输出不重复

一、Exactly once：

1、 什么是事务处理：

a) 能够处理且只被处理一次。例如，银行转账，A转给B，A有且仅转一次。
b) 能够输出，且只能够输出一次。而B接收转账，且直接收一次。

Spark Streaming的事务处理和关系型数据库的事务的概念有所不同，关系型数据库事务关注的是语句级别的一致性，例如银行转账。而Spark Streaming的事务关注的是某次job执行的一致性。也就是如何保证Job在处理数据的过程中做到如下两点：
不丢失数据
不重复处理数据

2、Exactly once容错：

　　事务处理中如何保证能够处理且只能处理一次，数据能够输出且只能输出一次。
　
　数据丢失的主要场景如下：

在Receiver收到数据且通过Driver的调度，Executor开始计算数据的时候如果Driver突然奔溃（导致Executor会被Kill掉），此时Executor会被Kill掉，那么Executor中的数据就会丢失。

3、 事务处理如下图 :

1）、事务处理过程解析 ：
（1） InputStream ： 输入数据 ；
（2）Executor ： 通过Receiver接收数据，当接收到数据后向Driver 汇报 ；
（3） Driver ： 通过StreamingContext接收到数据会启动Job进行操作 ；

2）、解决事务源数据接收的安全性 ：

事务处理解析 ：

（1） Executor ： 在Receiver接收来自Kafka数据首先通过BlockManager写入内存+磁盘或者通过WAL来保证数据的安全性；

（2） Executor ： 通过Replication完成后产生Ack信号；

（3） Kafka ： 确定收信息并读取下一条数据，Kafka才会进行updateOffsets操作 ；

（4） 通过WAL机制让所有的数据通过类似HDFS的方式进行安全性容错处理，从而解决Executor被Kill掉后导致数据丢失可以通过WAL机制恢复回来。

3）解决Driver数据输出的安全性 ：

　　数据的处理怎么保证有且仅有被处理一次？

　　数据零丢失并不能保证Exactly Once，如果Receiver接收且保存起来后没来得及更新updateOffsets时，就会导致数据被重复处理。
　　

　（1）、 通过StreamingContext接收数据通过CheckPoint进行容错 ；

（2）、logging the updates ： 通过记录跟踪所有生成RDD的转换（transformations）也就是记录每个RDD的lineage（血统）来重新计算生成丢失的分区数据 ；

Exactly Once的事物处理：
1、数据零丢失：必须有可靠的数据来源和可靠地Receiver，且整个应用程序的metadata必须进行checkpoint且通过WAL来保证数据安全；
2、SparkStreaming在1.3之后为了避免WAL的性能损失和实现Exactly Once而提供啦Kafka Direct API，把Kafka作为文件存储系统！！！此时兼具有流的优势和文件系统的优势，至此SparkStreaming+Kafka就构建了完美的流处理世界！！！所有的executor通过Kafka API直接消费数据，直接管理Offset,所以不会重复消费数据；实务实现啦！！！

二：数据输出不重复：

• 数据丢失：
  1、在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中Receiver接受数据的性能；
  2、如果通过Kafka作为数据来源的话，Kafka中有数据，Receiver接受的时候又会有数据副本，这个时候其实是存储资源的浪费；

• 关于SparkStreaming数据输出多次重写及其解决方案：
  1，为什么会有这个问题，因为Spark Streaming在计算的时候基于Spark Core，Spark Core天生会做以下事情导致SparkStreaming的结果（部分）重复输出
  Task重试，慢任务推测；Stage重试，Job重试；
  2，具体解决方案：
  设置spark.task.maxFailures次数为1；设置spark.speculation为关闭状态（因为慢任务推测其实非常消耗性能，所以关闭后可以显著的提高Spark Streaming性能
  Spark Streaming on Kafka的话，Job失败后可以设置auto.offset.reset为“largest”的方式；

补充说明：
最后再次强调可以通过transform和foreachRDD基于业务逻辑代码进行逻辑控制来实现数据不重复消费和输出不重复！这两个方法类似于Spark Streaming 的后门可以做任意想象的控制操作。

博文内容源自DT大数据梦工厂Spark课程的总结笔记。相关课程内容视频可以参考：
百度网盘链接：http://pan.baidu.com/s/1slvODe1（如果链接失效或需要后续的更多资源，请联系QQ460507491或者微信号：DT1219477246 获取上述资料）。