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不删除）