SparkStreaming 事务处理彻底掌握

1.      Exactly once

2.      输出不重复

Sparkstreaming应用程序分为两部分

1 Driver  : Driver的核心是streamingContext,
2 Executor : 在Executor中Receiver接收到数据并把数据（metadata）汇报给driver，收到数据之后，为了数据的安全性进行checkpoint（包含configuration ，Block MetaData,DStreamGraph,job，未完成的job和等待的job）  Job的执行：完全基于spark core的调度模式
 

Receiver 收到数据之后通过blockmanager写入磁盘或者通过wal保证数据的安全性，由于数据读进来的时候先放在内存中，executor奔溃，这个时候数据还是会丢失一部分。
Receiver接收到数据之后会进行replication，数据会保存在两个executor之上，当replication完成之后，会执行ack（确认收到信息并读取下一条信息）

Exactly once的事务处理

1 数据零丢失：必须有可靠的数据来源和可靠的receiver，且整个应用程序的metadata必须进行checkpoint，且通过wal来保证数据的安全
2 spark streaming 1.3的时候为了避免wal的性能损失和实现exactly once而提供了kafka direct api, 把kafka作为文件存储系统！！！此时兼具有流的流式和文件系统的优势，至此，spark streaming +kafka就构建了完美的流处理世界。所有executor通过kafka api直接消费数据，直接管理offset，所以也不会重复消费数据
使用Kafka优点：
数据不需要拷贝副本
不需要wal进行不必要的性能损耗
Kafka比hdfs高效很多，内存采用零拷贝的方式

数据丢失及其具体的解决方式：
1在receiver收到数据且通过Driver的调度executor开始计算数据的时候如果driver突然崩溃，则此时executor会被kill掉，那么executor重的数据就会丢失。此时就必须通过例如wal的方式让所有的数据都通过HDFS的方式首先进行安全性的容错处理，此时如果executor中的数据丢失的话就可以通过wal恢复回来；

数据重复读取的情况
在receiver收到数据且保存到了HDFS等持久化引擎但是没有来的及进行updateOffsets,此时Receiver奔溃后重新启动就会通过管理kafka的Zookeeper中的元数据再次重复读取数据，但是此时sparkstreaming认为是成功的，但是kafka认为是失败的，(因为没有更新offset到zookeeper中)，此时就会导致数据重新消费的情况


性能损失
通过wal的方式会极大的损伤sparkstreaming中reveivers接收数据的性能；
如果通过kafka作为数据来源的话，kafka中有数据，然后receiver接收的时候又会有数据副本，这个时候其实是存储资源的浪费。


关于sparkstreaming数据输出多次重写及其解决方案
1. 为什么会有这个问题，以为spark streaming 在计算的时候基于spark core ,spark core天生就会做以上事情导致spark streaming 的结果（部门）重复输出
Task重试
慢任务推测
Stage重试
Job重试

具体的解决方案
1设置最大允许失败的次数为1  spark.task.maxFailures次数为1
2设置spark,speculation为false及关闭状态(慢任务推测其实非常消耗性能，所以关闭后可以显著的提高spark streaming处理性能)
3Spark streaming on kafka 的话，job失败后可以设置auto.offset.reset为largest的方式


最后强调，通过transform和foreachRdd基于业务逻辑代码进行逻辑控制来实现数据不重复消费和重复输出