Meta公司内部项目-RaptorX：将Presto性能提升10倍

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

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

存储分离化存在的问题

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

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是一个分区列：

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

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

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

请注意：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），那么我们不需要该谓词，因为它对这个特定的分区总是成立的，我们可以在进行计划对比时省略该谓词条件。对于其他与谓词有一些重叠的分区，我们仍需要用给定的过滤器扫描整个分区。

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

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性能

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

User Guide用户指南

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

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

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

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

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

● 针对ORC 或DWRF格式：

● 针对Parquet格式：

文章贡献者：

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