​Alluxio SDK 在 Presto/Trino 中的应用

导读本文将分享 Alluxio Edge 在 Trino/ PrestoDB 中的应用。

主要内容包括：

1. Alluxio Edge 产生的背景2. Alluxio Edge 概要介绍3. Alluxio Edge 最佳实践场景4. Alluxio Edge 使用流程5. 问答环节分享嘉宾｜车赛光 Alluxio 解决方案工程师编辑整理｜苏磊内容校对｜李瑶出品社区｜DataFun01

Alluxio Edge 产生的背景

首先来介绍一下现代数据技术栈的演变历程。

10 年前，Hadoop 拥有一个紧密耦合的 MapReduce 和 HDFS 架构。HDFS 在本地部署，计算资源多由 YARN 管理。今天，技术栈的丰富带给我们更多的选择，并让不同的架构具备了可能性。我们现在看到了越来越多的计算与存储的解耦和分离；有了云和数据湖，而且越来越多的数据湖放在了云上；资源管理和编排则由 Kubernetes+ 容器来承担。所有这些技术的改变让我们的系统有了更好的弹性、更高的可扩展性、更便捷的管理。然而，这些好处也伴随着一个问题，即数据本地性的丧失。数据本地性就是计算引擎在本地（比如本节点、本集群）就可以访问数据的特性，其好处是高效的数据访问性能和低廉的数据访问开销。

在失去数据本地性以后，我们发现，数据的访问性能变得缓慢且不稳定，用户的查询运行时间变得更长，因此需要更长的时间来获取业务洞察。不仅如此，查询运行的时间越长，云上集群消耗的时间和资源就越多，导致集群成本增加。很多企业想要加快任务的执行速度，一部分原因是想让业务分析变得更加敏捷，另一部分原因是想节省计算资源的开销。

在使用云上对象存储的情况下，由于数据量的快速增长，我们发现数据的出口开销（也就是 egress cost）变成企业使用云成本的重要组成部分。尽管云上的对象存储的单位字节的存储成本很低，但数据就像被“绑架”了，当你想要从云上访问数据时，会产生各种额外开销，例如 API 调用开销和数据传输开销。如果这些开销发生在同一批数据上（比如热数据的反复读取），会带来巨大的成本。因此，有些用户会选择把要分析的数据一次性拷贝到计算集群附近的存储系统中，然后进行分析。这个方案需要人们建设和维护多个存储集群，并打造和维护数据拷贝任务的 pipeline。此外，数据的改动、数据生产和消费的变化等都容易引起拷贝错误，需要排查和解决。

Alluxio System 作为分布式的数据编排系统，具有缓存功能，能够解决上面的痛点。同时，我们在思考，如何把缓存这个最基本、最常用的功能做得更极致化。计算机领域有句著名的话，“在计算机科学中只有两件难事：缓存失效和命名”。于是，就诞生了 Alluxio Edge。

02

Alluxio Edge 概要介绍

Alluxio 是一个满足不同用户需求的数据平台。它包括两大类产品线，分别为Alluxio
System 和 Alluxio Edge。

Alluxio System 作为一个开源项目，已广为人知。简单地说，它是一个独立的分布式系统，其缓存容量可以水平扩展，并具备数据编排系统的其他功能，例如接口转换、统一命名空间等。本次分享的重点是 Alluxio Edge。

1. Alluxio Edge 是什么

Alluxio Edge 是一个库，可以放在如 PrestoDB 和 Trino 的应用程序的进程中运行。它可以利用 PrestoDB 或者 Trino 集群的本地存储空间（比如 SSD 或内存）来缓存数据。当大部分热数据能够放在本地磁盘或者内存中时，它是最理想的选择。

为什么我们需要一个缓存呢？主要有下面几个原因：

（1）对很多查询来说，IO 是排在第一位的性能瓶颈；

（2）对于有些存储系统，特别是 HDFS，Datanode 的性能波动会对 Presto 或者 Trino 等查询引擎的 IO 性能造成影响，让宝贵的 CPU 资源空转；

（3）分布式计算引擎工作需要消耗较大的网络资源，比如 shuffle。

