Meta 公司新探索 | 利用 Alluxio 数据缓存降低 Presto 延迟

概要速览📕

Meta 公司（前“Facebook 公司”，下文统称“Meta”）的 Presto 团队一直在与 Alluxio 合作为 Presto 提供开源数据缓存方案。该方案被用于 Meta 的多个用例，来降低从诸如 HDFS 等远端数据源扫描数据产生的查询延迟。实验证明，使用 Alluxio 数据缓存后，查询延迟和 IO 扫描都得到了显著优化。

我们发现，Meta 架构环境中的多个用例都得益于 Alluxio 数据缓存。以 Meta 的一个内部用例为例，其各分位的查询延迟分别下降了 33%（P50）、54%（P75）和 48%（P95）。此外，远端数据源扫描数据的 IO 性能提升了 57%。

Presto 架构📖

Presto 的架构允许存储和计算独立扩展，但是扫描远端存储中的数据可能会产生昂贵的操作成本，也难以达到交互式查询的低延迟要求。

Presto worker 只负责对从独立（通常是远端）数据源扫描的数据执行查询计划片段，而不会存储任何远端数据源的数据，因此计算可以进行弹性扩展。

下面的架构图清晰地展示了从远端 HDFS 读取数据的路径。每个 worker 都会独立地从远端数据源中读取数据，本文将只讨论对远端数据源读取操作的优化。

image.png

Presto +数据缓存架构📖

为了解决用例的亚秒级延迟问题，我们决定进行多种优化，其中一个重要的优化就是实现数据缓存。数据缓存作为一种传统的优化方式，能让工作数据集更靠近计算节点，减少对远端存储的访问，从而降低延迟并节约 IO 开销。

其中的困难在于，如果从远端数据源访问 PB 级别的数据时没有固定访问模式的话，如何能实现有效的数据缓存，此外，有效数据缓存的另一个要求是在 Presto 等分布式环境中实现数据的亲和性。

添加数据缓存功能后，Presto 的架构如下所示：

image.png

关于数据缓存，后面会有更详细的说明。

软亲和调度📖

Presto 目前的调度器在分配分片时已经把 worker 的负载纳入考量，因此该调度策略使得工作负载在 worker 之间均匀分配。但从数据本地性的角度来看，分片是随机分配的，不能保证任何亲和性，而亲和性恰恰是实现有效数据缓存的必备条件。对 Coordinator 而言，每次把分片分配给同一个 worker 至关重要，因为该 worker 可能已经缓存了分片所需的数据。

image.png

上图说明了亲和性调度是如何给 worker 分配分片的。

执行软亲和调度策略时，会尽可能将同一个分片分配给同一个 worker。软亲和调度器使用分片的哈希值来为分片选择一个首选 worker，软亲和调度器:

✓ 为分片计算其首选 worke。如果首选 worker 有充足的可用资源，那么调度器会把该分片分配给首选 worker。✓ 如果首选 worker 处于忙碌状态，那么调度器就会选择一个备选 worker，如果该备选 worker 有充足的可用资源，调度器就会把分片分配给它。✓ 如果备选 worker 也处于忙碌状态，那么调度器就会把分片分配给当前最空闲的 worker。

image.png

确定一个节点是否忙碌可通过两项配置来定义：

✓ 单节点最大分片数：node-scheduler.max-splits-per-node

✓ 单任务最大待定分片（pending split）数: node-scheduler.max-pending-splits-per-task

当某一节点上的分片数超过上述任一配置的限制时，该节点就被视为忙碌节点。可以看出，节点亲和性对于缓存的有效性至关重要。如果没有节点亲和性，同一分片可能会在不同的时间被不同的 worker 处理，这会导致冗余的分片数据缓存。

出于这个原因，如果亲和性调度器没能把分片分配给首选 worker 或者备选 worker（因均处于忙碌状态），调度器就会向被分配的 worker 发出信号，让其不要缓存分片数据。这意味着只有分片的首选或备选 worker 才会缓存该分片的数据。

