2024.1.13 Kafka六大机制和Structured Streaming

2024-01-13 18:36

本文主要是介绍2024.1.13 Kafka六大机制和Structured Streaming,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

目录

一 . Kafka中生产者数据分发策略

二.  Kafka消费者的负载均衡机制

三 . 数据不丢失机制

生产者端是如何保证数据不丢失的呢?

Broker端如何保证数据不丢失

 消费端如何保证数据不丢失

Kafka中消费者如何对数据仅且只消费一次

 四 . 启动Kafka eagle命令

数据积压问题处理

五 . 结构化流 

数据源 File Source

OPERATIONS数据处理操作

 Sink输出操作


六大机制:分区,副本,存储,查询,数据不丢失,负载均衡 ; 

一 . Kafka中生产者数据分发策略

        JAVA中的轮询分发策略 和 粘性分发策略:

                轮询:避免数据倾斜

                粘性: 产生数据倾斜

                轮询分发策略: 在Kafka的老版本中存在的一种分发策略,当生产数据的时候,只有value但是没有key的时候,采用轮询。
    优点: 可以保证每个分区拿到的数据基本是一样,因为是一个一个的轮询的分发
    缺点: 如果采用异步发送方式,意味着一批数据发送到broker端,由于是轮询策略,会将这一批数据拆分为多个小的批次,分别再写入到不同的分区里面去,写入进去以后,每个分区都会给予响应,会影响写入效率。

                粘性分发策略: 在Kafka新版本中存在的一种分发策略。当生产数据的时候,只有value但是没有key的时候,采用粘性分发策略
    优点: 在发送数据的时候,首先会随机的选取一个分区,然后尽可能将数据分发到这个分区上面去,也就是尽可能粘着这个分区。该分发方式,在异步发送的操作中,效率比较高。
    缺点: 在数据发送特别快的时候,可能会导致某个分区的数据比其他分区数据多很多,造成大量的数据集中在一个分区上面

二.  Kafka消费者的负载均衡机制

Kafka消费者的负载均衡机制
1- 在同一个消费组中,消费者的个数最多不能超过Topic的分区数。如果超过了,就会有一些消费者处于闲置状态,消费不到任何数据。
2- 在同一个消费组中,一个Topic中一个分区的数据,只能被同个消费组中的一个消费者所消费,不能被同个消费组中多个消费者所消费。但是一个消费组内的一个消费者可以消费多个分区的数据。也就是分区和消费者的对应关系,多对一
3-不同的消费组中的消费者,可以对一个Topic的数据同时消费,也就是不同消费组间没有任何关系

三 . 数据不丢失机制

生产者端是如何保证数据不丢失的呢?


答:生产者端将消息发送给到Kafka集群以后,broker要给生产者响应信息。响应原理就是ACK机制


ACK机制当中有3个参数配置值,分别是:0  1  -1(all)
0:生产者生产消息给到Kafka集群,生产者不等待(不接收)broker返回的响应信息
1:生产者生产消息给到Kafka集群,Kafka集群中的分区对应的Leader主副本所在的broker给生产者返回响应信息
-1(all):生产者生产消息给到Kafka集群,Kafka集群中的分区对应的所有副本给生产者返回响应信息


消息的生产效率排序(由高到低):0 > 1 > -1
消息的安全级别排序(由高到低):-1 > 1 > 0


在实际工作中如何选择ACK参数配置?
答:根据数据的重要程度进行选择。如果数据重要,优先保证数据的安全性,再考虑生产效率;如果数据不重要,优先考虑生产效率,再尽可能提升安全级别。

Broker端如何保证数据不丢失

        Broker端通过多副本机制确保数据不丢失。同时需要生产者端将acks设置为-1

 消费端如何保证数据不丢失

消费者消费消息的步骤:
1- 消费者首先连接到Kafka集群中,进行消息的消费

2- Kafka集群接收到Consumer消费者的消费请求以后,首先会根据group id(消费组名称),查找上次消费消息对应的offset(偏移量)

3- 如果没有查找到offset,消费者默认从Topic最新的地方开始消费

4- 如果有查找到offset,会从上次消费到的offset地方进行继续消费
    4.1- 首先先确定要读取的这个offset偏移量在哪个segment文件当中
    4.2- 查询这个segment文件对应的index文件,根据offset确定这个消息在log文件的什么位置,也就是确定消息的物理偏移量
    4.3- 读取log文件,查询对应范围内的数据即可
    4.4- 获取最终的消息数据

