帮助 Meta 解决 Presto 中的数据孤岛问题

{"value":"Raptor 是用来支持Meta（以前的Facebook）中的一些关键交互式查询工作负载的Presto连接器（presto-raptor）。尽管ICDE 2019的论文 Presto：SQL on Everything[https://research.facebook.com/publications/presto-sql-on-everything/](（https://research.facebook.com/publications/presto-sql-on-everything/）)中提到过这一特性，但它对于许多 Presto 用户来说仍然有些神秘，因为目前还没有关于此特性的可用文档。本文将介绍 Raptor 的历史，以及为什么 Meta 最终替换了它，转而采用基于本地缓存的新架构RaptorX。\n\n\n# Raptor简介\n一般来说，Presto 作为一个查询引擎并不具备存储空间，因此开发了连接器来查询不同的外部数据源。这个框架非常灵活，但在存算分离的架构中，很难提供低延迟保证。网络和存储延迟导致很难确保数据访问的稳定性。为了解决这个问题，Raptor被设计成 Presto 的独享存储引擎（shared-nothing storage engine）。\n\n## >> 动机—AB 测试框架中的一个初始用例 <<\\n在 Meta 公司，新的产品特性通常要经过 AB 测试，然后才能大范围发布。AB 测试框架允许工程师配置实验，在实验组启用新特性，然后通过监控一些关键指标与对照组进行比较。该框架为工程师提供了一个 UI（用户界面）来分析他们的实验统计数据，从而将配置转换为 Presto 查询，查询语句是已知且有限的。查询通常连接多个大型数据集，其中包括用户、设备、测试、事件属性等。这个用例的基本需求是：\\n\\n**1.准确性：**数据必须完整、准确，不能有偏差\\n\\n**2.灵活性：**用户应该能够根据分析需求随意划分其运行结果；\\n\\n**3.实时性：**测试结果应在数小时内获得；\\n\\n**4.交互延迟短：**查询需要在几秒钟内返回结果；\\n\\n**5.高可用：**作为产品开发的关键服务，服务的宕机时间必须很短。\\n\\nPresto 在典型的仓库设置中（比如使用 Hive 连接器直接查询仓库数据）可以轻松满足前两个要求，但无法满足其他的要求。仓库数据大多是 T+1 导入，没有近实时的数据导入，因此不能满足实时性的要求。此外，Meta 的数据中心已经转用存算分离的架构，当以高 QPS （查询吞吐率）扫描大型表时，无法保证低延迟。同时，典型的 Presto 部署会停止整个集群，因此也不能满足高可用需求。\\n\\n为了支持这一关键用例，我们开始了 Raptor 的产品化进程。\\n\\n## >>> RaptorX 架构 <<<\\n\\n\\n\\n▲ 使用 Raptor 连接器的 Presto 集群的高层次架构\\nRaptor连接器使用MySQL作为metastore来存储表和文件元数据。表数据存储在每个worker 节点的本地磁盘上，并定期备份到外部存储系统，以便在 worker节点崩溃时能够进行数据恢复。数据以足够小的批量方式导入Raptor集群中，从而确保分钟级别的延迟，满足实时性要求。此外，还创建了备用集群，提供高可用性。\\n\\n想要了解更多Raptor存储引擎的相关信息，请查看附录—Raptor架构信息[https://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-architecture-details]((https://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-architecture-details))或观看附录—Raptor讲座([https://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-talk](https://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-talk))。\\n\\n## 局限\\n通过存算耦合，Raptor 集群可以支持低延迟、高吞吐量的查询工作负载。但是，这种架构带来了以下几个问题：\\n\\n## 集群利用率低\\n\\nRaptor集群的大小通常取决于需要存储多少数据。由于存算耦合，随着表的增多，将需要更多的worker提供足够的存储空间，即使在集群空闲时段，重新将机器分配给其他业务使用的难度也变得非常大。\\n\\n## 尾部性能较差\\n\\n由于数据是对应分配给 worker 节点的，如果一个 worker 节点宕机或变慢，必然会影响查询性能，难以提供稳定的尾部性能。\\n\\n## - 工程开销较大\\n\\nRaptor 需要很多存储引擎特有的特性和处理功能的支持，比如数据导入/释放、数据压缩、数据备份/恢复、数据安全等。对于直接查询 Meta 数据仓库的 Presto 集群而言，所有这些服务都由专门的团队管理，所有用例都能从中受益。而对于 Raptor 来说，情况就不同了，这导致了工程开销。\\n\\n## - 运维开销较高\\n\\n由于Raptor集群需要部署额外的存储系统，因此也就带来额外的运维开销。不同的集群配置和行为意味着需要单独建立oncall的处理流程。\\n\\n## 潜在的安全和隐私漏洞\\n\\n随着安全和隐私需求的增加，安全与隐私策略的统一实现变得更加重要。使用单独的存储引擎使得这些策略执行起来非常困难且脆弱。\\n\\n# RaptorX 的启用\\nRaptor有着很多的痛点，因此从2019年开始，Meta的工程师们就在重新思考 Raptor的未来，是否有可能既从本地闪存中受益，又无需承担存算紧耦合架构带来的代价？最终确定的方向是在原生数据仓库之上添加一个新的本地缓存层。这个项目作为 Presto Raptor 连接器用例的替代品被命名为 RaptorX。\\n\\n从技术层面来讲，RaptorX项目与Raptor无关。直观来说，同样的闪存设备在RaptorX里被当作数据缓存使用来存储Ratpor表，因此将热数据存放在计算节点上。将本地闪存作为缓存使用而不作为存储引擎使用的优点如下：\\n\\n● Presto无需管理数据生命周期；\\n\\n● 单个 worker 故障导致的数据丢失对查询性能的影响较小；\\n\\n● 缓存作为文件系统层的一个特性，是 presto-hive 连接器的一部分，因此 RaptorX 集群的架构类似于其他 presto 集群，减少了运维开销。\\n\\n## >>> RaptorX 架构 <<<\\n\\n▲ RaptorX 的架构\\nRaptor和 RaptorX的根本区别是如何使用 worker 上的本地固态硬盘（SSD）。在 RaptorX 中，Presto Worker 使用 Alluxio 在本地缓存文件数据。不同表列的访问模式可能差异很大，像 ORC 和 Parquet 这样的列式文件格式通常用于数据存储，增加文件中的数据本地性。通过在列式文件上以较小的页面大小缓存文件片段，只有频繁访问的数据才会被保存在接近计算的地方。Presto coordinator 会尝试将处理相同数据的计算任务调度到相同的worker节点上，以提高缓存效率。RaptorX 还实现了文件footer和元数据缓存，以及其他能进一步提高性能的智能缓存策略。\\n\\n要了解更多有关 RaptorX 的信息，参见 《RaptorX: 将 Presto 性能提升十倍》[https://prestodb.io/blog/2021/02/04/raptorx](（https://prestodb.io/blog/2021/02/04/raptorx）)。\\n\\n## >>> RaptorX 和 Raptor 性能基准测试 <<<\\n我们对 RaptorX 和 Raptor 进行了基准性能对比测试。基准测试运行在一个有大约 1000 个 Worker 节点和一个 coordinator 的集群上。Raptor和 RaptorX 使用相同的硬件，整个数据集都能够缓存到 RaptorX 的本地固态硬盘中，因此缓存\\n\\n从基准测试结果中可以看到，RaptorX的P90延迟与Raptor相比降低了一半。RaptorX 中的平均查询延迟和 P90 查询延迟之间的差异要比 Raptor 小得多。这是因为在 Raptor 中，数据被物理绑定到计算它的 worker 点上，因此运行慢的节点将不可避免地影响查询延迟。而在RaptorX中，我们采用软亲和（soft affinity） 调度。软亲和调度将选择两个 worker 节点作为处理分片（split）的候选节点。如果首选的worker节点运行正常，则选择该节点，否则将选择辅助（secondary） worker 节点。数据很有可能在多个节点上缓存，因此对整体工作负载的调度策略可以进一步优化，从而达到更好的 CPU负载均衡。\\n\\n## >>> 从 Raptor 迁移到 RaptorX <<<\\nMeta 公司所有以前的 Raptor 用例都迁移到了 RaptorX上, RaptorX 提供了更好的用户体验，并且易于扩展。\\n\\n**A/B 测试框架**\\n\\n在前一节中，我们提到了 A/B 测试框架的要求是：准确性、灵活性、实时性、低交互延迟和高可用性。因为 RaptorX 是 Hive 原始数据的缓存层，所以 Hive 保证了数据的准确性。它享受所有来自核心Presto引擎的查询优化，以及 Hive 连接器中的许多特定优化。基准测试结果表明，RaptorX的平均查询和 P90 查询延迟都优于 Raptor。对于实时性要求，我们能够从 Meta 的近实时仓库数据导入框架优化中受益，它提高了所有 Hive 数据的实时性。与 Raptor 一样，备用集群保证了高可用性。\\n\\n在迁移过程中，由于用户体验良好，测试框架的使用量增长了2倍。RaptorX 集群能够按照与迁移前的 Raptor 集群相同的容量支持额外的用量。集群的 CPU 资源得到充分利用，无需担心存储限制。\\n\\n**仪表板**\\n\\n在Meta 中 Raptor 的另一个典型用例是优化仪表板体验。Presto 用于支持 Meta 中的许多仪表板用例，一些数据工程团队通过预聚合一些数据表，并且手动导入指定的Raptor集群来获得更好的查询性能。在迁移到 RaptorX之后，数据工程师便可以省去数据导入操作，也不再需要担心基础表（base tables）和预聚合表之间的数据一致性问题，同时，P50 以上的大多数分位的查询延迟的降幅都达到了30%左右。\\n\\n## >>> Raptor 范围之外 <<<\\n由于 RaptorX 在正常的 Hive 连接器工作负载下作为booster使用起来很容易，我们也在 Meta 的数仓交互式工作负载中启用了 RaptorX。这些是多租户集群，通过 Presto 处理几乎所有Hive 数据的非 ETL 查询，包括 Tableau、内部仪表板、各种自动生成的 UI 分析查询、各种内部工具生成的工作负载、工作流原型（pipeline prototyping）、调试、数据探索等。RaptorX 为这些集群提供了支持，提高了相同数据集的查询性能。\\n\\n# 附录\\nRaptor架构信息\\n\\n\\n▲ 数据组织\\nRaptor表是根据哈希函数进行桶（bucket）划分的。来自同一个bucket的数据被存储在同一个worker节点上。在同一列上的多个表被称为一个distribution。一个表桶可以包含多个分片（shard）, 而分片是Raptor数据的基本不可变单位, 以ORC格式的文件存储。表也可以有排序属性，可以更好地优化查询。\\n\\n**# 执行优化**\\nRaptor作为Presto的本地存储引擎，允许Presto将计算安排在数据节点上，从而提供低延迟、高吞吐量的数据处理能力。除了通用的SQL优化外，Raptor的数据组织方式还能实现更多的执行优化。\\n\\n● 本地关联：当在桶列上关联同一distribution的表时，Raptor将进行本地关联（Collocated Join），因为具有相同连接键的数据在同一个worker上，避免了重新分配。\\n\\n● 数据裁剪: Raptor可以进行分片粒度和ORC读取器粒度的裁剪\\n\\no 分片粒度的裁剪：分片的列范围存储在元数据中，可以根据查询谓词跳过分片。如果表有排序属性，分片将在该worker内被排序，这也可用于分片裁剪。\\n\\no ORC读取器粒度的裁剪：ORC读取器基于谓词，通过利用Stripe（一组行数据）元数据针对Stripe和行组进行裁剪。如果数据是有序的，排序属性也有助于数据裁剪。\\n\\n**# 其他特性**\\n● **时间列：**一个时间或日期类型的列可以被指定为时间列。如果指定了一个时间列，Raptor会在分片上严格按天进行限制（即一个shard里的记录都是属于某一天的）。鉴于数据保留策略，这将能够提高大表的数据留存性能。\\n\\n● **后台压缩：**为了保证实时性，数据通常是以小的时间粒度导入Raptor的，这可能导致产生很多小文件，对查询性能不利。Raptor worker定期运行后台作业，将多个小分片压缩成大分片，并进行外部排序，保证排序属性。\\n\\n● **数据恢复：**如果某个worker发生故障，coordinator将在集群的其他节点上重新分配故障worker的数据。所有worker将从备份存储中下载必要的数据。在恢复过程中，如果某个查询需要访问缺失数据，该操作将被阻止，直到数据下载/恢复完毕。\\n\\n● **数据清理：**每个worker都有一个后台进程，将其分配的数据与本地数据进行比较，从而恢复缺失的数据，更新陈旧的数据。\\n\\n● **数据再平衡：**如果coordinator检测到数据不平衡（例如，增加了新的worker节点），它会修复不平衡的数据分布。\\n\\n> Raptor讲座\\n如需了解更多有关Raptor的信息, 可点击此链接：Presto Raptor: MPP Shared-Nothing Database on Flash[https://engineering.fb.com/2016/06/16/core-data/data-scale-june-2016-recap/]((https://engineering.fb.com/2016/06/16/core-data/data-scale-june-2016-recap/))，查看2016年Data@Scale会议上关于Raptor的公开讲座。","render":"<p>Raptor 是用来支持Meta（以前的Facebook）中的一些关键交互式查询工作负载的Presto连接器（presto-raptor）。尽管ICDE 2019的论文 Presto：SQL on Everything<a href=\\"%EF%BC%88https://research.facebook.com/publications/presto-sql-on-everything/%EF%BC%89\\" target=\\"_blank\\">https://research.facebook.com/publications/presto-sql-on-everything/</a>中提到过这一特性，但它对于许多 Presto 用户来说仍然有些神秘，因为目前还没有关于此特性的可用文档。本文将介绍 Raptor 的历史，以及为什么 Meta 最终替换了它，转而采用基于本地缓存的新架构RaptorX。<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/a6461f402e02424d960205421af4949b_image.png\\" alt=\\"image.png\\" /></p>\n<h1><a id=\\"Raptor_3\\"></a>Raptor简介</h1>\\n<p>一般来说，Presto 作为一个查询引擎并不具备存储空间，因此开发了连接器来查询不同的外部数据源。这个框架非常灵活，但在存算分离的架构中，很难提供低延迟保证。网络和存储延迟导致很难确保数据访问的稳定性。为了解决这个问题，Raptor被设计成 Presto 的独享存储引擎（shared-nothing storage engine）。</p>\n<h2><a id=\\"gtgt_AB__ltlt_6\\"></a>&gt;&gt; 动机—AB 测试框架中的一个初始用例 &lt;&lt;</h2>\\n<p>在 Meta 公司，新的产品特性通常要经过 AB 测试，然后才能大范围发布。AB 测试框架允许工程师配置实验，在实验组启用新特性，然后通过监控一些关键指标与对照组进行比较。该框架为工程师提供了一个 UI（用户界面）来分析他们的实验统计数据，从而将配置转换为 Presto 查询，查询语句是已知且有限的。查询通常连接多个大型数据集，其中包括用户、设备、测试、事件属性等。这个用例的基本需求是：</p>\n<p>**1.准确性：**数据必须完整、准确，不能有偏差</p>\n<p>**2.灵活性：**用户应该能够根据分析需求随意划分其运行结果；</p>\n<p>**3.实时性：**测试结果应在数小时内获得；</p>\n<p>**4.交互延迟短：**查询需要在几秒钟内返回结果；</p>\n<p>**5.高可用：**作为产品开发的关键服务，服务的宕机时间必须很短。</p>\n<p>Presto 在典型的仓库设置中（比如使用 Hive 连接器直接查询仓库数据）可以轻松满足前两个要求，但无法满足其他的要求。仓库数据大多是 T+1 导入，没有近实时的数据导入，因此不能满足实时性的要求。此外，Meta 的数据中心已经转用存算分离的架构，当以高 QPS （查询吞吐率）扫描大型表时，无法保证低延迟。同时，典型的 Presto 部署会停止整个集群，因此也不能满足高可用需求。</p>\n<p>为了支持这一关键用例，我们开始了 Raptor 的产品化进程。</p>\n<h2><a id=\\"gtgtgt_RaptorX__ltltlt_23\\"></a>&gt;&gt;&gt; RaptorX 架构 &lt;&lt;&lt;</h2>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/ee317235c83a490891bd69d538a5aabf_image.png\\" alt=\\"image.png\\" /></p>\n<p>▲ 使用 Raptor 连接器的 Presto 集群的高层次架构<br />\\nRaptor连接器使用MySQL作为metastore来存储表和文件元数据。表数据存储在每个worker 节点的本地磁盘上，并定期备份到外部存储系统，以便在 worker节点崩溃时能够进行数据恢复。数据以足够小的批量方式导入Raptor集群中，从而确保分钟级别的延迟，满足实时性要求。此外，还创建了备用集群，提供高可用性。</p>\n<p>想要了解更多Raptor存储引擎的相关信息，请查看附录—Raptor架构信息<a href=\\"(https://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-architecture-details)\\" target=\\"_blank\\">https://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-architecture-details</a>或观看附录—Raptor讲座(<a href=\\"https://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-talk\\" target=\\"_blank\\">https://prestodb.io/blog/2022/01/28/avoid-data-silos-in-presto-in-meta#raptor-talk</a>)。</p>\\n<h2><a id=\\"_32\\"></a>局限</h2>\\n<p>通过存算耦合，Raptor 集群可以支持低延迟、高吞吐量的查询工作负载。但是，这种架构带来了以下几个问题：</p>\n<h2><a id=\\"_35\\"></a>集群利用率低</h2>\\n<p>Raptor集群的大小通常取决于需要存储多少数据。由于存算耦合，随着表的增多，将需要更多的worker提供足够的存储空间，即使在集群空闲时段，重新将机器分配给其他业务使用的难度也变得非常大。</p>\n<h2><a id=\\"_39\\"></a>尾部性能较差</h2>\\n<p>由于数据是对应分配给 worker 节点的，如果一个 worker 节点宕机或变慢，必然会影响查询性能，难以提供稳定的尾部性能。</p>\n<h2><a id=\\"__43\\"></a>- 工程开销较大</h2>\\n<p>Raptor 需要很多存储引擎特有的特性和处理功能的支持，比如数据导入/释放、数据压缩、数据备份/恢复、数据安全等。对于直接查询 Meta 数据仓库的 Presto 集群而言，所有这些服务都由专门的团队管理，所有用例都能从中受益。而对于 Raptor 来说，情况就不同了，这导致了工程开销。</p>\n<h2><a id=\\"__47\\"></a>- 运维开销较高</h2>\\n<p>由于Raptor集群需要部署额外的存储系统，因此也就带来额外的运维开销。不同的集群配置和行为意味着需要单独建立oncall的处理流程。</p>\n<h2><a id=\\"_51\\"></a>潜在的安全和隐私漏洞</h2>\\n<p>随着安全和隐私需求的增加，安全与隐私策略的统一实现变得更加重要。使用单独的存储引擎使得这些策略执行起来非常困难且脆弱。</p>\n<h1><a id=\\"RaptorX__55\\"></a>RaptorX 的启用</h1>\\n<p>Raptor有着很多的痛点，因此从2019年开始，Meta的工程师们就在重新思考 Raptor的未来，是否有可能既从本地闪存中受益，又无需承担存算紧耦合架构带来的代价？最终确定的方向是在原生数据仓库之上添加一个新的本地缓存层。这个项目作为 Presto Raptor 连接器用例的替代品被命名为 RaptorX。</p>\n<p>从技术层面来讲，RaptorX项目与Raptor无关。直观来说，同样的闪存设备在RaptorX里被当作数据缓存使用来存储Ratpor表，因此将热数据存放在计算节点上。将本地闪存作为缓存使用而不作为存储引擎使用的优点如下：</p>\n<p>● Presto无需管理数据生命周期；</p>\n<p>● 单个 worker 故障导致的数据丢失对查询性能的影响较小；</p>\n<p>● 缓存作为文件系统层的一个特性，是 presto-hive 连接器的一部分，因此 RaptorX 集群的架构类似于其他 presto 集群，减少了运维开销。</p>\n<h2><a id=\\"gtgtgt_RaptorX__ltltlt_66\\"></a>&gt;&gt;&gt; RaptorX 架构 &lt;&lt;&lt;</h2>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/d3a98ae0e31445748503fd8edc0e3a21_image.png\\" alt=\\"image.png\\" /><br />\\n▲ RaptorX 的架构<br />\\nRaptor和 RaptorX的根本区别是如何使用 worker 上的本地固态硬盘（SSD）。在 RaptorX 中，Presto Worker 使用 Alluxio 在本地缓存文件数据。不同表列的访问模式可能差异很大，像 ORC 和 Parquet 这样的列式文件格式通常用于数据存储，增加文件中的数据本地性。通过在列式文件上以较小的页面大小缓存文件片段，只有频繁访问的数据才会被保存在接近计算的地方。Presto coordinator 会尝试将处理相同数据的计算任务调度到相同的worker节点上，以提高缓存效率。RaptorX 还实现了文件footer和元数据缓存，以及其他能进一步提高性能的智能缓存策略。</p>\n<p>要了解更多有关 RaptorX 的信息，参见 《RaptorX: 将 Presto 性能提升十倍》<a href=\\"%EF%BC%88https://prestodb.io/blog/2021/02/04/raptorx%EF%BC%89\\" target=\\"_blank\\">https://prestodb.io/blog/2021/02/04/raptorx</a>。</p>\\n<h2><a id=\\"gtgtgt_RaptorX__Raptor__ltltlt_73\\"></a>&gt;&gt;&gt; RaptorX 和 Raptor 性能基准测试 &lt;&lt;&lt;</h2>\\n<p>我们对 RaptorX 和 Raptor 进行了基准性能对比测试。基准测试运行在一个有大约 1000 个 Worker 节点和一个 coordinator 的集群上。Raptor和 RaptorX 使用相同的硬件，整个数据集都能够缓存到 RaptorX 的本地固态硬盘中，因此缓存</p>\n<p>从基准测试结果中可以看到，RaptorX的P90延迟与Raptor相比降低了一半。RaptorX 中的平均查询延迟和 P90 查询延迟之间的差异要比 Raptor 小得多。这是因为在 Raptor 中，数据被物理绑定到计算它的 worker 点上，因此运行慢的节点将不可避免地影响查询延迟。而在RaptorX中，我们采用软亲和（soft affinity） 调度。软亲和调度将选择两个 worker 节点作为处理分片（split）的候选节点。如果首选的worker节点运行正常，则选择该节点，否则将选择辅助（secondary） worker 节点。数据很有可能在多个节点上缓存，因此对整体工作负载的调度策略可以进一步优化，从而达到更好的 CPU负载均衡。</p>\n<h2><a id=\\"gtgtgt__Raptor__RaptorX_ltltlt_78\\"></a>&gt;&gt;&gt; 从 Raptor 迁移到 RaptorX &lt;&lt;&lt;</h2>\\n<p>Meta 公司所有以前的 Raptor 用例都迁移到了 RaptorX上, RaptorX 提供了更好的用户体验，并且易于扩展。</p>\n<p><strong>A/B 测试框架</strong></p>\\n<p>在前一节中，我们提到了 A/B 测试框架的要求是：准确性、灵活性、实时性、低交互延迟和高可用性。因为 RaptorX 是 Hive 原始数据的缓存层，所以 Hive 保证了数据的准确性。它享受所有来自核心Presto引擎的查询优化，以及 Hive 连接器中的许多特定优化。基准测试结果表明，RaptorX的平均查询和 P90 查询延迟都优于 Raptor。对于实时性要求，我们能够从 Meta 的近实时仓库数据导入框架优化中受益，它提高了所有 Hive 数据的实时性。与 Raptor 一样，备用集群保证了高可用性。</p>\n<p>在迁移过程中，由于用户体验良好，测试框架的使用量增长了2倍。RaptorX 集群能够按照与迁移前的 Raptor 集群相同的容量支持额外的用量。集群的 CPU 资源得到充分利用，无需担心存储限制。</p>\n<p><strong>仪表板</strong></p>\\n<p>在Meta 中 Raptor 的另一个典型用例是优化仪表板体验。Presto 用于支持 Meta 中的许多仪表板用例，一些数据工程团队通过预聚合一些数据表，并且手动导入指定的Raptor集群来获得更好的查询性能。在迁移到 RaptorX之后，数据工程师便可以省去数据导入操作，也不再需要担心基础表（base tables）和预聚合表之间的数据一致性问题，同时，P50 以上的大多数分位的查询延迟的降幅都达到了30%左右。</p>\n<h2><a id=\\"gtgtgt_Raptor__ltltlt_91\\"></a>&gt;&gt;&gt; Raptor 范围之外 &lt;&lt;&lt;</h2>\\n<p>由于 RaptorX 在正常的 Hive 连接器工作负载下作为booster使用起来很容易，我们也在 Meta 的数仓交互式工作负载中启用了 RaptorX。这些是多租户集群，通过 Presto 处理几乎所有Hive 数据的非 ETL 查询，包括 Tableau、内部仪表板、各种自动生成的 UI 分析查询、各种内部工具生成的工作负载、工作流原型（pipeline prototyping）、调试、数据探索等。RaptorX 为这些集群提供了支持，提高了相同数据集的查询性能。</p>\n<h1><a id=\\"_94\\"></a>附录</h1>\\n<p>Raptor架构信息<br />\\n<img src=\\"https://dev-media.amazoncloud.cn/d4253052e0ac467c8151541072200548_image.png\\" alt=\\"image.png\\" /></p>\n<p>▲ 数据组织<br />\\nRaptor表是根据哈希函数进行桶（bucket）划分的。来自同一个bucket的数据被存储在同一个worker节点上。在同一列上的多个表被称为一个distribution。一个表桶可以包含多个分片（shard）, 而分片是Raptor数据的基本不可变单位, 以ORC格式的文件存储。表也可以有排序属性，可以更好地优化查询。</p>\n<p><strong># 执行优化</strong><br />\\nRaptor作为Presto的本地存储引擎，允许Presto将计算安排在数据节点上，从而提供低延迟、高吞吐量的数据处理能力。除了通用的SQL优化外，Raptor的数据组织方式还能实现更多的执行优化。</p>\n<p>● 本地关联：当在桶列上关联同一distribution的表时，Raptor将进行本地关联（Collocated Join），因为具有相同连接键的数据在同一个worker上，避免了重新分配。</p>\n<p>● 数据裁剪: Raptor可以进行分片粒度和ORC读取器粒度的裁剪</p>\n<p>o 分片粒度的裁剪：分片的列范围存储在元数据中，可以根据查询谓词跳过分片。如果表有排序属性，分片将在该worker内被排序，这也可用于分片裁剪。</p>\n<p>o ORC读取器粒度的裁剪：ORC读取器基于谓词，通过利用Stripe（一组行数据）元数据针对Stripe和行组进行裁剪。如果数据是有序的，排序属性也有助于数据裁剪。</p>\n<p><strong># 其他特性</strong><br />\\n● **时间列：**一个时间或日期类型的列可以被指定为时间列。如果指定了一个时间列，Raptor会在分片上严格按天进行限制（即一个shard里的记录都是属于某一天的）。鉴于数据保留策略，这将能够提高大表的数据留存性能。</p>\n<p>● **后台压缩：**为了保证实时性，数据通常是以小的时间粒度导入Raptor的，这可能导致产生很多小文件，对查询性能不利。Raptor worker定期运行后台作业，将多个小分片压缩成大分片，并进行外部排序，保证排序属性。</p>\n<p>● **数据恢复：**如果某个worker发生故障，coordinator将在集群的其他节点上重新分配故障worker的数据。所有worker将从备份存储中下载必要的数据。在恢复过程中，如果某个查询需要访问缺失数据，该操作将被阻止，直到数据下载/恢复完毕。</p>\n<p>● **数据清理：**每个worker都有一个后台进程，将其分配的数据与本地数据进行比较，从而恢复缺失的数据，更新陈旧的数据。</p>\n<p>● **数据再平衡：**如果coordinator检测到数据不平衡（例如，增加了新的worker节点），它会修复不平衡的数据分布。</p>\n<blockquote>\\n<p>Raptor讲座<br />\\n如需了解更多有关Raptor的信息, 可点击此链接：Presto Raptor: MPP Shared-Nothing Database on Flash<a href=\\"(https://engineering.fb.com/2016/06/16/core-data/data-scale-june-2016-recap/)\\" target=\\"_blank\\">https://engineering.fb.com/2016/06/16/core-data/data-scale-june-2016-recap/</a>，查看2016年Data@Scale会议上关于Raptor的公开讲座。</p>\\n</blockquote>\n"}