导读 Alluxio 可以作为开源的数据编排系统的首选方案，旨在解决现代分布式场景下数据访问效率低下的问题。在存算分离的架构下，Alluxio 通过把数据缓存在靠近计算的地方，减少数据移动和复制所带来的开销，加速数据计算。Alluxio 不仅适用于传统 Hadoop 环境，还可与现代大数据生态系统、云原生应用程序的存储和计算资源无缝集成。在混合云、混合存储架构中，Alluxio 作为数据联邦桥梁，为自治数据系统之间提供数据共享的解决方案。Alluxio的解决方案工程师车赛光本次分享的题目是《混合存储架构中的数据编排》。

本次分享会主要围绕以下六个方面展开：

1. 数据访问的主要命题

2. Alluxio 最佳适用场景

3. Alluxio 的缓存加速、命名空间、接口转换

4. 基于 Alluxio的数据管理

5. 基于 Alluxio的数据联邦

6. 问答环节

分享嘉宾｜车赛光 Alluxio 解决方案工程师

编辑整理｜阿东同学

内容校对｜李瑶

出品社区｜DataFun

01数据访问的主要命题

数据访问的问题贯穿整个计算机系统架构的演变历程。这些问题在不同时代都存在。主要包括以下几个命题：第一是如何提高数据的读写性能；第二是通过命名空间实现数据的便捷访问；第三是如何解决数据接口的兼容问题；第四是如何管理存储系统中的数据。当然，这些命题并不足以涵盖数据访问的所有方面，因为工程师还需要关注一系列其他相关的问题，例如安全、审计、监控等等。但这些其他问题并不是数据访问所独有的，所以我们重点关注的是前四个命题。

回看计算机系统的发展历史，我们大致可以把它划分为"单台服务器"时代、"单一分布式系统"时代、"多系统、多数据中心"时代。

在单台服务器时代，上述命题在操作系统中或者某些软件内部得到了解决。首先为了提高数据的读写性能，操作系统使用不同层级的缓存加速 CPU 对数据的访问速率。通过多级缓存可以让数据更加贴近于 CPU，从而避免每次都做磁盘寻址的过程。其次，操作系统文件系统提供统一的命名空间，方便用户或者应用程序去访问数据。然后是接口转换。像 Linux 的虚拟文件系统会提供不同存储挂载的模式，无论是从用户态还是内核态进行存储都要通过虚拟文件系统挂载在 Linux 的存储系统上，使不同的 NFS 或本地磁盘都能以一致的方式访问数据。因此虚拟文件系统本身就提供了接口转换。最后是数据管理，比如数据备份、文件系统的日志等功能。

之后，进入了以 Hadoop 为代表的单一分布式系统时代。在这个时期，上述命题在单一分布式系统内部被解决了。例如，MapReduce 会把任务根据数据本地性分发到合适的节点上执行以提高数据读写效率（数据本地性）。当单一 NameNode 的压力过大时，人们把 HDFS 集群进行分区管理，并在上面添加 HDFS RBF 做数据文件访问路由，可以通过 RBF 统一不同 HDFS 集群的命名空间以方便用户访问，同时还实现了集群层面的横向扩展和扩容。在接口转换方面，当用户需要通过 POSIX 的方式去访问数据时，特别是机器学习和应用程序需要访问 HDFS 数据时，就需要对文件接口进行转换。开源社区中有许多库，如 hdfs-fuse，主要用于上述目的。此外，大家熟悉的用于数据管理的 distcp，在不同的集群之间迁移数据。

从 Hadoop 的出现到当下，计算集群越来越多，应用场景也越来越丰富。计算框架如 Spark、Presto 等层出不穷。这些新框架的性能更好、功能更多，应用场景也更加广泛。同时，机器学习领域的工程实践比以往任何时候都活跃，应用场景也变得更为广泛，存储方案也比原来更加丰富和成熟，比如很多企业都在思考如何把对象存储用起来、用得更好；很多企业在同时使用多种类型的存储系统。多数据中心、多云、混合云的架构越来越多地被采纳。很多企业的架构已经迈入了"多系统、多数据中心时代"的时代。

不同的场景需要使用不同的计算框架。不同的计算框架能够在不同的场景中为我们提供不同的备选方案。不同的存储系统让我们能够在容量、性能、成本等方面找到适合自己的平衡点。多数据中心、多云、混合云的架构为我们进一步优化服务的可用性、可靠性、以及成本提供了可能。但是在面对更加丰富的架构设计的选择的同时，我们也要重新检视新架构下数据访问的 4 个命题。比如，在使用对象存储的过程中，如何提高对象存储方案的效率、减少公有云上对象存储访问的成本；在混合云场景中，如何处理带宽限制对数据网络传输的影响并提高数据访问的并发量；使用 HDFS 存放热数据、用对象存储存放冷数据的时候，如何使用统一的命名空间去统一访问数据，在数据的热度发生变化的时候，如何对数据进行管理。

