正文 

当前位置： 首页 > 程序 > java教程

meta公司内部项目-raptorx：将presto性能提升10倍(代码片段)

Alluxio Alluxio     2022-10-20     379

关键词：

目录

概要速览

存储分离化存在的问题

RaptorX：搭建分层缓存解决方案

Metastore版本化的缓存

文件列表缓存

片段结果缓存

文件描述符和footer缓存

Alluxio 数据缓存

软亲和调度

Performance性能

User Guide用户指南

概要速览

RaptorX是Meta（前“Facebook公司”，下文统称“Meta”）公司的一个内部项目名称，目的是为了降低查询延迟，让Presto的查询性能大大超越原生（vanilla） Presto，这篇文章介绍了RaptorX的关键模块——分层缓存。

有了分层缓存，我们能够将查询性能提升10倍。这一新的架构不仅可以完胜像Raptor之类以性能为导向的连接器，还具有向存储分离化（即存算分离架构）进行持续拓展和支持的额外优势。

存储分离化存在的问题

存储分离化是行业朝着独立存算扩容发展的必然趋势，能够帮助云服务供应商降低成本。Presto本身支持这样的存算分离架构，而数据可以从部署了Presto的服务器之外的远程存储节点获取。

尽管如此，存算分离对查询延迟提出了新的挑战，因为在网络饱和的情况下，通过网络扫描海量数据会受到IO的限制。此外，元数据访问和操作路径也需要通过网络来获取数据的位置；几个元数据RPC来回就能轻易地把延迟抬高到一秒以上，下图用橙线表示Hive连接器的IO相关操作路径，每条路径都可能成为查询性能的瓶颈。

RaptorX：搭建分层缓存解决方案

过去，为了解决网络饱和的问题，Presto通过内嵌的Raptor连接器，将数据从远端存储加载到本地的SSD（固态硬盘），从而实现快速访问，然而，这种解决方案与计算/存储共享节点差别不大，有悖于存算分离的理念。该解决方案的缺点很明显：要么因为worker节点的SSD空间已满而浪费CPU，要么因为CPU受限而浪费SSD容量。于是，Meta启动了RaptorX项目的开发。

RaptorX是为了将Presto查询性能提升至少10倍而开展的一个内部项目，其中分层缓存是RaptorX项目成功的关键。当存储节点与计算节点分离时，缓存的作用尤为显著。开发RaptorX的目的不是为了推出一个新的连接器或产品，而是构造一套内嵌的解决方案，让现有的工作负载无需迁移即可直接从中获益，该解决方案目前主要针对许多工作负载常用的Hive连接器。

下图展示了缓存解决方案的整体架构，该缓存具有分层结构，本文会详细介绍：

  • Metastore版本化的缓存方案：我们把表/分区信息缓存到coordinator中，鉴于元数据是可变的，就像Iceberg或Delta Lake那样，因此信息是被版本化的，我们只与metastore同步版本信息，并仅在当前版本失效时去获取最新版本。
  • 文件列表缓存：将来自远端存储分区目录的文件列表缓存起来。
  • 片段结果缓存：在leaf worker的本地SSD上缓存部分计算结果。由于查询会不断变化，所以我们需要运用裁剪技术来简化查询计划。
  • 文件句柄（file handle）和footer的缓存：在leaf worker内存中缓存打开的文件描述符（file descriptor）和stripe/文件footer信息，因为在读取文件时这些数据往往会被频繁访问。
  • Alluxio数据缓存：在leaf worker的本地SSD上用对齐的1MB大小数据块来缓存文件段。该库（library）是通过Alluxio的缓存服务搭建的。
  • 亲和调度器：是指根据文件路径固定地向对应worker发送请求，从而使缓存命中率最大化的调度器（scheduler）。

Metastore版本化的缓存

