引言:
随着数据量和数据复杂性的一直减少,越来越多的企业开始应用 OLAP(联机剖析解决)引擎来解决大规模数据并提供即时剖析后果。在抉择 OLAP 引擎时,性能是一个十分重要的因素。
因而,本文将应用 TPC-DS 基准测试的 99 个查问语句 来比照开源的 ClickHouse、Doris、Presto 以及 ByConity 这 4 个 OLAP 引擎的性能体现,以便为企业抉择适合的 OLAP 引擎提供参考。
TPC-DS 基准测试简介
TPC-DS(Transaction Processing Performance Council Decision Support Benchmark)是一个面向决策支持系统(Decision Support System,简称 DSS)的基准测试,该工具是由 TPC 组织开发,它模仿了多维分析和决策反对场景,并提供了 99 个查问语句,用于评估数据库系统在简单的多维分析场景下的性能。每个查问都设计用于模仿简单的决策反对场景,包含跨多个表的连贯、聚合和分组、子查问等高级 SQL 技术。
OLAP 引擎介绍
ClickHouse、Doris、Presto 和 ByConity 都是以后比拟风行的开源 OLAP 引擎,它们都具备高性能和可扩展性的特点。
- ClickHouse是由俄罗斯搜索引擎公司 Yandex 开发的一个列式数据库管理系统,它专一于大规模数据的疾速查问和剖析。
- Doris是一个分布式列式存储和剖析零碎,它反对实时查问和剖析,并能够与 Hadoop、Spark 和 Flink 等大数据技术进行集成。
- Presto是一个分布式 SQL 查问引擎,它由 Facebook 开发,能够在大规模数据集上进行疾速查问和剖析。
- ByConity是由字节开源的云原生数仓,采纳了存储计算拆散的架构,实现租户资源隔离、弹性扩缩容,并具备数据读写的强一致性等个性,它反对支流的 OLAP 引擎优化技术,读写性能十分优异。
本文将 应用这四个 OLAP 引擎对 TPC-DS 基准测试的 99 个查问语句进行性能测试,并比照它们在不同类型的查问中的性能差别。
测试环境和办法:
服务器配置:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 48
On-line CPU(s) list: 0-47
Thread(s) per core: 2
Core(s) per socket: 12
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 79
Model name: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
Stepping: 1
CPU MHz: 2494.435
CPU max MHz: 2900.0000
CPU min MHz: 1200.0000
BogoMIPS: 4389.83
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 30720K
NUMA node0 CPU(s): 0-11,24-35
NUMA node1 CPU(s): 12-23,36-47
测试方法:
- 应用 TPC-DS 基准测试的 99 个查问语句,和 1TB(28 亿行)的数据测试 4 个 OLAP 引擎的性能。
- 在每个引擎中应用雷同的测试数据集,并放弃雷同的配置和硬件环境。
- 对于每个查问,屡次执行并取平均值,以缩小测量误差,设置每次查问超时工夫为 500 秒。
- 记录查问执行的细节,例如查问执行打算、I/ O 和 CPU 应用状况等。
性能测试后果
咱们应用了雷同的数据集和硬件环境来测试这四个 OLAP 引擎的性能。
测试数据集大小为 1TB,硬件和软件环境如上介绍,咱们应用了 TPC-DS 基准测试中的 99 个查问语句别离在四个 OLAP 引擎上进行了间断三次的测试,并取三次均匀后果。
- 其中 ByConity 跑通了所有 99 个查问测试。
- Doris 在 SQL15 呈现 Crash,另外有 4 次的 Timeout,别离是 SQL54、SQL67、SQL78 和 SQL95。
- Presto 只在 SQL67 和 SQL72 产生 Timeout,其余查问测试都跑通了。
- Clickhouse 只跑通了 50% 的查问语句,大略有一部分是 Timeout,另一部分是零碎报错,剖析起因是 Clickhouse 不能无效的反对多表关联查问导致,只能把这类 SQL 语句做手动改写拆分能力执行。
因而在比照总耗时咱们临时排除 Clickhouse,其余三个 OLAP 引擎 TPC-DS 测试总耗时如下图 1 所示,从图 1 中咱们能够看出开源的 ByConity 查问性能显著优于其余引擎,性能约是其余的 3 - 4 倍。(注:以下所有图表纵坐标单位为秒)
图 1 TPC-DS 99 条查问总耗时
针对 TPC-DS 基准测试的 99 个查问语句,咱们接下来依照查问场景的不同进行分类,例如根底查问、连贯查问、聚合查问、子查问、窗口函数查问等。
上面咱们将应用这些分类形式来对 ClickHouse、Doris、Presto 和 ByConity 四个 OLAP 引擎进行性能剖析比照:
根底查问场景下
该场景蕴含简略的查问操作,例如从单个表中查问数据,过滤和排序后果等。根底查问的性能测试次要关注解决单个查问的能力。
其中 ByConity 的体现最佳,Presto 和 Doris 的性能也体现都不错, 这是因为根底查问通常只波及到大量的数据表和字段,因而可能充分利用 Presto 和 Doris 的分布式查问个性和内存计算能力,Clickhouse 对多表关联反对不好,呈现一些跑不通的景象,其中 SQL5、8、11、13、14、17、18 均超时,咱们按 Timeout=500 秒计算,但心愿显示更清晰截取 Timeout=350 秒。
下图 2 是根底查问场景下四个引擎的均匀查问工夫:
图 2 TPC-DS 根底查问的性能比照
连贯查问场景
连贯查问是常见的多表查问场景,它通常应用 JOIN 语句连贯多个表,并依据指定条件进行数据检索。
如图 3 咱们看到 ByConity 的性能最佳,次要得益于对查问优化器的优化,引入了基于代价的优化能力(CBO),在多表 Join 时候进行 re-order 的等优化操作。其次是 Presto 和 Doris,Clickhouse 在多表 Join 的成果相比其余三个性能不是很好,且对很多简单语句的反对不够好。
图 3 TPC-DS 连贯查问的性能比照
聚合查问场景
聚合查问是对数据进行统计计算的场景,例如测试 SUM、AVG、COUNT 等聚合函数的应用。
ByConity 仍然体现优异,其次是 Doris 和 Presto,Clickhouse 呈现了四次 Timeout,为了不便看出差别,咱们截取 Timeout 值到 250 秒。
图 4 TPC-DS 聚合查问的性能比照
子查问场景
子查问是在 SQL 语句中嵌套应用的查问场景,它通常作为主查问的条件或限度条件。
如下图 5 所示,ByConity 体现最佳,起因是 ByConity 实现了基于规定的优化能力(RBO)进行查问优化,通过算子下推、列裁剪和分区裁剪等技术,把简单的嵌套查问进行整体优化,替除所有的子查问,把常见算子转化成 Join+Agg 的模式。
其次是 Doris 和 Presto 体现绝对较好,但 Presto 在 SQL68 和 SQL73 呈现 Timeout,Doris 也在 3 个 SQL 查问呈现 Timeout,Clickhouse 同样呈现了局部超时和零碎报错,起因下面有提到。同样为不便看出差别,咱们截取 Timeout 值等于 250 秒。
图 5 TPC-DS 子查问的性能比照
窗口函数查问场景
窗口函数查问是一种高级的 SQL 查问场景,它能够在查问后果中进行排名、分组、排序等操作。
如下图 6 所示,ByConity 的性能最优,其次是 Presto,Doris 呈现了一次 Timeout 的状况,Clickhouse 仍然有局部没有跑通 TPC-DS 测试。
图 6 TPC-DS 窗口函数查问的性能比照
总结
本文对 ClickHouse、Doris、Presto 和 ByConity 四个 OLAP 引擎在 TPC-DS 基准测试的 99 个查问语句下的性能进行了剖析和比拟。咱们发现,在不同的查问场景下,四个引擎的性能体现存在差别。
- ByConity 在所有 TPC-DS 的 99 个查问场景下都体现优异,超过其余三个 OLAP 引擎;
- Presto 和 Doris 在连贯查问、聚合查问和窗口函数查问场景 下体现较好;
- 因为 Clickhouse 的设计和实现 并不是专门针对关联查问进行优化,因而在多表关联查问方面整体体现差强人意。
须要留神的是,性能测试后果取决于多个因素,包含数据结构、查问类型、数据模型等。在理论利用中,须要综合思考各种因素,以抉择最适宜本人的 OLAP 引擎。
在抉择 OLAP 引擎时,还须要思考其余因素,如可扩展性、易用性、稳定性等。在理论利用中,须要依据具体业务需要进行抉择,并对引擎进行正当的配置和优化,以获得最佳的性能体现。
总之,ClickHouse、Doris、Presto、ByConity 都是十分优良的 OLAP 引擎,具备不同的长处和实用场景。在理论利用中,须要依据具体业务需要进行抉择,并进行正当的配置和优化,以获得最佳的性能体现。同时,须要留神抉择具备代表性的查问场景和数据集,并针对不同的查问场景进行测试和剖析,以便更全面地评估引擎的性能。,以便更全面地评估引擎的性能。
欲了解更多可浏览墨天轮社区,围绕数据人的学习成长提供一站式的全面服务,打造集新闻资讯、在线问答、流动直播、在线课程、文档阅览、资源下载、常识分享及在线运维为一体的对立平台,继续促成数据畛域的常识流传和技术创新。