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範圍的資料。

這種方式有如下優點：
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自己一定是同步的，因此可以保證資料是消費一次且僅消費一次。