Spark-Streaming+kafka

Spark Streaming + Kafka direct API

direct 周期查询kafka的最新offset在每个topic + partition，然后定义每个batch的offset范围。当
处理数据的job被启动时，kakfa的简单消费API是被用于去读取设定的范围的offset从kafka(类似读取文件从
文件系统)。

有几个优点相对receiver：
	Simplified Parallelism:不需要去创建多个input Kafka stream然后union它们。采用
directStream，Spark Streaming将创建与Kafka partitions相同数据的RDD partitions
去消费，并行从kafka读取数据。因此kafka 和 RDD partition 是一一映射，这是很容易理解和调优的。

	Efficiency:实现零数据丢失在receiver需要把数据存储在 WAL中，WAL中复制数据。这个实际是低效
的，因为这个数据获取了两次复制--第一次被kafka,第二次被WAL。direct 方式排除这个问题，因为这里没有
receiver，因此不需要WAL。只要你有重大的kafka retention时，message 能够从kafka找回

    Exactly-once semantics:receiver 使用了kakfa的 高级API在zookeeper去存储消费的offset。
这是传统消费kafka的数据方式。direct方式能够确保零数据丢失，在这里存在小概率一些记录可能被消费两次
在一些失败后。重复消费的出现是因为非一致性在SparkStreaming接收到的可靠数据和记录在Zookeper的
offset。因此，direct方式，采用没有使用zookeper的简单的kafka API。offset记录在checkpoints
中。这个排除了Spark Streaming和Zookeeper/kafka的一致性，因此每条记录被spark Streaming接收的
是执行一次，即使失败。为了实现 exactly-once semantics为你的结果，你的输出操作保存数据至一个外部
数据存储必须要不是idempotent幂等性的，或者原子事务保存结果和offset

注意点：
	1. 强制类型转换 HasOffsetRange 只有在DirectKafkaStream的第一个方法才能成功，而不是后面的
链式方。可以通过transform()代码 foreachRDD()如果你的第一个方法只是是访问offset。然后再调用
Spark的其他方法。然而，注意RDD partition与kafka partition的一一映射关系将不再维持，在绝对绝对
经历了shuffle或者repartition之后，例如reduceByKey() 或者 window()。
	2. 这种方式没有使用receivers，标准的receiver相关的也不将被应用至 input DStreams--通过
direct 方式创建的。取代的是spark.streaming.kafka.* 其中一个重要的是
spark.streaming.kafka.maxRatePerPartition，这个设置用于设置每个kafka partition将被direct 
API读取的最大速率