当前位置：首页 > news >正文

【Apache Doris】如何实现高并发点查？（原理+实践全析）

news 文章来源：https://blog.csdn.net/ith321/article/details/139881500 2025/1/12 18:48:35

【Apache Doris】如何实现高并发点查？（原理+实践全析）

一、背景说明
二、原理介绍
三、环境信息
四、Jmeter初始化
五、参数预调
六、用例准备
七、高并发实测
八、影响因素
九、总结

本文主要分享 Apache Doris 是如何实现高并发点查的，以及如何实测单节点上万QPS。

一、背景说明

Apache Doris 是一款基于 MPP 架构的高性能、实时的分析型数据库。它可以在多个节点上并行处理查询，显著提高查询效率，且默认以列存格式引擎构建。这种格式非常适合进行数据分析，因为它可以有效地压缩数据，并且在执行查询时只需要读取相关的列。但有些高并发服务场景中，用户需要频繁获取整行数据，如果表较宽时，列存的IO也随之被放大。

Apache Doris 中 FE 是 SQL 查询的访问层服务，使用 Java 编写，分析和解析 SQL 也会导致高并发查询的高 CPU 开销，且其查询引擎和计划对于某些简单的查询（例如点查询）而言太重了。

那么，Apache Doris 是如何实现高并发查询以及如何实现高并发点查的呢？

二、原理介绍

Apache Doris 能够实现高并发查询的能力主要是通过以下几个方面：

MPP架构

基于大规模并行处理（Massively Parallel Processing, MPP）架构设计，它可以将查询分解为多个任务，在多个节点上并行执行这些任务，使得系统可以通过增加更多的计算资源来线性扩展其查询处理能力。

列式存储

使用列式存储格式，这意味着对于任何给定的查询，它只需要读取涉及到的列，而不是整行数据。这减少了磁盘I/O压力，因为只有必需的数据被加载到内存中。

数据分片

分区和分桶裁剪在 Apache Doris 中也是实现高并发查询的重要机制。这两种技术可以帮助更有效地组织数据，提高查询效率，尤其是在面对大规模数据集时。

向量化查询执行

Apache Doris 实现了向量化查询处理，这意味着在执行操作时，它可以一次处理数据列的一整块，而不是逐行处理。这样可以大大提高CPU的利用率，降低每个数据点的处理开销。

索引和物化视图

Apache Doris 支持创建索引和物化视图来加速查询，减少扫描行数和避免了大量的现场计算，例如倒排、ZoneMap、Bloom Filter和Bitmap 等索引和预计算物化。

统计信息和成本基准优化

Apache Doris 会收集表和列的统计信息，并使用这些信息来优化查询计划，选择最佳的执行路径。

… 此处省略上万字

基于【背景说明】和上述内容，Apache Doris 可实现单节点上千 QPS 的并发支持。但在一些超高并发要求（例如上万 QPS）的 Data Serving 场景中，仍然存在瓶颈。

因此，Apache Doris 引入了如下几个2.0新特性从降低 SQL 内存 IO 开销、提升点查执行效率以及降低 SQL 解析开销这三个设计点出发，进行一系列优化：

行式存储格式（Row Store Format）

Apache Doris 支持用户在建表时，通过 store_row_column 表属性另存一份行数据（列存+行存）。在单次检索整行数据时效率更高，减少磁盘访问次数。

行存缓存（Row Cache）

Apache Doris 有针对列数据的Page Cache。但如果一行包括多列数据，这类缓存可能会被大查询给刷掉，为了增加缓存命中率、提升点查询的性能，Apache Doris 引入了行存缓存（Row Cache）。

点查询短路径优化（Short-Circuit）

通常而言，一个查询会在 FE 端进行SQL语句解析、生成执行计划后下发到 BE 进行计算获取结果。但对于高并发点查场景，则不适合这个长流程。

因此，Apache Doris 实现了点查询的短路径优化。当FE接收到此类查询时，会在规划器中生成轻量级的 Short-Circuit Plan，避免生成复杂的 Fragment Plan 并消除了在 MPP 查询框架下执行调度的性能开销。

预处理语句优化（Prepared Statement）

高并发查询中的 CPU 开销可以部分归因于 FE 层分析和解析 SQL 的 CPU 计算，为了解决这个问题，Apache Doris 在 FE 端提供了与 MySQL 协议完全兼容的预处理语句（Prepared Statement）。

通过在 Session 内存 HashMap 中缓存预先计算好的 SQL 和表达式，在后续查询时直接复用缓存对象，避免这些结构在序列化和反序列化时造成CPU热点。

基于以上一系列优化，帮助 Apache Doris 在 Data Serving 场景的性能得到进一步提升。下面就来实测一把吧。

三、环境信息

硬件信息

内存：32G
CPU：16C
CPU架构：X86_64
硬盘：SSD单盘
节点数：1

软件信息

Doris版本：2.0.3
Manager版本：23.10.3
Jmeter版本：5.6
JDK版本：1.8
Mysql Driver版本：8.0
系统：CentOS

四、Jmeter初始化

