查询队列(Query Queue)快速入门

本文涉及的产品
实时数仓Hologres,5000CU*H 100GB 3个月
简介: 本文由钟昌宏(大宏)分享,主题为Hologres 3.0新功能——Hologres查询队列(Query Queue)的使用场景、基本用法及入门实践。内容涵盖四个部分:查询队列的基本介绍、并发控制与排队能力、查询隔离与熔断,以及如何在管控台观察计算组或实例使用查询队列的情况。通过分类器管理、匹配规则等机制,实现对不同类型Query的灵活控制,并结合Serverless Computing提升系统稳定性与成功率。适用于数据写入与查询任务的优化场景。

作者:钟昌宏(大宏) Hologres 研发

摘要:本次分享的主题为介绍 Hologres 3.0 推出的新功能 Hologres 查询队列(Query Queue)的使用场景、基本用法以及入门的实践,分为以下四个部分,第一部分是查询队列的基本介绍,为什么需要查询队列以及查询队列的基本架构。第二部分和第三部分分别介绍查询队列的四个基本功能:并发控制,排队能力,查询隔离和查询熔断。在第四个部分中,教大家如何在管控台观察计算组或者实例使用查询队列的情况,以及如何看一个 Query 是否使用了查询队列。

一、查询队列的基本介绍

1.1为什么需要查询队列(Query Queue)

查询队列也叫 Query Queue,是为了解决资源使用中的运维难题,未知流量峰值和未知的大任务。在使用 Hologres 过程中,通常会遇到一个这样的问题:有突发的流量高峰导致系统过载影响了实例或者计算组的稳定性,查询性能也受到了影响。这时就需要一个流量控制的手段,在突发流量到来时控制整体并发度,使得系统不至于过载,保障目前已有的 Query 的稳定性。还有一种情况是一些预期之外的大任务,比如大表的导入可能有预期之外的大量数据;或者因为业务调整来了一条非常大的 Query;或者在扫描分区的时候,预期是扫描一天的分区,但是由于某些原因可能扫掉了七天或者一个月的分区,SQL 就变成个大任务。这些大任务会占用系统的大量资源,影响实例的稳定性,这时候需要大任务的熔断能力,一旦能检测到有这样的异常大任务,要及时杀掉,防止进一步影响实例稳定性。对于这样的大任务还希望有手段能够使得它隔离出去运行,在本次课程的第一课中有介绍到 Serverless Computing 技术,大任务的隔离是可以使用 Serverless Computing 做到。本次课程会介绍如何将查询队列 Query Queue 和 Serverless Computing 结合起来,更灵活地使用 Serverless Computing,可以将这一类大任务通过查询队列,自动走到 Serverless Computing 中运行。

1.2查询队列的基本架构

以下是一个弹性计算组实例,可以看到两个计算组。查询队列的概念在计算组下,当用户的查询到来时,查询会匹配上不同的规则进入到不同的队列中,比如这里 INSERT,UPDATE,DELETE 就进入到了 Query Queue 1 中,这时候我们对查询队列进行并发度的限制,就可以做到对不同类型的 Query 控制不同的并发度。除此之外,我们还可以将队列里面的 Query 放到 Serverless Computing 里面去运行,如图中计算组 1 的 Query Queue 1 所示。也可以对于达到了某些的边界条件大查询,认为它是大查询,可以杀掉并在 Serverless 里 Rerun 重新运行一次,如计算组 2 的 Default Query Queue 所示,通过 Rerun 这个机制和手段能够提升实例整体运行的成功率。

1.3查询队列的主要能力

查询队列主要提供了能力有四个,第一个是并发控制,可以通过配置灵活的分类器来匹配 Query,走到不同的 Query Queue 中,实现多样化的并发控制能力。第二个是排队能力,为每个 Query Queue 定制不同的排队数值来解决复杂的业务场景需求。第三个是查询熔断的能力,一般根据运行的时间为 Query Queue 定制不同的查询熔断能力,解决大查询将系统负载打满的问题。第四个是查询隔离,针对被熔断掉的 Query 使得它自动通过 Serverless 方式重新运行,一方面实现了大查询熔断,同时也实现了大查询隔离,提升了系统运行的整体成功率和稳定性。

1.4查询队列使用场景示例

下面举一个简单的使用场景的例子。比如一个实例进行了读写分离,写入任务使用 init_warehouse 计算组,查询任务使用使用 readonly_warehouse 计算组。写入任务是 Flink 实时写入,一般可能是用 Fixed plan,写入量比较稳定,每日有波峰波谷,这种情况可以不使用查询队列,利用分时弹性的能力来解决写入的流量峰谷问题。还有一种写入是MaxCompute 的批量写入,这种写入一般是定时调度,而且任务资源开销大,可以创建一个 insert_1 查询队列处理任务,对它实现自动流控。如果这些任务存在大表也存在小表,当一些预期之外的大量数据导入时,可以使用自动使用 Serverless 将大查询隔离出去运行。如果预期之内所有的都是大表,也可以直接指定队列级别的所有 Query 都使用 Serverless 资源执行。