Alluxio 的数据编排技术就是想要帮助用户在多系统、多数据中心的架构中解决数据访问的四个命题。因此，当企业在考虑多个数据中心、多个云服务、异构存储的使用、数据访问性能优化的时候，我们推荐工程师从上述命题入手去思考数据访问的挑战，然后看一下 Alluxio 是如何解决这些问题和挑战的。

02Alluxio 的最佳试用场景

在单数据中心或者单区域的场景中，Alluxio 可以帮助用户解决一些痛点。例如，在单一 HDFS 集群的场景下，虽然 HDFS 的负载通常较为平稳，但在任务峰值时 NameNode 或 DataNode 可能会承受压力。在这种情况下，我们可以使用 Alluxio 分流 HDFS 的负载。另外，若在数据中心中使用 Presto 且不存储数据，则可以使用 Alluxio 的 SDK 作为 Presto 客户端缓存，提高 Presto 查询的性能，减少对象存储的开销。

在涉及到多个区域、多个数据中心以及计算框架和存储集群比较复杂的情况下，用户更应该考虑使用 Alluxio 解决新的技术挑战。

图左显示四个区域，每个区域表示一个独立的数据中心或云域，它们彼此交互，使用不同的存储方式，如对象存储和 HDFS。除了计算框架复杂之外，存储也是异构的混合模式。在这种多系统、多数据中心场景中，用户痛点主要包括数据读写性能不高或者不稳定、缺乏统一命名空间、缺乏可靠的协议转换方案等问题。Alluxio 不仅可以解决这些问题，还具有自动数据管理特性，帮助用户跨区域、跨存储管理数据。

03Alluxio 的数据缓存，命名空间，接口转换

Alluxio 是如何在上面的场景中解决用户的痛点的？这里，我们先介绍三个 Alluxio 核心功能。

1. 1. 数据缓存

第一个是 Alluxio 提供的数据缓存功能。如上面第一张图，本地数据中心和公有云之间的数据交互和数据访问需要通过网络。数据可以选择存储在对象存储或 HDFS 中，并在公有云上部署一些计算集群。在进行机器学习训练、批处理或即席查询时，数据访问由于网络限制而效率不高。因此，在公有云一侧，可以部署 Alluxio 集群缓存数据。部署 Alluxio 集群后，整个数据流模式发生了变化：计算在访问远端存储之前，会先访问 Alluxio；如果 Alluxio 已经缓存了数据，则可以直接从本地集群中高效访问数据，而无需通过网络重复获取数据；如果 Alluxio 尚未缓存这些数据，它将从远端存储拉取并缓存数据，然后将其交给计算集群处理。当 Alluxio 缓存数据时，不仅可以缓存文件的内容，还可以缓存文件的元数据信息。元数据缓存非常重要，因为它可以有效降低对象存储的访问成本、分散 HDFS NameNode 的负载。

Alluxio 不仅提供集群缓存，还可以提供客户端 SDK，帮助计算组件进行本地缓存。客户端缓存比集群缓存更接近客户端计算，所以性能更高。

因此，Alluxio 提供了两种不同级别的缓存，用户可以在不同场景中选择其一或者同时使用两种缓存。在使用时：

• Alluxio 可以将数据缓存在 MEM、SSD 或 HDD 中，让用户根据实际情况选择缓存资源。
• Alluxio 支持缓存中数据的生命周期管理，对数据的缓存时间进行 TTL 设置
• Alluxio 支持不同的缓存读写类型（穿透写、异步写、UFS 直接写等；缓存读、UFS 直接读）；用户可以根据数据类型选择缓存策略。
• 整个 Alluxio 资源由用户配置，用户可以根据需要分配机器、节点和资源，即完全管理缓存资源。在使用公有云的对象存储时，对象存储会对读操作的吞吐量和并发量限流；但是如果使用 Alluxio 作为对象存储的缓存，则不存在限流问题。
• Alluxio 缓存对存储的访问完全透明，不需要用户专门适配 Alluxio，使用非常方便。

2. 命名空间

第二个功能是统一命名空间。用户可以将不同的异构存储挂载到 Alluxio 的命名空间中，并通过统一命名空间访问这些存储。比如，用户同时使用了 HDFS 和 S3，那么他可以把 HDFS 和 S3 挂载到 Alluxio 的命名空间上，用户可以使用统一的视图访问数据，而不需要在不同数据源之间进行切换。

