Spark Streaming 连接kafka Receiver and Direct（官网自译）

Spark Streaming+kafka Intergration Guide

notes：
根据官网翻译
在这里我们开始介绍如何配置spark Streaming 去接受来自kafka的数据。
有两个方法能够做到：
1.老方法，使用的是Receivers 和 kafka的高级API
2.新方法（发行于spark1.3），取消了使用Receivers
他们拥有不同的编程模型，代表特征和保证语义，所以，阅读来获得更多的细节。
两个方法都是被考虑经过现在spark版本的稳定的API实现的。

Approach 1： Receiver-based Approach （基于接收器的方法）

这个方法是使用一个接收器来接受数据，这个接收器是使用kafka高级API的工具，对于所有的接受器来说，kafka的数据接收是通过一个数据接受器，此接收器是存在于spark Executor中的，之后的任务启动是通过spark Streaming 来处理数据。
然而在默认的配置下，此方法有可能会发生错误从而丢失数据（详情请看Receiver reliability ，来确保零数据丢失，不得不另外添加一个 Write-Ahead Logs（WAL）在spark Streaming中（在spark1.2中有介绍）kafka中所有接收到的数据会同步存储在write—Ahead Logs 分布式文件系统HDFS上 所以，所有的数据可以在发生错误的时候被恢复。
接下来，我们将要讨论如何去使用这个方法在你的流式应用中。

import org.apache.spark.streaming.kafka._

 val kafkaStream = KafkaUtils.createStream(streamingContext,
     [ZK quorum], [consumer group id], [per-topic number of Kafka partitions to consume])

需要注意的点：

1.在kafka中的Topic Partitions 不能与Spark Streaming中RDD产生的分区想关联，所以，增加topic特定的分区（KafkaUtils.createStream()仅仅能增加一个拥有简单接收器的consumer线程数量）它并不能增加接受数据的spark的并行度。
2.多个kafka输入Dstreams 可以被不同的group和topic创建，为了使用多个Receiver来并行接收数据。
3.如果你启用WAL with 一个多副本文件系统如HDFS，这些已经接受到的数据将被复制在日志中，
因此输入流的存储级别为存储级别StorageLevel。MEMORY_AND_DISK_SER

Approach2 ：Direct Approach（No Receivers）无接收器

这个新的缺少接收器（直连）的方法是在spark 1.3版本发布的，为了保证更加健壮的端对端担保，取代了使用接收器接受数据，此方法周期性的查询在kafka中每个topic+partition的最近offset，还包括定义了offset range 同执行到每个批次，当任务开启，开始处理数据后，kafka的低级API就开始被用来读取来自kafka中被定义过的offset的范围（简单的读取文件从文件系统中）。
此方法对比Receiver-based approach 有以下优点

1. 更加简明的并行机制：
   不需要创建多个kafak streams来输入和合并他们。通过directStream，spark Streaming 可以创建一个和kafka 中分区一致的多个RDD Partition 来提供消费，此形式会并行读取kafka中的所有数据。所以这是一个一对一的映射关系，这使得更加容易的理解和执行。
2. 更高效
   Receiver-based approach实现零数据丢失需要让数据存储在一个write—Ahead Logs中，是一种远程的数据复制。数据被有效的获取和复制了两次，一次是通过kafka，第二次是通过WAL，所以这是一个低效的方式。
   第二种方式，排除了这个问题，因为此方法取消了接收器，因此不需Write-Ahead Logs。由于有一个充足的kafka保留区域，消息能够从kafka中被恢复。
3. 精确语义
   第一种方法使用kafka的高级API在zookeeper中存储消费后的offset。这是一个传统的方法去消费kafka中的数据。虽然这个方法（同时write-Ahead Logs）能保证数据零丢失（至少能够读取一次数据），在发生错误后有小概率许多记录可能会被消费两次。此错误的发生是因为在spark Streaminging数据可靠接受和zookeeper 跟踪的offset前后矛盾。
   所以在直连方法中我们使用底层kafka API 来做跟踪offset，而不是使用zookeeper。offset的跟踪是通过spark Streaming的checkPoints 。消除了在spark Streaming和zookeeper/kafka 之间的矛盾（数据不一致），所以，每一条记录只会被spark Streaming
   有效的读取一次，就算其中发生了错误。
   为了实现输出结果的精确语义，你的输出操作（存储数据到外部数据容器时，必须保证幂等），或者自动数据处理存储的结果和offset

此方法有一个缺点 ，就是他不会更新zookeeper中的offset，因此以zookeeper作为基础的kafka镜像监控工具将不会显示进度。但是，你可以在每个批次中访问由此方法处理的偏移量，并自己更新Zookeeper的offset

                              转载请标明出处