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元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
