1、读取数据的并发度
Receiver的方式：采用的是单核的模式，即使你设置了多个线程数，你的上下文环境中设置的并行度很大，也不会产生影响，还是1。只有通过配置多个receiver才会并行的读取kafka中的数据
Direct的方式：读取数据的并行度和topic的分区数相同，而且生成的DStream的并行度也和topic的分区数相同，一一对应。
2、生成的DSream的并行度
Receiver的方式：程序中Batch的间隔是4000ms，每Batch的数据构成一个RDD，在整个执行的环境中spark.streaming.blockInterval =100。生成的DStream的并发度是4000/100 =40
Direct的方式：生成的DStream的并行度也和topic的分区数相同，一一对应。
3、kafka日志文件
Receiver的方式：默认情况下这种方式读取的数据都是存在内存中的很容易导致OOM，如果要保证零数据丢失，必须开启预写日志机制，该机制会同步地将接收到的Kafka数据写入分布式文件系统（比如HDFS）上的预写日志中，即使底层节点出现了失败，也可以使用预写日志中的数据进行恢复。这种方式日志会保存两份，Kafka自己本身就有高可靠的机制，会对数据复制一份，而这里又会复制一份到WAL中，数据冗余，效率低下。
Direct的方式：只要Kafka中作了数据的复制，那么就可以通过Kafka的副本进行恢复。减少了存储数据到hdfs的步骤增加了job的执行速度。
4、offset
Receiver的方式：ZooKeeper中保存消费过的offset的，无法保证数据被处理一次且仅一次，可能会处理两次。因为Spark和ZooKeeper之间可能是不同步的。
Direct的方式：Spark Streaming自己就负责追踪消费的offset，并保存在checkpoint中。Spark自己一定是同步的，因此可以保证数据是消费一次且仅消费一次。也可以把offset保存到mysql中。用事务的方式保证数据的读取和offset的保存同时成功才行。
