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基于业务逻辑代码进行逻辑控制来实现数据不重复消费和重复输出

感谢王家林老师的知识分享

王家林老师名片：

中国Spark第一人

感谢王家林老师的知识分享

新浪微博：http://weibo.com/ilovepains

微信公众号：DT_Spark

博客：http://blog.sina.com.cn/ilovepains

手机：18610086859

QQ：1740415547

邮箱：18610086859@vip.126.com

YY课堂：每天20:00现场授课频道68917580