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

{"value":"# 概要速览\nMeta公司（前“Facebook公司”，下文统称“Meta”）的Presto团队一直在与Alluxio 合作为Presto提供开源数据缓存方案。该方案被用于Meta的多个用例，来降低从诸如HDFS等远端数据源扫描数据产生的查询延迟。实验证明，使用Alluxio数据缓存后，查询延迟和IO扫描都得到了显著优化。\n\n我们发现，Meta架构环境中的多个用例都得益于Alluxio数据缓存。以Meta的一个内部用例为例，其各分位的查询延迟分别下降了33%（P50）、54%（P75）和48%（P95）。此外，远端数据源扫描数据的IO性能提升了57%。\n\n# Presto架构\nPresto的架构允许存储和计算独立扩展，但是扫描远端存储中的数据可能会产生昂贵的操作成本，也难以达到交互式查询的低延迟要求。\n\nPresto worker只负责对从独立（通常是远端）数据源扫描的数据执行查询计划片段，而不会存储任何远端数据源的数据，因此计算可以进行弹性扩展。\n\n下面的架构图清晰地展示了从远端HDFS读取数据的路径。每个worker都会独立地从远端数据源中读取数据，本文将只讨论对远端数据源读取操作的优化。\n\n\n# Presto +数据缓存架构\n为了解决用例的亚秒级延迟问题，我们决定进行多种优化，其中一个重要的优化就是实现数据缓存。数据缓存作为一种传统的优化方式，能让工作数据集更靠近计算节点，减少对远端存储的访问，从而降低延迟并节约IO开销。\n\n其中的困难在于，如果从远端数据源访问PB级别的数据时没有固定访问模式的话，如何能实现有效的数据缓存，此外，有效数据缓存的另一个要求是在Presto等分布式环境中实现数据的亲和性。\n\n添加数据缓存功能后，Presto的架构如下所示：\n\n\n关于数据缓存，后面会有更详细的说明。\n\n# 软亲和调度\nPresto目前的调度器在分配分片时已经把worker的负载纳入考量，因此该调度策略使得工作负载在worker之间均匀分配。但从数据本地性的角度来看，分片是随机分配的，不能保证任何亲和性，而亲和性恰恰是实现有效数据缓存的必备条件。对Coordinator而言，每次把分片分配给同一个worker至关重要，因为该worker可能已经缓存了分片所需的数据。\n\n\n上图说明了亲和性调度是如何给worker分配分片的。\n\n执行软亲和调度策略时，会尽可能将同一个分片分配给同一个worker。软亲和调度器使用分片的哈希值来为分片选择一个首选worker，软亲和调度器:\n\n✓ 为分片计算其首选worke。如果首选worker有充足的可用资源，那么调度器会把该分片分配给首选worker。\n✓ 如果首选worker处于忙碌状态，那么调度器就会选择一个备选worker，如果该备选worker有充足的可用资源，调度器就会把分片分配给它。\n✓ 如果备选worker也处于忙碌状态，那么调度器就会把分片分配给当前最空闲的worker。\n\n\n确定一个节点是否忙碌可通过两项配置来定义：\n\n✓ 单节点最大分片数：node-scheduler.max-splits-per-node\n✓ 单任务最大待定分片（pending split）数: node-scheduler.max-pending-splits-per-task\n\n当某一节点上的分片数超过上述任一配置的限制时，该节点就被视为忙碌节点。可以看出，节点亲和性对于缓存的有效性至关重要。如果没有节点亲和性，同一分片可能会在不同的时间被不同的worker处理，这会导致冗余的分片数据缓存。\n\n出于这个原因，如果亲和性调度器没能把分片分配给首选worker或者备选worker（因均处于忙碌状态），调度器就会向被分配的worker发出信号，让其不要缓存分片数据。这意味着只有分片的首选或备选worker才会缓存该分片的数据。\n\n# 数据缓存\nAlluxio文件系统是一个经常用作Presto分布式缓存服务的开源数据编排系统。为了在架构中实现亚秒级的查询延迟，我们希望进一步降低Presto和Alluxio之间的通信开销。因此， Alluxio和Presto的核心团队进行合作, 从Alluxio服务中发展出一个单节点的嵌入式缓存库。\n\n具体而言，Presto worker通过标准的HDFS接口查询位于同一个JVM内的Alluxio本地缓存。当缓存命中时，Alluxio本地缓存直接从本地磁盘读取数据，并将缓存数据返回给Presto；否则，Alluxio将访问远端数据源，并将数据缓存在本地磁盘上，以便后续查询。该缓存对Presto来说是完全透明的。一旦缓存出现问题（如本地磁盘发生故障），Presto还可以直接从远端数据源读取数据，该工作流程如下图所示：\n\n\n# 本地缓存的内部构成和配置\nAlluxio数据缓存是位于Presto worker节点上的库，它提供了一种与HDFS兼容的接口“AlluxioCachingFileSystem” ，作为Presto worker进行所有数据访问操作的主要接口。Alluxio数据缓存包含的设计选项有：\n\n# 基本缓存单元\n根据Alluxio的经验以及Meta团队早期的实验，以固定的数据块大小来进行数据读写和清理是最有效的。为了减少元数据服务的存储和服务压力，Alluxio系统中默认的缓存数据块大小为64MB。由于我们采用的Alluxio数据缓存只需要在本地管理数据和元数据，所以我们大大调低了缓存的粒度，把默认缓存粒度设置成大小为1MB的 “page（页面）”。\n\n# 缓存位置和层级\nAlluxio本地缓存默认将数据缓存到本地文件系统。每个缓存page作为单独的文件存储在目录下，目录结构如下：<BASE_DIR>/LOCAL/1048576/<BUCKET>/<PAGE>\n\n✓ BASE_DIR是缓存存储的根目录，可以通过Presto的配置项 “cache.base-directory ”来设置。\n✓ LOCAL表示缓存存储类型为LOCAL（本地）。Alluxio也支持RocksDB作为缓存存储。\n✓ 1048576:代表数据块的大小为1MB。\n✓ BUCKET作为各种页面文件的bucket的目录。之所以创建bucket是为了确保单一目录下不会有太多的文件，否则可能会导致性能很差。\n✓ PAGE代表以页面ID命名的文件。在Presto中，ID是文件名的md5哈希值。\n\n# 线程并发\n**每个Presto worker包含一组线程，每个线程执行不同的查询任务，但共享同一块数据缓存。**因此，该Alluxio数据缓存需要具备跨线程的高并发度，以提供高吞吐量。也就是说，数据缓存需要允许多个线程并发地获取同一个page，同时还能在清除缓存数据时确保线程安全。\n\n# 缓存恢复\n当worker启动（或重启）时，Alluxio本地缓存会尝试复用已经存在于本地缓存目录中的缓存数据。如果缓存目录结构是兼容的，则会复用已缓存数据。\n\n# 监控\nAlluxio在执行各种缓存相关操作时，会输出各种JMX指标。通过这些指标，系统管理员可以轻松地监控整个集群的缓存使用情况。\n\n# 基准测试\n我们以运行在某个生产集群上的查询来进行基准测试，该集群被当作测试集群来使用。\n\n**查询数**：17320\n**集群大小**：600个节点\n**单节点最大缓存容量**：460GB\n**清除策略**：LRU\n\n**缓存数据块大小**：1MB, 意味着数据按1MB的大小读取、存储和清除。\n\n**查询执行时间优化（单位：毫秒）**：\n\n\n从表格中可以看出，查询延迟有显著改善，其中P50的查询延迟降低了33%，P75降低了54%，P95降低了48%。\n\n# 开销节省\n✓ Master分支执行过程的总数据读取大小：582 TB\n✓ 缓存分支执行过程的总数据读取大小：251 TB\n\n# 节省的扫描数据量：57%\n# 缓存命中率\n在实验过程中，缓存命中率基本稳定地保持在较高的水平，多数时间维持在 0.9 和 1 之间。中间可能是由于新查询扫描大量新数据的原因出现了一些下降。我们需要添加一些其他算法来防止出现访问不太频繁的数据块相较于访问频繁的数据块更容易被缓存的情况。\n\n# 如何使用？\n使用数据缓存前，我们要做的第一件事就是启用软亲和调度策略，数据缓存不支持随机节点调度策略。\n\n要启用软亲和调度策略，在coordinator 中需要进行如下配置：\n\n ```\n\"hive.node-selection-strategy\", \"SOFT_AFFINITY”\n```\n\n要使用默认（随机）节点调度策略，则设置如下：\n\n```\n\"hive.node-selection-strategy\", \"NO_PREFERENCE”\n```\n\n要启用Alluxio数据缓存，在worker节点采用如下配置:\n\n✓ 启用worker节点上的数据缓存=> \"cache.enabled\", \"true\"\n✓ 将数据缓存类型设置为Alluxio=> \"cache.type\", \"ALLUXIO\"\n✓ 设置缓存数据存储的基本目录(base directory) => \"cache.base-directory\", \"file:///cache\"\n✓ 配置单个worker缓存所能使用的最大数据容量:\"cache.alluxio.max-cache-size\", \"500GB\"\n\n**其他有用的配置如下\nCoordinator 配置（可用来配置忙碌worker的定义）：**\n\n✓ 设置单任务最大待定分片数：node-scheduler.max-pending-splits-per-task\n✓ 设置单节点最大分片数：node-scheduler.max-splits-per-node\n\n**Worker 配置：**\n\n✓ 启用Alluxio缓存指标（默认：true）: cache.alluxio.metrics-enabled\n✓ Alluxio缓存指标的JMX类名(默认: alluxio.metrics.sink.JmxSink): cache.alluxio.metrics-enabled\n✓ Alluxio缓存使用的指标域名：(默认: com.facebook.alluxio): cache.alluxio.metrics-domain\n✓ Alluxio缓存是否要异步写入缓存(默认: false): cache.alluxio.async-write-enabled\n✓ Alluxio缓存是否要验证已有的配置(默认: false): cache.alluxio.config-validation-enabled\n\nAlluxio数据缓存为其缓存操作输出各种JMX指标。点击查看指标名称的完整列表。\n\n# 下一步工作\n✓ 实现通过限速器（rate limiter）控制缓存写入操作的速率，从而避免闪存耐久性问题；\n✓ 实现语义感知缓存，提高缓存效率；\n✓ 建立清理缓存目录的机制，用于维护或重新启动。\n✓ 可执行“dry run”模式\n✓ 能够施加各种容量使用限制，例如单表缓存配额限制，单分区缓存配额限制或单模式缓存配额限制。\n✓ 构建更强大的worker节点调度机制。\n✓ 增加新的算法实现，防止出现访问不太频繁的数据块相较于访问频繁的数据块更容易被缓存的情况。\n✓ 容错性：目前，当集群中的节点数量发生变化时，基于哈希的节点调度算法会出现问题。我们正在努力实现更鲁棒的算法，如一致性哈希。\n✓ 更好的负载均衡：当我们把其他因素如分片大小、节点资源等纳入考量后，我们就能更好地定义“忙碌”节点，继而在实现负载均衡方面做出更明智的决策。\n✓ 亲和性标准：目前，Presto集群内的亲和性粒度是文件级的。如果不能在该粒度标准下达到最佳性能，则需要调整我们的亲和性标准，使其更加细粒度，并在负载均衡和良好的缓存命中率之间找到平衡点，从而实现更好的整体性能。\n✓ 提高Alluxio缓存库的资源利用率。\n\n> **文章贡献者：**\n**Meta**:Rohit Jain, James Sun, Ke Wang, Shixuan Fan, Biswapesh Chattopadhyay, Baldeep Hira\n**Alluxio**: Bin Fan, Calvin Jia, Haoyuan Li\n","render":"<h1><a id=\"_0\"></a>概要速览</h1>\n<p>Meta公司（前“Facebook公司”，下文统称“Meta”）的Presto团队一直在与Alluxio 合作为Presto提供开源数据缓存方案。该方案被用于Meta的多个用例，来降低从诸如HDFS等远端数据源扫描数据产生的查询延迟。实验证明，使用Alluxio数据缓存后，查询延迟和IO扫描都得到了显著优化。</p>\n<p>我们发现，Meta架构环境中的多个用例都得益于Alluxio数据缓存。以Meta的一个内部用例为例，其各分位的查询延迟分别下降了33%（P50）、54%（P75）和48%（P95）。此外，远端数据源扫描数据的IO性能提升了57%。</p>\n<h1><a id=\"Presto_5\"></a>Presto架构</h1>\n<p>Presto的架构允许存储和计算独立扩展，但是扫描远端存储中的数据可能会产生昂贵的操作成本，也难以达到交互式查询的低延迟要求。</p>\n<p>Presto worker只负责对从独立（通常是远端）数据源扫描的数据执行查询计划片段，而不会存储任何远端数据源的数据，因此计算可以进行弹性扩展。</p>\n<p>下面的架构图清晰地展示了从远端HDFS读取数据的路径。每个worker都会独立地从远端数据源中读取数据，本文将只讨论对远端数据源读取操作的优化。<br />\n<img src=\"https://dev-media.amazoncloud.cn/776fc2acefed493f8b10d9c6e6e42d30_image.png\" alt=\"image.png\" /></p>\n<h1><a id=\"Presto__13\"></a>Presto +数据缓存架构</h1>\n<p>为了解决用例的亚秒级延迟问题，我们决定进行多种优化，其中一个重要的优化就是实现数据缓存。数据缓存作为一种传统的优化方式，能让工作数据集更靠近计算节点，减少对远端存储的访问，从而降低延迟并节约IO开销。</p>\n<p>其中的困难在于，如果从远端数据源访问PB级别的数据时没有固定访问模式的话，如何能实现有效的数据缓存，此外，有效数据缓存的另一个要求是在Presto等分布式环境中实现数据的亲和性。</p>\n<p>添加数据缓存功能后，Presto的架构如下所示：<br />\n<img src=\"https://dev-media.amazoncloud.cn/9179e11262c24890ae0a45bcd48138ad_image.png\" alt=\"image.png\" /></p>\n<p>关于数据缓存，后面会有更详细的说明。</p>\n<h1><a id=\"_23\"></a>软亲和调度</h1>\n<p>Presto目前的调度器在分配分片时已经把worker的负载纳入考量，因此该调度策略使得工作负载在worker之间均匀分配。但从数据本地性的角度来看，分片是随机分配的，不能保证任何亲和性，而亲和性恰恰是实现有效数据缓存的必备条件。对Coordinator而言，每次把分片分配给同一个worker至关重要，因为该worker可能已经缓存了分片所需的数据。<br />\n<img src=\"https://dev-media.amazoncloud.cn/ea9a2f07e4344282a84eacfd6ee9e331_image.png\" alt=\"image.png\" /></p>\n<p>上图说明了亲和性调度是如何给worker分配分片的。</p>\n<p>执行软亲和调度策略时，会尽可能将同一个分片分配给同一个worker。软亲和调度器使用分片的哈希值来为分片选择一个首选worker，软亲和调度器:</p>\n<p>✓ 为分片计算其首选worke。如果首选worker有充足的可用资源，那么调度器会把该分片分配给首选worker。<br />\n✓ 如果首选worker处于忙碌状态，那么调度器就会选择一个备选worker，如果该备选worker有充足的可用资源，调度器就会把分片分配给它。<br />\n✓ 如果备选worker也处于忙碌状态，那么调度器就会把分片分配给当前最空闲的worker。<br />\n<img src=\"https://dev-media.amazoncloud.cn/6d14d96fdc52403088d55188ae53dc8a_image.png\" alt=\"image.png\" /></p>\n<p>确定一个节点是否忙碌可通过两项配置来定义：</p>\n<p>✓ 单节点最大分片数：node-scheduler.max-splits-per-node<br />\n✓ 单任务最大待定分片（pending split）数: node-scheduler.max-pending-splits-per-task</p>\n<p>当某一节点上的分片数超过上述任一配置的限制时，该节点就被视为忙碌节点。可以看出，节点亲和性对于缓存的有效性至关重要。如果没有节点亲和性，同一分片可能会在不同的时间被不同的worker处理，这会导致冗余的分片数据缓存。</p>\n<p>出于这个原因，如果亲和性调度器没能把分片分配给首选worker或者备选worker（因均处于忙碌状态），调度器就会向被分配的worker发出信号，让其不要缓存分片数据。这意味着只有分片的首选或备选worker才会缓存该分片的数据。</p>\n<h1><a id=\"_45\"></a>数据缓存</h1>\n<p>Alluxio文件系统是一个经常用作Presto分布式缓存服务的开源数据编排系统。为了在架构中实现亚秒级的查询延迟，我们希望进一步降低Presto和Alluxio之间的通信开销。因此， Alluxio和Presto的核心团队进行合作, 从Alluxio服务中发展出一个单节点的嵌入式缓存库。</p>\n<p>具体而言，Presto worker通过标准的HDFS接口查询位于同一个JVM内的Alluxio本地缓存。当缓存命中时，Alluxio本地缓存直接从本地磁盘读取数据，并将缓存数据返回给Presto；否则，Alluxio将访问远端数据源，并将数据缓存在本地磁盘上，以便后续查询。该缓存对Presto来说是完全透明的。一旦缓存出现问题（如本地磁盘发生故障），Presto还可以直接从远端数据源读取数据，该工作流程如下图所示：<br />\n<img src=\"https://dev-media.amazoncloud.cn/ebd06803eee44de3b0194e890e17c5da_image.png\" alt=\"image.png\" /></p>\n<h1><a id=\"_51\"></a>本地缓存的内部构成和配置</h1>\n<p>Alluxio数据缓存是位于Presto worker节点上的库，它提供了一种与HDFS兼容的接口“AlluxioCachingFileSystem” ，作为Presto worker进行所有数据访问操作的主要接口。Alluxio数据缓存包含的设计选项有：</p>\n<h1><a id=\"_54\"></a>基本缓存单元</h1>\n<p>根据Alluxio的经验以及Meta团队早期的实验，以固定的数据块大小来进行数据读写和清理是最有效的。为了减少元数据服务的存储和服务压力，Alluxio系统中默认的缓存数据块大小为64MB。由于我们采用的Alluxio数据缓存只需要在本地管理数据和元数据，所以我们大大调低了缓存的粒度，把默认缓存粒度设置成大小为1MB的 “page（页面）”。</p>\n<h1><a id=\"_57\"></a>缓存位置和层级</h1>\n<p>Alluxio本地缓存默认将数据缓存到本地文件系统。每个缓存page作为单独的文件存储在目录下，目录结构如下：&lt;BASE_DIR&gt;/LOCAL/1048576/&lt;BUCKET&gt;/&lt;PAGE&gt;</p>\n<p>✓ BASE_DIR是缓存存储的根目录，可以通过Presto的配置项 “cache.base-directory ”来设置。<br />\n✓ LOCAL表示缓存存储类型为LOCAL（本地）。Alluxio也支持RocksDB作为缓存存储。<br />\n✓ 1048576:代表数据块的大小为1MB。<br />\n✓ BUCKET作为各种页面文件的bucket的目录。之所以创建bucket是为了确保单一目录下不会有太多的文件，否则可能会导致性能很差。<br />\n✓ PAGE代表以页面ID命名的文件。在Presto中，ID是文件名的md5哈希值。</p>\n<h1><a id=\"_66\"></a>线程并发</h1>\n<p>**每个Presto worker包含一组线程，每个线程执行不同的查询任务，但共享同一块数据缓存。**因此，该Alluxio数据缓存需要具备跨线程的高并发度，以提供高吞吐量。也就是说，数据缓存需要允许多个线程并发地获取同一个page，同时还能在清除缓存数据时确保线程安全。</p>\n<h1><a id=\"_69\"></a>缓存恢复</h1>\n<p>当worker启动（或重启）时，Alluxio本地缓存会尝试复用已经存在于本地缓存目录中的缓存数据。如果缓存目录结构是兼容的，则会复用已缓存数据。</p>\n<h1><a id=\"_72\"></a>监控</h1>\n<p>Alluxio在执行各种缓存相关操作时，会输出各种JMX指标。通过这些指标，系统管理员可以轻松地监控整个集群的缓存使用情况。</p>\n<h1><a id=\"_75\"></a>基准测试</h1>\n<p>我们以运行在某个生产集群上的查询来进行基准测试，该集群被当作测试集群来使用。</p>\n<p><strong>查询数</strong>：17320<br />\n<strong>集群大小</strong>：600个节点<br />\n<strong>单节点最大缓存容量</strong>：460GB<br />\n<strong>清除策略</strong>：LRU</p>\n<p><strong>缓存数据块大小</strong>：1MB, 意味着数据按1MB的大小读取、存储和清除。</p>\n<p><strong>查询执行时间优化（单位：毫秒）</strong>：<br />\n<img src=\"https://dev-media.amazoncloud.cn/161e24284ac04baa8c228aa447a45d15_image.png\" alt=\"image.png\" /></p>\n<p>从表格中可以看出，查询延迟有显著改善，其中P50的查询延迟降低了33%，P75降低了54%，P95降低了48%。</p>\n<h1><a id=\"_90\"></a>开销节省</h1>\n<p>✓ Master分支执行过程的总数据读取大小：582 TB<br />\n✓ 缓存分支执行过程的总数据读取大小：251 TB</p>\n<h1><a id=\"57_94\"></a>节省的扫描数据量：57%</h1>\n<h1><a id=\"_95\"></a>缓存命中率</h1>\n<p>在实验过程中，缓存命中率基本稳定地保持在较高的水平，多数时间维持在 0.9 和 1 之间。中间可能是由于新查询扫描大量新数据的原因出现了一些下降。我们需要添加一些其他算法来防止出现访问不太频繁的数据块相较于访问频繁的数据块更容易被缓存的情况。</p>\n<h1><a id=\"_98\"></a>如何使用？</h1>\n<p>使用数据缓存前，我们要做的第一件事就是启用软亲和调度策略，数据缓存不支持随机节点调度策略。</p>\n<p>要启用软亲和调度策略，在coordinator 中需要进行如下配置：</p>\n<pre><code class=\"lang-\">&quot;hive.node-selection-strategy&quot;, &quot;SOFT_AFFINITY”\n</code></pre>\n<p>要使用默认（随机）节点调度策略，则设置如下：</p>\n<pre><code class=\"lang-\">&quot;hive.node-selection-strategy&quot;, &quot;NO_PREFERENCE”\n</code></pre>\n<p>要启用Alluxio数据缓存，在worker节点采用如下配置:</p>\n<p>✓ 启用worker节点上的数据缓存=&gt; “cache.enabled”, “true”<br />\n✓ 将数据缓存类型设置为Alluxio=&gt; “cache.type”, “ALLUXIO”<br />\n✓ 设置缓存数据存储的基本目录(base directory) =&gt; “cache.base-directory”, “file:///cache”<br />\n✓ 配置单个worker缓存所能使用的最大数据容量:“cache.alluxio.max-cache-size”, “500GB”</p>\n<p><strong>其他有用的配置如下<br />\nCoordinator 配置（可用来配置忙碌worker的定义）：</strong></p>\n<p>✓ 设置单任务最大待定分片数：node-scheduler.max-pending-splits-per-task<br />\n✓ 设置单节点最大分片数：node-scheduler.max-splits-per-node</p>\n<p><strong>Worker 配置：</strong></p>\n<p>✓ 启用Alluxio缓存指标（默认：true）: cache.alluxio.metrics-enabled<br />\n✓ Alluxio缓存指标的JMX类名(默认: alluxio.metrics.sink.JmxSink): cache.alluxio.metrics-enabled<br />\n✓ Alluxio缓存使用的指标域名：(默认: com.facebook.alluxio): cache.alluxio.metrics-domain<br />\n✓ Alluxio缓存是否要异步写入缓存(默认: false): cache.alluxio.async-write-enabled<br />\n✓ Alluxio缓存是否要验证已有的配置(默认: false): cache.alluxio.config-validation-enabled</p>\n<p>Alluxio数据缓存为其缓存操作输出各种JMX指标。点击查看指标名称的完整列表。</p>\n<h1><a id=\"_136\"></a>下一步工作</h1>\n<p>✓ 实现通过限速器（rate limiter）控制缓存写入操作的速率，从而避免闪存耐久性问题；<br />\n✓ 实现语义感知缓存，提高缓存效率；<br />\n✓ 建立清理缓存目录的机制，用于维护或重新启动。<br />\n✓ 可执行“dry run”模式<br />\n✓ 能够施加各种容量使用限制，例如单表缓存配额限制，单分区缓存配额限制或单模式缓存配额限制。<br />\n✓ 构建更强大的worker节点调度机制。<br />\n✓ 增加新的算法实现，防止出现访问不太频繁的数据块相较于访问频繁的数据块更容易被缓存的情况。<br />\n✓ 容错性：目前，当集群中的节点数量发生变化时，基于哈希的节点调度算法会出现问题。我们正在努力实现更鲁棒的算法，如一致性哈希。<br />\n✓ 更好的负载均衡：当我们把其他因素如分片大小、节点资源等纳入考量后，我们就能更好地定义“忙碌”节点，继而在实现负载均衡方面做出更明智的决策。<br />\n✓ 亲和性标准：目前，Presto集群内的亲和性粒度是文件级的。如果不能在该粒度标准下达到最佳性能，则需要调整我们的亲和性标准，使其更加细粒度，并在负载均衡和良好的缓存命中率之间找到平衡点，从而实现更好的整体性能。<br />\n✓ 提高Alluxio缓存库的资源利用率。</p>\n<blockquote>\n<p><strong>文章贡献者：</strong><br />\n<strong>Meta</strong>:Rohit Jain, James Sun, Ke Wang, Shixuan Fan, Biswapesh Chattopadhyay, Baldeep Hira<br />\n<strong>Alluxio</strong>: Bin Fan, Calvin Jia, Haoyuan Li</p>\n</blockquote>\n"}