5- 消费者在消费的过程中,底层有个线程会定时的将消费的offset提交给到Kafka集群。Kafka集群会更新对应的offset的值

Kafka中消费者如何对数据仅且只消费一次

1- 将消费者的 enable.auto.commit 属性设置为 false,并手动管理消费者的偏移量。这样可以确保消费者在处理完所有消息后才更新偏移量,避免重复消费数据。也就是将消息的消费、消息业务处理代码、offset提交代码放在同一个事务当中。

2- 使用幂等生产者或事务性生产者来确保消息只被发送一次。这样可以避免重复发送消息,从而避免消费者重复消费数据。

3- 在消息中加入唯一的ID

 四 . 启动Kafka eagle命令

cd /export/server/kafka-eagle-bin-1.4.6/kafka-eagle-web-1.4.6/bin

./ke.sh start

数据积压问题处理

出现积压的原因:

  • 因为数据写入目的容器失败,从而导致消费失败

  • 因为网络延迟消息消费失败

  • 消费逻辑过于复杂, 导致消费过慢,出现积压问题

解决方案:

  • 对于第一种, 我们常规解决方案, 处理目的容器,保证目的容器是一直可用状态

  • 对于第二种, 如果之前一直没问题, 只是某一天出现, 可以调整消费的超时时间。并且同时解决网络延迟问题

  • 对于第三种, 一般解决方案,调整消费代码, 消费更快即可, 利于消费者的负载均衡策略,提升消费者数量

 

五 . 结构化流 

        有界: 数据大小固定,有开始和结尾

        无界: 源源不断的数据,没有明确的结尾

结构化流是构建在Spark SQL处理引擎之上的一个流式的处理引擎,主要是针对无界数据的处理操作。对于结构化流同样也支持多种语言操作的API:比如 Python Java Scala SQL ....

Spark的核心是RDD。RDD出现主要的目的就是提供更加高效的离线的迭代计算操作,RDD是针对的有界的数据集,但是为了能够兼容实时计算的处理场景,提供微批处理模型,本质上还是批处理,只不过批与批之间的处理间隔时间变短了,让我们感觉是在进行流式的计算操作,目前默认的微批可以达到100毫秒一次

真正的流处理引擎: Flink、Storm(早期流式处理引擎)、Flume(流式数据采集)

数据源 File Source

        将目录中写入的文件作为数据流读取,支持的文件格式为:text、csv、json、orc、parquet。。。。

文件数据源特点:
        1- 不能够监听具体的文件,否则会报错误java.lang.IllegalArgumentException: Option 'basePath' must be a directory
        2- 可以通过通配符的形式,来监听目录下的文件,符合要求的才会被读取
        3- 如果监听目录中有子目录,那么无法监听到子目录的变化情况 

File source只能监听目录,不能监听具体文件 

