数新网络,让每个人享受数据的价值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访问数据。