关于开源:帮助-Meta-解决-Presto-中的数据孤岛问题

9次阅读

共计 5183 个字符，预计需要花费 13 分钟才能阅读完成。

本文转载自 InfoQ 官网
作者：Alluxio- 钟荣荣；Meta-James Sun & Ke Wang

Raptor 是用来反对 Meta（以前的 Facebook）中的一些要害交互式查问工作负载的 Presto 连接器（presto-raptor）。只管 ICDE 2019 的论文 Presto：SQL on Everything（https://research.facebook.com…）中提到过这一个性，但它对于许多 Presto 用户来说依然有些神秘，因为目前还没有对于此个性的可用文档。本文将介绍 Raptor 的历史，以及为什么 Meta 最终替换了它，转而采纳基于本地缓存的新架构 RaptorX。

一般来说，Presto 作为一个查问引擎并不具备存储空间，因而开发了连接器来查问不同的内部数据源。这个框架非常灵活，但在存算拆散的架构中，很难提供低提早保障。网络和存储提早导致很难确保数据拜访的稳定性。为了解决这个问题，Raptor 被设计成 Presto 的独享存储引擎（shared-nothing storage engine）。

在 Meta 公司，新的产品个性通常要通过 AB 测试，而后能力大范畴公布。AB 测试框架容许工程师配置试验，在实验组启用新个性，而后通过监控一些要害指标与对照组进行比拟。该框架为工程师提供了一个 UI（用户界面）来剖析他们的试验统计数据，从而将配置转换为 Presto 查问，查问语句是已知且无限的。查问通常连贯多个大型数据集，其中包含用户、设施、测试、事件属性等。这个用例的根本需要是：

1. 准确性：数据必须残缺、精确，不能有偏差
2. 灵活性：用户应该可能依据剖析需要随便划分其运行后果；
3. 实时性：测试后果应在数小时内取得；
4. 交互提早短：查问须要在几秒钟内返回后果；
5. 高可用：作为产品开发的要害服务，服务的宕机工夫必须很短。

Presto 在典型的仓库设置中（比方应用 Hive 连接器间接查问仓库数据）能够轻松满足前两个要求，但无奈满足其余的要求。仓库数据大多是 T+1 导入，没有近实时的数据导入，因而不能满足实时性的要求。此外，Meta 的数据中心曾经转用存算拆散的架构，当以高 QPS（查问吞吐率）扫描大型表时，无奈保障低提早。同时，典型的 Presto 部署会进行整个集群，因而也不能满足高可用需要。

为了反对这一要害用例，咱们开始了 Raptor 的产品化过程。

Raptor 连接器应用 MySQL 作为 metastore 来存储表和文件元数据。表数据存储在每个 worker 节点的本地磁盘上，并定期备份到内部存储系统，以便在 worker 节点解体时可能进行数据恢复。数据以足够小的批量形式导入 Raptor 集群中，从而确保分钟级别的提早，满足实时性要求。此外，还创立了备用集群，提供高可用性。

