spark连接kafka的两种方式

  1. Reciver方式
    spark streaming通过Reciver方式获取kafka的数据实质是:在spark程序的Executor中开Reciver来接收来自kafka的数据,然后spark streaming会启动job去处理这些数据。
    因为这些数据是存在内存中的,所以这种方式会容易丢失数据,如果要启用高可靠机制,让数据零丢失,就必须启用Spark Streaming的预写日志机制(Write Ahead Log,WAL)。该机制会同步地将接收到的Kafka数据写入分布式文件系统(比如HDFS)上的预写日志中。所以,即使底层节点出现了失败,也可以使用预写日志中的数据进行恢复,但是效率会下降。
    在这里插入图片描述

  2. Direct
    使用Direct这种方式的话,spark会主动地拉取kafka的数据,它会周期性地查询kafka中每个partition中最新的offset。
    使用这种方式的优点:
    1.简化并行读取
    如果要读取多个partition,不需要创建多个输入DStream然后对它们进行union操作。
    Spark会创建跟Kafka partition一样多的RDD partition,并且会并行从Kafka中读取数据。
    所以在Kafka partition和RDD partition之间,有一个一对一的映射关系。
    2.高性能
    如果要保证零数据丢失,在基于receiver的方式中,需要开启WAL机制。
    这种方式其实效率低下,因为数据实际上被复制了两份,Kafka自己本身就有高可靠的机制,会对数据复制一份,而这里又会复制一份到WAL中。
    而基于direct的方式,不依赖Receiver,不需要开启WAL机制,只要Kafka中作了数据的复制,那么就可以通过Kafka的副本进行恢复。
    3.一次且仅一次的事务机制
    基于receiver的方式,是使用Kafka的高阶API来在ZooKeeper中保存消费过的offset的。
    这是消费Kafka数据的传统方式。
    这种方式配合着WAL机制可以保证数据零丢失的高可靠性,但是却无法保证数据被处理一次且仅一次,可能会处理两次。
    因为Spark和ZooKeeper之间可能是不同步的。
    基于direct的方式,使用kafka的简单api,SparkStreaming自己就负责追踪消费的offset,并保存在checkpoint中。
    Spark自己一定是同步的,因此可以保证数据是消费一次且仅消费一次。
    在这里插入图片描述
    使用Direct方式有拉取kafka的数据有三种策略,在创建createDirectStream的时候指定:
    在这里插入图片描述
    1.PreferBrokers:当且仅当Executor和broker在同一台机器上时使用。
    2.PreferConsistent:kafka的分区会均匀地分布在每个Executor上。
    3.PreferFixed:指定某一分区的数据分配到指定的Executor上。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页