ByConity 与主流开源 OLAP 引擎（Clickhouse、Doris、Presto）性能对比分析
引言：
随着数据量和数据复杂性的不断增加，越来越多的企业开始使用 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 个查询语句进行性能测试，并对比它们在不同类型的查询中的性能差异。
测试环境和方法：
服务器配置：
测试方法：
使用 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 引擎，具有不同的优点和适用场景。在实际应用中，需要根据具体业务需求进行选择，并进行合理的配置和优化，以获得最佳的性能表现。同时，需要注意选择具有代表性的查询场景和数据集，并针对不同的查询场景进行测试和分析，以便更全面地评估引擎的性能。，以便更全面地评估引擎的性能。
欲了解更多可浏览墨天轮社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、活动直播、在线课程、文档阅览、资源下载、知识分享及在线运维为一体的统一平台，持续促进数据领域的知识传播和技术创新。
版权声明: 本文为 InfoQ 作者【墨天轮】的原创文章。
原文链接:【http://xie.infoq.cn/article/153cde31054263fdf69e2b9e9】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
数据库技术爱好者 2019-11-22 加入
墨天轮社区围绕数据人的学习成长提供一站式的全面服务。我们的愿景是共同建设一个有温度的技术社区和全新的数据社群聚合体，以乐知乐享之志，成同心共济之果。
评论