网站防注入怎么办,龙岩市官方网站,永兴网站建设报价,石家庄建站网页模板数新网络#xff0c;让每个人享受数据的价值https://xie.infoq.cn/link?targethttps%3A%2F%2Fwww.datacyber.com%2F 一、Presto Alluxio简介 Presto
Presto是由Facebook开发的开源大数据分布式高性能 SQL查询引擎。 起初#xff0c;Facebook使用Hive来进行交互式查询…数新网络让每个人享受数据的价值https://xie.infoq.cn/link?targethttps%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 的场景 PrestoAlluxio的使用场景主要在交互式查询的场景中
1、实时数据分析
Presto可以查询各种实时数据源如Kafka配合Alluxio内存级缓存可以实现对实时数据流的秒级交互分析。 2、交叉数据源查询
Presto可以查询多源异构数据Alluxio提供数据访问统一层两者配合可以轻松实现交叉数据源的交互查询。 3、数据仓库查询分析
典型的数据仓库查询对交互性要求较高Presto Alluxio可实现对云数据仓库中数据的高速查询。 4、海量小文件查询
Alluxio可将海量小文件缓存到内存中Presto基于内存数据查询速度很快。 5、分布式环境复杂查询
在分布式环境下复杂查询需要访问全局数据PrestoAlluxio可通过内存加速解决网络IO问题。 6、多租户环境查询隔离
Alluxio通过缓存空间隔离提供查询隔离Presto按租户查询可实现多租户安全可靠查询。 7、持久化短查询结果
对于重复查询可以将Presto结果持久化到Alluxio避免重复计算。 8、跨云查询
Presto可查询多云数据Alluxio统一数据访问层实现跨云数据高效查询。 Presto和Alluxio在交互查询领域可以良好覆盖各种典型场景共同解决交互查询面临的关键痛点为用户提供高性能、灵活、稳定的交互式查询服务。 Presto Alluxio 部署方式 在生产环境中PrestoAlluxio可通过两种方式部署分别是基于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拿到表和分区的locationlocationUrl的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替换掉默认的实现DistributedFileSystemPresto在拿到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访问数据。