Presto coordinator会缓存表的元数据（模式、分区列表和分区信息），以避免向Hive Metastore发起耗时很长的getPartitions调用，但是，Hive表的元数据是可变的，所以我们需要进行版本管理并确定已缓存的元数据是否有效，因此，coordinator为每个缓存的键值对赋予了一个版本号。当收到读取请求时，coordinator会查询Hive Metastore，获取（未被缓存的）分区信息，或者与Hive Metastore核对确认已经缓存的信息是否是最新的。虽然和Hive Metastore进行远程交互的操作不可避免，但与获取全部分区信息相比，版本匹配的成本相对较低。

文件列表缓存

Presto coordinator将文件列表缓存在内存中，从而避免对远端存储发起耗时很长的listFile调用。这只适用于封闭的目录, 而对于开放分区，为了确保数据的实时性，Presto不会缓存这些目录。开放分区的一个主要用例是支持近实时的数据导入和处理。在这种情况下，数据导入引擎（如微批数据micro batch）将不断向开放分区写入新的文件，以便Presto可以读取近实时的数据。其他诸如压缩、metastore更新或为近实时导入数据创建副本等详细信息不在本文的讨论范围内。

片段结果缓存

运行在leaf 阶段的Presto worker可以决定将部分计算结果缓存在本地SSD上，这么做是为了防止多次查询时进行重复计算。最典型的用例是将执行计划的包括扫描、过滤、投影和/或聚合的片段结果缓存在leaf阶段 。

例如，假设一个用户发送了以下查询，其中ds是一个分区列：

SELECT SUM(col) FROM T WHERE ds BETWEEN'2021-01-01' AND '2021-01-03'

对2021-01-01、2021-01-02和2021-01-03每个分区（更准确地说是相应的文件）计算的部分求和结果将被缓存在leaf worker上，形成一个“片段结果”，现在假设用户发送了另外一项查询：

SELECT sum(col) FROM T WHERE ds BETWEEN '2021-01-01'AND '2021-01-05'

现在，Leaf worker便可以直接从缓存中获取2021-01-01、2021-01-02和2021-01-03的片段结果（部分求和结果），并且只需要对2021-01-04和2021-01-05两个分区计算部分求和即可。

由于片段结果是基于leaf查询片段的，用户可以添加或删除过滤器或投影，因此非常灵活。上述例子表明，只包含分区列的过滤器很容易处理。但是为避免由于频繁变化的非分区列过滤器造成的缓存失效，我们引入了基于分区统计信息的裁剪策略，请看下述查询，其中time是一个非分区列:

SELECT SUM(col) FROM T

WHERE ds BETWEEN '2021-01-01'AND'2021-01-05'

ANDtime > now() - INTERVAL'3' DAY

请注意：now()函数的值始终在变，如果leaf worker根据now()的绝对值来缓存计划片段，几乎不可能会命中缓存，但是，如果predicate（谓词条件） time > now() - INTERVAL '3' DAY是对于大多数分区来说为真（true）的“宽松”条件，我们可以在调度时把该谓词从计划中删除。

例如，如果今天是2021-01-04，那么我们知道对于分区ds = 2021-01-04，predicate time > now() - INTERVAL '3' DAY总是成立的。

如下图所示，一般而言，它包含一个谓词条件和3个分区 (A, B, C)，以及各分区同谓词条件相关的最小值（min）、最大值（max）的统计信息(stats)。当分区统计域与谓词域没有任何重叠时（如分区A），我们可以直接裁剪掉该分区，不需要向worker发送分片（split）。如果分区统计域完全包含在谓词域中（如分区C），那么我们不需要该谓词，因为它对这个特定的分区总是成立的，我们可以在进行计划对比时省略该谓词条件。对于其他与谓词有一些重叠的分区，我们仍需要用给定的过滤器扫描整个分区。

文件描述符和footer缓存

