共计 3867 个字符，预计需要花费 10 分钟才能阅读完成。
引言：
随着数据量和数据复杂性的一直减少，越来越多的企业开始应用 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 引擎，具备不同的长处和实用场景。在理论利用中，须要依据具体业务需要进行抉择，并进行正当的配置和优化，以获得最佳的性能体现。同时，须要留神抉择具备代表性的查问场景和数据集，并针对不同的查问场景进行测试和剖析，以便更全面地评估引擎的性能。，以便更全面地评估引擎的性能。
欲了解更多可浏览墨天轮社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、流动直播、在线课程、文档阅览、资源下载、常识分享及在线运维为一体的对立平台，继续促成数据畛域的常识流传和技术创新。