-1,基於接收者Receiver-based的方法

運算元：KafkaUtils.createStream 
方法：PUSH，從topic中去推送資料，將資料推送過來 
API：呼叫的Kafka高階API 
效果：SparkStreaming中的Receivers，恰好Kafka有釋出/訂閱 ，然而：此種方式企業不常用，說明有BUG，不符合企業需求。因為：接收到的資料儲存在Executor的記憶體，會出現資料漏處理或者多處理狀況 
解釋：這種方法使用Receiver來接收資料。Receiver是使用Kafka高階消費者API實現的。與所有的接收者一樣，通過Receiver從Kafka接收的資料儲存在Spark執行程式exector中，然後由Spark Streaming啟動的作業處理資料。但是，在預設配置下，這種方法可能會在失敗時丟失資料。為了確保零資料丟失，您必須在Spark Streaming（在Spark 1.2中引入）中額外啟用寫入日誌，同時儲存所有接收到的Kafka資料寫入分散式檔案系統（例如HDFS）的預先寫入日誌，以便所有資料都可以在失敗時恢復。 
缺點： 

• 配置spark.streaming.receiver.writeAheadLog.enable引數，每次處理之前需要將該batch內的日誌備份到checkpoint目錄中，這降低了資料處理效率，反過來又加重了Receiver端的壓力；另外由於資料備份機制，會受到負載影響，負載一高就會出現延遲的風險，導致應用崩潰。
• 採用MEMORY_AND_DISK_SER降低對記憶體的要求。但是在一定程度上影響計算的速度
• 單Receiver記憶體。由於receiver也是屬於Executor的一部分，那麼為了提高吞吐量，提高Receiver的記憶體。但是在每次batch計算中，參與計算的batch並不會使用到這麼多的記憶體，導致資源嚴重浪費。
• 提高並行度，採用多個Receiver來儲存Kafka的資料。Receiver讀取資料是非同步的，並不參與計算。如果開較高的並行度來平衡吞吐量很不划算。
• Receiver和計算的Executor的非同步的，那麼遇到網路等因素原因，導致計算出現延遲，計算佇列一直在增加，而Receiver則在一直接收資料，這非常容易導致程式崩潰。
• 在程式失敗恢復時，有可能出現數據部分落地，但是程式失敗，未更新offsets的情況，這導致資料重複消費。

為了回闢以上問題，降低資源使用，我們後來採用Direct Approach來讀取Kafka的資料，具體接下來細說。

-2,直接方法（無接收者）

運算元：KafkaUtils.createDirectStream 
方式：PULL，到topic中去拉取資料。 
API：kafka低階API 

Direct方式採用Kafka簡單的consumer api方式來讀取資料，無需經由ZooKeeper，此種方式不再需要專門Receiver來持續不斷讀取資料。當batch任務觸發時，由Executor讀取資料，並參與到其他Executor的資料計算過程中去。driver來決定讀取多少offsets，並將offsets交由checkpoints來維護。Direct方式無需Receiver讀取資料，而是需要計算時再讀取資料，所以Direct方式的資料消費對記憶體的要求不高，只需要考慮批量計算所需要的記憶體即可。
效果：每次到Topic的每個分割槽依據偏移量進行獲取資料，拉取資料以後進行處理，可以實現高可用 
解釋：在Spark 1.3中引入了這種新的無接收器“直接”方法，以確保更強大的端到端保證。這種方法不是使用接收器來接收資料，而是定期查詢Kafka在每個topic+分partition中的最新偏移量，並相應地定義要在每個批次中處理的偏移量範圍。當處理資料的作業啟動時，Kafka簡單的客戶API用於讀取Kafka中定義的偏移範圍（類似於從檔案系統讀取檔案）。請注意，此功能在Spark 1.3中為Scala和Java API引入，在Spark 1.4中針對Python API引入。 
優勢： 
①、簡化的並行性：不需要建立多個輸入Kafka流並將其合併。與此同時directStream，Spark Streaming將建立與使用Kafka分割槽一樣多的RDD分割槽，這些分割槽將全部從Kafka並行讀取資料。所以在Kafka和RDD分割槽之間有一對一的對映關係，這更容易理解和調整。

②、效率：在第一種方法中實現零資料丟失需要將資料儲存在預寫日誌中，這會進一步複製資料。這實際上是效率低下的，因為資料被有效地複製了兩次，一次是由Kafka，另一次是由預先寫入日誌（Write Ahead Log）複製。此方法消除了這個問題，因為沒有接收器，因此不需要預先寫入日誌。只要你有足夠的kafka保留，訊息可以從kafka恢復。

③、精確語義：第一種方法是使用Kafka的高階API在Zookeeper中儲存消耗的偏移量。傳統上這是從Kafka消費資料的方式。雖然這種方法（合併日誌）可以確保零資料丟失，但在某些失敗情況下，很小的機率兩次資料都同時丟失，發生這種情況是因為Spark Streaming可靠接收到的資料與Zookeeper跟蹤的偏移之間的不一致。因此，在第二種方法中，我們使用不使用Zookeeper的簡單Kafka API。在其檢查點checkpoint內，Spark Streaming跟蹤偏移量。這消除了Spark Streaming和Zookeeper / Kafka之間的不一致性，因此Spark Streaming每次記錄都會在發生故障時有效地接收一次。

請注意，這種方法的一個缺點是它不會更新Zookeeper中的偏移量，因此基於Zookeeper的Kafka監控工具將不會顯示進度。但是，您可以在每個批次中訪問由此方法處理的偏移量，並自己更新Zookeeper

優缺點對比其實很明顯：

直接讀取方式沒有專門的receivers，降低記憶體使用，生產中能將記憶體從10G降低到2-4G

直接讀取的qud， offset的維護需要手動開發，不能通過監控zookeeper來監控offset進度