本文基于Jmeter进行高并发实测。

安装部署

非GUI使用模式。

# 官方下载包 
wget https://dlcdn.apache.org/jmeter/binaries/apache-jmeter-5.6.tgz # 解压包 tar -zvf apache-jmeter-5.6.tgz 
# 解压后目录结构和本地UI模式一

上传mysql-connector包到lib目录下。

参数说明

命令模版和参数说明，详情可阅：

https://jmeter.apache.org/usermanual/get-started.html#non_gui

jmeter -n -t <脚本文件名>.jmx -l <本不存在的结果文件名>.jtl -e -o <存放html报告的空目录> -h 帮助 
-n 非GUI模式 
-t 测试脚本.jmx的路径和文件名称 
-l 测试结果存放的路径和文件名称 (要确保之前没有运行过，即xxx.jtl不存在，不然报错)，会自动创建 
-r 启动jmeter.properties文件中指定的所有远程服务器 
-e 在脚本运行结束后生成html报告 
-o 用于存放html报告的目录（目录要为空，不然报错），会自动创建

五、参数预调

fe.conf

-- 每个 FE 的最大连接数，默认值：1024
qe_max_connection=10240

be.conf

为了增加行缓存命中率，Doris单独引入了行存缓存；行缓存复用了 Doris 中的 LRU Cache 机制来保障内存的使用。

-- 是否开启行缓存， 默认不开启
disable_storage_row_cache=false 
-- 指定 Row cache 占用内存的百分比， 默认 20% 内存
row_cache_mem_limit=40%

表属性

建表时调整即可。

-- 必须为Unique Key表 
-- 开启行存
"store_row_column" = "true" 
-- 开启mow模式
"enable_unique_key_merge_on_write" = "true" 
-- 开启light 
schema change: "light_schema_change" = "true"

会话参数

-- 查看新优化器是否开启
show variables like '%enable_nereids_planner%'; -- 非必选，jdbc链接配置 useServerPrepStmts=true时，会自动走短路径优化、即不走旧优化器 
-- 如：jdbc:mysql://127.0.0.1:9030/ycsb?useServerPrepStmts=true 
set global experimental_enable_nereids_planner=false;

用户参数

-- 查看用户连接数
SHOW PROPERTY FOR 'root' LIKE '%max_user_connections%';
-- 设置连接数
SET PROPERTY FOR 'root' 'max_user_connections' = '10000';

六、用例准备

测试表创建

基于Star Schema Benchmark的part零件信息表调整创建，共9个字段、2个联合Key。

CREATE TABLE `row_part` (
`p_partkey` int(11) NULL,
`p_name` varchar(69) NULL,
`p_mfgr` varchar(21) NULL,
`p_category` varchar(24) NULL,
`p_brand` varchar(30) NULL,
`p_color` varchar(36) NULL,
`p_type` varchar(78) NULL,
`p_size` int(11) NULL,
`p_container` varchar(33) NULL
) ENGINE=OLAP
Unique KEY(`p_partkey`, `p_name`)
COMMENT 'OLAP'
DISTRIBUTED BY HASH(`p_partkey`, `p_name`) BUCKETS 10
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"light_schema_change" = "true",
"store_row_column" = "true" ,
"enable_unique_key_merge_on_write" = "true" 
);

测试表数据生成

测试表最终为3200万数据。

-- 源表为明细模型，目标表为开启了行存、mow和light_schema_change的unique模式表
-- 通过对字段+数字等方式去重快速造数
insert into row_part -- 目标测试表
select 
`p_partkey`+1, 
concat(`p_name`, '1'), 
`p_mfgr` ,
`p_category`,
`p_brand`,
`p_color`,
`p_type`L,
`p_size`,
`p_container`
from part; -- 源表

测试SQL

测试SQL如下。

select * from ssb_test.row_part
where p_partkey = ? and p_name = ?

确认是否符合高并发点查条件，即该SQL是否走短路径（当前版本需要where带上所有key才可触发）。

-- 本地client查验需要先关闭新优化器
set experimental_enable_nereids_planner=false;--  ScanNode中是否有SHORT-CIRCUIT标识
explain 
select * from ssb_test.row_part
where p_partkey = 5 and p_name = 'blush chiffon';

如下图所示，ScanNode中有SHORT-CIRCUIT标识，符合高并发点查条件。

prepare参数生成

获取prepare的csv参数数据。

-- 
select 
p_partkey,
p_name 
from ssb_test.row_part
limit 3000;

导出查询结果集（通过dbeaver自身的功能导出csv数据作为prepare参数）。

导出后会在相应目录生成对应文件（需要手动去除第一行的字段名）。

上传至jmeter的home目录下。

JMX脚本准备

可以在本地jmeter客户端配置后保存生成.jmx再上传至jmeter的home目录下。

① JDBC连接管理器

jdbc:mysql:loadbalance://fe_ip:9030/db?characterEncoding=utf8&amp;useSSL=false&amp;useServerPrepStmts=true;cachePrepStmts=true&amp;prepStmtCacheSqlLimit=1024

直接影响效率的参数：