此外，**Alluxio 还提供了一种有趣的挂载方式，即可以将不同的存储系统挂载到Alluxio 命名空间的同一目录下。**这种挂载方式称为 Union Mount，它打破了传统的"挂载"语义的定义，允许用户通过一个挂载点访问多个数据源。这种抽象命名空间可以将具体的物理命名空间和应用层解耦，从而降低对业务的侵入性。本文后面的部分会讨论一个使用 Union Mount 的场景。

1. 3. 接口转换

第三个功能是接口转换。可以看到，Alluxio 所处的软件层次位于计算和存储之间，就像操作系统中的数据总线一样，并向上层提供不同的数据访问接口。换句话说，在该层次中，Alluxio 将计算和存储进行了访问接口的解耦，无论下面的存储系统接口如何变化，上面的计算系统都可以使用适合自己的接口去访问底层的数据，整个访问过程是顺畅和无感知的。这有什么用处呢？比如，以前的数据都保存在 HDFS 中，但是用户想要对数据进行备份或者进行热、冷分离。如果引入对象存储，用户则需要对 S3 等协议进行适配；如果上层计算通过 Alluxio 去访问，Alluxio 侧为计算屏蔽了存储接口的差异，将底层的 HDFS 和 S3 接口都统一成上面的 HDFS 接口进行数据访问，也就是说，计算侧不需要进行任何改造，仍然可以通过 HDFS 接口访问 S3 上的数据。

抽象存储系统接口，能够帮助用户方便地整合机器学习和大数据技术栈。例如，许多训练任务的数据都存储在 HDFS 或对象存储中，然而 PyTorch 和 TensorFlow 更倾向使用 POSIX 接口去访问数据，这种数据访问接口的差异可以通过 Alluxio 来屏蔽。

接口转换配合统一命名空间的使用，可以帮助用户建立统一的数据访问视图。例如，一个集团公司下属多个子公司，且子公司的数据存放在异构存储系统中。集团公司可以搭建一个 Alluxio 服务，把子公司的存储系统都挂载到集团公司的 Alluxio 服务上，然后使用 Alluxio 的 RESTful 接口为用户提供文件/对象的 Web 视图。

04基于 Alluxio 的数据管理

以上是 Alluxio 的几个核心功能，此外，Alluxio 还提供数据管理功能。

我们看这样一个场景：由于 HDFS 集群资源非常有限，容量已经达到了瓶颈，所以用户需要将热数据放在 HDFS 中，将冷数据放在对象存储中，以实现数据的冷热分层。用户需要对不同的数据或者分区设置不一样的策略。例如，对于超过 6 个月的文件，Alluxio 会将其放在对象存储中，因为这些数据已经变成冷数据；对于小于 6个月的文件，Alluxio 会将其放在 HDFS 中。其中，6 个月是用户自定义的时间（用户可以定义其他时间阈值作为冷热数据的分界线），有的文件需要根据文件创建时间决定其冷热状态，有的需要根据文件的名称来判断。

一种办法是用户编写和维护脚本或使用数据集成软件进行数据迁移。另一种方法是使用 Alluxio。

Alluxio 提供了 Alluxio PDDM 执行引擎的功能来帮助用户管理数据。用户根据场景和需求，在执行引擎上定义一些数据管理策略，比如哪些文件需要迁移、迁移的目的地是哪里、原始文件是否删除等。

策略定义好以后，执行引擎就根据策略去做相应的工作了。例如定期扫描目录树、拷贝出错的重试、老文件的删除等，整个数据管理的工作都被执行引擎自动化地完成了。

结合前面提到的 union mount 挂载：因为数据从 HDFS 挪到了对象存储里边，物理位置发生了变化，但是由于两个存储的数据的挂载点都挂载在 Alluxio 的同一个目录下面，因此用户应用程序如果通过 Alluxio 目录去访问数据的话，并不会感知到物理位置的变化，这样就完全避免了由于数据在混合存储下物理位置变化而带来的改造需求。Alluxio 数据管理，将 PDDM 执行引擎和 union mount 这两个功能配合使用，达到数据管理的目的，并且对应用是低侵入的。

05基于 Alluxio 的数据联邦

最后谈谈基于 Alluxio 的数据联邦场景。许多企业，尤其是正处于数字化和 IT 化转型过程中的大型企业，会涉及使用多个系统或者多家云服务的情况。例如，有些集团的区域公司在发电站周围建立了较小规模的数据中心进行数据收集，每个区域公司有自己的数据中心，每个中心有自己的技术栈；再有，一些大型集团的生产部门和销售部门分布在不同区域，各部门相对独立且使用不同的云服务。这种类型的数字化过程或者IT 建设方式的优点在于高敏捷度：区域公司或者部门只需快速解决自己的痛点，并选择合适的解决方案和服务即可。但同时，容易导致数据孤岛的产生。

