Presto+Alluxio数据平台实战

数新网络，让每个人享受数据的价值https://xie.infoq.cn/link?target=https%3A%2F%2Fwww.datacyber.com%2F

一、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访问数据。