导语
金山云-企业云团队（赵侃、李金辉）在交互查问场景下对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要缓存这些小文件时，会间接缓存合并后的文件，大幅晋升读取速度。