13518219792
本篇内容介绍了“Exactly once事务的处理方法是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
成都创新互联公司是专业的临淄网站建设公司，临淄接单;提供网站建设、网站设计,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行临淄网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
1，Exactly once 事务
什么事Exactly once 事务？
数据仅处理一次并且仅输出一次，这样才是完整的事务处理。
Spark在运行出错时不能保证输出也是事务级别的。在Task执行一半的时候出错了，虽然在语义上做了事务处理，数据仅被处理一次，但是如果是输出到数据库中，那有空能将结果多次保存到数据库中。Spark在任务失败时会进行重试，这样会导致结果多次保存到数据库中。
如下图，当运行在Executor上的Receiver接收到数据通过BlockManager写入内存和磁盘，或者通过WAL机制写记录日志，然后把metedata信息汇报给Driver。在Driver端定期进行checkpoint操作。Job的执行还是基于Spark Core的调度模式在Executor上执行Task。
Exactly once 事务的处理：
1，数据零丢失：必须有可靠的数据来源和可靠的Receiver，且整个应用程序的metadata必须进行checkpoint，且通过WAL来保证数据安全。
我们以数据来自Kafka为例，运行在Executor上的Receiver在接收到来自Kafka的数据时会向Kafka发送ACK确认收到信息并读取下一条信息，kafka会updateOffset来记录Receiver接收到的偏移，这种方式保证了在Executor数据零丢失。
在Driver端，定期进行checkpoint操作，出错时从Checkpoint的文件系统中把数据读取进来进行恢复，内部会重新构建StreamingContext(也就是构建SparkContext)并启动，恢复出元数据metedata，再次产生RDD，恢复的是上次的Job，然后再次提交到集群执行。
那么数据可能丢失的地方有哪些呢和相应的解决方式？
在Receiver收到数据且通过Driver的调度Executor开始计算数据的时候，如果Driver突然奔溃，则此时Executor会被杀死，那么Executor中的数据就会丢失(如果没有进行WAL的操作)。
解决方式：此时就必须通过例如WAL的方式，让所有的数据都通过例如HDFS的方式首先进行安全性容错处理。此时如果Executor中的数据丢失的话，就可以通过WAL恢复回来。
这种方式的弊端是通过WAL的方式会极大额损伤SparkStreaming中Receivers接收数据的性能。
数据重复读取的情况：
在Receiver收到数据保存到HDFS等持久化引擎但是没有来得及进行updateOffsets(以Kafka为例)，此时Receiver崩溃后重新启动就会通过管理Kafka的Zookeeper中元数据再次重复读取数据，但是此时SparkStreaming认为是成功的，但是kafka认为是失败的(因为没有更新offset到ZooKeeper中)，此时就会导致数据重新消费的情况。
解决方式：以Receiver基于ZooKeeper的方式，当读取数据时去访问Kafka的元数据信息，在处理代码中例如foreachRDD或transform时，将信息写入到内存数据库中(memorySet)，在计算时读取内存数据库信息，判断是否已处理过，如果以处理过则跳过计算。这些元数据信息可以保存到内存数据结构或者memsql，sqllite中。
如果通过Kafka作为数据来源的话，Kafka中有数据，然后Receiver接收的时候又会有数据副本，这个时候其实是存储资源的浪费。
Spark在1.3的时候为了避免WAL的性能损失和实现Exactly Once而提供了Kafka Direct API，把Kafka作为文件存储系统。此时兼具有流的优势和文件系统的优势，至此Spark Streaming+Kafka就构建了完美的流处理世界（1，数据不需要拷贝副本；2，不需要WAL对性能的损耗；3，Kafka使用ZeroCopy比HDFS更高效）。所有的Executors通过Kafka API直接消息数据，直接管理Offset，所以也不会重复消费数据。
2，输出不重复
关于Spark Streaming数据输出多次重写及其解决方案：
1，为什么会有这个问题，因为Spark Streaming在计算的时候基于Spark Core天生会做以下事情导致Spark Streaming的结果(部分)重复输出。Task重试，慢任务推测，Stage重试，Job重试。
2，具体解决方案：
设置spark.task.maxFailures次数为1，这样就不会有Task重试了。设置spark.speculation为关闭状态，就不会有慢任务推测了，因为慢任务推测非常消耗性能，所以关闭后可以显著提高Spark Streaming处理性能。
Spark Streaming On Kafka的话，Job失败后可以设置Kafka的参数auto.offset.reset为largest方式。
最后再次强调可以通过transform和foreachRDD基于业务逻辑代码进行逻辑控制来实现数据不重复消费和输出不重复。这两个方法类似于Spark Streaming的后门，可以做任意想象的控制操作。
“Exactly once事务的处理方法是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！