对于查询任务也可以根据业务不同创建不同查询队列,比如业务查询A优先级相对更高,可以创建一个产生队列的 select_1 处理查询流量,进行自动流控。如果要求它的成功率是比较高的,当开启大查询隔离的时候,那么那些触发了熔断的 Query 就可自动的使用 Serverless 重跑,保证了整体运行的成功率。对于业务 B 的查询,相对来说优先级比较低,可以创建一个查询队列 2 处理流量,进行自动流控,并且开启大查询熔断,遇到一些大查询可能潜在的影响整个计算组的时候,就将它直接 Kill 掉。

二、并发控制与排队能力

2.1并发控制与排队能力——查询队列管理

下面介绍一下如何进行查询队列的管理。首先创建查询队列的时候,需要指定 max_concurrency 和 max_queue_size 两个参数。max_concurrency 是最大并发度,max_queue_size 是最大的队列长度,还可以设置 queue_timeout_ms 排队超时时间,默认值是 -1,一开始都不限制。

2.2并发控制与排队能力——分类器管理

有了查询队列之后,下一个问题是如何把 Query 分到对应的查询队列中,这时就必须提到下一个概念——分类器。如下图所示,分类器会按照优先级顺序进行匹配,归属到第一个符合匹配规则的分类器。在这张图中以颜色的深浅来描述分类器的优先级,颜色越深代表它的优先级越高,可以看到 Classifier 1 的颜色是最深,因此它的优先级最高。Query 会优先和它的规则匹配,可以看到当 Serving Query 到来的时候,优先和 Classifier 1 匹配,看看能够是否匹配上,如果匹配上就直接进入到 queue 1。Ad-hoc 查询到来时候,同样的规则也是先跟优先级最高的 Classifier 1 匹配,发现匹配不上是一个虚线,因此它会和优先级次之的 Classifier 2 进行匹配,匹配上了就进入到 queue 2。其他的 Query 如 ETL Job、Datalake Query 也是以类似规则进行匹配的。一个查询队列可以绑定多个分类器,比如查询 queue 2 绑定了 Classifier 2 和 Classifier 3 ,但是一个分类器只能属于一个查询队列。还有另外一个问题,如果一条 Query 没有匹配上任何的分类器怎么办呢?像图上的 Others 一样,最后会走到 default queue 中。分类器的创建和属性的设置和 Query Queue 类似。系统表 hologres.hg_classifiers 可以查询目前已经创建的所有分类器。

2.3并发控制与排队能力——分类器匹配规则

有了分类器之后,下一步问题就是如何在分类器上设置对应的匹配规则。 Hologres 目前支持的分类器匹配规则有:查询类型(INSERT, SELECT, UPDATE, DELETE)、当前账号、数据库名称、请求使用的引擎、SQL 指纹、存储模式和应用名称等。

2.4并发控制与排队能力——分类器匹配规则验证

配置好查询队列之后,可以通过 Explain 语句查看一条 Query 是否走到预期之内的查询队列中。在 Explain 语句展示的结果中,Query Queue 这一行显示的是所匹配到的查询队列信息。这里显示的就是在 init_warehouse 中进入到了 insert_queue 队列里,是被 insert_clf 分类器所捕获的。如果不使用查询队列或者 Query 不支持使用查询序列,例如 Fixed Plan,Plan 中不会展示 Query Queue 的对应信息。下面这张图是查询 hologres.hg_classifiers 这张系统表来查询已配置的分类器以及它所有的匹配规则。

2.4并发控制与排队能力——分类器匹配规则注意事项

一个值得注意的点是系统默认的查询列的 default_queue 会随着实例的创建或者计算组的创建自动创建出来,不支持匹配分类器和任何的匹配规则。如果 SQL 没有匹配上任何的分类器,它会进入到 default_queue,因此它是一个兜底的手段存在,所以它不支持配置分类器和规则。其次,查询之类只对 SELECT、INSERT、UPDATE 和 DELETE 这类 SQL 生效,对 Fixed Plan 不支持。如果SQL 是 Copy,Create Table As 或者是 Insert Overwrite 这类 SQL 引擎本身也会产生对应的 INSERT 语句,查询队列对于这些 INSERT 语句同样是生效的。

三、查询隔离与查询熔断

以下Demo将为大家展示查询队列的使用方法,包含创建,并发控制、熔断设置、查询日志等等,视频操作请查看:https://cloud.video.taobao.com/vod/-voecIwYjmczL8m0NLodhIZ4dutnlObu9ziUxKmT6yk.mp4

