Doris 如何实现高并发点查?(原理+实践全析)

文摘   2024-10-25 00:00   重庆  

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

全文目录:

  1. 背景说明

  2. 原理介绍

  3. 环境信息

  4. Jmeter初始化

  5. 参数预调

  6. 用例准备

  7. 高并发实测

  8. 影响因素

  9. 总结


一、背景说明

Apache Doris 官方介绍图

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

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

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

二、原理介绍

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

1. MPP架构

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

2. 列式存储

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

3. 数据分片

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

4. 向量化查询执行

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

5. 索引和物化视图

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

6. 统计信息和成本基准优化

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

...... 此处省略上万字

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

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

1. 行式存储格式(Row Store Format)

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

2. 行存缓存(Row Cache)

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

3. 点查询短路径优化(Short-Circuit)

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

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

4. 预处理语句优化(Prepared Statement)

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

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

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

三、环境信息

1. 硬件信息

  • 内存:32G

  • CPU:16C

  • CPU架构:X86_64

  • 硬盘:SSD单盘

  • 节点数:1

2. 软件信息

  • Doris版本:2.0.3

  • Manager版本:23.10.3

  • Jmeter版本:5.6

  • JDK版本:1.8

  • Mysql Driver版本:8.0

  • 系统:CentOS

四、Jmeter初始化

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

1. 安装部署

非GUI使用模式。

# 官方下载包 
wget https://dlcdn.apache.org/jmeter/binaries/apache-jmeter-5.6.tgz 

#
 解压包 tar -zvf apache-jmeter-5.6.tgz 
# 解压后目录结构和本地UI模式一

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

2. 参数说明

命令模版和参数说明,详情可阅:

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报告的目录(目录要为空,不然报错),会自动创建
五、参数预调

1. fe.conf

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

2. be.conf

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

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

3. 表属性

建表时调整即可。

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

4. 会话参数

-- 查看新优化器是否开启
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;

5. 用户参数

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

1. 测试表创建

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

CREATE TABLE `row_part` (
`p_partkey` int(11NULL,
`p_name` varchar(69NULL,
`p_mfgr` varchar(21NULL,
`p_category` varchar(24NULL,
`p_brand` varchar(30NULL,
`p_color` varchar(36NULL,
`p_type` varchar(78NULL,
`p_size` int(11NULL,
`p_container` varchar(33NULL
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" 
);

2. 测试表数据生成

测试表最终为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; -- 源表

3. 测试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标识,符合高并发点查条件。

4. prepare参数生成

获取prepare的csv参数数据。

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

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

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

上传至jmeter的home目录下。

5. 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

直接影响效率的参数:

  • useServerPrepStmts = true

  • cachePrepStmts = true

② 线程组

主要用于控制压测的循环测试、线程数和压测时间等;本文默认设置的是100线程数压60秒。

③ CSV数据文件设置

需要注意文件名、即对应 [prepare参数生成] 的csv文件存放路径, 以及csv列对应的字段名称和分隔符的填写。

④ SQL测试脚本

选择Prepare模式随机传参,其中[Parameter values]和[Parameter types]需要和SQL中的[?]缺省值完全对齐。

七、高并发实测

Jmeter执行脚本(简易模式)。

./bin/jmeter -n -t row_part.jmx

最终随机压测结果的平均QPS为6W+/S

压测过程中,BE的CPU大致使用50%(其中包括Jmeter进程的),内存使用率较低。

八、影响因素

1. 常规配置

  • 未按【参数预调】进行调整

  • 未按【JMX脚本准备】进行合理设置

  • 数据分区分桶太大(并行度过高)或太小(并发过小)都会影响效率

2. jdbc参数

去除 jdbc url 中的useServerPrepStmts=true; 参数时降为3W+/S。

仅去除 jdbc url 中的cachePrepStmts=true; 参数时降为2W/S。

3. 线程数

不宜过高,例如> 1W线程数时,降为2W+/S。

不宜过少,例如5个线程数时,降为1W+/S。

具体线程数设置需要根据【环境信息】进行对比调整。

4. fe个数

合理范围内,1个fe可提高一定的并发量。如果多加fe、QPS都没有增长,需要定位是否存在其它影响因素。

5. prepare参数分布

【prepare参数生成】过于集中、可能导致集中查某几台be影响效率,需要足够分散。

6. 资源瓶颈

如果上述原因都符合预期,且CPU还相对空闲的情况下,QPS依旧无法提升,需要排查网络或IO等资源是否遇到了瓶颈。

7. 其它

欢迎各位看官补充。

九、总结

Apache Doris 基于MPP架构、列存、分区分桶、向量化引擎、索引视图和基准优化等方面实现了高性能并发查询。在此基础上引入了行存、短查询路径和Prepared Statement特性实现了高并发点查询,效果俱佳。如果有相关场景的同学,欢迎实测交流。

至此,【Apache Doris】如何实现高并发点查 分享结束,查阅过程中若遇到问题欢迎留言交流。

往期推荐

大数据平台开发规范示例

【Apache Doris】Manager 极致丝滑地运维管理

【Apache Doris】如何一键实现MySQL万表整库同步?

Kafka TO Doris 保姆级入门详解

Apache Doris 资源隔离详解

ChatGPT快速入门

如何正确地使用ChatGPT(角色扮演+提示工程)

超强满血不收费的AI绘图教程来了(在线Stable Diffusion一键即用)



大数据技能圈
分享大数据前沿技术,实战代码,详细文档
 最新文章