想要理解更多 Raptor 存储引擎的相干信息，请查看附录—Raptor 架构信息 (https://prestodb.io/blog/2022…) 或观看附录—Raptor 讲座(https://prestodb.io/blog/2022…)。

局限

通过存算耦合，Raptor 集群能够反对低提早、高吞吐量的查问工作负载。然而，这种架构带来了以下几个问题：

集群利用率低

Raptor 集群的大小通常取决于须要存储多少数据。因为存算耦合，随着表的增多，将须要更多的 worker 提供足够的存储空间，即便在集群闲暇时段，从新将机器调配给其余业务应用的难度也变得十分大。

尾部性能较差

因为数据是对应调配给 worker 节点的，如果一个 worker 节点宕机或变慢，必然会影响查问性能，难以提供稳固的尾部性能。

工程开销较大

Raptor 须要很多存储引擎特有的个性和解决性能的反对，比方数据导入 / 开释、数据压缩、数据备份 / 复原、数据安全等。对于间接查问 Meta 数据仓库的 Presto 集群而言，所有这些服务都由专门的团队治理，所有用例都能从中受害。而对于 Raptor 来说，状况就不同了，这导致了工程开销。

运维开销较高

因为 Raptor 集群须要部署额定的存储系统，因而也就带来额定的运维开销。不同的集群配置和行为意味着须要独自建设 oncall 的解决流程。

潜在的平安和隐衷破绽

随着平安和隐衷需要的减少，平安与隐衷策略的对立实现变得更加重要。应用独自的存储引擎使得这些策略执行起来十分艰难且软弱。

Raptor 有着很多的痛点，因而从 2019 年开始，Meta 的工程师们就在从新思考 Raptor 的将来，是否有可能既从本地闪存中受害，又无需承当存算紧耦合架构带来的代价？最终确定的方向是在原生数据仓库之上增加一个新的本地缓存层。这个我的项目作为 Presto Raptor 连接器用例的替代品被命名为 RaptorX。

从技术层面来讲，RaptorX 我的项目与 Raptor 无关。直观来说，同样的闪存设施在 RaptorX 里被当作数据缓存应用来存储 Ratpor 表，因而将热数据寄存在计算节点上。将本地闪存作为缓存应用而不作为存储引擎应用的长处如下：
● Presto 无需治理数据生命周期；
● 单个 worker 故障导致的数据失落对查问性能的影响较小；
● 缓存作为文件系统层的一个个性，是 presto-hive 连接器的一部分，因而 RaptorX 集群的架构相似于其余 presto 集群，缩小了运维开销。

Raptor 和 RaptorX 的基本区别是如何应用 worker 上的本地固态硬盘（SSD）。在 RaptorX 中，Presto Worker 应用 Alluxio 在本地缓存文件数据。不同表列的拜访模式可能差别很大，像 ORC 和 Parquet 这样的列式文件格式通常用于数据存储，减少文件中的数据本地性。通过在列式文件上以较小的页面大小缓存文件片段，只有频繁拜访的数据才会被保留在靠近计算的中央。Presto coordinator 会尝试将解决雷同数据的计算任务调度到雷同的 worker 节点上，以进步缓存效率。RaptorX 还实现了文件 footer 和元数据缓存，以及其余能进一步提高性能的智能缓存策略。

要理解更多无关 RaptorX 的信息，参见《RaptorX: 将 Presto 性能晋升十倍》（https://prestodb.io/blog/2021…）。

咱们对 RaptorX 和 Raptor 进行了基准性能比照测试。基准测试运行在一个有大概 1000 个 Worker 节点和一个 coordinator 的集群上。Raptor 和 RaptorX 应用雷同的硬件，整个数据集都可能缓存到 RaptorX 的本地固态硬盘中，因而缓存

从基准测试后果中能够看到，RaptorX 的 P90 提早与 Raptor 相比升高了一半。RaptorX 中的均匀查问提早和 P90 查问提早之间的差别要比 Raptor 小得多。这是因为在 Raptor 中，数据被物理绑定到计算它的 worker 点上，因而运行慢的节点将不可避免地影响查问提早。而在 RaptorX 中，咱们采纳软亲和（soft affinity）调度。软亲和调度将抉择两个 worker 节点作为解决分片（split）的候选节点。如果首选的 worker 节点运行失常，则抉择该节点，否则将抉择辅助（secondary）worker 节点。数据很有可能在多个节点上缓存，因而对整体工作负载的调度策略能够进一步优化，从而达到更好的 CPU 负载平衡。

Meta 公司所有以前的 Raptor 用例都迁徙到了 RaptorX 上, RaptorX 提供了更好的用户体验，并且易于扩大。

A/B 测试框架

在前一节中，咱们提到了 A/B 测试框架的要求是：准确性、灵活性、实时性、低交互提早和高可用性。因为 RaptorX 是 Hive 原始数据的缓存层，所以 Hive 保障了数据的准确性。它享受所有来自外围 Presto 引擎的查问优化，以及 Hive 连接器中的许多特定优化。基准测试结果表明，RaptorX 的均匀查问和 P90 查问提早都优于 Raptor。对于实时性要求，咱们可能从 Meta 的近实时仓库数据导入框架优化中受害，它进步了所有 Hive 数据的实时性。与 Raptor 一样，备用集群保障了高可用性。

在迁徙过程中，因为用户体验良好，测试框架的使用量增长了 2 倍。RaptorX 集群可能依照与迁徙前的 Raptor 集群雷同的容量反对额定的用量。集群的 CPU 资源失去充分利用，无需放心存储限度。

仪表板

在 Meta 中 Raptor 的另一个典型用例是优化仪表板体验。Presto 用于反对 Meta 中的许多仪表板用例，一些数据工程团队通过预聚合一些数据表，并且手动导入指定的 Raptor 集群来取得更好的查问性能。在迁徙到 RaptorX 之后，数据工程师便能够省去数据导入操作，也不再须要放心根底表（base tables）和预聚合表之间的数据一致性问题，同时，P50 以上的大多数分位的查问提早的降幅都达到了 30% 左右。

因为 RaptorX 在失常的 Hive 连接器工作负载下作为 booster 应用起来很容易，咱们也在 Meta 的数仓交互式工作负载中启用了 RaptorX。这些是多租户集群，通过 Presto 解决简直所有 Hive 数据的非 ETL 查问，包含 Tableau、外部仪表板、各种主动生成的 UI 剖析查问、各种外部工具生成的工作负载、工作流原型（pipeline prototyping）、调试、数据摸索等。RaptorX 为这些集群提供了反对，进步了雷同数据集的查问性能。

Raptor 架构信息

Raptor 表是依据哈希函数进行桶（bucket）划分的。来自同一个 bucket 的数据被存储在同一个 worker 节点上。在同一列上的多个表被称为一个 distribution。一个表桶能够蕴含多个分片（shard）, 而分片是 Raptor 数据的根本不可变单位, 以 ORC 格局的文件存储。表也能够有排序属性，能够更好地优化查问。

执行优化
Raptor 作为 Presto 的本地存储引擎，容许 Presto 将计算安顿在数据节点上，从而提供低提早、高吞吐量的数据处理能力。除了通用的 SQL 优化外，Raptor 的数据组织形式还能实现更多的执行优化。

● 本地关联：当在桶列上关联同一 distribution 的表时，Raptor 将进行本地关联（Collocated Join），因为具备雷同连贯键的数据在同一个 worker 上，防止了重新分配。
● 数据裁剪: Raptor 能够进行分片粒度和 ORC 读取器粒度的裁剪
o 分片粒度的裁剪：分片的列范畴存储在元数据中，能够依据查问谓词跳过分片。如果表有排序属性，分片将在该 worker 内被排序，这也可用于分片裁剪。
o ORC 读取器粒度的裁剪：ORC 读取器基于谓词，通过利用 Stripe（一组行数据）元数据针对 Stripe 和行组进行裁剪。如果数据是有序的，排序属性也有助于数据裁剪。

其余个性
●  工夫列：一个工夫或日期类型的列能够被指定为工夫列。如果指定了一个工夫列，Raptor 会在分片上严格按天进行限度（即一个 shard 里的记录都是属于某一天的）。鉴于数据保留策略，这将可能进步大表的数据留存性能。
●  后盾压缩：为了保障实时性，数据通常是以小的工夫粒度导入 Raptor 的，这可能导致产生很多小文件，对查问性能不利。Raptor worker 定期运行后台作业，将多个小分片压缩成大分片，并进行内部排序，保障排序属性。
● 数据恢复：如果某个 worker 产生故障，coordinator 将在集群的其余节点上重新分配故障 worker 的数据。所有 worker 将从备份存储中下载必要的数据。在复原过程中，如果某个查问须要拜访缺失数据，该操作将被阻止，直到数据下载 / 复原结束。
●  数据清理：每个 worker 都有一个后盾过程，将其调配的数据与本地数据进行比拟，从而复原缺失的数据，更新古老的数据。
●  数据再均衡：如果 coordinator 检测到数据不均衡（例如，减少了新的 worker 节点），它会修复不均衡的数据分布。

Raptor 讲座
援用
如需理解更多无关 Raptor 的信息, 可点击此链接：Presto Raptor: MPP Shared-Nothing Database on Flash(https://engineering.fb.com/20…)，查看 2016 年 [email protected] 会议上对于 Raptor 的公开讲座。

想要获取更多乏味有料的【流动信息】【技术文章】【大咖观点】，请关注[[Alluxio 智库]](https://page.ma.scrmtech.com/…)：

正文完