金山云团队分享 | 5000 字读懂 Presto 如何与 Alluxio 搭配

导语

• 金山云-企业云团队（赵侃、李金辉）在交互查询场景下对 Presto 与 Alluxio 相结合进行了一系列测试，并总结了一些 Presto 搭配 Alluxio 使用的建议。

• 本次测试未使用对象存储，计算引擎与存储间的网络延时也比较低。如果存储 IO 耗时和网络耗时较大时，Alluxio 加速收益应会更明显。

测试目的

• 验证影响 Alluxio 加速收益的各种因素

• 记录 Alluxio 在适宜条件下的加速表现

• 总结 Alluxio 的使用建议

测试环境

集群部署架构图

• 计算引擎使用 Presto，数据源为 Hive，Alluxio 作为缓存。

• 共搭建 2 个集群：Presto+Alluxio 集群，Hadoop 集群。

Presto+Alluxio 集群配置

• 机器：4 台 linux 虚拟机

• cpu/内存：32 核 64G

• 磁盘：60GB SSD + 200GB SSD

• 网络：万兆带宽

• 关键配置：

Hadoop 集群配置

• 机器：5 台 linux 虚拟机

• cpu/内存：16 核 32G

• 磁盘：60GB HDD + 1200GB HDD

• 网络：万兆带宽

测试用数据集列表

• 测试使用的数据是 tpc-ds 标准数据集。

• 因测试需要，我们导入了多份不同大小的数据集。每份数据集里的表结构是完全相同的，区别是表中的数据量不同，部分表之间的分区也不相同。

Alluxio 强悍的加速表现

首先我们来看看，当提供了相对适宜的条件，Alluxio 的具体加速表现。

• 以下查询的数据集是 tpc-ds 数据集 tpcds_bin_partitioned_orc_100，整个数据集的大小为 23.4G。

• 以下执行的 SQL 是在 tpc-ds 提供的 sql 中选取 7 条满足条件的，实验中对 7 条 SQL 各反复查询 10 次，记录每次查询的耗时。

• 每次查询之间间隔 8~10 秒，给 Alluxio 的异步缓存一定时间，尽量提高下一次查询的命中率。

实验结果展示

• 重点说明

￮ 耗时的单位为 ms。￮ “avg”列的值是第 2 次查询至第 10 次查询耗时的平均数。￮“first”列的值就是第 1 次查询的耗时。“加速收益”列的计算方式是：(first - avg) / first。

实验结果分析

• 第一次查询时，由于数据还没有被缓存，耗时是最高的，往后数据逐渐被异步缓存入 Alluxio，查询耗时逐渐递减，等全量数据进入 Alluxio 缓存，此时加速收益达到最高，查询耗时最低且停止递减。

• 我们可以看到相较于耗时最大的 first，avg 的值有大幅度的降低，耗时仅有原来的 20%~30%。从“加速收益”列来看可以更量化的评估加速收益。

• 下面我们验证一下关于影响 Alluxio 加速收益的具体因素。在下面的实验中，可以看到 Alluxio 在更适宜的环境下，甚至可以把查询耗时减少到原来的 5%。

影响加速收益的重要因素

• 根据测试的结果，结合官方文档描述，总结出几点因素会对 Alluxio 加速收益产生影响。下面我们就来看看这些因素

• 重点说明：这里说的 Alluxio 加速收益，指的是查询的耗时在加速后比加速前快了多少，并不单单是指 IO 那部分的耗时快了多少。更具象化的描述，它指的是单个查询在加速后的耗时比加速前降低了百分之多少。

因素一：查询的 Hive 表的底层数据文件的大小和加速收益正相关

1. 结论：查询的数据文件在小于约 2MB 时，文件越小，Alluxio 加速收益越低。

因文件过小，所以每个文件是一个 split。Presto 解析每个 split 创建 driver，调度 driver 执行，这段耗时是不能被加速的，而 operator 扫描的数据太小，那么磁盘 IO 的耗时在整个耗时中占比就会较低，Alluxio 对查询的加速收益就会降低。

在本次测试所使用的环境中，每个数据文件小于约 50KB 时，在查询的整体耗时上，加速收益会比较低。

数据文件大于约 2MB 时，文件大小对加速收益的影响相对不那么明显。

这个 2MB 和 50KB 只是在本环境中观察到的一个大概阈值，在不同环境中可能会有不同的表现。

2. 验证：用一条简单的 SQL 进行测试

【a. 实验用例说明】

测试方法采用相同的 SQL 去查询 5 个 tpcds 数据集中的同名表，保证 SQL 复杂度相同、表结构相同，分区表的分区数相同，仅仅是数据文件大小不同。

这里用一条简单的 SQL 语句反复多次查询，记录每次查询的耗时。