引入缓存能够很好地解决上述 IO 瓶颈、存储系统性能波动的问题，还能节约宝贵的网络资源。

上图显示了 Alluxio Edge 的参考架构。当有一个 Trino 工作节点时，Alluxio Edge 会在 Trino 工作节点嵌入一个本地缓存。Trino 工作节点和 Alluxio Edge 在数量上是一一对应的。通常，一个 Trino 集群中包含很多 Trino Worker 节点，所以也会有多个 Alluxio Edge。Alluxio Edge 会利用本地节点的存储资源缓存数据，因此当 Trino 从 S3 等存储系统访问数据时，数据会经过 Alluxio Edge，并被 Alluxio Edge 自动缓存在本地的存储中。Alluxio Edge 提供了一个 Dashboard，来汇总整个 Trino 集群中所有 Alluxio Edge 的统计信息，并在仪表板中汇总、显示诸如集群信息、成本节约、资源状态之类的内容。

经过测试发现，Alluxio
Edge 使端到端查询的性能提高了大约 1.5 倍到 10 倍。在仅有 IO 的查询上，能够观察到 10 到 50 倍的 IO 速度提升。不仅如此，我们还看到，云存储 API 的调用在使用 Alluxio Edge 后减少了 50% 到 90%。有的时候，如果有大量请求同时发送到 S3，S3 可能会出现流量限制，其他的对象存储也会有相同的限流行为来保证系统的整体公平性和稳定性。当限流出现时，查询性能会变得不稳定。通过使用 Alluxio Edge 数据缓存，有助于减少网络拥塞和存储系统需要接受的请求数量，因此也有助于减轻底层存储的负载。

2. Alluxio Edge 的主要功能

Alluxio Edge 的设计目标是提供一个数据处理和分析场景下的边缘缓存解决方案。主要功能如下：

• 利用本地 SSD 或内存进行数据缓存，以提供更快的数据访问速度。当数据缓存在本地磁盘或者内存中时，数据的重复读取将不再访问底层存储。底层存储的性能不稳定或者强负载已经严重影响它的性能的时候，本地缓存的效果会非常明显。
• Alluxio Edge 支持多种现代数据湖连接器，包括 Iceberg、Hudi、DeltaLake 和 Hive。这意味着，无论您的数据是存储在哪个数据湖解决方案中，Alluxio Edge 都能与之兼容。这个功能大大扩展了 Alluxio Edge 的使用场景和可用范围。
• Alluxio Edge 支持广泛的数据格式，图中只列出了一部分，其实 Alluxio Edge可以支持任何 PrestoDB 和 Trino 所支持的数据格式。这为用户提供了巨大的灵活性，使用户能够在不同的数据格式之间进行选择。
• Alluxio Edge 支持灵活的缓存驱逐和使用策略。默认情况下，它支持 LRU 和 FIFO 策略。LRU (Least Recently Used) 是一个常见的缓存替换策略，当缓存空间占满时，这个策略会驱逐最近最少使用的数据。FIFO (First-In-First-Out) 如其名所示，会驱逐最先进入缓存的数据。用户还可以根据其特定的需求和场景定义自己的缓存替换策略。Alluxio Edge 也支持 TTL (Time To Live)。使用 TTL 后，过期数据会被优先驱逐。Alluxio Edge 的“数据配额”功能可以确保缓存不会超出为其分配的特定大小或配额的存储空间。

3. Alluxio Edge 是如何工作的

Alluxio Edge 的大致工作原理如下（以 Trino 为例）：

当 Trino 通过连接器（比如 Hudi）尝试访问数据时，它将请求  AlluxioCachingFileSystem。如果 AlluxioCachingFileSystem 检查后发现缓存被命中了，那么，它会通过缓存管理器（AlluxioCacheManager）从本地 SSD 或内存中访问数据；如果缓存并未命中，请求则会被发送到 UnderFileSystem 中，UnderFileSystem 负责从存储系统中（例如 S3、HDFS 等）访问数据。在数据被读取后，AlluxioCachingFileSystem 会通过 AlluxioCacheManager 异步缓存数据。

