sparkstreaming 消费kafka数据的 kafkautil 提供两种创建dstream的方法：
1 老版本的createStream方法
2 新版本的createDirectStream方法
通过createDirectStream方法创建出来的dstream的rdd partition 和 kafka 的topic的partition是一一对应的，通过低阶API直接从kafka的topic消费消息，并行计算效率高，默认将偏移量保存在kafka内部。
区别：
receive
工作流程：
1 spark集群中的worker节点中得executor线程里的receiver接口会一直消费 kafka 中的数据
优点：
1 receive使用了高阶API，需要消费者连接zookeeper来读取偏移量
2 由zookeeper来维护偏移量，不用我们来手动维护，这样的话就比较简单一些，减少代码量
缺点：
1 丢数据 它是由executor内的receive来拉取数据并存放在内存中，再由Driver端提交job来处理数据。如果底层节点出现错误，就会发生数据丢失。
2 浪费资源 为了防止1中丢数据可以，通过写WAL的方式，将数据存到hdfs上面做备份，那么如果再次发生错误，就可以从中读取数据。但这样会导致同样数据存了两份，浪费了资源。
3 可能会读取到重复数据 spark和zk不同步，导致一份数据读了两次
4 效率低 因为是分批次执行的，接收的数据直到设定的时间间隔，才进行计算。而且我们在kafkautil的createSteam中设定的partition数量，只会增加receive的数量，不能提高并行计算的效率。可以通过设置不同的group和topic创建dstream，之后再通过union合并dstream,提高并行度。
direct
1 工作原理：
1 direct方式就是使用executor直接连接kafka节点
2 我们自定义偏移量的使用
2 优点：
1 高效性。 当我们读取topic下的数据时，他会自动对应topic下partition生成相对应数量的RDD Partition 提高计算时的并行度，提高了效率
2 实现数据的零丢失。 当发生数据丢失，只要kafka上的数据进行了复制，就可以根据副本进行数据重新拉取，不需要通过WAL来维持数据的完整性
3 保证数据只消费一次。通过自定义维护偏移量，把业务处理和偏移量维护绑定在一个事务操作上
