Spark-Streaming獲取kafka數據的兩種方式-Receiver與Direct的方式，可以從代碼中簡單理解成Receiver方式是通過zookeeper來連接kafka隊列，Direct方式是直接連接到kafka的節點上獲取數據了。
一、基於Receiver的方式
這種方式使用Receiver來獲取數據。Receiver是使用Kafka的高層次Consumer API來實現的。receiver從Kafka中獲取的數據都是存儲在Spark Executor的內存中的，然後Spark Streaming啓動的job會去處理那些數據。
然而，在默認的配置下，這種方式可能會因爲底層的失敗而丟失數據。如果要啓用高可靠機制，讓數據零丟失，就必須啓用Spark Streaming的預寫日誌機制（Write Ahead Log，WAL）。該機制會同步地將接收到的Kafka數據寫入分佈式文件系統（比如HDFS）上的預寫日誌中。所以，即使底層節點出現了失敗，也可以使用預寫日誌中的數據進行恢復。
讀取代碼如下：
val conf = new SparkConf().setAppName("streamingKafka").setMaster("local[2]")
val sc = SparkContext.getOrCreate(conf)
val ssc = new StreamingContext(sc,Seconds(5))
val kafkaParams = Map(
"zookeeper.connect" -> "localhost:2181",
"group.id" -> "spark-streaming-test",
"zookeeper.connection.timeout.ms" -> "4000")
val topic = "streaming_kafka"
val defaultParallelism = sc.defaultParallelism
val streaming =( 1 to defaultParallelism).map( time=>{
KafkaUtils.createStream[String,String,StringDecoder,StringDecoder](ssc,kafkaParams,Map(topic->defaultParallelism),StorageLevel.MEMORY_ONLY_SER)
})
val unifiedStream = ssc.union(streaming)
意的要點
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自己一定是同步的，因此可以保證數據是消費一次且僅消費一次。
val topics = Set("streaming_kafka")
val brokers = "192.168.225.13:9092,192.168.225.14:9092,192.168.225.15:9092"
val kafkaParam1s = 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, kafkaParam1s, topics)
val events = kafkaStream.flatMap(line => {
Some(line.toString())
})
