Spark版本定制班第4课-Frank.docxVIP

Spark源码定制班第4课 PAGE11 / NUMPAGES11 第4课：Spark Streaming事务处理 作者：杭州-Frank 本期导读： Exactly Once 输出不重复  HYPERLINK /base/10 \o Apache Spark知识库 \t _blank Spark?Streaming?事务处理架构 什么是事务 以银行转帐为例，A用户转笔账给B用户，如果B用户没收到账，或者收到多笔账，都是破坏事务的一致性。事务处理就是，能够处理且只会处理一次，即A只转一次，B只收一次。 从事务视角解密Spark Streaming HYPERLINK /base/16 \o 大型网站架构知识库 \t _blank 架构 SparkStreaming应用程序启动时会分配资源，除非整个集群硬件资源崩溃，一般情况下都不会有问题。 SparkStreaming程序分成而部分： Driver Executor Receiver接收到数据后不断发送元数据给Driver，Driver接收到metadata元数据信息后进行CheckPoint处理。其中CheckPoint包括： Configuration（含有 HYPERLINK /base/10 \o Apache Spark知识库 \t _blank Spark?Conf、Spark Streaming等配置信息）、 Block MetaData、 DStreamGraph、 未处理完和等待中的Job。 Receiver可以在多个Executor节点的上执行Job，Job的执行完全基于SparkCore的调度模式进行。 架构演进变化图 根据上面的解密画出最基础的架构，如下图1所示： 图1 图1只是Spark Streaming基本的情况，Executor只有函数处理逻辑和数据，外部InputStream流入到Receiver中通过BlockManager写入磁盘、内存、WAL进行容错。WAL先写入磁盘然后写入Executor中，WAL它是写进HDFS的，失败可能性不大。如果1G数据要处理，Executor一条一条接收，Receiver接收数据是积累到一定记录后才会写入WAL，如果Receiver线程失败时，数据有可能会丢失。 Driver处理元数据前会进行CheckPoint，Spark Streaming获取数据、产生作业，但没有解决执行的问题，执行一定要经过Spark Context。Driver级别的恢复，通过CheckPoint从文件系统上恢复，重新构建Streaming Context，也就是重新构建SparkContext，再重新生成Spark Job，再提交Spark集群运行。Receiver的重新恢复时会通过磁盘的WAL从磁盘恢复过来。演进后的架构如下图2所示： 图2 Spark Streaming和Kafka结合不会出现WAL数据丢失的问题，Spark Streaming必须考虑外部流水线的方式处理。Spark Streaming 1.3的时候为了避免WAL的性能损失和实现Exactly Once而提供了Kafka Direct API，把Kafka作为文件存储系统！ Spark Streaming+Kafka构建完美的流处理世界！下图3是再次演化后的架构图： 图3 Exactly Once原理 Exactly Once的事务处理： 1．数据零丢失：必须有可靠的数据来源和可靠的Receiver，且整个应用程序的metadata必须进行checkpoint，且通过WAL来保证数据安全； 2．Spark Streaming 1.3的时候为了避免WAL的性能损失和实现Exactly Once而提供了Kafka Direct API，把Kafka作为文件存储系统！！！此时兼具有流的优势和文件系统的优势，至此，Spark Streaming+Kafka就构建了完美的流处理世界！！！ 为什么说它完美： 数据不需要拷贝复本； 不需要进行WAL，不必要的性能损耗。 kafka比HDFS高效很多，内存中产生Memory copy的方式。 有了kafka就不需要所谓的Receiver，所有的Executors通过Kafka API直接消费数据，直接管理Offset，所以也不会重复消费数据；事务实现啦！！！ 数据丢失及其具体的解决方式： 在Receiver收到数据且通过Driver的调度Executor开始计算数据的时候，如果Driver突然崩溃，则此时Executor会被Kill掉，那么Executor中的数据就会丢失。 此时就必须通过列如WAL的方式，让所有的数据都通过列如HDFS的方式进行安全性容错处理，此时如果Executor数据