1、KafkaUtils.createDstream
構造函數爲KafkaUtils.createDstream(ssc, [zk], [consumer group id], [per-topic,partitions] )
使用了receivers來接收數據，利用的是Kafka高層次的消費者api，對於所有的receivers接收到的數據將會保存在Spark executors中，然後通過Spark Streaming啓動job來處理這些數據，默認會丟失，可啓用WAL日誌，該日誌存儲在HDFS上
A、創建一個receiver來對kafka進行定時拉取數據，ssc的rdd分區和kafka的topic分區不是一個概念，故如果增加特定主體分區數僅僅是增加一個receiver中消費topic的線程數，並不增加spark的並行處理數據數量
B、對於不同的group和topic可以使用多個receivers創建不同的DStream
C、如果啓用了WAL，需要設置存儲級別，即KafkaUtils.createStream(….,StorageLevel.MEMORY_AND_DISK_SER)。
2.KafkaUtils.createDirectStream
區別Receiver接收數據，這種方式定期地從kafka的topic+partition中查詢最新的偏移量，再根據偏移量範圍在每個batch裏面處理數據，使用的是kafka的簡單消費者api
優點:
A、 簡化並行，不需要多個kafka輸入流，該方法將會創建和kafka分區一樣的rdd個數，而且會從kafka並行讀取。
B、高效，這種方式並不需要WAL，WAL模式需要對數據複製兩次，第一次是被kafka複製，另一次是寫到wal中
C、恰好一次語義(Exactly-once-semantics)，傳統的讀取kafka數據是通過kafka高層次api把偏移量寫入zookeeper中，存在數據丟失的可能性是zookeeper中和ssc的偏移量不一致。EOS通過實現kafka低層次api，偏移量僅僅被ssc保存在checkpoint中，消除了zk和ssc偏移量不一致的問題。缺點是無法使用基於zookeeper的kafka監控工具。