Presto+Alluxio性能调优五大技巧

Presto是一个开源的分布式SQL引擎，因其查询具有低延迟、高并发性和原生支持多数据源的特点而广受认可。Alluxio是一个开源分布式文件系统，以内存速度提供统一的数据访问层。Presto和Alluxio的组合在京东、网易等许多公司中越来越受欢迎，这些公司将Alluxio构建在慢速或远程存储之上作为分布式缓存层，以便查询热数据，避免反复从云存储中读取数据。之前的一篇博客文章中，我们已经在高层次.

Alluxio

3111人浏览 · 2019-03-23 22:14:03

Alluxio · 2019-03-23 22:14:03 发布

常用链接
Alluxio项目官网
 Alluxio Inc网站
 Alluxio在各大厂用例
关注Alluxio微信公众号：Alluxio_China

之前的一篇博客文章中，我们已经在高层次上讨论了Presto+Alluxio数据分析技术栈的优势。本文将深入探讨Presto+Alluxio数据分析技术栈的五大性能调优技巧。

关于数据本地性注意事项

默认情况下，当Presto从远程数据源（例如AWS S3）读取数据时，其任务调度不会考虑数据位置因素，因为数据源始终都是远程的。但是当Presto与Alluxio服务同置(collocated)运行时，Alluxio可能会将输入数据缓存到Presto worker的本地，并以内存速度提供下次检索。在这种情况下，Presto可以利用Alluxio从本地的Alluxio worker存储读取数据（称之为短路读取），无需任何额外的网络传输。因此，为了最大化数据输入吞吐量，用户应确保实现任务本地性和Alluxio短路读取。
要检查是否按照预期实现了本地性和短路读取，可以在Alluxio MetricsUI页面监控Short-circuit Read和From Remote Instances这两项：
在这里插入图片描述
如果短路读取的百分比较低，可以使用dstat来监控Alluxio worker的网络流量模式。

1、本地性感知调度 (Locality-aware Scheduling)

为了使Presto能够利用数据本地性，可以启用本地性感知调度模式，以便Presto协调器(coordinator)可以在Presto worker上调度具有本地缓存的数据分片或数据块的任务。在config.properties中设置node-scheduler.network-topology=flat；并且如果你正使用Hiveconnector从Alluxio读取数据，在catalog/hive.properties中设置hive.force-local-scheduling=true。

2、确保主机名匹配

感知本地性任务调度是基于Alluxio worker的文件块地址与Presto worker地址之间的字符串匹配进行的。如果使用IP指定Presto worker地址，并使用机器主机名指定Alluxio worker地址，即便Presto worker和Alluxio worker是同置的，地址也将不匹配。为了避免这种情况，需配置alluxio.worker.hostname和alluxio.user.hostname属性，以匹配Presto worker地址的主机名。用户可以在alluxio-site.properties中设置这些属性，并在Presto的etc/jvm.config的-Xbootclasspath/p:

使用高并发来均衡 I/O 和CPU负载

在开启感知本地性调度后，一旦输入数据缓存到在Alluxio中，Presto就可以从本地Alluxio存储（例如，Alluxio worker配置中的Ramdisk）直接高效地读取数据。在这种情况下，查询的性能瓶颈可能会从I/O带宽转移到CPU资源。请检查Presto worker上的CPU使用情况：如果CPU没有完全饱和，则可能表明Presto worker线程的数量可以设置地更高，或者在批处理中数据分片的数量还不够大。

3、更多worker线程

可以通过设置config.properties中的task.max-worker-threads来调整worker线程数量，典型的设置数量为CPU核数乘以Presto worker节点单核的超线程(hyper-thread)数。可能还需要调整task.concurrency来调节某些并行运算符（如连接和聚合）的本地并发性。

4、批处理中的数据分片数量

Presto会定期调度并将数据分片分配到批处理中。每个批处理的数据分片之间的调度间隙会浪费可用于查询处理的CPU周期。数据分片会处于两种状态：“待处理(pending)”和“正在运行(running)”。将数据分片分配给Presto worker时，数据分片会处于待处理状态，然后当Presto worker线程开始处理数据分片时，数据分片会转换到正在运行状态。node-scheduler.max-splits-per-node属性控制Presto节点上待处理和正在运行的数据分片的数量上限，node-scheduler.max-pending-splits-per-task属性控制待处理数据分片的数量上限。提高这两个属性的值，可以防止Presto worker线程饥饿(starvation)并减少调度开销。请注意，如果这两个属性的值太高，则可能导致仅将所有数据分片只分配给一小部分worker，从而导致worker负载不均衡。

其他

5、防止Alluxio客户端超时

在瓶颈为网络带宽的I/O密集型工作负载下，用户可能会遇到由Alluxio1.8中的Netty超时引起的异常，例如：

Caused by: alluxio.exception.status.DeadlineExceededException: Timeout to read 158007820288 from [id: 0x73ce9e77, /10.11.29.28:59071 => /10.11.29.28:29999].
    at alluxio.client.block.stream.NettyPacketReader.readPacket(NettyPacketReader.java:156)
    at alluxio.client.block.stream.BlockInStream.positionedRead(BlockInStream.java:210)
    at alluxio.client.file.FileInStream.positionedReadInternal(FileInStream.java:284)
    at alluxio.client.file.FileInStream.positionedRead(FileInStream.java:254)
    at alluxio.hadoop.HdfsFileInputStream.read(HdfsFileInputStream.java:142)
    at alluxio.hadoop.HdfsFileInputStream.readFully(HdfsFileInputStream.java:158)
    at org.apache.hadoop.fs.FSDataInputStream.readFully(FSDataInputStream.java:107)
    at com.facebook.presto.hive.orc.HdfsOrcDataSource.readInternal(HdfsOrcDataSource.java:63)

这是因为Presto中的Alluxio客户端未能在预设超时时间内从Alluxio worker获取数据。在这种情况下，可以将alluxio.user.network.netty.timeout增加到更大的值（例如，10分钟）。