receiver:
使用kafka的高級api consumerAPI，自動更新offset到zookeeper;
在executor上會有receiver從kafka接收數據並存儲在Spark executor中，在到了batch時間后觸發job去處理接收到的數據，1個receiver占用1個core
使用wal預寫機制，因為需要使用hdfs等存儲,因此會降低性能
缺點：
work中receiver讀取kafka分區數據和sparkstreaming讀取數據后提交offset時機，都由高階api決定，但是會造成數據數據丟失（原因：當高階api提交offset后，但是sparkstreaming因為某種原因不可用，這時sparksteaming讀取的數據存在executor內存中，會造成數據丟失）
假設有6個分區，這樣receiver需要啟動6個線程，隨着數據量加大，這樣會造成讀寫瓶頸；多個receiver中Dstream進行合並以及wal預寫機制都會影響性能
高階消費者api提交offset到zookeeper
direct
沒有receiver，無須使用core不停的接收數據；
定時去kafka讀取每個partition最新offset以及上次處理的offset，也會處理當前查詢偏移量的數據范圍
使用kafka 簡單api，自己保存offset，kafka和zookeeper不會保存偏移量（自己維護offset，sparkstreaming讀取分區數據，將offset和job信息寫入到CheckPointPath中，job結束，job信息刪除,但是offset不刪除）