简介：
Spark-Streaming获取kafka数据的两种方式-Receiver与Direct的方式，能够简单理解成：api
- Receiver方式是经过zookeeper来链接kafka队列，
- Direct方式是直接链接到kafka的节点上获取数据了。
1、基于Receiver的方式
这种方式使用Receiver来获取数据。Receiver是使用Kafka的高层次Consumer API来实现的。receiver从Kafka中获取的数据都是存储在Spark Executor的内存中的，而后Spark Streaming启动的job会去处理那些数据。网络
然而，在默认的配置下，这种方式可能会由于底层的失败而丢失数据。若是要启用高可靠机制，让数据零丢失，就必须启用Spark Streaming的预写日志机制（Write Ahead Log，WAL）。该机制会同步地将接收到的Kafka数据写入分布式文件系统（好比HDFS）上的预写日志中。因此，即便底层节点出现了失败，也可使用预写日志中的数据进行恢复。
须要注意的要点异步
一、Kafka中的topic的partition，与Spark中的RDD的partition是没有关系的。因此，在KafkaUtils.createStream()中，提升partition的数量，只会增长一个Receiver中，读取partition的线程的数量。不会增长Spark处理数据的并行度。分布式
二、能够建立多个Kafka输入DStream，使用不一样的consumer group和topic，来经过多个receiver并行接收数据。性能
三、若是基于容错的文件系统，好比HDFS，启用了预写日志机制，接收到的数据都会被复制一份到预写日志中。所以，在KafkaUtils.createStream()中，设置的持久化级别是StorageLevel.MEMORY_AND_DISK_SER。spa
2、基于Direct的方式
这种新的不基于Receiver的直接方式，是在Spark 1.3中引入的，从而可以确保更加健壮的机制。替代掉使用Receiver来接收数据后，这种方式会周期性地查询Kafka，来得到每一个topic+partition的最新的offset，从而定义每一个batch的offset的范围。当处理数据的job启动时，就会使用Kafka的简单consumer api来获取Kafka指定offset范围的数据。线程
这种方式有以下优势：日志
一、简化并行读取：若是要读取多个partition，不须要建立多个输入DStream而后对它们进行union操做。Spark会建立跟Kafka partition同样多的RDD partition，而且会并行从Kafka中读取数据。因此在Kafka partition和RDD partition之间，有一个一对一的映射关系。队列
二、高性能：若是要保证零数据丢失，在基于receiver的方式中，须要开启WAL机制。这种方式其实效率低下，由于数据实际上被复制了两份，Kafka本身自己就有高可靠的机制，会对数据复制一份，而这里又会复制一份到WAL中。而基于direct的方式，不依赖Receiver，不须要开启WAL机制，只要Kafka中做了数据的复制，那么就能够经过Kafka的副本进行恢复。事务
三、一次且仅一次的事务机制：
基于receiver的方式，是使用Kafka的高阶API来在ZooKeeper中保存消费过的offset的。这是消费Kafka数据的传统方式。这种方式配合着WAL机制能够保证数据零丢失的高可靠性，可是却没法保证数据被处理一次且仅一次，可能会处理两次。由于Spark和ZooKeeper之间多是不一样步的。
四、下降资源。
Direct不须要Receivers，其申请的Executors所有参与到计算任务中；而Receiver-based则须要专门的Receivers来读取Kafka数据且不参与计算。所以相同的资源申请，Direct 可以支持更大的业务。
五、下降内存。
Receiver-based的Receiver与其余Exectuor是异步的，并持续不断接收数据，对于小业务量的场景还好，若是遇到大业务量时，须要提升Receiver的内存，可是参与计算的Executor并没有需那么多的内存。而Direct 由于没有Receiver，而是在计算时读取数据，而后直接计算，因此对内存的要求很低。实际应用中咱们能够把原先的10G降至如今的2-4G左右。
六、鲁棒性更好。
Receiver-based方法须要Receivers来异步持续不断的读取数据，所以遇到网络、存储负载等因素，致使实时任务出现堆积，但Receivers却还在持续读取数据，此种状况很容易致使计算崩溃。Direct 则没有这种顾虑，其Driver在触发batch 计算任务时，才会读取数据并计算。队列出现堆积并不会引发程序的失败。
基于direct的方式，使用kafka的简单api，Spark Streaming本身就负责追踪消费的offset，并保存在checkpoint中。Spark本身必定是同步的，所以能够保证数据是消费一次且仅消费一次。