数据缓存📖

Alluxio 文件系统是一个经常用作 Presto 分布式缓存服务的开源数据编排系统。为了在架构中实现亚秒级的查询延迟，我们希望进一步降低 Presto 和 Alluxio 之间的通信开销。因此， Alluxio 和 Presto 的核心团队进行合作, 从 Alluxio 服务中发展出一个单节点的嵌入式缓存库。

具体而言，Presto worker 通过标准的 HDFS 接口查询位于同一个 JVM 内的 Alluxio 本地缓存。当缓存命中时，Alluxio 本地缓存直接从本地磁盘读取数据，并将缓存数据返回给 Presto；否则，Alluxio 将访问远端数据源，并将数据缓存在本地磁盘上，以便后续查询。该缓存对 Presto 来说是完全透明的。一旦缓存出现问题（如本地磁盘发生故障），Presto 还可以直接从远端数据源读取数据，该工作流程如下图所示：

image.png

本地缓存的内部构成和配置

Alluxio 数据缓存是位于 Presto worker 节点上的库，它提供了一种与 HDFS 兼容的接口“AlluxioCachingFileSystem” ，作为 Presto worker 进行所有数据访问操作的主要接口。Alluxio 数据缓存包含的设计选项有：

基本缓存单元

根据 Alluxio 的经验以及 Meta 团队早期的实验，以固定的数据块大小来进行数据读写和清理是最有效的。为了减少元数据服务的存储和服务压力，Alluxio 系统中默认的缓存数据块大小为 64MB。由于我们采用的 Alluxio 数据缓存只需要在本地管理数据和元数据，所以我们大大调低了缓存的粒度，把默认缓存粒度设置成大小为 1MB 的 “page（页面）”。

缓存位置和层级

Alluxio 本地缓存默认将数据缓存到本地文件系统。每个缓存 page 作为单独的文件存储在目录下，目录结构如下：<BASE_DIR>/LOCAL/1048576/<BUCKET>/<PAGE>

✓ BASE_DIR 是缓存存储的根目录，可以通过 Presto 的配置项 “cache.base-directory ”来设置。

✓ LOCAL 表示缓存存储类型为 LOCAL（本地）。Alluxio 也支持 RocksDB 作为缓存存储。

✓ 1048576:代表数据块的大小为 1MB。

✓ BUCKET 作为各种页面文件的 bucket 的目录。之所以创建 bucket 是为了确保单一目录下不会有太多的文件，否则可能会导致性能很差。

✓ PAGE 代表以页面 ID 命名的文件。在 Presto 中，ID 是文件名的 md5 哈希值。

线程并发

每个 Presto worker 包含一组线程，每个线程执行不同的查询任务，但共享同一块数据缓存。因此，该 Alluxio 数据缓存需要具备跨线程的高并发度，以提供高吞吐量。也就是说，数据缓存需要允许多个线程并发地获取同一个 page，同时还能在清除缓存数据时确保线程安全。

缓存恢复

当 worker 启动（或重启）时，Alluxio 本地缓存会尝试复用已经存在于本地缓存目录中的缓存数据。如果缓存目录结构是兼容的，则会复用已缓存数据。

监控

Alluxio 在执行各种缓存相关操作时，会输出各种 JMX 指标。通过这些指标，系统管理员可以轻松地监控整个集群的缓存使用情况。

基准测试📖

我们以运行在某个生产集群上的查询来进行基准测试，该集群被当作测试集群来使用。

查询数：17320 集群大小：600 个节点单节点最大缓存容量：460GB 清除策略：LRU

缓存数据块大小：1MB, 意味着数据按 1MB 的大小读取、存储和清除。

查询执行时间优化（单位：毫秒）：

image.png

