spark 正则表达式替换_Spark实战 | Kafka与Spark Streaming的联姻

Kafka与Spark虽然没有很直接的必然关系，但是实际应用中却经常以couple的形式存在。如果你的Kafka的爱好者，流式计算框架Spark、Flink等也不得不去了解；如果你是Spark的爱好者，Kafka又或许是必不可少的一部分。在之前的文章中我们介绍了很多spark的知识，这里主要来讲述一下Kafka与Spark Streaming的结合，如果大家有兴趣，后面会放出一个系列的文章，包括Spark编程模型、Spark Streaming、Spark SQL、Structured Streaming以及Kafka与Structured Streaming的联姻。如果没有兴趣。。。嗯。。。请下方留言告知。。。

采用Spark Streaming流式处理Kafka中的数据，首先需要的是把数据从Kafka中接收过来，然后转换为Spark Streaming中的DStream。接收数据的方式一共有两种：利用接收器Receiver的方式接收数据、直接从Kafka中读取数据。

Receiver方式是通过KafkaUtils.createStream()方法来创建一个DStream对象，它不关注消费位移的处理，Receiver方式的结构如下图所示。但这种方式在Spark任务执行异常时会导致数据丢失的情况，如果要保证数据的可靠性，需要开启预写式日志，简称WAL(Write Ahead Logs)，只有接收到的数据被持久化到WAL之后才会去更新Kafka中的消费位移。接收到的数据和WAL存储位置信息被可靠地存储，如果期间出现故障，这些信息被用来从错误中恢复，并继续处理数据。

WAL的方式可以保证从Kafka中接收的数据不被丢失。但是在某些异常情况下，一些数据被可靠地保存到了WAL中，但是还没有来得及更新消费位移，这样会造成Kafka中的数据被Spark拉取了不止一次。同时在Receiver方式中，Spark中的RDD分区和Kafka的分区并不是相关的，因此增加Kafka中主题的分区数并不能增加Spark处理的并行度，而仅是增加接收器接收数据的并行度。

Direct方式是从Spark1.3开始引入的，它通过KafkaUtils.createDirectStream()方法创建一个DStream对象，Direct方式的结构如下图所示。该方式中Kafka的一个分区与Spark RDD对应，通过定期扫描所订阅Kafka每个主题的每个分区的最新偏移量以确定当前批处理数据偏移范围。与Receiver方式相比，Direct方式不需要维护一份WAL数据，由Spark Streaming程序自己控制位移的处理，通常通过检查点机制处理消费位移，这样可以保证Kafka中的数据只会被Spark拉取一次。

注意使用了Direct的方式并不就意味着就实现了精确一次的语义(Exactly Once Semantics)，如果要达到精确一次的语义标准，还需要配合幂等性操作或者事务性操作。

在Spark官网中关于Spark Streaming与Kafka集成给出了两个依赖版本，一个是基于Kafka 0.8之后的版本(spark-streaming-kafka-0-8)，一个是基于Kafka 0.10及其之后的版本(spark-streami