Spark 针对 Kafka 的不同版本,提供了两套整合方案:spark-streaming-kafka-0-8 和 spark-streaming-kafka-0-10,其主要区别如下:
最近工作有点忙,所以更新文章频率低了点,在这里给大家说声抱歉,前面已经写过在spark streaming中管理offset,但当时只知道怎么用,并不是很了解为何要那样用,最近一段时间又抽空看了一个github开源程序自己管理offset的源码,基本已经理解透彻了,当然这里面还包含了由于理解不透彻导致升级失败的一个案例,这个在下篇文章会分享出来。本篇我们先从理论的角度聊聊在Spark Streaming集成Kafka时的offset状态如何管理。 spark streaming 版本 2.1 kafka 版
spark读取kafka数据流提供了两种方式createDstream和createDirectStream。 两者区别如下: 1、KafkaUtils.createDstream 构造函数为KafkaUtils.createDstream(ssc, [zk], [consumer group id], [per-topic,partitions] ) 使用了receivers来接收数据,利用的是Kafka高层次的消费者api,对于所有的receivers接收到的数据将会保存在Spark executors中,然后通过Spark Streaming启动job来处理这些数据,默认会丢失,可启用WAL日志,该日志存储在HDFS上 A、创建一个receiver来对kafka进行定时拉取数据,ssc的rdd分区和kafka的topic分区不是一个概念,故如果增加特定主体分区数仅仅是增加一个receiver中消费topic的线程数,并不增加spark的并行处理数据数量 B、对于不同的group和topic可以使用多个receivers创建不同的DStream C、如果启用了WAL,需要设置存储级别,即KafkaUtils.createStream(….,StorageLevel.MEMORY_AND_DISK_SER) 2.KafkaUtils.createDirectStream 区别Receiver接收数据,这种方式定期地从kafka的topic+partition中查询最新的偏移量,再根据偏移量范围在每个batch里面处理数据,使用的是kafka的简单消费者api 优点: A、 简化并行,不需要多个kafka输入流,该方法将会创建和kafka分区一样的rdd个数,而且会从kafka并行读取。 B、高效,这种方式并不需要WAL,WAL模式需要对数据复制两次,第一次是被kafka复制,另一次是写到wal中
The Spark Streaming integration for Kafka 0.10 is similar in design to the 0.8 Direct Stream approach;
关于SparkStreaming从理论到实战的部分,博主已经在前面的博客中介绍了。本篇博客,为大家带来的是SparkStreaming整合Kafka的教程!
在这里我们解释如何配置 Spark Streaming 以接收来自 Kafka 的数据。有两种方法,一种为使用 Receivers 和 Kafka 高级API的旧方法,以及不使用 Receivers 的新方法(在 Spark 1.3 中引入)。它们具有不同的编程模型,性能特征和语义保证。就目前的 Spark 版本而言,这两种方法都被为稳定的API。
前面的文章已经介绍了在spark streaming集成kafka时,如何处理其偏移量的问题,由于spark streaming自带的checkpoint弊端非常明显,所以一些对数据一致性要求比较高的项目里面,不建议采用其自带的checkpoint来做故障恢复。 在spark streaming1.3之后的版本支持direct kafka stream,这种策略更加完善,放弃了原来使用Kafka的高级API自动保存数据的偏移量,之后的版本采用Simple API也就是更加偏底层的api,我们既可以用chec
Spark Streaming是一个基于Spark Core之上的实时计算框架,可以从很多数据源消费数据并对数据进行实时的处理,具有高吞吐量和容错能力强等特点。
注意:读数据只能从Leader读, 写数据也只能往Leader写,Follower会从Leader那里同步数据过来做副本!!!
上篇文章,讨论了在spark streaming中管理消费kafka的偏移量的方式,本篇就接着聊聊上次说升级失败的案例。 事情发生一个月前,由于当时我们想提高spark streaming程序的并行处理性能,于是需要增加kafka分区个数,,这里需要说下,在新版本spark streaming和kafka的集成中,按照官网的建议 spark streaming的executors的数量要和kafka的partition的个数保持相等,这样每一个executor处理一个kafka partition的数据,效
一般的大型集群和平台, 都需要对其进行监控的需求。 要针对各种数据库, 包括 MySQL, HBase 等进行监控 要针对应用进行监控, 例如 Tomcat, Nginx, Node.js 等 要针对硬件的一些指标进行监控, 例如 CPU, 内存, 磁盘 等
这篇博客将会记录Structured Streaming + Kafka的一些基本使用(Java 版)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6wtQxLP6-1626354186973)(/img/image-20210506154426999.png)]
下午的时候翻微信看到大家在讨论Spark消费Kafka的方式,官网中就有答案,只不过是英文的,当然很多博客也都做了介绍,正好我的收藏夹中有一篇文章供大家参考。文章写的通俗易懂,搭配代码,供大家参考。
Kafka是⼀个分布式、分区的、多副本的、多⽣产者、多订阅者,基于zookeeper协调的分布式⽇志系统(也可以当做MQ系统),常⻅可以⽤于web/nginx⽇志、访问⽇志,消息服务等等。 Kafka主要应⽤场景:⽇志收集系统和消息系统
为了让Spark Streaming消费kafka的数据不丢数据,可以创建Kafka Direct DStream,由Spark Streaming自己管理offset,并不是存到zookeeper。启用Spark Streaming的 checkpoints是存储偏移量的最简单方法,因为它可以在Spark的框架内轻松获得。 checkpoints将应用程序的状态保存到HDFS,以便在故障时可以恢复。如果发生故障,Spark Streaming应用程序可以从checkpoints偏移范围读取消息。
http://spark.apache.org/docs/2.4.5/structured-streaming-kafka-integration.html
框架版本 spark2.1.0 kafka0.9.0.0 当使用sparkstreaming处理流式数据的时候,它的数据源搭档大部分都是Kafka,尤其是在互联网公司颇为常见。 当他们集成的时候我们需要重点考虑就是如果程序发生故障,或者升级重启,或者集群宕机,它究竟能否做到数据不丢不重呢? 也就是通常我们所说的高可靠和稳定性,通常框架里面都带有不同层次的消息保证机制,一般来说有三种就是: at most once 最多一次 at least once 最少一次 exactly once 准确一次 在sto
消息队列一般包含两种模式,一种是点对点的模式,一种是发布订阅的模式。前文提到过 kafka 是一款基于发布订阅的消息队列。那么kafka是怎么去发布消息,怎么去保存消息,订阅消息的呢?首先我们从kafka的发布订阅模型开始分析。
每个集群都有一个broker是集群控制器(自动从集群的活跃成员中选举出来) 控制器负责管理工作: 将分区分配给broker 监控broker 集群中一个分区属于一个broker,该broker称为分区首领。 一个分区可以分配给多个broker,此时会发生分区复制。 分区的复制提供了消息冗余,高可用。副本分区不负责处理消息的读写。
我们知道,当下流行的MQ非常多,不过很多公司在技术选型上还是选择使用Kafka。与其他主流MQ进行对比,我们会发现Kafka最大的优点就是吞吐量高。实际上Kafka是高吞吐低延迟的高并发、高性能的消息中间件,配置良好的Kafka集群甚至可以做到每秒几十万、上百万的超高并发写入。
分布式,是程序员必备技能之一,在面试过程中属于必备类的,在工作中更是会经常用到。而Kafka是一个分布式的基于发布订阅的消息队列,目前它的魅力是无穷的,对于Kafka的奥秘,还需要我们细细去探寻。
Spark Streaming 是一种构建在 Spark 上的实时计算框架,它扩展了 Spark 处理大规模流式数据的能力。Spark Streaming 的优势在于:
SparkStreaming与kafka010整合 读本文之前,请先阅读之前文章: 必读:再讲Spark与kafka 0.8.2.1+整合 Spark Streaming与kafka 0.10的整合,和0.8版本的direct Stream方式很像。Kafka的分区和spark的分区是一一对应的,可以获取offsets和元数据。API使用起来没有显著的区别。这个整合版本标记为experimental,所以API有可能改变。 工程依赖 首先,添加依赖。 groupId = org.apache.spark
随着大数据的快速发展,业务场景越来越复杂,离线式的批处理框架MapReduce已经不能满足业务,大量的场景需要实时的数据处理结果来进行分析、决策。Spark Streaming是一种分布式的大数据实时计算框架,他提供了动态的,高吞吐量的,可容错的流式数据处理,不仅可以实现用户行为分析,还能在金融、舆情分析、网络监控等方面发挥作用。个推开发者服务——消息推送“应景推送”正是应用了Spark Streaming技术,基于大数据分析人群属性,同时利用LBS地理围栏技术,实时触发精准消息推送,实现用户的精细化运营。此外,个推在应用Spark Streaming做实时处理kafka数据时,采用Direct模式代替Receiver模式的手段,实现了资源优化和程序稳定性提升。
大数据时代来临,如果你还不知道Kafka那你就真的out了(快速掌握Kafka请参考文章:如何全方位掌握Kafka核心技术)!据统计,有三分之一的世界财富500强企业正在使用Kafka,包括所有TOP10旅游公司,7家TOP10银行,8家TOP10保险公司,9家TOP10电信公司等等。
1.消费者 import org.apache.kafka.clients.consumer.ConsumerRecord; import org.apache.kafka.clients.consumer.ConsumerRecords; import org.apache.kafka.clients.consumer.KafkaConsumer; import org.apache.kafka.common.serialization.StringDeserializer; import java.u
kafka 是一款基于发布订阅的消息系统,Kafka的最大的特点就是高吞吐量以及可水平扩展, Kafka擅长处理数据量庞大的业务,例如使用Kafka做日志分析、数据计算等。
说人话:其实就是讲Spark Streaming 的好处与坑。好处主要从一些大的方面讲,坑则是从实际场景中遇到的一些小细节描述。
Spark是Scala语言实现的核心数据结构是RDD的基于内存迭代计算的分布式框架。
之前刚学Spark时分享过一篇磨炼基础的练习题,➤Ta来了,Ta来了,Spark基础能力测试题Ta来了!,收到的反馈还是不错的。于是,在正式结课Spark之后,博主又为大家倾情奉献一道关于Spark的综合练习题,希望大家能有所收获✍
Kafka 起初是由 LinkedIn 公司采用 Scala 语言开发的一个多分区、多副本且基于 Zookeeper 协调的分布式消息系统,现已被捐献给 Apache 基金会。目前 Kafka 已经定位为一个分布式流式处理平台,它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性被广泛使用。目前越来越多的开源式分布处理系统如:Storm、Spark、Flink 等都支持与 Kafka 集成。
文章有点长,但是写的都挺直白的,慢慢看下来还是比较容易看懂,从Kafka的大体简介到Kafka的周边产品比较,再到Kafka与Zookeeper的关系,进一步理解Kafka的特性,包括Kafka的分区和副本以及消费组的特点及应用场景简介。
1.将kafka streaming 和 redis整合 实现词频统计 Producer.class 生成数据daokafka package day14; /** * 创建一个生产者 生成随机的key 和 字母 * 用于实现实时流统计词频 并 存储到redis */ import org.apache.kafka.clients.producer.KafkaProducer; import org.apache.kafka.clients.producer.ProducerRecord;
Apache Kafka是基于发布/订阅的容错消息系统,由Scala和Java编写,是一个分布式消息队列,具有高性能、持久化、多副本备份、横向扩展能力。
在大数据时代中我们迫切需要实时应用解决源源不断涌入的数据,然而建立这么一个应用需要解决多个问题:
Apache Kafka 正在迅速成为最受欢迎的开源流处理平台之一。我们在 Spark Streaming 中也看到了同样的趋势。因此,在 Apache Spark 1.3 中,我们专注于对 Spark Streaming 与 Kafka 集成进行重大改进。主要增加如下:
1.1 Introduction Kafka is a distributed streaming platform. What exactly does that mean? kafka是一个分布式
前面文章介绍了不少有关Spark Streaming的offset的管理以及如何优雅的关闭Spark Streaming的流程序。 到目前为止还有几个问题: (1)有关spark streaming集成kafka时,如果kafka新增分区, 那么spark streaming程序能不能动态识别到而不用重启? (2)如果需要重启,那么在自己管理offset时,如何才能识别到新增的分区? (3)spark streaming优雅关闭的策略还有那些? 首先第一个问题,如果kafka要新增分区,对于正在运行的实时流
(一)业务场景 传统离线数仓模式下,日志入库前首要阶段便是ETL,Soul的埋点日志数据量庞大且需动态分区入库,在按day分区的基础上,每天的动态分区1200+,分区数据量大小不均,数万条到数十亿条不等。下图为我们之前的ETL过程,埋点日志输入Kafka,由Flume采集到HDFS,再经由天级Spark ETL任务,落表入Hive。任务凌晨开始运行,数据处理阶段约1h,Load阶段1h+,整体执行时间为2-3h。
此检查点位置必须是HDFS兼容文件系统中的路径,两种方式设置Checkpoint Location位置:
将每批次数据状态,按照Key与以前状态,使用定义函数【updateFunc】进行更新,示意图如下:
今天,我们开始了我们的新旅程,这就是Apache Kafka教程。在这个Kafka教程中,我们将看到什么是Kafka,Apache Kafka的历史,为什么是Kafka。此外,我们还将学习Kafka架构、Kafka的组件和Kafka分区。此外,我们还将讨论Kafka的各种比较和Kafka的使用案例。除此之外,我们将在这个Kafka教程中看到各种术语,如Kafka Broker、Kafka Cluster、Kafka Consumer、Kafka Topics等。
在上篇文章中,我们过了下基本的理论,也介绍了主流的流处理框架:Storm,Trident,Spark Streaming,Samza和Flink。今天咱们来点有深度的主题,比如,容错,状态管理或者性能。除此之外,我们也将讨论开发分布式流处理应用的指南,并给出推荐的流处理框架。
虽然SparkStreaming已经停止更新,Spark的重点也放到了 Structured Streaming ,但由于Spark版本过低或者其他技术选型问题,可能还是会选择SparkStreaming。SparkStreaming对于时间窗口,事件时间虽然支撑较少,但还是可以满足部分的实时计算场景的,SparkStreaming资料较多,这里也做一个简单介绍。
上一文对消费者组的一些概念,基本原理进行了简单描述,本文继续来聊聊消费者组中另外一个比较重要的内容:偏移量的存储。
我们看到Kafka最新的定义是:Apache Kafka® is a distributed streaming platform
领取专属 10元无门槛券
手把手带您无忧上云