sparkStreaming 消费kafak有两种方式
1：receiver方式
2：direct方式
receiver方式：
1：sparkStreaming 将kafka之中的数据读取到spark内存之中，
然后对spark内存之中的数据进行计算操作。
2：offset 管理：
offset的提交被封装了，然后提交到了zookeeper之中。
3：kafka topic之中的partition的数目与 sparkStreaming之中partition的数目无关。
简单的 receiver demo:
其中的topic 变量是map 类型，键是kafka topic的名字，值是读取这个topic的线程的数量。
增加这个值，不会提升sparkStreaming 的并行处理的力度，但是会加快从receiver之中接收数据的速度。
receiver 方式 容错：
1：executor容错 ，开启wal机制。
具体的执行代码
2:diver端容错 设置checkpoint。
对driver 进行容错配置，
使用StreamingContext.getOrCreate() 函数来创建StreamingContext,
传入的第一个参数是 checkpoint的路径。
然后streamingContextFactory 函数是具体封装了对StreamingContext的执行逻辑。
然后还有注意的点：
checkpoint 是可以设置时间的，一般设置的时间在Duration的时长的5-10倍 左右。
direct方式：
优点：
1：简化并行读取 （RDD之中partition的数量 与 topic之中partition的数量是一致的）
2：高性能
调用kafka的低阶api,自己维护offset,数据直接从kafak之中读取，
相当于把kafak看成了hdfs。
offset是由自己来进行管理。
kafka topic的partition与 spark rdd之中的partition的数量是相同的。
所以直连消费kafka的时候，sparkstreaming的并行度是kafka之中topic的分区的数目。
手动维护 kafka的offset 的方式代码：
截图的代码不全 ，但是大体的思路就是，将kafka topic分区的 offset 更新到zookeeper之中。
使用kafka direct 方式消费数据的代码思路说明：
1：其实最重要的就是，就是KafkaStream的创建，所以就是具体的创建的代码。
主要的话就是会有三种情况，
一种的话，就是第一次创建这个应用
另外一种的话，其实就是再次重启了这个应用。
其实这个步骤其实是最重要的，其他的话，对于kakfaDirect流的创建
反而不是很需要的。
还有一种就是：重新启动应用，但是kafka的topic的分区的数目发生了变化。
kafka direct 连接streaming 的方式之中，最重要的其实是：
如何维护offset。
1:可以手动将offset 放置在 zookeeper之中。
2：也可以将offset 放置在mysql之中
3：也可以将offset 放置在hbase之中
....