从表格中可以看出，查询延迟有显著改善，其中 P50 的查询延迟降低了 33%，P75 降低了 54%，P95 降低了 48%。

开销节省

✓ Master 分支执行过程的总数据读取大小：582 TB

✓ 缓存分支执行过程的总数据读取大小：251 TB

节省的扫描数据量：57%

缓存命中率

在实验过程中，缓存命中率基本稳定地保持在较高的水平，多数时间维持在 0.9 和 1 之间。中间可能是由于新查询扫描大量新数据的原因出现了一些下降。我们需要添加一些其他算法来防止出现访问不太频繁的数据块相较于访问频繁的数据块更容易被缓存的情况。

如何使用？📖

使用数据缓存前，我们要做的第一件事就是启用软亲和调度策略，数据缓存不支持随机节点调度策略。

要启用软亲和调度策略，在 coordinator 中需要进行如下配置：

 "hive.node-selection-strategy", "SOFT_AFFINITY”

复制代码

要使用默认（随机）节点调度策略，则设置如下：

"hive.node-selection-strategy", "NO_PREFERENCE”

复制代码

要启用 Alluxio 数据缓存，在 worker 节点采用如下配置:

✓ 启用 worker 节点上的数据缓存=> "cache.enabled", "true"

✓ 将数据缓存类型设置为 Alluxio=> "cache.type", "ALLUXIO"

✓ 设置缓存数据存储的基本目录(base directory) => "cache.base-directory", "file:///cache"

✓ 配置单个 worker 缓存所能使用的最大数据容量:"cache.alluxio.max-cache-size", "500GB"

其他有用的配置如下

Coordinator 配置（可用来配置忙碌 worker 的定义）：

✓ 设置单任务最大待定分片数：node-scheduler.max-pending-splits-per-task

✓ 设置单节点最大分片数：node-scheduler.max-splits-per-node

Worker 配置：

✓ 启用 Alluxio 缓存指标（默认：true）: cache.alluxio.metrics-enabled

✓ Alluxio 缓存指标的 JMX 类名(默认: alluxio.metrics.sink.JmxSink): cache.alluxio.metrics-enabled

✓ Alluxio 缓存使用的指标域名：(默认: com.facebook.alluxio): cache.alluxio.metrics-domain

✓ Alluxio 缓存是否要异步写入缓存(默认: false): cache.alluxio.async-write-enabled

✓ Alluxio 缓存是否要验证已有的配置(默认: false): cache.alluxio.config-validation-enabled

Alluxio 数据缓存为其缓存操作输出各种 JMX 指标。点击查看指标名称的完整列表。

下一步工作📖

✓ 实现通过限速器（rate limiter）控制缓存写入操作的速率，从而避免闪存耐久性问题；

✓ 实现语义感知缓存，提高缓存效率；✓ 建立清理缓存目录的机制，用于维护或重新启动。

✓ 可执行“dry run”模式

✓ 能够施加各种容量使用限制，例如单表缓存配额限制，单分区缓存配额限制或单模式缓存配额限制。

✓ 构建更强大的 worker 节点调度机制。

✓ 增加新的算法实现，防止出现访问不太频繁的数据块相较于访问频繁的数据块更容易被缓存的情况。

✓ 容错性：目前，当集群中的节点数量发生变化时，基于哈希的节点调度算法会出现问题。我们正在努力实现更鲁棒的算法，如一致性哈希。

✓ 更好的负载均衡：当我们把其他因素如分片大小、节点资源等纳入考量后，我们就能更好地定义“忙碌”节点，继而在实现负载均衡方面做出更明智的决策。

✓ 亲和性标准：目前，Presto 集群内的亲和性粒度是文件级的。如果不能在该粒度标准下达到最佳性能，则需要调整我们的亲和性标准，使其更加细粒度，并在负载均衡和良好的缓存命中率之间找到平衡点，从而实现更好的整体性能。

✓ 提高 Alluxio 缓存库的资源利用率。