sparkstreaming读取kafka的两种方式
来源:互联网 发布:mac口红质地 编辑:程序博客网 时间:2024/05/19 20:43
spark streaming提供了两种获取方式,一种是同storm一样,实时读取缓存到内存中;另一种是定时批量读取。
这两种方式分别是:
Receiver-base
Direct
2:维护blockforpushing队列,它是等待被拉到到BlockManager的中转站。它是currentbuffer和BlockManager的中间环节。它里面的每一个元素其实就是一个currentbuffer。
3:维护两个定时器,其实就是一个生产-消费模式。blockintervaltimer定时器,负责生产端,定时将currentbuffer放进blockforpushing队列。blockforpushingthread负责消费端,定时将blockforpushing里的数据转移到BlockManager。
如上述代码,函数getKafkaInputStream提供了zookeeper, topic, groupId, numReceivers, partition以及ssc,其传入函数分别对应:
zookeeper: ZooKeeper连接信息
topic: Kafka中输入的topic信息
groupId: consumer信息
numReceivers: 打算开启的receiver个数, 并用来调整并发
partition: Kafka中对应topic的分区数
以上几个参数主要用来连接Kafka并读取Kafka数据。具体执行的步骤如下:
Kafka相关读取参数配置,其中 zookeeper.connect即传入进来的zookeeper参数;auto.offset.reset设置从topic的最新处开始读取数据;zookeeper.connection.timeout.ms指zookeepr连接超时时间,以防止网络不稳定的情况;fetch.message.max.bytes则是指单次读取数据的大小;group.id则是指定consumer。
指定topic的并发数,当指定receivers个数之后,但是由于receivers个数小于topic的partition个数,所以在每个receiver上面会起相应的线程来读取不同的partition。
读取Kafka数据,numReceivers的参数在此用于指定我们需要多少Executor来作为Receivers,开多个Receivers是为了提高应用吞吐量。
union用于将多个Receiver读取的数据关联起来。
这种方式是延迟的。也就是说当action真正触发时才会去kafka里接数据。因此不存在currentbuffer的概念。它把kafka每个分区里的数据,映射为KafkaRdd的概念。题外话,在structured streaming中,也已经向DataFrame和DataSet统一了,弱化了RDD的概念。
真正与kafka打交道的是KafkaCluster,全限定名: org.apache.spark.streaming.kafka.KafkaCluster。包括设备kafka各种参数,连接,获取分区,以及偏移量,设置偏移量范围等。
Direct方式采用Kafka简单的consumer api方式来读取数据,无需经由ZooKeeper,此种方式不再需要专门Receiver来持续不断读取数据。当batch任务触发时,由Executor读取数据,并参与到其他Executor的数据计算过程中去。driver来决定读取多少offsets,并将offsets交由checkpoints来维护。将触发下次batch任务,再由Executor读取Kafka数据并计算。从此过程我们可以发现Direct方式无需Receiver读取数据,而是需要计算时再读取数据,所以Direct方式的数据消费对内存的要求不高,只需要考虑批量计算所需要的内存即可;另外batch任务堆积时,也不会影响数据堆积。其具体读取方式如下图:Spark Streaming提供了一些重载读取Kafka数据的方法,本文中关注两个基于Scala的方法,这在我们的应用场景中会用到,具体的方法代码如下:
方法createDirectStream中,ssc是StreamingContext;kafkaParams的具体配置见Receiver-based之中的配置,与之一样;这里面需要指出的是fromOffsets ,其用来指定从什么offset处开始读取数据。
方法createDirectStream中,该方法只需要3个参数,其中kafkaParams还是一样,并未有什么变化,不过其中有个配置auto.offset.reset可以用来指定是从largest或者是smallest处开始读取数据;topic是指Kafka中的topic,可以指定多个。具体提供的方法代码如下:
在实际的应用场景中,我们会将两种方法结合起来使用,大体的方向分为两个方面:
应用启动。当程序开发并上线,还未消费Kafka数据,此时从largest处读取数据,采用第二种方法;
应用重启。因资源、网络等其他原因导致程序失败重启时,需要保证从上次的offsets处开始读取数据,此时就需要采用第一种方法来保证我们的场景
总体方向上,我们采用以上方法满足我们的需要,当然具体的策略我们不在本篇中讨论,后续会有专门的文章来介绍。从largest或者是smallest处读Kafka数据代码实现如下:
提高成本。Direct需要用户采用checkpoint或者第三方存储来维护offsets,而不像Receiver-based那样,通过ZooKeeper来维护Offsets,此提高了用户的开发成本。
监控可视化。Receiver-based方式指定topic指定consumer的消费情况均能通过ZooKeeper来监控,而Direct则没有这种便利,如果做到监控并可视化,则需要投入人力开发。
- sparkstreaming读取kafka的两种方式
- Kafka到SparkStreaming的两种方式
- SparkStreaming和Kafka集成的两种方式(最全)
- spark读取kafka两种方式的区别
- spark读取kafka两种方式的区别
- SparkStreaming读取Kafka数据
- Flume直接到SparkStreaming的两种方式
- kafka0.8版本和sparkstreaming整合的两种不同方式
- SparkStreaming和Kafka的整合
- kafka同SparkStreaming的结合
- Kafka->SparkStreaming
- sparkstreaming+kafka
- sparkstreaming+kafka
- Spark获取Kafka数据的两种方式(源码)
- 13.kafka 收集日志的两种方式
- Spark-Streaming 和Kafka连接的两种方式
- Spark-Streaming 和Kafka连接的两种方式
- Spark Streaming获取kafka数据的两种方式
- leetcode 514. Freedom Trail
- 1563: 高精度加法
- Linux中关于用户和组的介绍
- Error:Error converting bytecode to dex
- OpenVPN服务器
- sparkstreaming读取kafka的两种方式
- 三极管:NPN和PNP
- 非root用户运行docker
- 博主的一些话
- java语言基础(85)——标准输入输出流 和 随机访问流
- [Spring Boot] 5. Spring Boot中的ApplicationContext
- Message,Handler,MessageQueue和Looper
- 排序总览
- java : [基于Apache CXF构建SOA应用] 书中提到的 common_build.xml