Doris性能测试报告

本文最后更新于：11 分钟前

前言

Doris性能测试报告

一、Doris介绍

实时分析型数据库Apache Doris，几乎国内的一二线大厂都在使用它做数据分析

官方地址：https://doris.apache.org/

Apache Doris源于百度2008年启动的产品Palo在2018年捐献给Apache基金会，是一个基于 MPP 架构的高性能、实时的分析型数据库，他非常简单易用，而且性能还不错，仅需亚秒级响应时间即可获得查询结果，不仅支持高并发的查询场景，也可以支持高吞吐的复杂分析场景，比如你可以基于它做用户行为分析、日志检索平台、用户画像分析、订单分析等应用。
Doris的架构非常简洁，易于运维，并且可以支持10PB以上的超大数据集

1. Doris特性

这里特性很多，但是如果没接触过大数据的同学，可能不是特别了解，但是注意这个特性，支持SQL 语言，兼容MySQL，比如：通过Mybatis 写好 sql，就可以调用查询，而且他能支持亿级数据检索响应，以前还是想分库分表呢，现在有了它可以在考虑一下它了，看分库分表有必要吗，但是这里要注意下，它是一个 OLAP 引擎与 OLTP还是有点区别，如果业务场景，新增多后期更新少，同时查询场景多，那么可以在 mysql 中保存一段时间的热点数据，来进行相关业务操作，而报表查询都走Doris
这里可能有些人员不懂什么是 OLAP，下面是一个OLAP与OLTP对比图

2. Doris架构

Doirs只有两个主进程模块。一个是 Frontend（FE），另一个是Backend（BE）

2.1 Frontend（FE）

主要负责用户请求的接入、查询计划的解析、元数据的存储和集群管理相关工作， Doris采用Paxos协议以及Memory + Checkpoint + Journal的机制来确保元数据的高性能及高可靠。

Leader、follower和 observer它们三个构成一个可靠的服务，保证单节点宕机的情况下，元数据能够实时地在线恢复，而不影响整个服务，与zookeeper角色一样。

2.2 Backend（BE）

BE主要负责数据存储、查询计划的执行。

  • BE管理tablet副本, tablet是table经过分区分桶形成的子表, 采用列式存储。
  • BE受FE指导, 创建或删除子表。
  • BE接收FE分发的物理执行计划与其他BE共同协作完成执行。
  • BE读本地的列存储引擎, 获取数据, 通过索引和谓词下沉快速过滤数据。
  • BE后台执行compact任务, 减少查询时的读放大。
    以上FE和 BE支持动态弹性扩容，而且在扩容过程中对应用无影响，同时Doris 不依赖zk、hdfs等，所以架构很简单，这种架构设计极大的简化了运维成本，其实一个好的产品就应该这样，把复杂留给自己，把简单留给用户

二、OLAP对比

在我们解决大数据查询分析时，也调研了比较知名的一些产品，下面是一个对比

1. ClickHouse

提到 Doris 不得不提ClickHouse，CK是由俄罗斯IT公司Yandex为Yandex.Metrica网络分析服务开发的开发的实时数仓，以性能著称，但是经过测试，与 Doris在不同场景各有优劣， 但是它的架构复杂、运维成本高，同时对 sql 语法兼容性没有Doris好，因此没有选择，不过国内也有不少公司在使用

2. Doris

运维成本低、兼容Mysql 语法、架构足够简单、社区支持性好（非常活跃），同时经过百度内部长达10 多年的大规模使用，成熟度不容置疑，没有理由不选它

三、性能测试

Doris Version：doris-2.1.5-rc02

  • 3 FE + 3 BE + 3Broker集群部署
  • CPU：Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz 2 physical CPU package(s) 16 physical CPU core(s) 32 logical CPU(s)
  • 内存：128GB
  • 硬盘：2.8T机械硬盘
  • 网卡：千兆网卡

1. 单节点单表测试

单表话单数据准备如下

话单分区 数据量 物理数据量 存储数据量(单备份)
2024-09-02 32887605 7.5 GB 1.898 GB
2024-09-03 31884513 7.3 GB 1.833 GB
2024-09-04 30990812 7.1 GB 1.799 GB
2024-09-05 31736650 7.2 GB 1.843 GB
2024-09-06 33726540 7.7 GB 2.031 GB
2024-09-07 42865361 9.9 GB 2.745 GB
2024-09-08 41825321 9.6 GB 2.728 GB