select * from web_sales where ws_wholesale_cost=1。where 条件字段 ws_wholesale_cost 并不是分区字段，所以会触发全表扫描。

在 presto 看到仅被划分出 2 个 stage

本次实验查询的 web_sales 表在 5 个数据集中的相关元数据

￮ 对于分区表，由于数据文件较小，每个文件就是一个 split。￮ 为了有更清晰的对比，也引入了非分区表的查询，非分区表的数据文件数较少，每个数据文件大小均在 100MB 以上，Presto 会按照 HDFS 文件块大小来划分 split，每个 split 中的数据大概是 28~38MB 左右。

【b. 实验结果展示】

【c. 实验结果分析】

￮ 当每个 split 的数据小于 2MB 时，加速收益会明显低一些。数据越小，加速收益越低，split 的数据达到几十 KB 时，加速就很微弱了。￮ 我们看到当每个 split 的数据达到 2MB 时，加速收益和 30MB 的区别不大，说明数据大于 2MB 后，数据大小对加速的影响就不大了。￮ 下面我们换一条 SQL、换一张表再验证一次，可以看到结论是一样的。

3. 验证：用 tpcds 中的 Query55 进行测试

【a. 实验用例说明】

query55 中包含聚合、排序、大小表 join，复杂度一般，presto 会为其划分 7 个 stage

query55 查询的事实表为 store_sales。

store_sales 表的相关元数据

【b.实验结果展示】

【c. 实验结果分析】

￮ 结论跟上一次实验一致，当 split 的数据只有百来 K 的时候，加速收益比较微弱，仅 20%。￮ split 的数据大于 2M 以上，数据大小对加速收益的影响较小。

因素二：执行的 SQL 语句的复杂度和加速收益负相关

1. 结论：SQL 语句越复杂，Alluxio 的加速收益越低

SQL 语句越复杂，计算的耗时就会越长，在整体耗时中，IO 耗时的占比就会下降，而 Alluxio 只能加速 IO 的耗时，所以在整体耗时的加速上，收益会降低。

在评估 SQL 复杂度时，我们可以参考 Presto 在执行 SQL 时划分的 Stage 的数量，来量化 SQL 的复杂度，Stage 越多则说明 SQL 相对复杂些。当然也可以肉眼大致判断下复杂度：

a. 简单：分组聚合、排序 b. 复杂：大小表 join、select 语句嵌套 c. 特别复杂：大表 join 大表、更多的表参与 join、多个 select 语句嵌套

2. 验证：针对 store_sales 事实表进行测试

【a. 实验用例说明】

测试方法：采用选取 tpc-ds 中查询同一张事实表的不同 query，去查询同一个数据集。保证表结构相同、文件数相同、文件大小相同、分区数相同，仅仅 SQL 不同。

query 中除了事实表还会查询维度表，不同 query 涉及的维度表可能不同，但是维度表的数据量极小(比事实表小 1000 倍至 1w 倍)，且都不是分区表，所以在这里我们可以忽略维度表不同所带来的影响。

测试时对同一条 sql 反复执行，记录每次执行的耗时。每次查询之间间隔 8~10 秒。

以下测试数据集选择 tpcds_bin_partitioned_orc_100，事实表选择 store_sales。

store_sales 表的相关元数据：

测试 SQL 采用如下 6 条

【b. 实验结果展示】

【c. 实验结果分析】

￮ 我们看到最简单的 SQL，加速收益非常高。￮ 面对一般复杂的 SQL，Alluxio 也依然很好的加速收益。￮ 整体来看，Stage 数量小于 15 时，Alluxio 都有不错的表现。

3. 验证：当查询的数据文件较小且 SQL 语句很复杂

【a. 实验用例说明】

我们这里再补充做一个实验，当查询的数据文件较小，而 SQL 语句又复杂的话，加速收益如何呢。

本实验 SQL 语句使用 query88，分别查询 2 套数据集。

表的相关元数据

【b. 实验结果展示】

【c. 实验结果分析】

我们看到，在这种很不适宜 Alluxio 的条件下，加速收益会比较低。

因素三：查询 SQL 语句返回的数据量的大小和加速收益负相关

1. 结论：查询返回的数据量越大，Alluxio 的加速收益越低

Presto 最后会使用一个 Driver 来 reduce 所有 Driver 的计算结果，数据量越大，reduce 的耗时越长，这里主要包括计算的耗时和网络 IO 耗时。如果是扫表时过滤的数据就很少，那么参与计算的数据量就会增加，增加了计算耗时，那么就降低了 IO 耗时在整个查询耗时中的占比

2. 验证：

【a. 实验用例说明】

我们使用 2 条简单的 SQL 查询同一张表，用 where 条件和 limit 控制一下返回的数据量

使用 tpcds_bin_partitioned_orc_100 中的 web_sales 表。

表的相关元数据