Presto worker将文件描述符缓存在内存中，避免对远端存储进行耗时较长的openFile调用。此外，worker还会把经常访问到的列文件和stripe footer缓存在内存中。目前支持的文件格式是ORC，DWRF和Parquet。在内存中缓存此类信息的原因是footer作为针对数据建立的索引信息通常具有高缓存命中率。

Alluxio 数据缓存

Alluxio数据缓存是一个主要特性区别于被淘汰的Raptor连接器。Presto worker每次进行读取操作时将远端存储数据以它原始格式（经过压缩或者可能也经过加密）缓存在本地SSD上。对于将来的读取请求，如果读取范围内的数据已经缓存在本地SSD上，则该读取请求将直接从本地SSD返回结果。缓存库是我们与Alluxio和Presto开源社区共同搭建的。

缓存机制将每次读取对齐成1MB固定大小的数据块，这里的1MB是可以根据不同的存储能力进行配置的。比如，假设Presto发起一次从偏移量0开始的长度为3MB的读取请求，那么Alluxio缓存会检查0-1MB、1-2MB和2-3MB的数据块是否已经缓存在磁盘上，然后只远程获取尚未被缓存的数据块。缓存清除策略基于LRU，会从磁盘上删除最久没被访问过的数据块。Alluxio数据缓存为Hive连接器提供了标准的Hadoop文件系统接口，并且基于专门用来支撑规模达到Meta级别工作负载的高性能、高并发且可容错的存储引擎，以透明的方式对请求的数据块进行缓存。

软亲和调度

为了最大程度地提高worker的缓存命中率，coordinator需要将同一文件的请求调度给同一个worker。因为文件的一部分很有可能已经被缓存在那个特定的worker上了。调度策略是“软”的，也就是说，如果目标worker太忙或不可用，调度器会退而求其次，安排给它的备选worker进行缓存，或者在必要时直接跳过不予缓存。该调度策略确保了缓存不在关键路径上，但仍然能够提升性能。

Performance性能

Meta已经在公司内部全面部署了RaptorX缓存并进行了实战测试。为了与原生（vanilla） Presto进行性能比较，我们在一个包含114个节点的集群上进行了TPC-H基准测试。每个worker都有1TB的本地SSD，每个任务配置4个线程。我们在远端存储中准备了放大系数（scale factor）为100的TPC-H表。下图展示了Presto和装备了分层缓存的Presto之间的性能对比结果。

从基准测试结果来看，像Q1、Q6、Q12-Q16、Q19和Q22这样的重扫描或重聚合的查询都能实现超过10倍的延迟改善。甚至像Q2、Q5、Q10或Q17这样的重关联查询也有3-5倍的延迟改善。

User Guide用户指南

要完全启用该功能，我们需要为worker配备本地的SSD，为了能够启用本文所述的各个缓存层，请进行以下配置:

调度(/catalog/hive.properties):

hive.node-selection-strategy=SOFT_AFFINITY

Metastore版本化的缓存(/catalog/hive.properties):

hive.partition-versioning-enabled=true

hive.metastore-cache-scope=PARTITION

hive.metastore-cache-ttl=2d

hive.metastore-refresh-interval=3d

hive.metastore-cache-maximum-size=10000000

文件列表缓存(/catalog/hive.properties):

hive.file-status-cache-expire-time=24h

hive.file-status-cache-size=100000000

hive.file-status-cache-tables=*

数据缓存(/catalog/hive.properties):

cache.enabled=true

cache.base-directory=file:///mnt/flash/data

cache.type=ALLUXIO

cache.alluxio.max-cache-size=1600GB

片段结果缓存(/config.properties and /catalog/hive.properties):

fragment-result-cache.enabled=true

fragment-result-cache.max-cached-entries=1000000

fragment-result-cache.base-directory=file:///mnt/flash/fragment

fragment-result-cache.cache-ttl=24h

hive.partition-statistics-based-optimization-enabled=true

文件和stripe footer 缓存(/catalog/hive.properties):