此外，这里提到的对象如 AlluxioCachingFileSystem、AlluxioCacheManager 都是在集群启动过程中，加载到 Trino
Worker 进程中的，它们成为了 Alluxio Trino Worker 进程的一部分。所以，计算节点对缓存的读取完全是在进程内部进行的，效率非常高。

4. Alluxio Edge 相关的技术挑战

• 数据一致性

底层存储中的文件在被缓存后，有可能被更新。Hive 上的文件出现不一致的情况比较少，但是在使用了 Hudi 等组件后，upsert 操作的频率大大增加，使得文件更新的频率加快，底层存储和缓存中的数据一致性问题亟待解决。为了解决数据一致性的问题，引入了 page versioning 的概念，把文件的 modification time 作为文件的 page 的版本号。在使用缓存数据之前，Alluxio Edge 会检查 page 的版本号，只有在版本一致的情况下，缓存数据才被使用。

• 数据本地性

默认情况下，数据会被缓存在任意的 worker 节点上。如果缓存的位置是不固定的，Coordinator 很难判断应该把 split 派给哪个 worker。“软亲和”用来解决这个问题。软亲和开启后，数据可以固定地缓存在某个节点上。Coordinator 在分派 split 的时候，优先选择可能会有缓存数据的 worker。由于是“软”亲和，所以这个分派不是固定的：如果可能会有缓存数据的 worker 比较繁忙，coordinator 会选择最“闲”的 worker 分派 split，这样虽然损失了数据本地性，但是平衡了 worker 之间的工作负载。另外，即使缓存能够稳定地找到某个 worker 节点，也要考虑 worker 节点变化的情况。比如，原来的 worker 下线了，或者新的 worker 上线了，要避免其他 worker 重新缓存数据。一致性哈希技术用来解决 worker 节点变化的问题。

• 缓存利用率

由于一段时期内需要访问的全量数据总是远远大于热数据，而缓存的资源又是有限的，如果对所有的数据不加限制地进行缓存，会造成数据频繁被驱逐，缓存命中率不高的结果。解决这个问题的办法是使用缓存过滤策略。即用户在缓存过滤策略中定义“库、表、分区的 TTL”。只有满足策略的数据才被缓存。通过这个办法，缓存资源可以有效地存放热数据，大大增加了缓存命中率。

5. TPC-DS Benchmark 测试

对 Alluxio Edge 的效果，我们首先做了充分的内部测试。测试时，我们使用了TPC-DS 作为测试数据集和 SQL 集。在所有其他条件都相同的情况下，我们比较了使用 Alluxio Edge 和直接读 S3 两种方式，结果显示：

在性能方面，所有查询时间大于 2 秒的 73 个查询中，70 个查询有明显的加速效果；所有查询执行时间的平均值提高了 63%。左图中，红色部分是 S3 直读的查询运行时间，蓝色部分是使用了 Alluxio Edge 作为本地缓存后查询的运行时间，蓝色部分明显小于红色部分。

在成本节约方面，S3 API 的请求数和数据传输量有肉眼可见的减少。右图来自 AWS CloudWatch 监控系统提供的 S3 对象存储的相关指标，每个图中有两部分线段，前一部分的线段是使用 Alluxio Edge 时，API 调用和下载数据量的指标，后一部分是 S3 直读的（API 调用和下载数据量）指标。可以看到，这些 Alluxio Edge 对应的指标远远优于直读 S3 对应的指标。

6. 应用实例

Uber 在三个集群，共 1500 个节点上部署了 Alluxio Edge。在他们的使用中，观察到端到端的输入-读取性能提高了 50%，而对 HDFS 的数据读取流量减少了 10%。到 GCS 的读取请求有 80% 被避免了。而且，查询延迟的 90 分位数从 228 秒减少到了 50 秒。

在新加坡某电商用户的测试环境中，Alluxio Edge 使查询延迟降低了 40%，同时 IO 吞吐量增加了 10 倍。

7. Alluxio Edge
Dashboard

