一、基於Receiver的方式
這種方式使用Receiver來獲取數據。Receiver是使用Kafka的高層次Consumer API來實現的。receiver從Kafka中獲取的數據都是存儲在Spark Executor的內存中的,然後Spark Streaming啓動的job會去處理那些數據。
然而,在默認的配置下,這種方式可能會因爲底層的失敗而丟失數據。如果要啓用高可靠機制,讓數據零丟失,就必須啓用Spark Streaming的預寫日誌機制(Write Ahead Log,WAL)。該機制會同步地將接收到的Kafka數據寫入分佈式文件系統(比如HDFS)上的預寫日誌中。所以,即使底層節點出現了失敗,也可以使用預寫日誌中的數據進行恢復。
如何進行Kafka數據源連接
1、在maven添加依賴
- <dependency>
- <groupId>org.apache.spark</groupId>
- <artifactId>spark-streaming-kafka_2.10</artifactId>
- <version>1.4.1</version>
- </dependency>
2、scala代碼
- val kafkaStream = {
- val sparkStreamingConsumerGroup = "spark-streaming-consumer-group"
- val kafkaParams = Map(
- "zookeeper.connect" -> "zookeeper1:2181",
- "group.id" -> "spark-streaming-test",
- "zookeeper.connection.timeout.ms" -> "1000")
- val inputTopic = "input-topic"
- val numPartitionsOfInputTopic = 5
- val streams = (1 to numPartitionsOfInputTopic) map { _ =>
- KafkaUtils.createStream(ssc, kafkaParams, Map(inputTopic -> 1), StorageLevel.MEMORY_ONLY_SER).map(_._2)
- }
- val unifiedStream = ssc.union(streams)
- val sparkProcessingParallelism = 1 // You'd probably pick a higher value than 1 in production.
- unifiedStream.repartition(sparkProcessingParallelism)
- }
需要注意的要點
1、Kafka中的topic的partition,與Spark中的RDD的partition是沒有關係的。所以,在KafkaUtils.createStream()中,提高partition的數量,只會增加一個Receiver中,讀取partition的線程的數量。不會增加Spark處理數據的並行度。
2、可以創建多個Kafka輸入DStream,使用不同的consumer group和topic,來通過多個receiver並行接收數據。
3、如果基於容錯的文件系統,比如HDFS,啓用了預寫日誌機制,接收到的數據都會被複制一份到預寫日誌中。因此,在KafkaUtils.createStream()中,設置的持久化級別是StorageLevel.MEMORY_AND_DISK_SER。
二、基於Direct的方式
這種新的不基於Receiver的直接方式,是在Spark 1.3中引入的,從而能夠確保更加健壯的機制。替代掉使用Receiver來接收數據後,這種方式會週期性地查詢Kafka,來獲得每個topic+partition的最新的offset,從而定義每個batch的offset的範圍。當處理數據的job啓動時,就會使用Kafka的簡單consumer api來獲取Kafka指定offset範圍的數據。
這種方式有如下優點:
1、簡化並行讀取:如果要讀取多個partition,不需要創建多個輸入DStream然後對它們進行union操作。Spark會創建跟Kafka partition一樣多的RDD partition,並且會並行從Kafka中讀取數據。所以在Kafka partition和RDD partition之間,有一個一對一的映射關係。
2、高性能:如果要保證零數據丟失,在基於receiver的方式中,需要開啓WAL機制。這種方式其實效率低下,因爲數據實際上被複制了兩份,Kafka自己本身就有高可靠的機制,會對數據複製一份,而這裏又會複製一份到WAL中。而基於direct的方式,不依賴Receiver,不需要開啓WAL機制,只要Kafka中作了數據的複製,那麼就可以通過Kafka的副本進行恢復。
3、一次且僅一次的事務機制:
基於receiver的方式,是使用Kafka的高階API來在ZooKeeper中保存消費過的offset的。這是消費Kafka數據的傳統方式。這種方式配合着WAL機制可以保證數據零丟失的高可靠性,但是卻無法保證數據被處理一次且僅一次,可能會處理兩次。因爲Spark和ZooKeeper之間可能是不同步的。
基於direct的方式,使用kafka的簡單api,Spark Streaming自己就負責追蹤消費的offset,並保存在checkpoint中。Spark自己一定是同步的,因此可以保證數據是消費一次且僅消費一次。
scala連接代碼
- val topics = Set("teststreaming")
- val brokers = "bdc46.hexun.com:9092,bdc53.hexun.com:9092,bdc54.hexun.com:9092"
- val kafkaParams = Map[String, String]("metadata.broker.list" -> brokers, "serializer.class" -> "kafka.serializer.StringEncoder")
- // Create a direct stream
- val kafkaStream = KafkaUtils.createDirectStream[String, String, StringDecoder, StringDecoder](ssc, kafkaParams, topics)
- val events = kafkaStream.flatMap(line => {
- Some(line.toString())
- })
三、總結:兩種方式在生產中都有廣泛的應用,新api的Direct應該是以後的首選方式。
參考之前的文章,Direct連接kafka的實例:
http://blog.csdn.net/kwu_ganymede/article/details/50160793