Spark Streaming揭秘 Day4-事务一致性(Exactly one)

Spark Streaming揭秘 Day4

事务一致性Exactly one

引子

对于业务处理系统，事务的一致性非常的关键，事务一致性(Exactly one)，简单来说，就是输入数据一定会被处理，且只会被处理一次。下面来研究下Spark Streaming是如何做到这点的。我想说的是，Spark Streaming是一个非常优秀的软件，通过对它的研究，能对我们在类似领域的其他软件工作有所借鉴。

1.总体机制

从整个Spark Streaming的整体处理流程来分析，在上节已经介绍了，数据管理，主要通过Executor上的Receiver以及Drvier上的ReceiverTracker来完成。主要是图中绿色的四个步骤。但通过阅读代码，我们会发现整个流程中还会增加两步(红)，对应的分别是Checkpoint和WAL两个机制，这个就是保证事务一致性的关键。

2.CheckPoint和WAL

CheckPoint是一种数据备份技术，因为是全量备份，主要针对元数据信息进行管理，具体来说，会对Driver中的关键数据进行备份，在Job运行前和运行后，都会进行，用来确保一旦Job失败之后，灾难现场的恢复。

Write-Ahead Logging(预写日志系统)，是一种高效的日志算法，用来保证数据安全。其原理是在写入数据前，进行日志记录，一旦发生灾难，采用重做日志的方式来恢复。

但是需要注意的是，在WAL写入过程中，如果发生集群异常，还是会有可能丢失数据！！！

3.引入Kafka

针对上述这个问题，Spark Streaming 1.3的时候为了避免WAL的性能损失和实现Exactly Once而提供了Kafka Direct API，把Kafka作为文件存储系统，通过Kafka来实现数据完整性的确保。

同时，如果通过Kafka的作为数据来源的话，可以将Kafka作为数据副本，替代Receiver接收的时候保存的数据副本，极大的减少存储资源。

4.数据重复读取的情况

在Receiver收到数据且保存到了HDFS等持久化引擎但是没有来得及进行updateOffsets，此时Receiver崩溃后重新启动就会通过管理Kafka的ZooKeeper中元数据再次重复读取数据，但是此时SparkStreaming认为是成功的，但是Kafka认为是失败的（因为没有更新offset到ZooKeeper中），此时就会导致数据重新消费的情况。

针对这个问题，一般的解决思路是在应用内部使用内存数据库保存offset信息，所有的Executors通过Kafka API直接消费数据，直接管理Offset，所以也不会重复消费数据；

5.关于数据输出多次重写及其解决方案

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

5.其他

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

欲知后事如何，且听下回分解

DT大数据每天晚上20：00YY频道现场授课频道68917580