Receiver是使用Kafka的高層次Consumer API來實現的。
Receiver從Kafka中獲取的數據都是存儲在Spark Executor的內存中的，然后Spark Streaming啟動的job會去處理那些數據。
然而，在默認的配置下，這種方式可能會因為底層的失敗而丟失數據。
如果要啟用高可靠機制，讓數據零丟失，就必須啟用Spark Streaming的預寫日志機制（Write Ahead Log，WAL）。
該機制會同步地將接收到的Kafka數據寫入分布式文件系統（比如HDFS）上的預寫日志中。
所以，即使底層節點出現了失敗，也可以使用預寫日志中的數據進行恢復，但是效率會下降。
Direct這種方式會周期性地查詢Kafka，來獲得每個topic+partition的最新的offset，從而定義每個batch的offset的范圍。
當處理數據的job啟動時，就會使用Kafka的簡單consumer api來獲取Kafka指定offset范圍的數據。
Drirect這種方式有如下優點：
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，SparkStreaming自己就負責追蹤消費的offset，並保存在checkpoint中。
Spark自己一定是同步的，因此可以保證數據是消費一次且僅消費一次。