● 针对ORC 或DWRF格式：

hive.orc.file-tail-cache-enabled=true

hive.orc.file-tail-cache-size=100MB

hive.orc.file-tail-cache-ttl-since-last-access=6h

hive.orc.stripe-metadata-cache-enabled=true

hive.orc.stripe-footer-cache-size=100MB

hive.orc.stripe-footer-cache-ttl-since-last-access=6h

hive.orc.stripe-stream-cache-size=300MB

hive.orc.stripe-stream-cache-ttl-since-last-access=6h

针对Parquet格式：

hive.parquet.metadata-cache-enabled=true

hive.parquet.metadata-cache-size=100MB

hive.parquet.metadata-cache-ttl-since-last-access=6h
文章贡献者：
Meta:Abhinav Sharma, Amit Dutta, Baldeep Hira, Biswapesh Chattopadhyay, James Sun, Jialiang Tan, Ke Wang, Lin Liu, Naveen Cherukuri, Nikhil Collooru, Peter Na, Prashant Nema, Rohit Jain, Saksham Sachdev, Sergey Pershin, Shixuan Fan, Varun Gajjala
Alluxio: Bin Fan, Calvin Jia, HaoYuan Li
Twitter: Zhenxiao Luo
Pinterest: Lu Niu

请点击“阅读原文”了解更多详情

更多精彩内容可微信搜索“Alluxio服务号”，获取更多精彩内容

如有疑问，可添加Alluxio小助手（VX：Alluxio_Tianyu），探索更奇妙的开源世界

facebook改名“meta”拥抱元宇宙，gamefi项目“murphy”备受关注

社交媒体巨头“脸书”CEO扎克伯格在该公司的活动上，揭晓了外界期待已久的公司新名字：“Meta”。新名称“Meta”来自于科幻词语宇宙（Metaverse），来描述新公司在虚拟世界中工作和娱乐的愿景。并宣布这将... 查看详情

prestocon超清视频和ppt我给你整好了

...需求。Meta（Facebook）的KeWang和Alluxio的BinFan致力于RaptorX的开发，进一步提升每个查询的cachehitrate。RaptorX的相关文章也可以参考《RaptorX:将Presto性能提升十倍》另外，PrestoonVelox（Prestissimo）项目也有 查看详情

facebook正式改名meta，十年内虚拟化身上班不是梦

小扎要元宇宙不要“脸”了Facebook将成为元宇宙公司。Facebook最近的日子实在是不好过，前产品经理FrancesHaugen将公司内部文件公开，暴露了公司内部算法会放大仇恨和恶化青少年心理问题，对网络上的错误和暴力等信... 查看详情

模拟项目

一，配置目前网络环境1.1问题一家新创建的IT公司，公司位于北京有80多台服务器目前网络环境使用技术，通过端口映射技术将web服务器发布给Internet：三层交换：汇聚接入层交换机默认路由：实现到互联网数以万计网络访问的简... 查看详情

小扎遭meta员工炮轰：元宇宙将“杀死”公司！

整理|苏宓出品|CSDN（ID：CSDNnews）在Meta全面进军元宇宙的一年后，不知道CEO扎克伯格是否后悔过，可以肯定的是，其不少员工已然处于非常焦虑的状态下。据外媒BusinessInsider报道，近日在美国匿名论坛Bl... 查看详情

meta处境越加艰难，或将引入末位淘汰制

...，或将引入末位淘汰制1　　据外媒benzinga报道，Facebook母公司Meta的工程主管MaherSaba，向工程经理发布通知，要求他找出团队中表现最差的部分员工，并把名单上报到人力资源系统。　　Saba在邮件中写道，“如果你的直接下属存... 查看详情

小扎遭meta员工炮轰：元宇宙将“杀死”公司！(代码片段)

