概要速览

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都会独立地从远端数据源中读取数据，本文将只探讨对远端数据源读取操作的优化。

Presto +数据缓存架构

为了解决用例的亚秒级提早问题，咱们决定进行多种优化，其中一个重要的优化就是实现数据缓存。数据缓存作为一种传统的优化形式，能让工作数据集更凑近计算节点，缩小对远端存储的拜访，从而升高提早并节约IO开销。

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

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

对于数据缓存，前面会有更具体的阐明。

软亲和调度

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

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

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

✓ 为分片计算其首选worke。如果首选worker有短缺的可用资源，那么调度器会把该分片调配给首选worker。
✓ 如果首选worker处于繁忙状态，那么调度器就会抉择一个备选worker，如果该备选worker有短缺的可用资源，调度器就会把分片调配给它。
✓ 如果备选worker也处于繁忙状态，那么调度器就会把分片调配给以后最闲暇的worker。

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

✓ 单节点最大分片数：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还能够间接从远端数据源读取数据，该工作流程如下图所示：

本地缓存的外部形成和配置

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的大小读取、存储和革除。

查问执行工夫优化（单位：毫秒）：

从表格中能够看出，查问提早有显著改善，其中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缓存库的资源利用率。

文章贡献者：

Meta:Rohit Jain, James Sun, Ke Wang, Shixuan Fan, Biswapesh Chattopadhyay, Baldeep Hira
Alluxio: Bin Fan, Calvin Jia, Haoyuan Li
原文内容公布于：2020/6/16