在 Meta 中避免 Presto 中的数据孤岛：从 Raptor 到 RaptorX 的旅程

Raptor是一个 Presto 连接器 ( presto-raptor )，用于为 Meta（以前的 Facebook）中的一些关键交互式查询工作负载提供支持。尽管在 ICDE 2019 论文Presto: SQL on Everything中有所提及，但对于许多 Presto 用户来说仍然有些神秘，因为没有此功能的可用文档。本文将阐明 Raptor 的历史，以及为什么 Meta 最终取代它，转而采用基于本地缓存的新架构，即 RaptorX。

猛禽的故事

一般来说，Presto 作为一个查询引擎，并不拥有存储。相反，连接器被开发用于查询不同的外部数据源。这个框架非常灵活，但很难在分解的计算和存储架构中提供低延迟保证。网络和存储延迟增加了避免可变性的难度。为了解决这个限制，Raptor 被设计为 Presto 的无共享存储引擎。

动机——AB测试框架中的一个初始用例

在 Meta 中，新产品功能通常会在更广泛地发布之前经过 AB 测试。AB 测试框架允许工程师配置向测试组推出新功能的实验，然后针对控制组监控关键指标。该框架为工程师提供了一个 UI 来分析他们的实验统计数据，从而将配置转换为 Presto 查询。查询形状是已知且有限的。查询通常会加入多个大型数据集，包括用户、设备、测试、事件属性等。这个用例的基本要求是：

• 准确性：数据需要完整、准确，不能是近似值。
• 灵活性：用户应该能够任意分割他们的结果。
• 新鲜度：测试结果应在数小时内提供。
• 交互延迟：查询需要在几秒钟内返回结果。
• 高可用性：作为产品开发的关键服务，该服务的停机时间应该最短。

Presto 在典型的仓库设置中（即使用 Hive 连接器直接查询仓库数据）可以轻松满足前两个要求，但不能满足其余要求。那时还没有近实时的数据摄取，仓库数据大部分是每天摄取，不满足新鲜度要求。Meta 的数据中心已经转向分散的计算/存储架构，当以高 QPS 扫描大型表时，该架构无法保证延迟。典型的 Presto 部署会停止整个集群，因此无法满足 HA 要求。

为了支持这个关键用例，我们开始了生产 Raptor 的旅程。

猛禽架构

以下是带有 Raptor 连接器的 Presto 集群的高级架构。

Raptor 连接器使用 MySQL 作为其元数据存储来存储表和文件元数据。表数据存储在每个工作节点的闪存盘上，并定期备份到外部存储系统，以便在工作节点崩溃时进行恢复。数据以足够小的批次被摄取到 Raptor 集群中，以提供分钟级延迟，提供新鲜度。创建备用集群以提供高可用性 (HA)。

限制

由于计算/存储并置，Raptor 集群可以支持低延迟、高吞吐量的查询工作负载。然而，搭配的另一面也很重要。

集群利用率低

Raptor 集群的大小通常取决于需要存储多少数据。随着表的增长，由于计算/存储并置，需要更多的工作节点，这也为将这些机器重新用于其他用途提出了挑战，即使在集群空闲时也是如此。

低尾性能

由于数据是硬分配给worker节点的，如果worker节点宕机或者变慢，势必会影响查询性能，难以提供稳定的尾部性能。

工程费用高

Raptor 需要大量存储引擎特定的功能和流程，例如数据摄取/驱逐、数据压缩、数据备份/恢复、数据安全等。对于直接查询 Meta 数据仓库的分解式 Presto 集群，所有这些服务都由专用管理团队，改进使所有用例受益。Raptor 则不能这样说，这导致了工程开销。

高运营开销

Raptor 集群的额外存储方面也需要额外的操作工作。不同的集群配置和行为意味着必须设置单独的待命流程。

潜在的安全和隐私漏洞

随着安全和隐私需求的增加，安全和隐私策略的统一实施变得更加重要。使用单独的存储引擎使得执行这些策略变得非常困难和脆弱。

RaptorX 的诞生

带着 Raptor 的痛点，Meta 的工程师们开始重新思考 Raptor 在 2019 年的未来。是否有可能在不支付并置存储/计算架构成本的情况下从本地闪存存储中受益？决定的方向是在普通数据仓库之上添加一个新的本地缓存层。作为 Presto Raptor 连接器用例的替代品，该项目
被命名为 RaptorX。

从技术上讲，RaptorX 项目与 Raptor 无关。直觉是，同一个闪存驱动器可用于将 Raptor 表存储为数据缓存，从而将热数据保留在计算节点上。使用本地闪存作为缓存而不是存储引擎的优点是：

• Presto 不再需要管理数据生命周期。
• 单worker故障导致的数据丢失对查询性能的影响较小。
• 缓存作为文件系统层中的一项功能是 presto-hive 连接器的一部分；因此，RaptorX 集群的架构类似于其他仓库 presto 集群，从而减少了运营开销。

RaptorX 架构

以下是 RaptorX 的架构：

Raptor 和 Raptor X 的根本区别在于如何使用 worker 上的本地 SSD。在 RaptorX 中，Presto 工作人员使用 Alluxio 在本地缓存文件数据。众所周知，不同表列的访问模式可能非常不同，并且像 ORC 和 Parquet 这样的列文件格式通常用于数据文件以增加文件内的数据局部性。在列文件的顶部缓存小页面大小的文件片段将只保留
靠近计算的频繁访问的数据。为了提高缓存效率，Presto 协调器尝试将处理相同数据的计算调度到同一个工作节点。RaptorX 还实现了文件页脚和元数据缓存以及其他可以进一步提高性能的智能缓存策略。

RaptorX 与 Raptor 性能基准测试

我们运行基准测试来比较 RaptorX 原型与 Raptor 的性能。基准测试在具有约 1000 个工作节点和一个协调器的集群上运行。Raptor 和 RaptorX 使用相同的硬件，因此整个数据集适合 RaptorX 的本地 SSD 缓存；因此缓存命中率接近 100%。