整理|苏宓 出品|CSDN（ID：CSDNnews）在Meta全面进军元宇宙的一年后，不知道CEO扎克伯格是否后悔过，可以肯定的是，其不少员工已然处于非常焦虑的状态下。据外媒BusinessInsider报道，近日在美国匿名论坛... 查看详情

raptorx:将presto性能提升十倍

...的文章，欢迎关注微信公众号：过往记忆大数据RaptorX：构建分层缓存解决方案过去，为了解决网络瓶颈问题，Presto有一个内置的Raptor连接器，可以将数据从远程存储加载到本地SSD，以便快速访问。然而... 查看详情

meta公司新探索|利用alluxio数据缓存降低presto延迟(代码片段)

...有用的配置如下下一步工作文章贡献者：概要速览Meta公司（前“Facebook公司”，下文统称“Meta”ÿ 查看详情

1.1万人被裁，人均71万补偿，扎克伯格承认因决策失误致meta首次大规模裁员

...#xff0c;这意味着将有超过1.1万名员工离职，这也成为该公司创办以来最大规模的裁员。扎克伯格表示，他要为公司的失误负责。这将是Meta历史上的第一次大规模裁员，Meta在9月底时曾宣布该公司拥有超过87000名员工。扎... 查看详情

meta与苹果的元宇宙碰撞

Meta 自从将公司改名后就成为了元宇宙产业中一个十分值得关注的企业，它号称在五年内转型为元宇宙公司，事实上，它也正在全力冲击元宇宙相关产业。最近，Meta 委托著名经济咨询公司 AnalysisGroup 制作了一... 查看详情

meta将启动史上首次大规模裁员

...校长。昨天看到一条新闻：知情人士称，脸书母公司Meta计划从本周开始大规模裁员，将影响数千名员工，计划最早在周三宣布。这可能是科技行业在疫情期间实现快速增长后，近期裁员潮中规模最大的一轮... 查看详情

扎克伯格allin元宇宙，公司更名meta，「脸」不要了

博雯发自凹非寺量子位报道|公众号QbitAIFacebook现在正式更名为Meta！这是10月28日举办的FacebookConnect大会上，CEO扎克伯格宣布的重大决定。新名字Meta取自单词Metaverse，意为元宇宙。这也就是扎克伯格在昨天发表的《创始... 查看详情

公司内部中搭建wiki服务做项目管理系统

tomcat+mysql+xwiki搭建开源wiki系统xwiki是使用java语言编写的开源wiki系统  xwiki有多种版本，standalone的版本可以直接下载之后独立安装，默认集成了jetty运行，但是这种方式安装xwiki，运行速度比较慢，在大部分的情况下不能满... 查看详情

jenkins集群在公司内部的实践(一)

...jenkins作为一款实用且广泛实用的CI/CD工具，为大多数中小公司拿来即用。可当我们的业务和工程逐渐增多，它在构建和自动化任务方面的压力也越来越大。jenkins主要是用来基于源码的打包，公司用到的语言包括java/php/android/h5等... 查看详情

脸书被裁员工将至少获71万补偿,究竟是怎么一回事?

参考技术A“把寒气传给每一个人”，这不，国外公司也感受到了这股寒气。近日消息，媒体报道称由于通货膨胀、欧洲能源危机等原因导致全球经济增长放缓，微软、推特等互联网开始裁员并缩减招聘规模。其中脸书母公司Meta... 查看详情

公司规划

公司内部主要运营模式：一、项目：项目分成三类1、老客户老项目2、老客户新项目3、新客户新项目4、外包模式的项目按照谁的项目谁拿销售提成的原则中间包括：公司项目，员工与客户谈成的项目销售提成归员工所有员工新... 查看详情

将token存入session中(代码片段)

在项目实践中遇到这种情况：一个原本在公司内网中的项目，现独立出一个单独的模块做成单独的项目部署到客户端，帮助客户实现数据对接，这就要求在项目中不涉及到持久化及redis的使用，在使用redis存放token时，由于客户端... 查看详情