子公司和各部门自己的数据如果能够安全地、充分地被共享和使用，数据的价值则能够趋于最大化；反之，如果数据的共享和使用被数据孤岛而影响，企业所拥有的数据资产的价值会大打折扣。业界有很多解决方案来提升数据价值，如近几年比较流行的数据网格（data mesh），是一种"从上到下"的解决方案。除此之外，还有其他的方案。

这里，我们讨论一种使用 Alluxio 的解决方案。

假设，集团想要打通子公司之间或者部门之间的数据通路。

首先，集团公司建立集中式的数据管理平台。平台包含操作界面和存储系统。集团公司允许来自子公司的数据资产管理人员注册数据资产，例如，注册某子公司拥有哪些存储系统、哪些目录、哪些文件等；对于格式化数据，用户在数据管理平台中注册自己的库、表信息。

然后，数据管理平台根据用户提供的数据资产注册信息，通过 Alluxio 和 Meta Store Proxy，把子公司的数据资产接入进来。具体说来，存储系统（HDFS、对象存储、NAS等）挂载到集团公司的 Alluxio 上，其他子公司通过 Alluxio 统一访问这些存储系统中的数据；结构化数据的元数据（库、表）挂载到 Meta Store Proxy 上，其他子公司通过 Meta Store Proxy 统一访问这些信息。

最后，用户访问数据时，如果访问本部门或公司的数据，可按照原来的方式进行访问。如果要实现共享数据或数据的联邦查询、分析或任务等，则通过集团公司的数据管理平台访问。访问过程中，代理提供库表信息，访问具体文件时，则使用Alluxio。子公司在访问共享数据时，由于通过数据管理平台访问，所以需要受到集团公司对数据访问权限的控制。此外，由于所有数据在同一个平台中注册，数据的发现和使用、数据资产的管理变为集中化的方式。

以上就是基于 Alluxio 的数据联邦场景下的解决方案。

最后，欢迎大家关注 Alluxio，谢谢大家。

06问答环节

Q1：存储计算一体是不是没有优势了？

存储和计算一体化的方式，在我看来具有很大的优势，但同时也需要解决一些问题，关键是要看系统发展的阶段、处理的数据量和任务数量有多少。如果任务量不是特别大，只需要一个框架或者几个系统就可以解决的情况下，仍可以考虑使用存储和计算一体化的方式，因为它高效且管理方便。但如果部门众多、数据量很大、数据分散或成本很高，或者存储软件已经达到瓶颈，就需要考虑将计算和存储分离的架构，当然前提是在集群扩容或升级软件的基础上，综合考虑更多的方案。

Q2：分享中提到的都是 HDFS 或者对象存储机对接，对于 GPFS、NFS、 GlusterFS 这些存储系统的混合存储，在每个工作节点都需要安装这些存储的客户端挂载本地目录，用 Alluxio 管理这些存储系统，是否有更优雅的方案？

首先，数据需要存储在存储系统上，因此在工作节点上挂载客户端并安装客户端以挂载本地目录是不可避免的。因此，引入 Alluxio 缓存来进行交互时也需要以客户端安装和挂载本地目录为前提。这项工作是不可避免的。

不过，在我们正在讨论的场景中，用户可能会使用二三十个 NAS 存储，但每个 NAS 上存储的数据量和文件数量都不希望过多。这是因为如果小文件数量过多，数据文件的访问效率和性能会急剧下降。因此，对每个 NAS 上的存储容量和文件数量进行限制是必要的。

如果数据增加了怎么办？解决方法是引入更多的 NAS 集群。现在要考虑的方案是将这些 NAS 数据移动到对象存储中存储。因为对象存储不考虑之前 NAS 的限制，但是对象存储的性能可能不能与 NAS 相媲美。因此，我们考虑将对象存储和 Alluxio 结合起来，以替代 NAS 或者共同使用，这是另一个解决方案。因此，如果数据仍然需要存储在存储系统中，我认为引入 Alluxio 是不必要的。但是，如果考虑引入另一种类型的存储，如分布式文件系统或对象存储，那么 Alluxio 可以帮助用户解决许多问题。

Q3：社区版是否也支持 union 挂载和数据迁移引擎能力？

现在社区版没有这项功能的，只有 Alluxio 企业版有该功能。

以上就是本次分享的内容，谢谢大家。