读取代码通用格式:

                sparksession.readStream

                     .format('CSV|JSON|TEXT|PARQUET|ORC)

                    .option('参数名1','参数值1')
                    .option('参数名2','参数值2')
                    .option('参数名N','参数值N')
                    .schema(元数据信息)
                    .load('需要监听的目录地址')

OPERATIONS数据处理操作

        指的是数据处理部分,该操作和SparkSQL完全一致 

 Sink输出操作

        append模式:

                只支持追加,不支持聚合和排序,每次只打印追加的内容

        complete模式:

                每一次都全量处理,因为数据量大,所以必须聚合,也可以支持排序

        update模式: 

                支持聚合的append模式,有聚合操作只会输出有变化和新增的内容,不支持排序;

这篇关于2024.1.13 Kafka六大机制和Structured Streaming的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/602413

相关文章

Linux系统稳定性的奥秘:探究其背后的机制与哲学

在计算机操作系统的世界里,Linux以其卓越的稳定性和可靠性著称,成为服务器、嵌入式系统乃至个人电脑用户的首选。那么,是什么造就了Linux如此之高的稳定性呢?本文将深入解析Linux系统稳定性的几个关键因素,揭示其背后的技术哲学与实践。 1. 开源协作的力量Linux是一个开源项目,意味着任何人都可以查看、修改和贡献其源代码。这种开放性吸引了全球成千上万的开发者参与到内核的维护与优化中,形成了

Spring中事务的传播机制

一、前言 首先事务传播机制解决了什么问题 Spring 事务传播机制是包含多个事务的方法在相互调用时,事务是如何在这些方法间传播的。 事务的传播级别有 7 个,支持当前事务的:REQUIRED、SUPPORTS、MANDATORY; 不支持当前事务的:REQUIRES_NEW、NOT_SUPPORTED、NEVER,以及嵌套事务 NESTED,其中 REQUIRED 是默认的事务传播级别。

常用MQ消息中间件Kafka、ZeroMQ和RabbitMQ对比及RabbitMQ详解

1、概述   在现代的分布式系统和实时数据处理领域,消息中间件扮演着关键的角色,用于解决应用程序之间的通信和数据传递的挑战。在众多的消息中间件解决方案中,Kafka、ZeroMQ和RabbitMQ 是备受关注和广泛应用的代表性系统。它们各自具有独特的特点和优势,适用于不同的应用场景和需求。   Kafka 是一个高性能、可扩展的分布式消息队列系统,被设计用于处理大规模的数据流和实时数据传输。它

展厅设计主要的六大要素

1、从创意开始      展示设计的开始必须创意在先。根据整体的风格思路进行创意,首先要考虑的是主体的造型、大小高度位置以及它和周围展厅的关系。另外其他道具设计制作与运作方式也必须在创意中有明确的体现。      2、平面感      平面感是指对展示艺术设计平面图纸审美和功能两个方面理性的感觉认识。它是三维空间设计认识的基础,也是施工的重要依据。展示空间的设计应先在展场环境的平面

(13)DroneCAN 适配器节点(一)

文章目录 前言 1 特点 2 固件  3 ArduPilot固件DroneCAN设置 4 DroneCAN适配器节点 前言 这些节点允许现有的 ArduPilot 支持的外围设备作为 DroneCAN 或 MSP 设备适应 CAN 总线。这也允许扩展自动驾驶仪硬件的功能。如允许 I2C 设备(如罗盘或空速)距离自动驾驶仪 1m 以上,并实现多达 32 个伺服输出通道。

算法13—Bit Map算法简介

1. Bit Map算法简介          来自于《编程珠玑》。所谓的Bit-map就是用一个bit位来标记某个元素对应的Value, 而Key即是该元素。由于采用了Bit为单位来存储数据,因此在存储空间方面,可以大大节省。 2、 Bit Map的基本思想         我们先来看一个具体的例子,假设我们要对0-7内的5个元素(4,7,2,5,3)排

多头注意力机制(Multi-Head Attention)

文章目录 多头注意力机制的作用多头注意力机制的工作原理为什么使用多头注意力机制?代码示例 多头注意力机制(Multi-Head Attention)是Transformer架构中的一个核心组件。它在机器翻译、自然语言处理(NLP)等领域取得了显著的成功。多头注意力机制的引入是为了增强模型的能力,使其能够从不同的角度关注输入序列的不同部分,从而捕捉更多层次的信息。 多头注意力机

Linux-笔记 线程同步机制

目录 前言 实现 信号量(Semaphore) 计数型信号量 二值信号量  信号量的原语操作 无名信号量的操作函数 例子 互斥锁(mutex) 互斥锁的操作函数 例子 自旋锁 (Spinlock) 自旋锁与互斥锁的区别 自旋锁的操作函数 例子 前言         线程同步是为了对共享资源的访问进行保护,确保数据的一致性,由于进程中会有多个线程的存在,

Spring 集成 RabbitMQ 与其概念,消息持久化,ACK机制

目录 RabbitMQ 概念exchange交换机机制 什么是交换机binding?Direct Exchange交换机Topic Exchange交换机Fanout Exchange交换机Header Exchange交换机RabbitMQ 的 Hello - Demo(springboot实现)RabbitMQ 的 Hello Demo(spring xml实现)RabbitMQ 在生产环境

Rust:Future、async 异步代码机制示例与分析

0. 异步、并发、并行、进程、协程概念梳理 Rust 的异步机制不是多线程或多进程,而是基于协程(或称为轻量级线程、微线程)的模型,这些协程可以在单个线程内并发执行。这种模型允许在单个线程中通过非阻塞的方式处理多个任务,从而实现高效的并发。 关于“并发”和“并行”的区别,这是两个经常被提及但含义不同的概念: 并发(Concurrency):指的是同时处理多个任务的能力,这些任务可能在同一时