SparkStreaming集成Kafka spark接收kafka数据的方式

SparkStreaming集成Kafka

 

       sparkStreaming从Kafka读取数据的2种方式

       文档：http://spark.apache.org/docs/2.2.0/streaming-kafka-0-8-integration.html

方式一：Receiver-based Approach

        此方法使用Receiver接收数据。Receiver是使用Kafka高级消费者API实现的。与所有接收器一样，从Kafka通过Receiver接收的数据存储在Spark执行器中，然后由Spark Streaming启动的作业处理数据。

要记住的要点：

       Kafka中的主题分区与Spark Streaming中生成的RDD分区无关。因此，增加主题特定分区KafkaUtils.createStream()的数量只会增加使用单个接收器中消耗的主题的线程数。它不会增加Spark在处理数据时的并行性。有关详细信息，请参阅主文档。

      可以使用不同的组和主题创建多个Kafka输入DStream，以使用多个接收器并行接收数据。

      如果已使用复制文件系统（如HDFS）启用了“预读日志”，则已在日志中复制接收的数据。因此，输入流的存储级别的存储级别StorageLevel.MEMORY_AND_DISK_SER（即使用 KafkaUtils.createStream(...,StorageLevel.MEMORY_AND_DISK_SER)）。

这种方法在失败时可能丢失数据

 

Approach 2: Direct Approach (No Receivers)

 

与基于接收器的方法（即方法1）相比，该方法具有以下优点。

•      简化的并行性：无需创建多个输入Kafka流并将它们联合起来。使用directStream，Spark Streaming将创建与要使用的Kafka分区一样多的RDD分区，这些分区将并行地从Kafka读取数据。因此，Kafka和RDD分区之间存在一对一的映射，这更容易理解和调整。

•      效率：在第一种方法中实现零数据丢失需要将数据存储在Write Ahead Log中，这进一步复制了数据。这实际上是低效的，因为数据有效地被复制两次 - 一次由Kafka复制，第二次由Write Ahead Log复制。第二种方法消除了问题，因为没有接收器，因此不需要Write Ahead Logs。只要您有足够的Kafka保留，就可以从Kafka恢复消息。

•       完全一次的语义：第一种方法使用Kafka的高级API在Zookeeper中存储消耗的偏移量。传统上，这是从Kafka使用数据的方式。虽然这种方法（与预写日志结合使用）可以确保零数据丢失（即至少一次语义），但某些记录在某些故障下可能会被消耗两次。这是因为Spark Streaming可靠接收的数据与Zookeeper跟踪的偏移之间存在不一致。因此，在第二种方法中，我们使用不使用Zookeeper的简单Kafka API。Spark Streaming在其检查点内跟踪偏移量。这消除了Spark Streaming和Zookeeper / Kafka之间的不一致，因此尽管出现故障，Spark Streaming也会有效地接收每条记录一次。为了获得结果输出的精确一次语义，主编程指南中输出操作的语义以获取更多信息）。

请注意，此方法的一个缺点是它不会更新Zookeeper中的偏移量，因此基于Zookeeper的Kafka监视工具将不会显示进度。但是，您可以在每个批次中访问此方法处理的偏移量，并自行更新Zookeeper （详情看文档）

 

性能：

       直接去拉取数据的方式

       当且仅当每批次数据处理完成，再去抓取下一批数据，

       可以设置每批次抓取最大条目数

              spark.streaming.kafka.maxRatePerPartition

        如果从一个topic中获取数据，一个topic中有3个分区

        spark.streaming.kafka.maxRatePerPartition = 5000

        一次性拉取到15000

sparkStreaming采用Direct方式从Kafka topic中pull数据，每批次Batch处理数据RDD，

RDD的分区数目 =  所有kafka topic总的分区数目之和