Alluxio Edge 为用户提供了一个本地部署的 dashboard。这个 dashboard 对 Trino/PrestoDB 上所有的 Alluxio Edge 节点收集的指标进行集中化汇总和展示。提供的信息包括集群摘要、成本节省、资源使用状态等。通过使用这个 Dashboard，用户可以了解当前 Alluxio Edge 的状态，比如缓存空间有多少、使用了多少；Alluxio Edge 帮助用户节约了多少数据访问成本，比如一共多少 S3 API 被调用、多少 S3 API 调用实际产生了费用；还有资源状态指标，如果看到峰值，可能会发现系统出了问题。有了这个仪表板，用户可以轻松地了解节约的成本，并获得具有洞察力的调优信息。

03

Alluxio Edge 最佳实践场景

• 用户需要正在或者准备使用 Trino 或者 PrestoDB。
• 用户想要提升性能或者控制成本。
• 探索如何优化 Trino 或者 PrestoDB 的时候，不要忘记考虑 Alluxio Edge。

04

Alluxio Edge 使用流程

Alluxio Edge 的使用非常简便，基本流程如下：

第一步

• 从网站(www.alluxio.com.cn)下载 Alluxio Edge 的 tarball
• 将其放入计算引擎的相关路径中
• 运行查询并比较查询性能的变化
• 启动本地 dashboard 查看成本节省指标

第二步

• 使用本地仪表板进行持续的观测和优化

05

问答环节

Q1：小规模的集群、数据量的场景下，是不是推荐使用 Alluxio Edge 呢?

A1：在刚才我们分享的实战场景中，比如 Uber 的例子和新加坡电商的例子，那些用户的体量都很大，具体来说，他们的集群大小、数据量、任务数等都很大。所以，一方面，Alluxio Edge 是经受过大规模实战场景的打磨的。另一方面，对于这些用户，10% 甚至 1% 的性能提升或者成本控制都非常可观。而 Alluxio Edge 为这些用户实际带来了远超 10% 的增益，结果是非常令人激动的。在小规模的场景中，用户可以分析一下自己的数据类型，比如热数据的占比是否可观，看一下自己的可用资源的情况，比如 SSD 的可用资源和热数据的大小的比例。如果热数据有一定的占比，并且有足够的本地缓存资源，用户应该尝试一下 Alluxio Edge，毕竟 Alluxio Edge 的使用非常简单。一旦任务的规模增加，它的价值能够很快体现。:

Q2：如果 Trino 或者 PrestoDB 的本地资源有限怎么办？

A2：在这种情况下，您可以考虑使用多级缓存。例如，使用 Alluxio
System 作为 L2 缓存，配合 Alluxio Edge 一起工作。和 Alluxio Edge 相比，Alluxio System 的特点是：(1）它是一个独立的系统并且可以横向扩展，所以它可以缓存比 Alluxio Edge 更多的数据；(2) 它的数据可以被不同的 worker 节点或不同的 Trino 或 Presto DB 集群共享，甚至被其他计算引擎共享。即使 Alluxio System 存在的情况下，Alluxio Edge 仍然有优势，因为它是计算引擎的一部分（嵌入式缓存），缓存性能更高。

Q3：缓存空间的大小如何影响缓存的性能和成本节约的增益？

A3：如果缓存大小太小，缓存未命中率会更高，缓存数据会被更频繁地驱逐，从而收益会减少。理想情况下，本地存储容量应该能够容纳在一段时间内访问的大部分热数据。如果热数据存在并且可以被识别，那么可以相应地分配或调整缓存存储大小。以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

车赛光

Alluxio

解决方案工程师

10 年专注于大数据研发和解决方案。

往期优质文章推荐

往期推荐

知乎舰桥平台如何打造内容运营平台提升业务能力？

大模型时代 AI 技术在金融行业的创新应用

大语言模型分布式训练的量化分析与最佳实践,以 GPT-175B 为例

小米数据生产平台的产品设计方法与实践

降本不增“笑”的正确打开方式

网易数帆 指标中台构建核心技术解析

Apache Celeborn 社区的今天和明天

小红书推搜场景下如何优化机器学习异构硬件推理突破算力瓶颈！

如何看待大数据云原生发展之路–观 2023 云栖大会有感

百度视频推荐跨域多目标预估与融合的实践和思考

小米指标体系的建设及管理最佳实践

推荐多任务 2023 最新进展：用户生命周期视角下的多任务推荐模型 STAN

混合存储架构中的数据编排

DataFun

点个在看你最好看