查询队列使用场景总结

以上就是查询的功能和用法的全部内容,下面对查询的使用场景进行总结。首先,对于数据写入任务需要确保成功率,实时写入可以不使用查询队列,对离线写入使用查询队列,其中大任务使用查询队列的大查询隔离功能,自动使用 Serverless Computing 资源运行。对于数据查询任务可以根据业务的优先级决定查询队列的使用方式,高优先级的任务使用查询队列时,大任务使用查询队列的大查询隔离功能,自动使用 Serverless Computing 资源重跑。低优先级的任务在使用查询队列时,大任务使用查询队列的大查询熔断功能,如果发现它潜在的可能对实例的稳定性造成影响,可以直接 Kill 掉。

以上就是本次分享的全部内容。Hologre 一体化实时湖仓平台,目前在阿里巴巴集团内部以及阿里云上客户各个领域和各个业务上都有很广泛的应用,用户如果感兴趣,可以扫描右上角的二维码,通过 Hologre 官网查看更多案例,也可以扫描右下角的二维码领取一些免费试用的 CU 时。最后,感谢谢大家的收听,谢谢!


13个专题6万字详解,Hologres一体化实时湖仓实践手册发布

Hologres 3.0 全新升级为一体化实时湖仓平台,通过统一数据平台实现湖仓存储一体、多模式计算一体、分析服务一体、Data+Al 一体,实现一份数据、一份计算、一份服务,极大提高数据开发及应用效率。立即下载>>https://developer.aliyun.com/ebook/8436电子书亮点:

ꔷ 结合Deepseek+PAI 构建RAG检索增强系统

ꔷ 结合Flink、Paimon、MaxCompute等构建一体化实时湖仓平台

Serverless系列功能快速入门,降价46%并保障资源隔离与稳定

ꔷ Dynamic Table、运维诊断优化、流量分析函数等3.0最新功能实践

image.png

相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
目录
打赏
0
0
0
0
480
分享
相关文章
为何我建议你学会Queue集合
面试官:你说说Queue集合都有什么常用类?JDK源码对Queue集合是这么解释的,大家看看。专为在处理之前保存元素而设计的集合。南哥是这么理解的,List集合用于存储常用元素、Map集合用于存储具有映射关系的元素、Set集合用于存储唯一性的元素。Queue集合呢?所有的数据结构都是为了解决业务问题而生,而Queue集合这种数据结构能够存储具有先后时间关系的元素,很适用于在业务高峰期,需要缓存当前任务的业务场景。像Kafka、RabbitMQ、RocketMQ都是队列任务这种思想。
为何我建议你学会Queue集合
MetaQ/RocketMQ 原理问题之Consume queue中的条目长度是固定的问题如何解决
MetaQ/RocketMQ 原理问题之Consume queue中的条目长度是固定的问题如何解决
RocketMQ-初体验RocketMQ(10)-过滤消息_SQL92表达式筛选消息
RocketMQ-初体验RocketMQ(10)-过滤消息_SQL92表达式筛选消息
183 0
消息队列 MQ产品使用合集之topic相同,但是tag不同,这个类不能放入map中,该如何处理
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
查询Kafka集群中消费组(group)信息和对应topic的消费情况
查询Kafka集群中消费组(group)信息和对应topic的消费情况
3502 0
stack_queue:三个关键注意事项解析
stack_queue:三个关键注意事项解析
SpringBoot-Kafka(生产者事务、手动提交offset、定时消费、消息转发、过滤消息内容、自定义分区器、提高吞吐量)
SpringBoot-Kafka(生产者事务、手动提交offset、定时消费、消息转发、过滤消息内容、自定义分区器、提高吞吐量)
SpringBoot-Kafka(生产者事务、手动提交offset、定时消费、消息转发、过滤消息内容、自定义分区器、提高吞吐量)
深入理解RabbitMQ中的prefetch_count参数
在某一次用户标签服务中大量用到异步流程,使用了RabbitMQ进行解耦。其中,为了提高消费者的处理效率针对了不同节点任务的消费者线程数和prefetch_count参数都做了调整和测试,得到一个相对合理的组合。这里深入分析一下prefetch_count参数在RabbitMQ中的作用。
773 5
深入理解RabbitMQ中的prefetch_count参数
RT-Thread快速入门-消息队列
RT-Thread快速入门-消息队列
205 0
为什么kafka 需要 subscribe 的 group.id?我们是否需要使用 commitSync 手动提交偏移量?
Kafka 使用消费者组的概念来实现主题的并行消费 - 每条消息都将在每个消费者组中传递一次,无论该组中实际有多少个消费者。所以 group 参数是强制性的,如果没有组,Kafka 将不知道如何对待订阅同一主题的其他消费者。
346 2