Receiver

• 使用Kafka的高層次Consumer API來實現
• receiver從Kafka中獲取的資料都儲存在Spark Executor的記憶體中，然後Spark Streaming啟動的job會去處理那些資料
• 要啟用高可靠機制，讓資料零丟失，就必須啟用Spark Streaming的預寫日誌機制（Write Ahead Log，WAL）。該機制會同步地將接收到的Kafka資料寫入分散式檔案系統（比如HDFS）上的預寫日誌中
• Kafka中topic的partition與Spark中RDD的partition是沒有關係的，因此，在KafkaUtils.createStream()中，提高partition的數量，只會增加Receiver的數量，也就是讀取Kafka中topic partition的執行緒數量，不會增加Spark處理資料的並行度。
• 可以建立多個Kafka輸入DStream，使用不同的consumer group和topic，來通過多個receiver並行接收資料
• 如果基於容錯的檔案系統，比如HDFS，啟用了預寫日誌機制，接收到的資料都會被複制一份到預寫日誌中。因此，在KafkaUtils.createStream()中，設定的持久化級別是StorageLevel.MEMORY_AND_DISK_SER。

Direct

Spark1.3中引入Direct方式，用來替代掉使用Receiver接收資料，這種方式會週期性地查詢Kafka，獲得每個topic+partition的最新的offset，從而定義每個batch的offset的範圍。當處理資料的job啟動時，就會使用Kafka的簡單consumer api來獲取Kafka指定offset範圍的資料。

• 使用Kafka的簡單Consumer Api
• 簡化並行讀取：如果要讀取多個partition，不需要建立多個輸入DStream，然後對它們進行union操作。Spark會建立跟Kafka partition一樣多的RDD partition，並且會並行從Kafka中讀取資料。所以在Kafka partition和RDD partition之間，有一個一對一的對映關係。
• 高效能：如果要保證零資料丟失，在基於receiver的方式中，需要開啟WAL機制。這種方式其實效率低下，因為資料實際上被複制了兩份，Kafka自己本身就有高可靠的機制會對資料複製一份，而這裡又會複製一份到WAL中。而基於direct的方式，不依賴Receiver，不需要開啟WAL機制，只要Kafka中作了資料的複製，那麼就可以通過Kafka的副本進行恢復。
• 一次且僅一次的事務機制：基於receiver的方式，是使用Kafka的高階API來在ZooKeeper中儲存消費過的offset的。這是消費Kafka資料的傳統方式。這種方式配合著WAL機制可以保證資料零丟失的高可靠性，但是卻無法保證資料被處理一次且僅一次，可能會處理兩次。因為Spark和ZooKeeper之間可能是不同步的。基於direct的方式，使用kafka的簡單api，Spark Streaming自己就負責追蹤消費的offset，並儲存在checkpoint中。Spark自己一定是同步的，因此可以保證資料是消費一次且僅消費一次。由於資料消費偏移量是儲存在checkpoint中，因此，如果後續想使用kafka高階API消費資料，需要手動的更新zookeeper中的偏移量

參考：https://www.cnblogs.com/heml/p/6796414.html