￮ SQL1：select * from web_sales where ws_wholesale_cost=1- 返回的数据条数为 7.35K，数据大小为 2.12MB。￮ SQL2：select * from web_sales limit 2000000- 返回的数据条数为 2M，数据大小为 558.87MB。

【b. 实验结果展示】

【c. 实验结果分析】

￮ 在返回少量数据时，查询的整体耗时很短，加速收益非常好￮ 返回大量数据时，查询的整体耗时大幅增加，加速收益不太好

因素四：影响加速收益的硬件环境因素

Alluxio 的加速收益还受以下硬件因素影响：

• Alluxio 缓存读写速度• UFS 磁盘读写速度• 网络带宽

这部分结论就不做验证了。

声明：所有测试均在较为理想的环境下进行

• 上述所有测试，都没有考虑同时扫描的数据文件大小超过了 Alluxio 缓存的情况，在查询时，数据可以被全量缓存，达到全部本地命中的效果。所以我们看到每次查询耗时在经过 2 到 4 次查询的递减后，就会在一个很小的范围内波动，总的来说耗时比较稳定。

• 在生产环境可能会面临很多查询并行执行，需要扫描大量数据，数据文件的总大小会超过 Alluxio 缓存的大小。那么就会触发数据的淘汰，每个查询都不可能缓存所有需要的数据，所以查询的耗时永远不会稳定，而是在一个较大的区间范围去波动。

• 本次测试没有涵盖数据文件存储在对象存储的场景。如果使用对象存储 S3，预计会有更显著的加速效果。

关于 Alluxio 应用于生产业务的使用、优化建议

• Alluxio 并不能在所有场景下都达到良好的加速收益，要发挥 Alluxio 更大的价值，我们总结了一些使用、优化建议。

建议一：使用 Shadow Cache 检测 Alluxio 与生产上业务的贴合性

生产上引入 Alluxio 是否能带来加速收益，应该设置多大的缓存容量能达到最大收益，需要有评估和检测。

Alluxio 提供了一个 Shadow Cache 功能，可以使用布隆过滤器记录计算引擎访问过哪些数据以及总数据量的大小。每次计算引擎访问数据，都统计一次是否命中 shadow cache 中的数据。结合 shadow cache 和 Alluxio 的命中率可以检测业务是否适合使用缓存。

￮ 业务场景不适合使用缓存：统计 shadow cache 的命中率，如果较低，则说明业务场景中极少会访问重复数据，那么是不适合使用缓存的。￮ Alluxio 缓存需要加大空间：如果 shadow cache 的命中率高，但 Alluxio 缓存的命中率低，说明业务场景适合使用缓存，但是当前 Alluxio 缓存的空间过小了。因为在数据文件被重复访问时，之前存入 Alluxio 的缓存，已经因为缓存满了而被淘汰了，所以重复访问时将得不到任何加速。那么此时加大 Alluxio 缓存空间会取得更好的加速收益。￮ Alluxio 缓存的收益已经达到较佳值：如果 shadow cache 命中率高，Alluxio 缓存的命中率也高，则说明目前 Alluxio 缓存带给业务的加速收益已经达到良好水平，再加大 Alluxio 缓存空间意义不大。

使用 Shadow Cache，对使用 Alluxio 在优化上有一个更直观的方向指导。

建议二：预先加载热数据

Alluxio 的加速需要先把数据 load 到缓存中，这需要等待用户先访问一次数据，也就是说第一次查询是没有加速收益的。那么对于热点数据，我们可以在用户访问前就预先 load 到缓存中。对于长时间不会改变且热点的数据，还可以把数据 pin 在缓存中，不会被淘汰。

建议三：动态判断查询是否需要被加速

有的查询被 Alluxio 缓存可以带来很好的加速收益，有的则不行。我们可以在查询时动态的判断是否需要让 Alluxio 缓存。在查询时，解析 SQL 语句得到查询的表，先去拿到表的元数据，判断数据文件大小，同时也结合 SQL 的大致复杂度，再决定查询是否要走 Alluxio。

建议四：设置单层缓存，使用 SSD 作为存储介质

Alluxio 官方建议不要设置多层缓存，数据在多层缓存中的下沉和上浮可能会对性能有些影响。出于成本和性能的综合考虑，单层缓存的存储介质建议使用 SSD。

建议五：合并小文件

小文件过多会影响 Alluxio 的加速收益，可以对热点数据，在查询前先执行小文件的合并。Alluxio 提供了这个功能，可以对 Hive 表同一分区下的所有文件进行合并，合并后的文件不会覆盖原来的小文件，也不会更改 Hive 的元数据。当 Alluxio 要缓存这些小文件时，会直接缓存合并后的文件，大幅提升读取速度。

想要获取更多有趣有料的【活动信息】【技术文章】【大咖观点】，请点击关注：