开源 OLAP 引擎综评：HAWQ、Presto、ClickHouse
source link: https://www.infoq.cn/article/N1KuVWtYYIdhVFlEpXEu
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
编者按
谈到大数据就会联想到 Hadoop、Spark 整个生态的技术栈。大家都知道开源大数据组件种类众多，其中开源 OLAP 引擎包含 Hive、SparkSQL、Presto、HAWQ、ClickHouse、Impala、Kylin 等。当前企业对大数据的研究与应用日趋理性，那么，如何根据业务特点，选择一个适合自身场景的查询引擎呢？
百分点在某国家级项目中承担了日增超 5000 亿级的数据处理与分析任务，集群的总数据量已接近百万亿。本报告结合百分点在项目中的业务场景，对 HAWQ、Presto、ClickHouse 做了综合评测，供大家参考。
一、测试整体方案
百分点面对的业务场景，主体是要解决超大规模数据集的 Ad-Hoc 查询问题，并且大多是单表查询场景。架构团队在此过程中选取了 HAWQ、Presto、ClickHouse 进行评测。评测中选取的数据集与 SQL 来自项目实际业务，我们需要评测维度主要如下：
A．数据在不同压缩格式下的压缩能力。
B．不同格式下的数据查询能力。
C．特定格式下的 HAWQ、Presto、ClickHouse 查询能力横向对比。
二、测试组件介绍
1.HAWQ
HAWQ 是 Hadoop 原生 SQL 查询引擎，结合了 MPP 数据库的关键技术优势和 Hadoop 的可扩展性、便捷性，以及 ANSI SQL 标准的支持；具有 MPP（大规模并行处理系统）的性能，比 Hadoop 生态圈里的其它 SQL 引擎快数倍；具有非常成熟的并行优化器等。
2.Presto
Presto 是一个分布式的查询引擎，本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。Presto 是一个 OLAP 的工具，擅长对海量数据进行复杂的分析。但是，对于 OLTP 场景，并不是 Presto 所擅长，所以不要把 Presto 当做数据库来使用。
Presto 需要从其他数据源获取数据来进行运算分析，它可以连接多种数据源，包括 Hive、RDBMS（Mysql、Oracle、Tidb 等）、Kafka、MongoDB、Redis 等。
3.ClickHouse
ClickHouse 是“战斗民族”俄罗斯搜索巨头 Yandex 公司开源的一个极具 " 战斗力 " 的实时数据分析数据库，是面向 OLAP 的分布式列式 DBMS，圈内人戏称为“喀秋莎数据库”。ClickHouse 有一个简称 "CK"，与 Hadoop、Spark 这些巨无霸组件相比，ClickHouse 很轻量级，其特点包括：分布式、列式存储、异步复制、线性扩展、支持数据压缩和最终数据一致性，其数据量级在 PB 级别。
三 、测试环境
1. 服务器硬件配置
大数据服务器：大数据网络增强型 d1ne
2.OLAP 引擎环境
- HAWQ 环境
- Presto 环境
- ClickHouse 环境
3. 测试数据
数据存放路径：/data1~12/iplog，一个盘 20G，6 台服务器每台都是 240G，一共 1440GB；每台服务器 12 个盘装载 4 个分区（小时）数据，每个盘装载 4 个分区的 1/12 的数据，4 个文件，每个文件大小 5G，2500w 条记录，一条记录 200Byte。
4. 测试 SQL
测试挑选 4 个实际典型 SQL，大致如下：
四、测试过程
1.HAWQ 存储格式与性能评测
经过对比测试后，考虑数据的压缩比、数据的插入速度，以及查询时间这三个维度综合评估，我们的场景推荐 HAWQ 采用列式存储 +Gzip5 的压缩方式；如果大家对压缩没有非常高的要求，可以按照测试的详细数据采用其它的组合方式。
HAWQ 压缩测试注意事项：只有当 orientation=parquet 的时候才能使用 gzip 进行压缩，orientation=row 的时候才能使用 zlib 进行压缩，snappy 不支持设置压缩级别。
详细的评测数据及图片展现如下文所示。
- 行式存储与压缩 ：
HAWQ 的插入方式是将数据写入 CSV 文件后，Load 到 HAWQ 表中。本次评测的是数据 Load 的过程和最终压缩比。可以发现，zlib 压缩级别到 5 以后，压缩比的降低就不那么明显了。
测试明细：
结果图形展示：
- 行式存储查询性能 ：
测试明细：
结果图形展示：
- 列式存储与压缩 ：
测试明细：
结果图形展示：
- 列式存储查询性能 ：
测试明细：
结果图形展示：
2.Presto 存储格式与性能评测
经过对比测试后，考虑数据的压缩比、数据的插入速度，以及查询时间这三个维度综合评估，我们的场景推荐 Presto 采用 LZ4+ORC 方式。这个结果也与各公司采用的格式一致。
- 存储与压缩 ：
测试方式，通过 CSV 文件 Load 到 Hive 表，原始数据总量为 1440GB。
- 查询性能 ：
3. 查询对比测试：HAWQ vs Presto vs ClickHouse
通过对比测试结果可以发现，在相同的数据量查询 SQL 情况下，ClickHouse 对比 HAWQ、Presto 有数量级的性能优势。由于我们的业务更多是单表的 Ad-Hoc 查询和分析，因此本次评测最终采用 ClickHouse 作为我们的 OLAP 引擎。
同时，测试过程中我们也发现一些有意思的现象，如：
(1) HAWQ 对查询都是全表扫描，如类似 Select * from where c1=xxx limit 10 查询，而 Presto 则对扫描的结果直接返回。
(2) HAWQ 查询会使用到系统缓存，而 Presto 对这方面并没有特别的优化。表现出的现象就是，在一定的并发度下，HAWQ 反而会体现出缓存的优势，而 Presto 性能则呈现线性下降趋势。
详细见测试过程的详细记录及图形化的直观展现。
- 并发 1 查询性能 ：
- 并发 10 查询性能 ：
- 并发 20 查询性能 ：
4. 其它扩展测试
- Presto 单机多 Worker ：
我们通过添加单机的 Worker 数量验证是否提高查询效率，提高单机的查询利用率。
单机增加 Presto Worker，部署多 Worker。测试结果：表现为 CPU 瓶颈，没有效果。如下图，可以发现每个 Worker 的吞吐也少了一半。
- Presto 扩容 ：
我们通过添加扩容机器并部署 Worker，验证查询性能影响。
加入新的机器，部署 Worker。测试结果：表现为性能基本线性增长，受限于数据节点的磁盘 IO 和网络。
- ClickHouse 横向扩展查询测试 ：
测试横向扩展对查询性能的影响，每个节点的数据量是相同的，使用相同的 SQL 分别测试单节点、五节点、十节点的查询性能。
根据测试结果可以看出，横向扩展后，节点数和数据量等比增加，查询时间几乎保持不变。所以对于 ClickHouse 我们可以基于单节点的数据量和性能，推断一定场景下整个集群的情况。
测试明细：
结果图形展示：
- ClickHouse PageCache 缓存查询测试:
测试 PageCache 对查询性能的影响，首先清除所有缓存分别查询四个 SQL，然后再重复执行一次，可以发现，PageCache 对第二次查询的性能提高是影响巨大的。
ClickHouse 充分利用了系统缓存（PageCache），对查询有数量级的性能提升作用。
测试明细：
结果图形展示：
五、各组件综合分析
通过上述测试结果和分析图表，结合我们查询各组件的开源介绍进行综合分析，如下：
HAWQ 采用基于成本的 SQL 查询优化器，生成执行计划；同时在标准化 SQL 兼容性这方面表现突出（基于 TPC-DS 进行 SQL 兼容性测试）。数据存储直接使用 HDFS，与其它 SQL on Hadoop 引擎不一样，HAWQ 采用自己的数据模型及存储方式。在本次对单表的查询测试中，性能并不理想，并且我们发现对于表查询类似 limit 1 语句。HAWQ 也会全表扫描，这个过程让我们感觉有点诧异。
Presto 的综合能力对比其他 SQLon Hadoop 引擎还是比较突出的。我们在测试过程中发现，单节点的扫描速度达 5000WRow/S。Presto 是完全基于内存的并行计算，对内存有一定的要求。只装载数据到内存一次，其他都是通过内存、网络 IO 来处理，所以在慢速网络下是不适合的，所以它对网络要求也是很高。Presto 只是查询引擎，不负责数据的底层持久化、装载策略。Presto 支持丰富的多数据源，可跨多个数据源查询。另外，在我们测试的版本上没有本地数据读取优化策略，开源社区里在新版本上是支持的。
ClickHouse 作为战斗民族的开源神器，是目前所有开源 MPP 计算框架中速度最快的。对比测试的结果表明，ClickHouse 在单表的查询中性能十分优异。对多表的关联分析场景，查询其他报告并不十分理想，本次测试并不涉及，不做评论。ClickHouse 性能很大程度上依赖于系统缓存。对完全非缓存，进行磁盘扫描的场景，性能也不是十分突出，二者也有数量级的性能差距。这也是我们在使用过程中的优化点。
最后，以上采用 MPP 架构的 OLAP 引擎，随着并发的提高，查询性能都出现了线性下降，Presto 在这个问题上的尤为明显。CK 由于单次查询速度快，所以一定程度上掩盖了这个问题。因此，大家在未来的业务中进行 OLAP 评估时，也需要将并发作为一个重要的考虑因素。
本文转载自公众号百分点（ID：baifendian_com）。
原文链接：
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK