数新网络，让每个人享受数据的价值

一、Presto & Alluxio 简介

Presto

Presto 是由 Facebook 开发的开源大数据分布式高性能 SQL 查询引擎。

起初，Facebook 使用 Hive 来进行交互式查询分析，但 Hive 是基于 MapReduce 为批处理而设计的，延时很高，满足不了用户对于交互式查询想要快速出结果的场景。

为了解决 Hive 并不擅长的交互式查询领域，Facebook 开发了 Presto，它专注于提供低延时、高性能的交互式查询服务。

与 Hive 等其他批处理的 SQL 引擎不同，Presto 的查询速度非常快，可以在亚秒级或者分钟级内返回结果，让用户能够更加轻松地进行数据分析和查询。同时，Presto 还支持多种数据源的查询，包 Hive、MySQL、PostgreSQL、Kafka 等，提供了丰富的函数库和强大的扩展性，使得它在企业数据分析、数据仓库构建等领域有着广泛的应用。

Alluxio

Alluxio 是一个开源的分布式内存文件系统，由 UC Berkeley AMPLab 实验室开发。

Alluxio 最初名为 Tachyon，后更名为 Alluxio。它主要解决大数据计算中数据访问速度瓶颈的问题。Alluxio 将数据缓存在内存中，使大数据应用程序可以更快速地访问数据。

与传统的 HDFS 不同，Alluxio 无需将数据预先写入磁盘，而是直接将数据缓存在内存，大大提升了数据访问速度。对于需要访问同一数据集的不同计算框架如 Spark、MapReduce、Hive 等，Alluxio 只需将数据集缓存到内存一次，之后所有框架都可以共享这份缓存数据，避免了数据的重复加载。

此外，Alluxio 支持混合存储架构，可以挂载多种底层存储系统如 AWS S3、Azure Blob Store、HDFS 等。数据会先被 Cache 到 Alluxio 中，如果 Cache 不足，Alluxio 会暂时从底层储存系统中读取数据。

Alluxio 作为内存级数据访问层，极大地提升了大数据应用的性能。它被广泛应用于数据分析、机器学习等需要高吞吐访问大数据集的场景。

二、应用 Presto + Alluxio 的场景

Presto+Alluxio 的使用场景主要在交互式查询的场景中：

1、实时数据分析

Presto 可以查询各种实时数据源如 Kafka，配合 Alluxio 内存级缓存，可以实现对实时数据流的秒级交互分析。

2、交叉数据源查询

Presto 可以查询多源异构数据，Alluxio 提供数据访问统一层，两者配合可以轻松实现交叉数据源的交互查询。

3、数据仓库查询分析

典型的数据仓库查询对交互性要求较高，Presto + Alluxio 可实现对云数据仓库中数据的高速查询。

4、海量小文件查询

Alluxio 可将海量小文件缓存到内存中，Presto 基于内存数据查询速度很快。

5、分布式环境复杂查询

在分布式环境下，复杂查询需要访问全局数据，Presto+Alluxio 可通过内存加速解决网络 IO 问题。

6、多租户环境查询隔离

Alluxio 通过缓存空间隔离提供查询隔离，Presto 按租户查询，可实现多租户安全可靠查询。

7、持久化短查询结果

对于重复查询，可以将 Presto 结果持久化到 Alluxio，避免重复计算。

8、跨云查询

Presto 可查询多云数据，Alluxio 统一数据访问层，实现跨云数据高效查询。

Presto 和 Alluxio 在交互查询领域可以良好覆盖各种典型场景，共同解决交互查询面临的关键痛点，为用户提供高性能、灵活、稳定的交互式查询服务。

Presto + Alluxio 部署方式

在生产环境中，Presto+Alluxio 可通过两种方式部署，分别是基于 K8s 和 Yarn 部署：

Presto + Alluxio on K8s 部署

在本部署方案中，将 Presto 的 Coordinator 和 worker 包括 Alluxio 的 master worker 和 Presto 的网关 Gateway 都部署在 K8s 上，由 K8s 完成负载和高可用的功能；

Presto on Yarn 部署

在 Yarn 部署方式中，即由 Yarn 完成原来由 K8s 完成的工作，在 Yarn 部署中，需要使用开源组件 Apache Slider；在 Yarn 部署中，将 Presto 的 coordinator 和 worker 部署在 Yarn 上；在部署中，需要使用混合部署的模式，需要在每一台部署的 nodeManager 或者宿主机上部署一个 AlluxioWorker，使 PrestoWorker 可以短路读取本地的缓存，其中缓存存储介质建议使用 SSD，可实现较好的加速效果。

三、使用 Alluxio 遇到的问题

问题一：其他业务系统不能识别 Alluxio

问题描述: (以访问 Hive 表为例)

Presto 查询前先访问 HMS 拿到表和分区的 location，locationUrl 的 schema 必须是 alluxio:/，Presto 才会使用 alluxio.hadoop.FileSystem 去访问 Alluxio Master (由 core-site.xml 中的 fsalluxioimpl 配置)。

如果拿到的 locationUrl 的 schema 是 hdfs://，Presto 默认使用 org.apache.hadoop.hdfs.DistributedFileSystem 去访问 NameNode(fs.hdfsimpl 的默认值)。

但是如果 HMS 中存的 location 是 alluxio://，其他业务系统无法识别这个 schema。

解决方案：

重写一个 hadoop 兼容的文件系统客户端，配置到 core-site.xml 中的 fs.hdfsimpl，替换掉默认的实现 DistributedFileSystem；Presto 在拿到 hdfs://的 location 时，就会使用自实现的客户端来处理，直接访问 Alluxio，相当于把 schema 转换成 alluxio://。

问题二：如何提高缓存空间的利用效率？

解决方案：

默认配置下，会造成多次远程命中和缓存数据大量几余，数据更容易被淘汰，降低命中率，可通过开启 Presto 软亲和性，并采用一致性 hash 算法来分配 Split，实现在保持数据本地性的前提下，降低缓存冗余。

其中：集群整体都进入繁忙的时候，软亲和性等于失效，进而降低数据本地性引发缓存冗余、数据淘汰、命中率下降。

四、适合 Alluxio 的场景

场景一：UFS 的文件不宜太小

读取的小文件越小，Alluxio 加速收益越低。

同样大小的数据，小文件越多，读取的元数据、创建的 split 和 driver 数越多，还要调度更多的 driver 执行，这些操作都无法被加速。

例如在数仓中采集到 ODS 层的数据，如果存在大量小文件，进而导致 DWDDWS 层也有大量小文件这种场景下，使用 Alluxio 加速交互式查询数仓的效果会比较差。

优化建议：合并掉 Hive 表的小文件。

场景二：UFS 的文件不宜太小

执行的 sql 查询越复杂，加速收益越低在整体耗时中，IO 耗时的占比就会下降，而 Alluxio 只能加速 IO 的耗时，所复杂 sql 的计算耗时较长以在整体耗时的加速上收益会降低。

ETL 中的那些复杂 sql，使用 Alluxio 来加速意义不大。

优化建议：过于复杂的 sql 执行时不要走 Alluxio 访问数据。