单表执行语句如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
SELECT
	sum( a.sum_time / 3600 / 7 ) AS sum_view_time,
	count( loginaccount ) AS sum_view_cnt,
	sum( a.sum_time / 3600 / 7 )/ count( loginaccount ) AS rhj_view_time 
FROM
	(
	SELECT
		userid AS loginaccount,
		sum( CASE WHEN view_time > 18000 THEN 18000 ELSE view_time END ) AS sum_time 
	FROM
		(
		SELECT
			userid,
			servicetype,
			categoryid,
			contentid,
		CASE
				
				WHEN categoryid NOT IN ( '11BANN99999999211025000214149171', '11BANN99999999211103000214327725', 'catec120160122805183000000012432', 'catec120131030758725000000008278', 'catec120131030534835000000008277', 'catec120150805425627000000011883', 'catec120161229342425000000014611', '11BANN99999999210517000211324269', 'catec120160408420390000000013495', 'catec120181218783900000000019245', 'catec120200212756518000000020653', '11BANN99999999211025000214149171', '11BANN99999999211103000214327725' ) THEN
				unix_timestamp( endtime, '%Y%m%d%H%i%s' )- unix_timestamp( starttime, '%Y%m%d%H%i%s' ) ELSE 0 
			END AS view_time 
		FROM
			c3_user_contentview 
		WHERE
			datelabel BETWEEN '20240902' 
			AND '20240908' 
			AND endreason != '2' 
			AND categoryid NOT IN ( '11BANN99999999211025000214149171', '11BANN99999999211103000214327725', 'catec120160122805183000000012432', 'catec120131030758725000000008278', 'catec120131030534835000000008277', 'catec120150805425627000000011883', 'catec120161229342425000000014611', '11BANN99999999210517000211324269', 'catec120160408420390000000013495', 'catec120181218783900000000019245', 'catec120200212756518000000020653', '11BANN99999999211025000214149171', '11BANN99999999211103000214327725' ) 
		) main 
	GROUP BY
	userid 
	) a;
1C

2亿4千万的数据量下，doris执行耗时8.94秒

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
SELECT
sum( a.sum_time / 3600 / 7 ) AS sum_view_time,
count( loginaccount ) AS sum_view_cnt,
sum( a.sum_time / 3600 / 7 )/ count( loginaccount ) AS rhj_view_time 
FROM
(
SELECT
userid AS loginaccount,
sum( CASE WHEN view_time > 18000 THEN 18000 ELSE view_time END ) AS sum_time 
FROM
(
SELECT
userid,
servicetype,
categoryid,
contentid,
CASE
WHEN categoryid NOT IN ( '11BANN99999999211025000214149171', '11BANN99999999211103000214327725', 'catec120160122805183000000012432', 'catec120131030758725000000008278', 'catec120131030534835000000008277', 'catec120150805425627000000011883', 'catec120161229342425000000014611', '11BANN99999999210517000211324269', 'catec120160408420390000000013495', 'catec120181218783900000000019245', 'catec120200212756518000000020653', '11BANN99999999211025000214149171', '11BANN99999999211103000214327725' ) THEN
unix_timestamp( endtime, 'yyyyMMddHHmmss' )- unix_timestamp( starttime, 'yyyyMMddHHmmss' ) ELSE 0 
END AS view_time 
FROM
c3_user_contentview 
WHERE
datelabel BETWEEN '20240902' 
AND '20240908' 
AND endreason != '2' 
AND categoryid NOT IN ( '11BANN99999999211025000214149171', '11BANN99999999211103000214327725', 'catec120160122805183000000012432', 'catec120131030758725000000008278', 'catec120131030534835000000008277', 'catec120150805425627000000011883', 'catec120161229342425000000014611', '11BANN99999999210517000211324269', 'catec120160408420390000000013495', 'catec120181218783900000000019245', 'catec120200212756518000000020653', '11BANN99999999211025000214149171', '11BANN99999999211103000214327725' ) 
) main 
GROUP BY
userid 
) a;
1C

hive执行耗时75.778秒

2. 单节点多表关联测试

运维成本低、兼容Mysql 语法、架构足够简单、社区支持性好（非常活跃），同时经过百度内部长达10 多年的大规模使用，成熟度不容置疑，没有理由不选它

1. 测试3

1. 测试4

1. 测试5

1. 测试6

性能测试
#Doris
Doris性能测试报告
https://www.chaierss.online/posts/ed202b4f.html
作者
Chaierss
发布于
2024年9月30日
许可协议
Powered By Valine
v1.4.16