基于AIGC的写作尝试：Presto: A Decade of SQL Analytics at Meta（翻译）
基于AIGC的写作尝试：Presto: A Decade of SQL Analytics at Meta（翻译）
ABSTRACT
Presto是一个开源的分布式SQL查询引擎，支持多个EB级数据源的分析工作负载。Presto用于低延迟的交互式用例以及Meta的长时间运行的ETL作业。它最初于2013年在Meta推出，并于2019年捐赠给Linux基金会。在过去的十年中，随着Meta数据量的超级增长以及新的SQL分析需求，维护查询延迟和可扩展性对Presto提出了令人印象深刻的挑战。其中一个最重要的优先事项是确保查询可靠性不会随着向更小、更弹性的容器分配的转变而退化，这需要查询在显著较小的内存余量下运行，并且可以随时被抢占。此外，来自机器学习、隐私政策和图形分析的新需求已经促使Presto维护者超越传统的数据分析。在本文中，我们讨论了近年来几个成功的演变，这些演变在Meta的生产环境中将Presto的延迟和可扩展性提高了数个数量级。其中一些值得注意的是分层缓存、本地矢量化执行引擎、物化视图和Presto on Spark。通过这些新的能力，我们已经弃用了或正在弃用各种传统的查询引擎，以便Presto成为为整个数据仓库服务的单一组件，用于交互式、自适应、ETL和图形处理工作负载。
CCS CONCEPTS
（ACM Computing Classification System Concepts）
- Information systems → Database query processing;
- Parallel and distributed DBMSs;
- Online analytical processing engines.
KEYWORDS
Data Warehouse, Presto, OLAP, SQL, Distributed Database, Data Analytics, ETL
INTRODUCTION
Presto是一个开源的分布式查询引擎，自2013年以来一直支持Meta的生产分析工作负载。它提供了一个SQL接口，用于查询存储在不同存储系统上的数据，例如分布式文件系统。自2019年捐赠给Linux基金会以来，Presto在美国科技行业领袖中的使用和贡献持续增，包括Uber、、Intel、Ahana等。在捐赠后，Meta仍然积极参与Presto的贡献，50%的提交来自Meta。Meta的Presto部署也在顶级分支上，以确保每个版本都在Meta规模上进行了测试。
在Meta内部，Presto用于大规模的交互式、自适应和提取转换加载（ETL）工作负载。使用案例包括仪表板、A/B测试、自适应分析、数据清理和转换。随着将所有SparkSQL工作负载迁移到Presto，Presto将很快成为公司仓库的唯一SQL接口。
虽然Presto最初是为交互式SQL查询的纯内存处理而设计的，但Meta的各趋势挑战了它的能力。由于其效率，员工开始将其用于运行长达数十分钟的轻量级ETL工作负载[44]，随着数据呈指数级增长，Presto变得越来越慢。向更灵活和弹性的资源管理模型的转变，使用更小、短暂的容器，导致可靠性降低。此外，随着对更丰富的分析需求的增长，例如机器学习特征工程和图形分析，它们得不到很好的支持。最后，遵守Meta的数据隐私政策需要新的数据抽象和数据存储机制，以有效支持隐私策略执行。本文的主要重点是描述我们如何改进Presto的架构，以应对这些挑战，从以下三个方面说明。
首先，延迟和效率。随着数据量的增加，相同查询的扫描成本增加，导致等待变长。由于集群中机器的RPC连接数量不能无限增加，添加更多机器到集群中会达到一个极限。此外，使用更多机器本质上增加了单个机器故障的可能性。其他延迟改进，以保用户可以在大规模可扩展数据扫描的情况下仍然具有低延迟的仪表板体验。特别是对于重要的仪表板，用户希望Presto表现得好像数据已经被裁减或存储在内存中，可以任意切片和切块。
其次，可扩展性和可靠性。SQL是Meta ETL工作负载的首选，这推动了Presto的流行。由于Presto不提供容错性，并且硬件限制了内存，因此需要新的方法来支持比Presto当前支持的CPU、内存运行时间重得多的ETL工作负载[44]。此外，Meta已经调整了容器分配，使其具有更弹性的可管理性和更小的内存占用。弹性允许更灵活的容量来平衡公司中不同类型工作负载的高峰和低使用然而，它也带来了一个复杂的挑战，因为机器可能会任意宕机。在这些限制下需要新的设计原则来扩展工作负载，以处理任意大的内存消耗和任意长的运行时间，同时具有不稳定的基础架构。
最后，需要超越数据分析的要求。现代仓库已经成为数据湖，以根据不同用例的需求允许数据使用。一个典型的用例是机器学习特征工程。Meta的机器学习相关数据量已经超过了分析。机器学习工程师利用像Presto或SparkSQL这样的分析引擎从原始数据中提取特征，用于训练目的。隐私政策是另一个重要的要求。Facebook、Instagram和WhatsApp用户可以选择退出个人数据用于内容推荐或Meta已经收集的任何其他数据用例。Presto正在确保数据得到适当的保护。此外，Meta关注社交图谱。我们已经看到用户要求通过Presto进行类似SQL的图分析，以表达具有数十亿个节点和边的复杂逻辑。
本文的其余部分结构如下。第2节概述了Presto的原始架构以及在过去几年中在Meta的架构基础上面临的挑战。第3、4和5节分别介绍了Presto的演变，以改善延迟、可扩展性和效率。第6节讨论了机器学习、隐私和图形分析等领域，以说明用户如何利用Presto作为引擎来操作Meta仓库数据，进行更丰富的分析。第7节演示了这些演变如何帮助提高在Meta规模下生产数据的性能。第8节讨论了这个领域的相关工作，第9节总结了剩余的挑战和计划的工作来解决它们。我们在第10节的结论中强调了本文讨论的改进以及我们弃用各种引擎，使Presto成为我们仓库的核心。
ARCHITECTURE AND CHALLENGES
Meta在2022年拥有21个数据中心[12]，每个数据中心的面积都是数百万平方英尺。Meta的数据仓库在这些数据中心中拥有大量存储空间。绝大多数Meta员工每天都直接或间接地使用Presto或其他工具访问这些数据。
随着Meta仓库数据呈指数级增长，Presto面临各种困难，以保证用户具有相同的延迟和可扩展性体验。随着扫描变得更大，仪表板变得更慢，用户开始利用内存或共存存储计算引擎[40,44]以获得更好的性能。在ETL方面，更可扩展的引擎，如Spark [57]，被视为首选，因为内置的容错性可以保证长时间运行的作业即使容器崩溃也能完成。使用弹性容量的不断增长趋势需要以更高的频率分配和取消分配容器。今天，没有保证一个容器可以连续几个小时专用于Presto集群。Presto的原始架构采用分离的存储和内存处理，只能最优地处理运行几秒钟到几分钟之间的查询。随着Presto需求超出其原始要求，我们设计了方法来使Presto本身演以克服所面临的挑战。
图1说明了Presto集群的原始架构[44]。它由一个协调器和数千个可扩展的工作节点组成。协调器负责排队和解析查询字符串，然后将其转换为计划。计划将应用优化，并根据shuffle边界分成计划片段或简单片段。这些片段将并行地调度到工作节点上。工作节点负责使用内存中的所有数据进行查询处理，并通过网络上的流式RPC进行数据Shuffle。每个工作节点将启动任务来处理接收到的片段数据。处理后的数据将被洗牌到不同的内存缓冲区中，等待不同的下游任务获取。一个集群可以同时运行多个查询和它们的任务，具有完全的多租户共享内存、IO、网络和CPU。Presto还支持存储连接器，允许扫描异构数据源进行相同的查询。
正如我们从原始架构中可以看出的那样，由于外部存储与计算引擎分离，延迟可能会受到IO的瓶颈限制。此外，所有工作节点目前都是用Java编写的，这在程序上比没有对内存分配进行精细控制的本地代码慢。存储连接器也成为一把双刃剑：为了支持低延迟的仪表板，像Raptor [44]这样的系统被构建为使用专门类型的机器将仓库数据转储到本地内存或磁盘中，以便仪表板可以更快地加载。共存存储不仅引入了数据管理开销，而且也减少了存储和计算的独立扩展的好处。
从可扩展性的角度来看，协调器作为单点故障和工作节点缺乏容错能力的问题随着数据增长以及弹性容量的引入而被放大。内存处理设计也定义了系统可以容纳多少数据的上限。基于网络的Shuffle由于连接限制无法扩展到数千个工作节点以上。
除了延迟和可扩展性方面的挑战之外，以机器学习为重点和以隐私政策为重点的不断增长的趋势逐渐将传统的面向分析的数据仓库转变为更开放和灵活的“数据湖”设置。分析数据不再是不可变的。Meta需要有能力根据用户的隐私选择删除用户数据。在机器学习特征工程期间，还可以高度灵活地添加列以尝试不同的候选特征。
在本文的其余部分，我们将讨论在Meta成功推出的几个Presto演变，以解决上述挑战。其中一些改进在我们的prestodb博客[1、8、17、29、37、54、55]中有更深入的讨论。图2说明了新Presto架构的高级想法。当一个查询被发送到Presto集群时，它可以在以下两种设置中的任何一种上运行：(1)原始的Presto架构，但具有多个协调器以避免单点故障，本地矢量化执行以提高性能，闪存数据缓存以避免IO瓶颈，以及许多其他将在本文中讨论的改进；或者(2)Presto on Spark，利用Spark作为运行时，Presto作为可扩展性的评估库。在这两种设置中，我们提供了物化视图来提高查询性能，并为机器学习特征工程和隐私用例提供数据可变性。此外，这两种设置都可以将内存中的数据溢出到临时存储中，以克服内存限制。原始的Presto架构现在也增强了可恢复性，以物化中间数据。另一方面，Presto on Spark设置利用临时存储进行洗牌。还引入了额外的元数据。类型存储用于支持用户定义的类型，函数存储用于支持SQL函数编写和评估，统计存储用于更好的优化决策。远程函数用于运行用户定义的函数。
LATENCY IMPROVEMENTS
随着数据的增长，查询延迟自然会受到降级的影响。本节介绍了几个增强Presto的方法，以从CPU、IO和内存的角度改善延迟。
Caching
分离的存储使得扩和独立计算成为可能。然而分离引入了新的查询延迟挑战，因为在网络饱和时通过网络扫描大量数据甚至元数据可能会受到IO限制。为了解决这个问题，我们在各个层面引入了缓存。在本文的其余部分，我们使用文件的概念来表示物理存储在远程存储中的数据切片。
原始数据缓存：工作节点上的本地闪存设备上的数据缓存可以帮助减少从远程存储节点读取数据的IO时间。Presto工作节点在读取时将远程数据以其原始形式（压缩和可能加密）缓存在本地闪存中。如果将来有一个读取请求覆盖了可以在本地闪存中找的范围，请求将直返回结果。缓存单元的大小是对齐的，以避免碎片化。例如，如果一个读取请求覆盖了范围2.3MB，4.5MB)，Presto将发出范围[2MB，5MB)的远程读取，并为[2MB，3MB)、[3MB，4MB)和4MB，5MB)的块缓存和索引。对于任何来与[2MB，5MB)范围重叠的读取，重叠部分将直接从本地磁盘获取。这些缓存单元的驱逐策略是LRU（最近最少使用）。
片段结果缓存：此外，正在运行叶子阶段的任务（负责从远程存储中拉取数据的任务）可以决定在本地闪存缓存部分计算结果，以防止在多个查询中重复计算。一典型的方法是在具有一级扫描、过滤、投和/或聚合的叶子阶段上缓存计划片段结果。例如，用户可能决定查询过去1天的报告聚合结果。稍后，他们可以调整仪表板以查看过3天的聚合结果。然后对于第二个查询，我们可以通过缓存来防止第一天的重复计算。只有剩余的2天数据需要扫描和部分聚合。
请注意，片段结果基于叶子查询片段，这可能会因用户调整过滤器或投影而高度变化。为了在用户频繁更改过滤器或投影时最大化缓存命中率，我们依赖基于统计的规范化。规范化首先执行从不同变量名称到固定名称的同构映射，以便具有相同含义的不同别名的查询最终具有相同的计划。然后，它对表达式进行排序，以便像𝑎>𝑏和𝑏<𝑎这样的表达式具有相同的格式。最后，在过滤器中修剪谓词。给定一个形式为谓词连接的合取范式的过滤器𝜙，谓词修剪通过删除𝜙中所有满足的谓词来生成一个新的过滤器。请注意，该方法不仅限于合范式，其他一般表示形式如析取范式也适用。因为每个工作节点只读取部分数据，所以它可以在运行时比协调器在计划时更多地修剪过滤器的谓词。对于由工作节点读取的文件，工作节点获取文件的统计信息（通常是最小值和最大值）以检查统计范围是否满足某些谓词。工作节点将删除过滤器中完全满足的谓词，或者如果任何谓词不满足，则评估整个过滤器为False。
元数据缓存和目录服务器：在协调器和工作节点上还引入了各种元数据级别的缓存。像文件索引（在其他上下文中也称为“脚注”或“标题”）这样的热数据被缓存在内存中。可变元数据，如表模式或文件路径，带有版本控制缓存在协调器中。还有一个选项是将元数据缓存托管在目录服务器中，以进一步扩展缓存。目录服务器可以是独立的部署，除了协调器之外，也可以与协调器共存。然而在Meta我们不使用独立的目录服务器，以避免部署碎片化。
缓存本地性：为了最大化工作节点（无论是内存还是本地闪存）上的缓存命中率，协调器需要使用哈希函数将同一文件的读取请求调度到同一工作节点上。为了避免热点工作节点，调度程序将在必要时回退到其次选工作节点进行缓存，或者直接跳过缓存。提供了各种哈希策略，如简单模块哈希或一致性哈希。相同的逻辑也适用于查询路由。由于Presto在全球范围内部署在多个数据中心，路由器将重定向查询到具有缓存数据的集群，并采取热点预防措施作为备选方案。
通过实施上述所有机制，我们能够通过提供相同或更快的查询延迟，在Meta [14]完全废弃了像Raptor [44]这样的共存存储连接器和像Cubrick [40]这样的内存数据库。更多详细信息，包括TPC-H基准测试，可以在我们的博客[1, 29]中找到。
Native vectorized execution
Presto是用Java编写的。这不仅防止了精确的内存管理，而且使我们无法利用现代的矢量化CPU执行，如SIMD。Velox [41]是一个最初从Meta的Presto孵化出来的项目，用于支持C++矢量化执行。后来它成为了一个通用的矢量化执行库，可以受益于机器学习加速等用例。
Presto与Velox紧密集成，以利用矢量化执行。为了托管C++库，构建了本地C++工作节点，直接与协调器通信。Shuffle和IO采用本地Velox格式，因此不需要额外的复制来转换为Presto格式。当查询开始时，协调器将查询计划片段调度到C++工作节点。工作节点接收计划片段并将其转换为Velox计划。在C++工作节点内部直接接收Velox计划时，会生成本地线程以充分利用内存的可互换性。
在Velox的执行线程中，函数、表达式和IO以矢量化方式执行。简单的表达式通过SIMD一次计算多个值。Velox具有与Presto兼容的类型和函数语义，因此相同的函数签名可以在Java和C++执行中产生相同的结果。
图3展示了所有TPC-H查询的平均查询延迟和CPU时间，比例因子为1000，分别用Java和本地执行。基准测试在相同的集群上进行，具有相同数量的核心和内存配置。延迟和CPU的总体改进约为2-3倍。生产数据的更详细比较在第7节中讨论。
Adaptive filtering
高效的剪枝非常重要，因为用户可以任意切分和切割维度。本节介绍了在过去几年中新建的Presto过滤和剪枝技术。
子字段剪枝：像映射、数组和结构体这样的复杂类型在现代数据仓库中被广泛使用。例如，机器学习工作负载通常会产生包含数千个嵌入特征的大型映射，这些特征存储表列中。复杂类型实例的字段，表示为𝜏，是𝜏中的嵌套元素。例如，如果𝜏是一个数组类型实例，则𝜏[2]表示𝜏的第二个子字段。需要有效地提取子字段，而不必读取整个复杂对象，以实现CPU效率。Presto通过向读取器发出复杂对象所需的索引或键来支持子字段剪枝。读取器将根据列格式（如ORC [38]或Parquet [39]）跳过未使用的子字段。在上述数组类型实例的示例中，只有𝜏[2]从磁盘中读取；𝜏的所有其他索引都被跳过。剪枝是递归的，以支持任意级别的嵌套。
过滤器重排序：除了子字段剪枝外，过滤器下推是一种常见的策略，通过在扫描时应用过器来减少扫描大小以便即使在查询计划中明确要求某些列或行，也不必将它们物化。在各种情况下，一些过滤器比其他过滤器更有效；它们在更少的CPU周期内删除更多的行。在运行时，Presto会自动重新排序过滤器，以便在评估较不具选择性的过滤器之前评估具有更高选择性的过滤器。在读取任何数据之前，过滤器中的每个函数都会初始化为（1）“CPU周期估计”，该估计基于函数的元数和输入类型计算，以及（2）固定的选择性。随着读取器开始扫描和过滤数据，每个函数的选择性都会被分析，并且CPU周期估会调整以反映实际的CPU周期。在运行时，过滤器中函数的顺序会根据其选择性和平均CPU周期的乘积动态重新排序。随着扫描期间数据的变化，选择性和CPU周期不断调整，以自适应地重新排序过滤器。
基于过滤器的延迟物化：在为一批行应用一组过滤器时，Presto跟踪已满足过滤器谓词的行。对于在该批次中未通过早期过滤器的行，没有必要评估甚至材料化需要其他过滤器的列的行。例如，如果我们要在列col1和col2上应用过滤器“col1>10 AND col2=5”，则扫描将首先针对col1中的所有行评估col1>10，这些行必须材料化。但是，只有在col2中通过col1>10的行需要材料化才能评估col2=5。这是大多数现代数据库中实现的一种技术。但是，在[44]中没有介绍它。生产中整体过滤改进的收益在第7节中详细介绍。
动态连接过滤：在Presto中，过滤器下推可以进一步增强以与“动态连接过滤”一起使用。对于内连接，构建侧可以提供以布隆过滤器、范围或不同值格式的“摘要”，作为探测侧的过滤器。可以将摘要通过上述框架作为额外的过滤器推送到扫描中，以便探测侧读取器不会材料化与连接键不匹配的数据。摘要的格式取决于构建侧的不同值数量，因此摘要的大小应该小而相对有效，但不应该“过度拟合”。
Materialized views and near real-time data
数据仓库通常以每小时或每天的方式以列格式编写表格数据。经过时间增量后，编写的数据变得不可变。历史上，Presto只能读取不可变数据。最近，我们扩展了能力，以读取注入到数据仓库中的正在进行的数据，以提供近实时（NRT）支持。在Meta，NRT支持可在数据创建后的几十秒内使用。
通过NRT支持，正在构建更多的NRT仪表板以反映更频繁的指标变化。Presto支持Meta大部分仪表板。用户很少针对原始数据构建仪表板，因为通常太大以提供低延迟体验。预计算表格是首选的，以提前减少基数。但是，这种方法不适用于NRT用例，因为数据是连续到来的。为了满足低延迟要求和数据新鲜度，Presto内置了材料化视图功能。
物化视图是由存储其结果的查询表示的视图。当Presto创建物化视图时，将创建一个自动作业来物化视图数据。只要基本表的某些单位（通常是小时或天）变得不可变，自动作业就会运行视图查询以物化视图数据。另一方面，连续到来的NRT数据在变得不可变之前不会被物化为视图。当用户查询物化视图时，Presto会确定哪些部分的视图已被物化，哪些部分没有。然后，Presto将查询分解为一个UNION ALL查询，以组合材料化数据以及来自基本表的非材料化新鲜数据。这使得查询可以提供新鲜度和低延迟，因为数据大小减小了。
物化视图的另一个用例是子查询优化。给定一个查询，Presto检索与查询表相关联的所有物化视图。Presto尝试匹配物化视图是否是接收到的子查询。如果有匹配项则接收到的查询将被重写以利用物化视图，而不是从基本表中获取数据。当前支持的查询模式仅允许扫描、过滤、投影和聚合。支持少量聚合函数，如SUM、MIN、MAX、AVG、COUNT等。
由于物化视图支持仅针对Meta的试点用户推出，没有普遍可用性，因此我们只展示早期用户的收益。图4说明了在Meta上最大的单表交互式工作负载中使用物化视图的改进。该表上的工作负载包括NRT表上的所有简单聚合查询，该表包含数百亿行，压缩大小为半PB。由于整个工作负载中最常用的常见子查询，为该表创建了五个物化视图。由于子查询优化是在引擎端自动发生的，因此没有用户端的更改。使用物化视图，CPU、扫描行和延迟在90th百分位上都有超过2倍的降低。
SCALABILITY IMPROVEMENTS
越来越多地利用Presto支持重型ETL作业。当进入运行时间数小时和PB级别扫描的领域时，原始的Presto架构将无法充分扩展。为了处理单点故障、工作器崩溃、数据偏斜和内存限制，Presto已经集成了各种改进和重新架构。
Multiple coordinators
协调器一直是Presto的单点故障。这对于长时间运行的查询尤其具有挑战性，在高峰期间协调器中可能排队数千个查询。协调器崩溃意味着所有查询都将失败。从可扩展性的角度来看，由于查询调度需要大量的内存和CPU，水平扩展协调器在更多查询并行运行时会达到极限。此外，Meta基础设施设计趋向于具有较小内存的容器，目前所有查询排队、查询调度和集群管理都无法使用较小内存实现。
Presto通过将查询和集群的生命周期分开来解决了这个问题。协调器仅控制查询的生命周期，而新引入的资源管理器负责集群的排队和资源利用监控。图5展示了多个协调器和多个资源管理器架构的拓扑结构，它们最初都驻留在单个协调器中。查询将首先发送到任意一个协调器。协调器彼此独立，没有相互通信。然后，查询将可选地发送到资源管理器进行排队。资源管理器具有高可用性。排队的查询和集群控制面板信息在所有实例中都进行了复制。使用Raft等共识协议来确保资源管理器崩溃不会导致任何排队查询的丢失。协调器定期从资源管理器获取排队信息，以决定要执行哪些查询。使用定期信息获取，如果协调器发现资源管理器中没有查询排队，或者队列中的查询优先级较低，它可以决定执行新提交的查询，以避免排队开销或网络跳转延迟。
引入多个协调器不仅消除了单点故障，还克服了弹性容量和Meta基础设施推动使用较小容器的问题。现在，协调器或资源管理器可以更频繁地被取消分配，而无需保留排队状态数小时。更多细节可以在我们的博客[17]中找到。
Recoverable grouped execution
Presto架构采用流式RPC Shuffle和内存数据处理进行了优化，以实现低延迟。然而当涉及到运行PB级别扫描或数小时运行时间的ETL查询时，它既不具备内存限制的可扩展性，也不具备确保没有工作器崩溃的可靠性。为了支持任意大的查询，我们开发了可恢复的分组执行。（更多细节可以在我们的博客[8]中找到）。
在仓库中数据通常是分区的。例如，数据可以按天着陆，因此“天”是自然分区。这也可以扩展到具有其他类型分区，如模块哈希或z-排序。具有相同分区键（由表列表示）的行属于同一分区。图6显示了哈希分区的示例，其中表在列col1上进行了分区，哈希函数mod（3）导致3个分区。
在Presto中，如果表扫描后的第一个聚合、连接或窗口函数键是数据分区键的超集，查询可以以“分组”方式执行。在这种情况下，引擎不会扫描整个数据集并基于聚合、连接或窗口函数键进行洗牌。它只会按分区逐个扫描，因为键在分区之间是不相交的。如果执行整个查询所需的内存超过了集群可以提供的内存，则优先选择分组执行以降低峰值内存消耗。继续使用图6中的示例，假设用户有一个查询“SELECT COUNT() from table1 GROUP BY col1”。正常扫描将并行读取所有3个分区，并基于聚合键col1进行洗牌。然后，聚合阶段将在内存中接收所有7个不同的值，然后发出最终聚合结果。相反，分组执行将逐个分区扫描。因为查询中的分区键col1与聚合键col1相同，所以它将首先扫描分区1中的所有内容，并在内存中仅构建具有3个不同值（1、4和7）的哈希表，并发出3个值的最终结果。然后，它将继续处理每个分区2和3的两个值。在这种情况下，峰值内存使用量将小于并行扫描所有内容。
分组执行可以扩展到第一个洗牌之外，或者当数据没有按聚合、连接或窗口函数键进行分区时。实现这一点的方法是通过注入一个洗牌阶段，以基于下游键以分区方式实现源数据。好处是允许分组执行适用于任意查询和任意源数据。缺点是中间数据实现的开销。
通过中间数据实现，我们进一步构建了对分组执行在洗牌点边界处的故障恢复支持。如果一个工作器崩溃，调度程序将直接从中间数据重新运行失败的执行，而不是从源数据重新运行。从架构的角度来看，还可以支持更细粒度的恢复，例如使用容错本地磁盘或分布式分解洗牌服务（例如Cosco [25]集成）。
图7显示了查询“SELECT COUNT() FROM table1 GROUP BY col1”的可恢复分组执行示例，其中table1包含数万亿个col1的不同值，无法适应整个集群的内存。为了克服内存限制，第一个洗牌将基于col1。写入器将持久化数据，而不是直接将洗牌键管道传输到COUNT聚合中。然后聚合阶段可以在洗牌数据上进行分组执行（显示为灰色框），以降低峰值内存消耗。每个分组执行都是可恢复的，因为col1上的中间数据已经持久化。
Presto on Spark
可恢复的分组执行使Presto能够通过支持故障恢复来克服内存限制。虽然故障恢复边界在洗牌点，但可能过于粗糙。有几个成熟的通用数据计算引擎具有内置的更细粒度的故障恢复机制。Spark [57]就是其中之一。Spark提供了弹性分布式数据集（RDD），它是跨集群节点分区的元素集合，可以并行操作。RDD可以自动从容器或任务故障中恢复。Presto on Spark是一种新的架构，它完全摆脱了现有的Presto集群拓扑结构，具有多租户性质。它利用Presto作为库，并在Spark RDD接口之上运行，以提供可扩展性和可靠性，而不需要额外的成本。
Presto on Spark架构使用Spark的调度程序、洗牌、资源管理和任务执行替换了Presto内置的这些功能，如图8所示。要启动Presto on Spark查询，Spark首先在其进程中作为库启动简化的Presto协调器，以解析和优化查询。然后，简化的协调器将发现所有必要的任务，并将它们与优化的物理计划一起编译成RDD任务，然后将其发送到Spark进行调度。RDD任务实例携带原始的Presto计划片段。一旦调度完成，RDD执行线程将在简化的Presto工作器上作为库运行，基于Presto计划片段。外部洗牌执行需要在工作器上实现，以利用外部洗牌服务。外部洗牌服务可以避免RPC洗牌在连接限制和故障边界方面的短缺。如果容器崩溃，Spark集群管理器将自动重试RDD线程。请注意，原始的Presto服务，如协调器和工作器，都作为库提供。这些库不相互通信，也不管理内存、线程或网络。所有这些方面都从库中删除，以简化并委托给Spark集群。
请注意，我们仅利用Spark及其RDD级别及以下。在这种情况下，不使用SparkSQL [6]，因为我们需要保证Presto的语言语法和语义一致性。在Meta，最初使用Presto和具有Meta内部语法变化2的SparkSQL来运行ETL作业。然而，两者之间的语言差异导致了高用户摩擦。Presto on Spark项目旨在统一堆栈，同时具有来自Presto的语言语义以及来自Spark的可扩展性和可靠性。
Presto on Spark和可恢复的分组执行都旨在解决可扩展性和可靠性挑战。可恢复的分组执行仍利用多租户模式，具有更多的内存和CPU灵活性。另一方面，Presto on Spark具有容器级别的隔离，可以提供更好的可扩展性和可靠性。在Meta生产中，由于弹性容量的不确定性，容器可能经常被排空以平衡高峰和低谷使用。因此，对于长时间运行的作业来说，可恢复性是处理离线容器的强需求。有关更多详细信息，请参阅我们的博客[54]。
从2022年初开始，Meta开始将所有SparkSQL工作负载迁移到Presto on Spark上，以统一SQL接口。在Presto的情况下，SparkSQL堆栈的解析器、分析器、优化器和操作执行层将完全被弃用。只有Spark RDD接口保留下来，因为它是Presto on Spark的一个重要组成部分。我们还在努力替换可恢复的分组执行，因为它不如Presto on Spark可扩展。有关更多学习内容，请参见第7节。
Spilling
尽管Presto有前两种可扩展选项来克服集群范围内的内存限制，但数据倾斜仍可能发生，导致单个工作器超出本地工作器内存限制。随着Meta朝着更小的内存大小容器迈进，这种情况变得尤为严重。Presto实现了溢出功能，将聚合、连接、窗口函数和topN操作的内存哈希表物化到磁盘上。采用应用程序级别的溢出而不是依赖操作系统将内存页面交换到磁盘上，有助于更精细地控制查询执行。在Meta中，交互式和即席工作负载将数据溢出到本地闪存以获得低延迟，而ETL工作负载将数据溢出到远程存储以获得可扩展性。
一旦在构建查询的哈希表时达到内存限制，每个哈希表将基于哈希键进行排序并序列化到磁盘上。然后，查询将继续处理，就好像哈希表为空一样。一旦哈希表再次增长到限制，相同的过程将重复，直到处理完所有数据。然后，对这些排序的哈希表进行外部合并，以限制在发出结果时的内存使用。请注意，内存哈希和溢出解决技术在工业界已经广为人知[22, 45]。
EFFICIENCY IMPROVEMENTS
除了延迟和可扩展性的改进外，效率对于查询性能也非常重要。本节介绍了我们为提高效率所做的几项改进。
Cost-Based Optimizer
优化器对于查询引擎至关重要。正确的计划可以充分利用集群中的资源。Presto具有基于成本的优化器，可以为CPU、IO和内存分配成本，以平衡这些因素并生成优的计划。具体而言，基于成本的优化用于做出以下决策：（1）选择连接类型，包括广播连接和重新分配连接；（2）连接重排序以最小化总体内存使用。希望充分利用内存，同时提供CPU效率，而不超过内存限制。但是，对于广播连接，它还可以提供更低的延迟和更少的CPU周期。因此，权衡是将内存使用最小化到限制以提供优化的CPU性能。过滤器重排序的用例不包含在基于成本的优化器中，因为它在运行时讨论，详见第3.3节。
为了做出正确的决策，需要外部信息来估算成本。在Meta中为了描述数据分布，为每个表分区存储统计信息；这里的分区是在第4.2节中定义的。所有写入仓库的数据的服务，包括Presto，都负责计算并发布分区统计信息到元数据存储中。这些统计信息会随着相应分区的删除而被删除。常见的统计信息包括直方图、总值计数、不同值计数、空值计数、最小值、最大值等。这些统计信息可以帮助估算过滤器选择性，以估算过滤器后输入表的基数。它还有助于估算连接表的大小以进行内存估算。在计划时间，基于成本的优化器将获取输入表的统计信息，并从计划的叶子到根填充成本估算，并相应地调整计划以生成最小成本。对于过滤器或连接选择性，应用简单的启发式方法来估算计划上部的数据基数和大小。
图9(a)展示了应用基于成本的优化后生产集群的ETL查询与连接查询的CPU减少情况。60%的这类查询计划发生了变化并减少了CPU使用率。柱状图展示了启用基于成本的优化的查询与禁用优化的相同查询集的CPU比率。大多数查询的CPU效率得到了改善（由比率≤1的区域表示）。虽然有些查询在启用基于成本的优化后使用了更多的CPU，但这并不一定意味着退步。对于那些CPU利用率增加的查询，其中83%的查询降低了内存使用率。
History-Based Optimizer
在大多数情况下，表统计信息可以为计划成本估算提供足够的信息。然而，估算可能会出错。此外，过滤器或连接选择性事先是未知的，因此随着查询中嵌入更多的过滤器，估算可能会越来越不精确。因此，Presto还支持基于历史的优化器。由于Presto在Meta的ETL作业中得到了广泛的利用，因此查询高度重复且可预测。基于历史的优化器的想法是利用先前完成的重复查询的精确执行统计信息来指导未来重复查询的计划。除了第5.1节中提到的两种连接策略外，基于历史的优化器还可以更细粒度地控制计划，包括（1）调整SuffleWrite大小和（2）部分或中间聚合消除。
当生成查询计划时，将应用第3.1节中提到的相同规范化方法到查询计划中。（请注意，第3.1节中的谓词修剪是在工作节点的文件级别上进行的。对于优化器，仅可用表级统计信息）。然后，计划的常量将被替换为符号。 "符号计划"将作为外部统计信息存储的键，其值将是查询完成后的实际执行统计信息。当安排具有相同结构但不同常量的查询时，成本估算将直接从具有相同符号计划的外部统计信息存储中获取。由于ETL查询仅在“日期”常量日复一日地更改，因此先前生成的符号计划提供的统计信息可以精确到最新的ETL处理。
图9(b)展示了与图9(a)类似的生产集群的ETL查询的CPU减少情况。我们比较启用基于历史的优化的查询与仅启用基于成本的优化的相同查询集。这些查询不仅限于连接查询，因为基于历史的优化也可以提高通用查询的性能。在与仅启用基于成本的优化的相同查询集进行比较时，25%的查询计划发生了变化，导致CPU使用率总体上提高了10%。
Adaptive execution
统计信息对于计划者做出决策非常有帮助。Presto的优化器力求使用数据统计信息在静态情况下选择最佳计划，正如前面的章节所讨论的那样。然而，不完整的统计信息、对数据的假设（如均匀性假设、缺乏关于数据相关性和偏斜的信息）以及复杂的查询（例如，复杂的函数或多路连接）会导致次优的计划。因此，需要自适应执行来在运行时动态调整查询计划，以便在计划不是最优的情况下进行调整。
自适应执行利用已完成的任务将统计信息报告回协调器，以便协调器可以使用它们来重新优化下游任务的计划。优化的类型是第5.2节中基于历史的优化器支持的类型的超集；自适应执行还为连接和聚合提供了偏斜处理。这主要是因为在运行时检测偏斜键不需要任何外部知识，因为许多元数据存储不具备提供表或列的偏斜值的适当支持。
为了利用运行时统计信息，调度程序会分阶段地从扫描任务一直到根任务调度任务。一旦上游任务完成，优化器将基于新收集的统计信息进行重新运行，并根据新计划调度下游任务。由于原始的Presto架构以流式方式洗牌数据，因此自适应执行仅适用于支持分阶段执行和分解洗牌的Presto on Spark模式。
ENABLING RICHER ANALYTICS
除了分析工作负载的延迟、可扩展性和效率改进之外，Meta公司越来越注重强调机器学习特征工程用例、增加对隐私要求的支持以及图形分析。本节讨论了对各种此类用例的支持。
Handling mutability
传统上，数据仓库只支持不可变数据。近年来，我们看到了可变数据支持和版本控制的趋势不断增长。例如 Delta Lake [5]、Apache Iceberg [28]和Apache Hudi [27]。Presto与所有这些表格格式集成。然而，它们对于Meta内部的用例来说并不足够。
在Meta中，可变性有两个主要用例：(1) 机器学习特征工程(2) 针对隐私的行级删除。对于(1)，特征工程是使用领域知识从原始数据中提取有用信息的过程，以特征的形式提供给机器学习算法使用。在Meta中，这些过程可以通过类似Presto的分析引擎或具有声明性语言（例如SQL）的流式引擎来完成，通过从原始数据生成特征。机器学习工程师将继续探索数据，以找到适合改进机器学习模型的合适特征。在为模型选择特征之前，候选特征将被记录并与主表关联。根据训练结果，候选特征可以合并到主表中或被删除。可能同时开发数百个探索性候选特征。主表模式的频繁更改并不理想。因此，需要一种更灵活的方式来变异列。对于(2)，Meta用户（包括Facebook、Instagram和WhatsApp）可以选择不收集其个人数据以进行内容推荐或其他用途。Meta需要有能力根据用户的定删除用户数据。仓库表格的规模达到EB级别。高频率地反复重写这些表格是不可行的。因此，需要一种可变的解决方案来处理这些不可变数据。
为了解决上述问题，Delta被集成到Presto中。Delta是Meta内部的一种解决方案，允许对表进行变异，具有添加或移动列或行的灵活性。Delta将一个或多个“delta文件”与单个主文件关联起来。Delta文件用作主文件的更改日志，指示主文件中添加或删除的新列或新行。主文件和Delta文件都与相同的逻辑行计数对齐，以从物理表示中恢复逻辑数据。当Presto读取主文件时，它将启动额外的读取器来合并这些Delta文件以反映更改。Delta文件的关联和顺序保留在具有版本控制的元数据存储中。Delta文件使仓库实现逻辑删除，以满足隐私要求。这些Delta文件定期压缩到主文件中，以避免读取开销。该过程确保所有相应的物理位都被删除。
在这种情况下，机器学习候选特征可以被建模为额外的Delta列，用户数据删除可以被建模为要删除的Delta行。添加新的候选特征或某些用户删除个人数据将导致新的Delta文件按顺序与主文件关联。请注意，由于个人数据删除活动经常发生，需要对这些行删除进行批处理，以避免创建过多的Delta文件。
对于列的添加或删除，Delta文件合并不会影响扫描性能，因为文件格式是列式的。然而，对于行删除，性能将受到影响。图10显示了在生产环境中读取时合并Delta文件时扫描CPU的性能影响。x轴显示删除的行数百分比，y轴表示与没有删除时的CPU成本相比的CPU成本。当只需要删除1%的行时，会产生额外的6%的CPU成本。然而，如果需要删除60%的行，则成本可能会显著增加到170%。
User-defined types
Presto允许用户定义类型以丰富语义。类型可以按继承关系定义在层次结构中。例如，可以基于Long类型定义ProfileId类型，其中UserId和PageId类型是其子类型。用户定义的类型定义存储在远程元数据存储中。除了存储类型定义本身之外，还可以将额外信息与用户定义的类型关联起来。例如，通过SQL表达式表示的约束条件。这允许在运行时进行数据质量检查。例如，不希望UserId是负整数或超过一定长度。另一个例子是策略规范，它涉及到隐私日益增长的要求。近年来，用户数据保护、匿名化和删除方面有共同的要求。为了实现这个目标，先决条件是识别仓库中的用户数据。用户定义的类型允许业务领域专家对其数据进行建模，以反映表中的用户数据，并将隐私策略与其关联。例如，表所有者可以定义一个Email类型，应在着陆时立即进行匿名化，并在7天后删除。仓库可以在后台应用这些策略以符合隐私要求。
User-defined functions
用户定义函数（UDF）允许将自定义逻辑嵌入SQL中。在Presto中，有多种支持UDF的方式。
进程内UDF：基本支持是进程内UDF。函数以库的形式编写和发布。Presto在运行时加载库，并在与主评估引擎相同的进程中执行它们。这种模式可以高效，因为没有上下文切换。然而，它仅由Presto on Spark支持，因为函数库含任意代码，不适合在多租户模式下运行。
UDF服务：为了支持多租户模式或不同的编程语言中的UDF，Presto构建了UDF服务器。函数通过来自Presto集群的RPC在远程服务器上调用。UDF服务器经常更新函数（每几分钟到几小时），因此函数发布速度比Presto引擎快得多。因为表达式可以包含本地可执行函数和远程UDF，所以在编译时，表达式将被分解为本地可执行和远程可执行，具有不同的投影阶段。本地可执行表达式编译成字节码以进行快速执行；而远程可执行表达式在UDF服务器上执行。
SQL函数：虽然UDF提供了灵活性，但出于审计和隐私目的，查询应该能够在没有执行黑匣子的情况下“推理”出来。为了在表达性和可推理性之间取得平衡，引入了SQL函数。当函数逻辑可以用SQL表示时，我们允许用户定义SQL函数，通过避免编写冗长且难以阅读的SQL语句来简化查询逻辑。SQL函数是具有明确定义的输入和输出类型的SQL代码片段。SQL函数定义也存储在远程元数据存储中。SQL函数将在执行期间自动编译并可选地进行内联。有关SQL函数如何工作的详细分解已在我们的博客[50]上发布。
Graph extensions
在Meta中，图形数据集在多个用例中自然产生，从社交网络到表示数据如何通过系统流动的谱系图。虽然用户已经利用了专门的图形查询系统，如图形数据库[2、9、35、48]和图形分析引擎[15、19、56]，但我们可以利用Presto处理许多这样的工作负载，从而使我们能够在Presto之上整合这些专门的引擎。这种整合带来了多种好处，例如为用户提供一个共同的前端，并允许我们在共享基础设施上运行图形工作负载。
在Presto上支持图工作负载具有两个主要挑战。首先，使用普通SQL表达图形查询意味着通过连接执行图形遍历，这是不直观、容易出错且通常由于复杂性而不切实际的。其次，图形遍历查询具有迭代和有状态的特性（例如，下一个要访问的顶点取决于已经访问的顶点），通常导致具有许多大型连接的查询，这挑战了Presto优化执行和扩展到大型图形的能力。
为了解决这些挑战，我们扩展了Presto SQL，引入了图形查询语言结构，受现有图形查询语言[21、26、31、51]的启发。这些语言结构通过提供熟悉的声明性接口，使更多的人能够进行图形查询，而不是让用户学习特定于图形的编程框架。此外，我们构建了一个图形查询计划器，结合了图形特定的优化，以高效地在Presto运行时执行迭代查询。
在列表1中的示例查询涵盖了我们已经纳入语言中的一些特性。首先，FROM GRAPH子句不引用表，而是引用“图形”。这是我们在Meta仓库中引入的新元数据工件，其中包含从图形的模式（顶点或边缘类型以及其属性的名称和类型）到存储图形的底层表的映射。我们省略了关于用户如何指定和存储图形工件的细节，因为这超出了本文的范围。
在大多数情况下，对图形工件的查询旨在计算图形中的一组路径。我们使用MATCH语法来指定一个可视化模式，为我们想要查询的路径提供一个模板。括号，如“(src:Vertex)”用于指定顶点，“->”带有标签的箭头，如“/:Edge/”用于指定边缘及其方向。上面的示例计算从顶点src到顶点dst的路径，路径长度至少为1且最多为5。图形查询的输出是一个表，其中每行是一个路径。WHERE子句继承了标准SQL谓词语义，用于过滤计算出的路径。我们使用图形特定的函数，以及现有的Presto函数，使用表达式“all_match(edges(path), e -> e.property = TRUE)”引用路径数组上的复杂谓词。在同一个示例中，SELECT子句中的vertices(path)返回一个数组，其中包含路径中按顺序找到的所有顶点对象。
这些语言扩展所提供的高级表达能力为图形特定的优化提供了机会。在底层，图形查询被解析为一个特殊的图形逻辑计划，然后利用图形查询的语义进行优化。最终，优化后的图形逻辑计划被转换为关系计划，就像处理任何Presto查询一样执行。下面，我们描述其中的一些优化。
多步执行：像列表1中的查询的朴素实现会将其转换为一个关系查询，其中包含与路径的最大长度相同数量的连接。这样的查询可能会达到Presto的内存限制，特别是当需要计算太多路径时。为了解决这个问题，我们实现了一种优化，将图形查询计划转换为一系列较小的Presto查询计划。每个较小的查询计划计算路径的长度，将其存储到一个临时中间表中，然后用于继续扩展路径。这使得每个迭代都在内存限制内。
高效的路径扩展：再次考虑列表1，朴素的计划会计算长度为1、2等的路径，并对它们进行UNION ALL。这会导致冗余计算。计算长度为𝑁的路径需要与计算长度为𝑁−1的路径相同的工作量，再加上将其扩展为长度为𝑁的路径的工作量。然而，对于这种计划，Presto优化器通常无法以一般的方式消除冗余工作。相反，在我们生成的查询计划中，一旦我们计算出长度为𝑁−1的路径，我们会生成每个路径的两个副本。然后，我们将其中一个副本扩展到长度为𝑁的路径，保留另一个副本，有效地重用计算。
高效的子图计算：给定一组顶点𝑉，我们将子图定义为仅由从𝑉中任何一个顶点可达的边组成的图形的子集。计算路径与计算子图具有不同的要求。例如，在计算子图时，无需跟踪路径并通过连接边缘表来扩展它们。我们只需要跟踪已访问的边缘。这使得子图计算计划可以从存储中一次扫描边缘表，然后通过标记可以扩展的边缘来操作它，从而最小化IO。
复杂的过滤器下推：用户可以使用诸如all_match之类的函数在路径上指定过滤器，从而允许指定适用于输入路径的所有元素的任意谓词。例如，列表1仅查询所有边缘属性为TRUE的路径。当前的通用Presto优化器难以推动这种谓词下推。相反，图形语义信息使我们能够在每个连接之后直接将这些过滤器下推，每个连接都计算下一个跳跃，从而最小化计算的中间路径数量。
我们通过基准测试展示了在Presto上运行图形工作负载的实用性和率。我们将Presto与Apache Giraph [15]进行比较，后者是Meta专门设计用于批量图形分析工作负载的引擎。请注意，部分Giraph功能也正在因这些Presto图形扩展而被弃用。图11展示了两个引擎在CPU比率方面在Presto上运行的效率。我们执行了4个图形查询，以说明使用Presto的CPU收益。查询Q1-3计算从特定顶点开始的一组路径。顶点的连通性很高，导致路径数量呈指数增长。Q1计算所有路径，最多10个跳，Q2最多15个跳，Q3最多20个跳。总共，在20个跳之后，我们计算了12亿条路径。其中大部分路径在第10到16个跳之间找到。Q4是一个查询，计算一个“子图”（给定顶点下游可达的边缘集）在一个更大的图形上。关于观察到的性能，Giraph允许在每个算法的实现中进行高度可定制化，这可能是一把双刃剑。尽管它可以实现高水平的特定于作业的优化，这也使其更容易受到由自定义代码引入的低效率的影响。另一方面，Presto具有声明性SQL接口，以交换表达能力与始终使用高度优化的每个运算符（扫描、连接、聚合等）的实现。这些声明性图形构造使用户能够表达图形分析逻辑，我们可以透明地将其转换为执行它们所需的SQL。
PERFORMANCE IN PRODUCTION
本节展示了在本文引入的迭代开发过程中，Meta生产工作负载的性能和经验教训。[12]提供了Meta规模的大致概念。鉴于我们不能披露详细的数字，我们展示了这篇论文的努力使我们克服了过去几年数据量的超级增长的程度。
Interactive and ad-hoc workload scalability
即使数据量增加，Presto的剪枝、过滤和缓存使得延迟保持一致，提供了相同的用户体验，年复一年。图12展示了过去3年中P75（第75个百分位数）和P90交互式和自适应工作负载的延迟以及数据增长。红色和黄色系列分别是过去3年相对稳定的P75和P90延迟。然而，如果我们以2019年中期的数据扫描量为基准，扫描的数据量在3年内增长了近600%，导致增长了5倍。在同一时期内，交互式集群群集中添加的核心数量仅增加了82%。请注意，图13展示了交互式和自适应工作负载混合的延迟；一般来说，自适应工作负载的延迟比交互式工作负载更高，更波动，这是由于它们的探索性质。
Interactive workload latency
在本节中，我们比较了Meta的交互式作负载。这种工作负载的整个集群已经完全迁移到了[44]中讨论的原始Presto架构之外。在新架构的背景下，任何内存中或磁盘上的存储连接器也已被弃用。
为了说明尽管完全弃用了原始架构和连接器的情况下的改进，我们手动设置了与生产环境相同的核心、线程和内存的集群，以模拟生产流量。我们比较的四个设置是：（1）[44]中的原始架构与分离的存储，（2）在（1）之上讨论的缓存改进，（3）在（2）之上讨论的自适应过滤改进，以及（4）在（3）之上讨论的本地矢量化执行集成。
图13展示了四个设置与Meta生产工作负在P75（第75个百分位数）、P90和P95上的延迟比较。Y轴是延迟时间（秒）。总的来说，在执行延迟的所有百分位数上，缓存相对于原始架构提供了约60%的改进。自适应过滤又增加了10-20%。另一个超过50%的主要改进来自本地矢量化执行。
ETL workload scalability
在本节中，我们比较了Meta的交互式作负载。这种工作负载的整个集群已经完全迁移到了[44]中讨论的原始Presto架构之外。在新架构的背景下，任何内存中或磁盘上的存储连接器也已被弃用。
为了说明尽管完全弃用了原始架构和连接器的情况下的改进，我们手动设置了与生产环境相同的核心、线程和内存的集群，以模拟生产流量。我们比较的四个设置是：（1）[44]中的原始架构与分离的存储，（2）在（1）之上讨论的缓存改进，（3）在（2）之上讨论的自适应过滤改进，以及（4）在（3）之上讨论的本地矢量化执行集成。
图13展示了四个设置与Meta生产工作负在P75（第75个百分位数）、P90和P95上的延迟比较。Y轴是延迟时间（秒）。总的来说，在执行延迟的所有百分位数上，缓存相对于原始架构提供了约60%的改进。自适应过滤又增加了10-20%。另一个超过50%的主要改进来自本地矢量化执行。
与第7.1节讨论的情况类似，图14展示了过去3年ETL工作负载的数据扫描占用情况。我们还以2019年中期的数据扫描量为基准。扫描的数据量增长了450%，导致增长了3.5倍。该图还显示了2020年中期可恢复分组执行的推出以及2021年中期Presto on Spark的推出。推出后，这两个新架构开始迅速增长，以处理更重的工作负载。正如第4节所述，我们最初开发可恢复分组执行作为支持大规模ETL查询的手段。然而，我们发现这种方法并不像我们希望的那样可扩展，主要是由于它强调减少内存消耗以及其对工作进程崩溃的容错性不足。因此，随着Presto on Spark的推出，我们已经看到可恢复分组执行的使用量下降，如图14所示。用户已经迅速迁移到Presto on Spark，促使我们开始弃用可恢复分组执行的过程。
RELATED WORK
云提供商广泛提供交互式和自适应分析引擎。代表性的包括由Dremel [33, 34]提供支持的BigQuery、Snowflake [18]和Redshift [7]。各种内部引擎包括Procella [13]和F1 [43]。这些系统中也使用了类似的技术，如分离存储和缓存。
关于分析SQL批处理引擎，SparkSQL [6]是一个流行的开源引擎，支持长时间运行的ETL作业。作为SQL评估引擎，SparkSQL是建立在通用计算引擎Spark [57]之上的。本文中的Presto直接从SQL评估引擎开始，并逐渐在Spark之上演变出容错支持。F1 [43]是另一个利用交互式引擎作为库并在MapReduce框架 [20]上运行以支持容错的例子。
矢量化引擎是提高查询性能的行业趋势。值得注意的是DuckDB [42]、Photon [10]、ClickHouse [16]和阿里巴巴的Hologres [30]。
各种开源解决方案都支持可变性、版本控制和时间旅行，包括Delta Lake [5]、Iceberg [28]和Hudi [27]。Presto与所有这些表格格式都有集成，但仍然仅依赖于Meta的解决方案“delta”来支持更灵活的数据变异。
Giraph [15]是一个开源解决方案，用于进行图形分析。它的部分功能已被替换并迁移到了Presto图形扩展中。GraphX [56]和GraphFrames [19]是建立在Spark [57]之上的替代开源解决方案。
多年来，图形查询语言语法解决方案已经有许多迭代，其中一个流行的是Neo4j [35]使用的Cypher [26]。PGQL [51]是Oracle对这种语法的愿景，而GCORE [3]试图形式化围绕构建属性图查询语言的核心概念。TigerGraph [48]是另一种使用不同语法开发的语言。已经在为属性图查询语言制定ISO标准的GQL [31]上取得了进展，就像SQL是一个标准一样。最近，提出了SQL/PGQ [21]，最终将合并到GQL中，所有这些都仍在积极开发中。Gremlin [49]是一种用于查询图形的API，遵循更多的数据流结构，并与声明性的类SQL语言不同。
FUTURE WORK
本文中提到的技术是我们处理更复杂工作负载的初步探索。第4.2节中的可恢复分组执行就是我们早期探索的一个例子，后来被更通用的解决方案（第4.3节中的Presto on Spark）所取代。以下是一些剩余挑战和我们最近尝试的工程解决方案的列表。
非SQL API：第6.4节中的GraphSQL仅适用于与图形相关的用例的SQL扩展。我们正在探索一种通用的非SQL API，类似于Snowpark [4]或PySpark [23]中的Python API，以允许在协调器上执行控制流，并在工作进程上使用类SQL语义的数据流。新的非SQL API旨在提供类似过程式编程的编程体验，具有更丰富的语义，可以覆盖图形处理。
分布式缓存：第3.1节中的缓存策略依赖于机器具有本地闪存。在Meta，这是一个强假设，因为计算机器大多没有磁盘。我们正在探索一种直接嵌入到Meta分布式文件系统中的远程闪存缓存策略。在这样的设计中，缓存责任可以隐藏在Presto之外。它还为使用分布式缓存的其他服务提供了机会，超出了数据仓库的范围。
统一容器调度：Presto on Spark依赖于调度程序来分配容器进行隔离。当前的调度程序类似于开源的Yarn [52]。此外，Meta的流引擎也依赖于自己的调度程序 [32]。这些调度程序与Meta的容器解决方案Tupperware [46]类似于Kubernetes [11]具有重叠的功能。我们目前正在使用Tupperware原型设计一个轻量级模型，以支持快速和频繁的容器分配。新的架构旨在整合Presto on Spark、流引擎和其他通用集群管理的调度策略。
统一UDF：第6.3节中的UDF仅支持Presto。它们不能被用于像训练或推理这样的机器学习服务。这导致用户为了相同的目的编写多个版本的UDF，并部署到不同的服务中。机器学习服务和Presto正在迁移到第3.2节中提到的Velox执行库。我们正在扩展UDF提供，以便函数只需要编写一次。这将进一步解决Meta中各种UDF编写平台的碎片化问题。
更多隐私政策挑战：除了第6.1节讨论的数据变异之外，我们还面临着其他与隐私相关的挑战。一个主要的挑战是查询重写，它允许用户从仓库中获取数据的洞察力，而不会暴露敏感数据。例如，允许显示Facebook用户年龄的近似分布；然而，不允许显示确切的分布或不说个别用户的年龄。这通常被称为差分隐私 [24]。不幸的是，像[53]中提到的实现差分隐私的各种查询重写技术可能会生成过于复杂的SQL，导致更高的CPU或内存使用率。在Meta进行了几次探索，但没有成功的推出。另一个主要挑战是谱系。为了了解敏感数据的使用情况，需要一个完美的谱系图来跟踪敏感数据如何流入仓库以及如何使用。然而，定制的UDF、复杂的SQL逻辑或从仓库中下载数据可能会使跟踪变得困难。今天，我们依赖用户告诉谱系服务数据的使用和流动方式，这是容易出错的。
CONCLUSIONS
Presto已经继续发展，以更好地处理快速增长的数据量，提高交互式工作负载的延迟和ETL工作负载的可扩展性。为了改进这两个方面，进行了各种演变。支持低延迟和长时间运行的查询的设计原则考虑了未来的数据增长，而不是进行增量改进。包括缓存策略、矢量化执行或在类MapReduce框架上编译执行库等各种技术在行业中都是众所周知的。然而，据我们所知，这是第一次一家公司可以通过实施这些技术并在Meta规模上开源它们，以供社区使用，并展示它们的具体影响。通过这些努力，我们已成功通过在Presto上集中传统的ETL工作负载（之前由SparkSQL处理）、即席分析（之前由Presto处理）、交互式服务（之前由Raptor或Cubrick处理）和图形处理（之前由Giraph处理）来巩固我们的数据仓库设计。这消除了多个查询引擎的需求，并简化了我们的数据仓库设计。任何新的要求（例如，安全或隐私要求）来到数据仓库都不需要在以前分散的引擎中实现。未来，Presto的单个更改将涵盖所有入口点。
ACKNOWLEDGMENTS
We would like to thank Jim Apple, Philip Bell, Leiqing Cai, Naveen Cherukuri, Steve Chuck, Serge Druzkin, Victoria Dudin, Ge Gao, Shrinidhi Joshi, Konstantinos Karanasos, Shaloo Kshetrapal, Jiexi Lin, Eric Liu, Lin Liu, Ryan Lim, Mengdi Lin, Ruslan Mardugal- liamov, Guy Moore, Sara Narayan, Daniel Ohayon, Sourav Pal, Pedro Eugenio Rocha Pedreira, Harsha Rastogi, Michael Shang, Chandrashekhar Kumar Singh, Ying Su, Ariel Weisberg, Zhan Yuan, and many others who are or used to work at Meta for their con- tributions to this paper and Presto. We are very grateful for the contributions from the Presto open-source community. These engi- neering accomplishments would not have been possible without contributions from Ahana, Alluxio, Uber, Twitter, and many others.
REFERENCES
[1] RaptorX: Building a 10X Faster Presto. 2021. https://prestodb.io/blog/2021/02/04/ raptorx.
[2] Oracle Labs PGX: Parallel Graph AnalytiX. 2022. https://www.oracle.com/ middleware/technologies/parallel- graph- analytix.html.
[3] Renzo Angles, Marcelo Arenas, Pablo Barceló, Peter Boncz, George Fletcher, Claudio Gutierrez, Tobias Lindaaker, Marcus Paradies, Stefan Plantikow, Juan Sequeda, et al. 2018. G-CORE: A core for future graph query languages. In Proceedings of the 2018 International Conference on Management of Data. 1421– 1432.
[4] Snowpark API. 2022. https://docs.snowflake.com/en/developer-guide/snowpark/ index.html.
[5] Michael Armbrust, Tathagata Das, Sameer Paranjpye, Reynold Xin, Shixiong Zhu, Ali Ghodsi, Burak Yavuz, Mukul Murthy, Joseph Torres, Liwen Sun, Peter A. Boncz, Mostafa Mokhtar, Herman Van Hovell, Adrian Ionescu, Alicja Luszczak, Michal Switakowski, Takuya Ueshin, Xiao Li, Michal Szafranski, Pieter Senster, and Matei Zaharia. 2020. Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores. Proc. VLDB Endow. 13, 12 (2020), 3411–3424.
[6] MichaelArmbrust,ReynoldS.Xin,ChengLian,YinHuai,DaviesLiu,JosephK. Bradley, Xiangrui Meng, Tomer Kaftan, Michael J. Franklin, Ali Ghodsi, and Matei Zaharia. 2015. Spark SQL: Relational Data Processing in Spark. In Proceed- ings of the 2015 ACM SIGMOD International Conference on Management of Data, Melbourne, Victoria, Australia. 1383–1394.
[7] Nikos Armenatzoglou, Sanuj Basu, Naga Bhanoori, Mengchu Cai, Naresh Chainani, Kiran Chinta, Venkatraman Govindaraju, Todd J. Green, Monish Gupta, Sebastian Hillig, Eric Hotinger, Yan Leshinksy, Jintian Liang, Michael McCreedy, Fabian Nagel, Ippokratis Pandis, Panos Parchas, Rahul Pathak, Orestis Polychro- niou, Foyzur Rahman, Gaurav Saxena, Gokul Soundararajan, Sriram Subrama- nian, and Doug Terry. 2022. Amazon Redshift Re-invented. In SIGMOD ’22: International Conference on Management of Data. ACM, 2205–2217.
[8] Presto Unlimited: MPP SQL Engine at Scale. 2019. https://prestodb.io/blog/2019/ 08/05/presto- unlimited- mpp- database- at- scale.
[9] BradleyRBebee,DanielChoi,AnkitGupta,AndiGutmans,AnkeshKhandelwal, Yigit Kiran, Sainath Mallidi, Bruce McGaughy, Mike Personick, Karthik Rajan, et al. 2018. Amazon Neptune: Graph Data Management in the Cloud.. In ISWC (P&D/Industry/BlueSky).
[10] AlexanderBehm,ShoumikPalkar,UtkarshAgarwal,TimothyArmstrong,David Cashman, Ankur Dave, Todd Greenstein, Shant Hovsepian, Ryan Johnson, Arvind Sai Krishnan, Paul Leventis, Ala Luszczak, Prashanth Menon, Mostafa Mokhtar, Gene Pang, Sameer Paranjpye, Greg Rahn, Bart Samwel, Tom van Bussel, Herman Van Hovell, Maryann Xue, Reynold Xin, and Matei Zaharia. 2022. Photon: A Fast Query Engine for Lakehouse Systems. In SIGMOD ’22: International Conference on Management of Data. ACM, 2326–2339.
[11] Brendan Burns, Brian Grant, David Oppenheimer, Eric A. Brewer, and John Wilkes. 2016. Borg, Omega, and Kubernetes. Commun. ACM 59, 5 (2016), 50–57.
[12] Meta Data Centers. 2022. https://datacenters.fb.com/.
[13] Biswapesh Chattopadhyay, Priyam Dutta, Weiran Liu, Ott Tinn, Andrew Mc-Cormick, Aniket Mokashi, Paul Harvey, Hector Gonzalez, David Lomax, Sagar Mittal, Roee Ebenstein, Nikita Mikhaylin, Hung-Ching Lee, Xiaoyan Zhao, Tony Xu, Luis Perez, Farhad Shahmohammadi, Tran Bui, Neil Mckay, Selcuk Aya, Vera Lychagina, and Brett Elliott. 2019. Procella: Unifying serving and analytical data at YouTube. Proc. VLDB Endow. 12, 12 (2019), 2022–2034.
[14] BiswapeshChattopadhyay,PedroEugenioRochaPedreira,SundaramNarayanan, Sameer Agarwal, Yutian Sun, Peng Li, Suketu Vakharia, and Weiran Liu. 2023. Shared Foundations: Modernizing Meta’s Data Lakehouse. In 13th Conference on Innovative Data Systems Research, CIDR.
[15] AveryChing,SergeyEdunov,MajaKabiljo,DionysiosLogothetis,andSambavi Muthukrishnan. 2015. One Trillion Edges: Graph Processing at Facebook-Scale. Proc. VLDB Endow. 8, 12 (2015), 1804–1815.
[16] ClickHouse. 2016. https://clickhouse.com/.
[17] Disaggregated Coordinator. 2022. https://prestodb.io/blog/2022/04/15/ disggregated- coordinator. [18] Benoît Dageville, Thierry Cruanes, Marcin Zukowski, Vadim Antonov, Artin
Avanes, Jon Bock, Jonathan Claybaugh, Daniel Engovatov, Martin Hentschel, Jiansheng Huang, Allison W. Lee, Ashish Motivala, Abdul Q. Munir, Steven Pelley, Peter Povinec, Greg Rahn, Spyridon Triantafyllis, and Philipp Unterbrunner. 2016. The Snowflake Elastic Data Warehouse. In Proceedings of the 2016 International Conference on Management of Data, SIGMOD Conference 2016. ACM, 215–226.
[19] AnkurDave,AlekhJindal,LiErranLi,ReynoldXin,JosephGonzalez,andMatei Zaharia. 2016. GraphFrames: an integrated API for mixing graph and relational queries. In Proceedings of the Fourth International Workshop on Graph Data Man- agement Experiences and Systems, Redwood Shores, CA, USA, June 24 - 24, 2016, Peter A. Boncz and Josep Lluís Larriba-Pey (Eds.). ACM, 2.
[20] Jeffrey Dean and Sanjay Ghemawat. 2004. MapReduce: Simplified Data Pro- cessing on Large Clusters. In 6th Symposium on Operating System Design and Implementation (OSDI 2004). 137–150.
[21] Alin Deutsch, Nadime Francis, Alastair Green, Keith Hare, Bei Li, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Wim Martens, Jan Michels, et al. 2022. Graph pattern matching in gql and sql/pgq. In Proceedings of the 2022 International Conference on Management of Data. 2246–2258.
[22] David J. DeWitt, Randy H. Katz, Frank Olken, Leonard D. Shapiro, Michael Stonebraker, and David A. Wood. 1984. Implementation Techniques for Main Memory Database Systems. In SIGMOD’84, Proceedings of Annual Meeting, Boston, Massachusetts, USA, June 18-21, 1984. ACM Press, 1–8.
[23] Tomasz Drabas and Denny Lee. 2017. Learning PySpark. Packt Publishing Ltd. [24]CynthiaDwork.2006.Differentialprivacy.InAutomata,LanguagesandProgram- ming: 33rd International Colloquium, ICALP 2006, Venice, Italy, July 10-14, 2006, Proceedings, Part II 33. Springer, 1–12. [25] Cosco: An efficient facebook-scale shuffle service. 2020. https://databricks.com/
session/cosco- an- efficient- facebook- scale- shuffle- service. [26] Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Stefan Plantikow, Mats Rydberg, Petra Selmer, and Andrés Taylor. 2018. Cypher: An evolving query language for property graphs. In Proceedings of the 2018 International Conference on Management of Data. 1433– 1445.
[27] Apache Hudi. 2017. https://hudi.apache.org. [28] Apache Iceberg. 2018. https://iceberg.apache.org. [29] Avoid Data Silos in Presto in Meta: the journey from Raptor to RaptorX. 2022.https://prestodb.io/blog/2022/01/28/avoid- data- silos- in- presto- in- meta. [30] Xiaowei Jiang, Yuejun Hu, Yu Xiang, Guangran Jiang, Xiaojun Jin, Chen Xia, Weihua Jiang, Jun Yu, Haitao Wang, Yuan Jiang, Jihong Ma, Li Su, and Kai Zeng. 2020. Alibaba Hologres: A Cloud-Native Service for Hybrid Serving/Analytical Processing. Proc. VLDB Endow. 13, 12 (2020), 3272–3284. [31] GQL: One Property Query Language. 2022. https://gql.today/. [32] Yuan Mei, Luwei Cheng, Vanish Talwar, Michael Y. Levin, Gabriela Jacques-
Silva, Nikhil Simha, Anirban Banerjee, Brian Smith, Tim Williamson, Serhat Yilmaz, Weitao Chen, and Guoqiang Jerry Chen. 2020. Turbine: Facebook’s Service Management Platform for Stream Processing. In 36th IEEE International Conference on Data Engineering, ICDE 2020, Dallas, TX, USA, April 20-24, 2020. IEEE, 1591–1602.
[33] Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shiv- akumar, Matt Tolton, and Theo Vassilakis. 2010. Dremel: Interactive Analysis of Web-Scale Datasets. Proc. VLDB Endow. 3, 1 (2010), 330–339.
[34] Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shiv- akumar, Matt Tolton, Theo Vassilakis, Hossein Ahmadi, Dan Delorey, Slava Min, Mosha Pasumansky, and Jeff Shute. 2020. Dremel: A Decade of Interactive SQL Analysis at Web Scale. Proc. VLDB Endow. 13, 12 (2020), 3461–3472.
[35] Neo4j. 2022. https://neo4j.com/. [36] Diego Ongaro and John K. Ousterhout. 2014. In Search of an Understandable Consensus Algorithm. In 2014 USENIX Annual Technical Conference, USENIX ATC ’14. 305–319. [37] Common Sub-Expression optimization. 2021. https://prestodb.io/blog/2021/11/22/common- sub- expression- optimization. [38] Apache ORC. 2013. https://orc.apache.org/. [39] Apache Parquet. 2013. https://parquet.apache.org/. [40] Pedro Pedreira, Chris Croswhite, and Luis Carlos Erpen De Bona. 2016. Cubrick: Indexing Millions of Records per Second for Interactive Analytics. Proc. VLDB Endow. 9, 13 (2016), 1305–1316. [41] Pedro Pedreira, Orri Erling, Maria Basmanova, Kevin Wilfong, Laith S. Sakka, Krishna Pai, Wei He, and Biswapesh Chattopadhyay. 2022. Velox: Meta’s Unified Execution Engine. Proc. VLDB Endow. 15, 12, 3372–3384. [42] MarkRaasveldtandHannesMühleisen.2019.DuckDB:anEmbeddableAnalytical Database. In Proceedings of the 2019 International Conference on Management of Data, SIGMOD Conference. ACM, 1981–1984. [43] BartSamwel,JohnCieslewicz,BenHandy,JasonGovig,PetrosVenetis,Chanjun
Yang, Keith Peters, Jeff Shute, Daniel Tenedorio, Himani Apte, Felix Weigel, David Wilhite, Jiacheng Yang, Jun Xu, Jiexing Li, Zhan Yuan, Craig Chasseur, Qiang Zeng, Ian Rae, Anurag Biyani, Andrew Harn, Yang Xia, Andrey Gubichev, Amr El-Helw, Orri Erling, Zhepeng Yan, Mohan Yang, Yiqun Wei, Thanh Do, Colin Zheng, Goetz Graefe, Somayeh Sardashti, Ahmed M. Aly, Divy Agrawal, Ashish Gupta, and Shivakumar Venkataraman. 2018. F1 Query: Declarative Querying at Scale. Proc. VLDB Endow. 11, 12 (2018), 1835–1848.
[44] Raghav Sethi, Martin Traverso, Dain Sundstrom, David Phillips, Wenlei Xie, Yutian Sun, Nezih Yegitbasi, Haozhun Jin, Eric Hwang, Nileema Shingte, and Christopher Berner. 2019. Presto: SQL on Everything. In 35th IEEE International Conference on Data Engineering, ICDE. IEEE, 1802–1813.
[45] Leonard D. Shapiro. 1986. Join Processing in Database Systems with Large Main Memories. ACM Trans. Database Syst. 11, 3 (1986), 239–264.
[46] Chunqiang Tang, Kenny Yu, Kaushik Veeraraghavan, Jonathan Kaldor, Scott Michelson, Thawan Kooburat, Aravind Anbudurai, Matthew Clark, Kabir Gogia, Long Cheng, Ben Christensen, Alex Gartrell, Maxim Khutornenko, Sachin Kulka- rni, Marcin Pawlowski, Tuomas Pelkonen, Andre Rodrigues, Rounak Tibrewal, Vaishnavi Venkatesan, and Peter Zhang. 2020. Twine: A Unified Cluster Manage- ment System for Shared Infrastructure. In 14th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2020, Virtual Event, November 4-6, 2020.
[47] Ashish Thusoo, Joydeep Sen Sarma, Namit Jain, Zheng Shao, Prasad Chakka, NingZhang, Suresh Anthony, Hao Liu, and Raghotham Murthy. 2010. Hive - a petabyte scale data warehouse using Hadoop. In Proceedings of the 26th International Conference on Data Engineering, ICDE. 996–1005.
[48] TigerGraph. 2022. https://www.tigergraph.com/.
[49] Apache Tinkerpop. 2022. https://tinkerpop.apache.org/.
[50] Tutorial: How to Define SQL Functions With Presto Across All Connectors.2021. https://dzone.com/articles/tutorial- how- to- define- sql- functions- with-presto- a.
[51] Oskar van Rest, Sungpack Hong, Jinha Kim, Xuming Meng, and Hassan Chafi.2016. PGQL: a property graph query language. In Proceedings of the Fourth International Workshop on Graph Data Management Experiences and Systems. 1–6.
[52] Vinod Kumar Vavilapalli, Arun C. Murthy, Chris Douglas, Sharad Agarwal, Ma- hadev Konar, Robert Evans, Thomas Graves, Jason Lowe, Hitesh Shah, Siddharth Seth, Bikas Saha, Carlo Curino, Owen O’Malley, Sanjay Radia, Benjamin Reed,and Eric Baldeschwieler. 2013. Apache Hadoop YARN: yet another resource negotiator. In ACM Symposium on Cloud Computing, SOCC ’13, Santa Clara, CA, USA, October 1-3, 2013, Guy M. Lohman (Ed.). ACM, 5:1–5:16.
[53] Royce J Wilson, Celia Yuxin Zhang, William Lam, Damien Desfontaines, Daniel Simmons-Marengo, and Bryant Gipson. 2020. Differentially private SQL with bounded user contribution. Proceedings on privacy enhancing technologies 2020, 2 (2020), 230–250.
[54] Scaling with Presto on Spark. 2021. https://prestodb.io/blog/2021/10/26/Scaling- with- Presto- on- Spark.
[55] Getting Started with PrestoDB and Aria Scan Optimizations. 2020. https:// prestodb.io/blog/2020/08/14/getting- started- and- aria.
[56] Reynold S. Xin, Joseph E. Gonzalez, Michael J. Franklin, and Ion Stoica. 2013. GraphX: a resilient distributed graph system on Spark. In First International Workshop on Graph Data Management Experiences and Systems, GRADES, co- located with SIGMOD/PODS. CWI/ACM, 2.
[57] Matei Zaharia, Mosharaf Chowdhury, Michael J. Franklin, Scott Shenker, and Ion Stoica. 2010. Spark: Cluster Computing with Working Sets. In 2nd USENIX Workshop on Hot Topics in Cloud Computing, HotCloud’10.
本文系外文翻译，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
本文系外文翻译，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
