共计 5369 个字符，预计需要花费 14 分钟才能阅读完成。
导语
金山云 - 企业云团队（赵侃、李金辉）在交互查问场景下对 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 表的底层数据文件的大小和减速收益正相干
- 论断：查问的数据文件在小于约 2MB 时，文件越小，Alluxio 减速收益越低。
因文件过小，所以每个文件是一个 split。Presto 解析每个 split 创立 driver，调度 driver 执行，这段耗时是不能被减速的，而 operator 扫描的数据太小，那么磁盘 IO 的耗时在整个耗时中占比就会较低，Alluxio 对查问的减速收益就会升高。
在本次测试所应用的环境中，每个数据文件小于约 50KB 时，在查问的整体耗时上，减速收益会比拟低。
数据文件大于约 2MB 时，文件大小对减速收益的影响绝对不那么显著。
这个 2MB 和 50KB 只是在本环境中察看到的一个大略阈值，在不同环境中可能会有不同的体现。
- 验证：用一条简略的 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、换一张表再验证一次，能够看到论断是一样的。
- 验证：用 tpcds 中的 Query55 进行测试
【a. 试验用例阐明】
query55 中蕴含聚合、排序、大小表 join，复杂度个别，presto 会为其划分 7 个 stage
query55 查问的事实表为 store_sales。
store_sales 表的相干元数据
【b. 试验后果展现】
【c. 试验后果剖析】
￮ 论断跟上一次试验统一，当 split 的数据只有百来 K 的时候，减速收益比拟强劲，仅 20%。
￮ split 的数据大于 2M 以上，数据大小对减速收益的影响较小。
因素二：执行的 SQL 语句的复杂度和减速收益负相关
- 论断：SQL 语句越简单，Alluxio 的减速收益越低
SQL 语句越简单，计算的耗时就会越长，在整体耗时中，IO 耗时的占比就会降落，而 Alluxio 只能减速 IO 的耗时，所以在整体耗时的减速上，收益会升高。
在评估 SQL 复杂度时，咱们能够参考 Presto 在执行 SQL 时划分的 Stage 的数量，来量化 SQL 的复杂度，Stage 越多则阐明 SQL 绝对简单些。当然也能够肉眼大抵判断下复杂度：
a. 简略：分组聚合、排序
b. 简单：大小表 join、select 语句嵌套
c. 特地简单：大表 join 大表、更多的表参加 join、多个 select 语句嵌套
- 验证：针对 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 都有不错的体现。
- 验证：当查问的数据文件较小且 SQL 语句很简单
【a. 试验用例阐明】
咱们这里再补充做一个试验，当查问的数据文件较小，而 SQL 语句又简单的话，减速收益如何呢。
本试验 SQL 语句应用 query88，别离查问 2 套数据集。
表的相干元数据
【b. 试验后果展现】
【c. 试验后果剖析】
咱们看到，在这种很不合适 Alluxio 的条件下，减速收益会比拟低。
因素三：查问 SQL 语句返回的数据量的大小和减速收益负相关
- 论断：查问返回的数据量越大，Alluxio 的减速收益越低
Presto 最初会应用一个 Driver 来 reduce 所有 Driver 的计算结果，数据量越大，reduce 的耗时越长，这里次要包含计算的耗时和网络 IO 耗时。如果是扫表时过滤的数据就很少，那么参加计算的数据量就会减少，减少了计算耗时，那么就升高了 IO 耗时在整个查问耗时中的占比
- 验证：
【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 要缓存这些小文件时，会间接缓存合并后的文件，大幅晋升读取速度。
