Alluxio：面向 AI 计算的高性能数据访问平台

导读 随着技术发展，涌现出很多不同的数据架构，比如数据湖、湖仓一体、Data Fabric、Data Mesh 等，都是当前业界前沿的数据架构。本文将介绍目前主流的大数据技术栈和企业数据平台架构的最新发展趋势，并介绍Alluxio 产品所能带来的价值。

主要内容包括三大部分：

1. 大数据技术栈、企业数据平台趋势、Alluxio 架构定位

2. Alluxio 典型应用场景及核心能力

3. Alluxio 全球客户案例分析

分享嘉宾｜张青锋

编辑整理｜韩松

内容校对｜李瑶

出品社区｜DataFun

01

大数据技术栈及企业数据平台趋势，Alluxio 架构定位

目前大数据技术栈最新的发展趋势主要包括三大方面：

• 存算分离架构

传统的大数据计算引擎基本都是紧耦合的。比如 Map Reduce、Hive 和 HDFS 是紧密耦合的，是部署在一起的、存算一体的架构。随着业务的发展，目前业界也在做一些解耦工作。比如把 Spark 引擎跟 HDFS 引擎分开部署，这样实现了一定程度的存算分离，计算跟存储不再位于同一台主机上。

另外，还有一些更复杂的业务场景，比如多集群下会有多数据中心，K8s 集群在一个数据中心，计算引擎 Spark、Presto 放到另外一个集群中心。另外也引出了新的公有云的架构、私有云的架构、混合云的架构，以及更多的计算框架，包括 Spark、Presto、Flink 等等。现在也会有更多的存储框架，除了传统的 HDFS，还有对象存储等。

这些都是存算分离架构的发展。存算分离架构带来的好处显而易见，它解决了传统的计算和存储弹性伸缩及灵活扩展的问题。但同时也带来了一些问题，最大的问题就是计算性能的下降，因为缺少了数据本地性，存算分离架构之间会存在网络开销。

• 云原生技术应用

近些年大数据业界不断推动大数据云原生技术，比如大数据计算引擎（Spark）的云原生改造，基于 K8s 容器引擎对 Spark 进行部署。

在存储侧 HDFS 也在做一些云原生改造，比如最新的大数据对象存储引擎 Ozone，是一种对象存储。目前很多云上或者线下的对象存储，也在提供一些 HDFS、HCFS 接口来支持传统大数据分析，这些都是云原生技术在大数据技术栈上的应用。

云原生改造主要是为了提升扩展性和资源弹性，同时也带来了计算的弹性扩展，降低了整体的物理资源成本。但是对象存储存在一定的性能问题，跟原生的 HDFS 存储相比，在 list fail 功能以及一些原子操作上，性能相对来说并不理想。

• 数据湖/湖仓一体、MPP/云原生数据库架构演进

无论是数据湖还是湖仓一体，底层都是基于 HDFS 或对象存储等底层存储系统，在底层存储系统之上利用 Iceberg、Hudi、Delta Lake 等湖表格式支持一些分析场景，比如数据探索、OLAP 分析、机器学习等等。另外数据仓库现在也做了一些扩展，对接更多的数据湖存储，最终支持更广泛的分析场景。

在湖仓一体方面，有很多 MPP、云原生数据库，像 ClickHouse、Doris、TiDB 等新的数据库层出不穷。都在做一些云原生和存算分离架构的改造，支持对象存储，支持更多的数据湖的存储，支持容器化部署等。

存算分离趋势下的数据库、数据湖、湖仓一体技术实现了资源弹性，湖仓一体进一步实现了统一元数据、统一存储，以及减少数据冗余的目标。但是在底层存储系统(HDFS/对象存储)之上引入湖表结构层设计可能带来 IO 性能损失，需要统一的缓存加速层、统一接口支持。

以上就是大数据技术栈及企业数据平台架构整体的发展趋势。接下来介绍几个比较容易混淆的词。

• 数据编织/Data Fabric
  数据编织的核心是提供数据架构各结点之间的点对点的连接，数据结点可以是一个数据源，可以是存储系统，也可以是内外部的应用程序等。Data fabric 要实现将现有数据管理系统和应用系统编织在一起，提供可重用的 Pipeline 服务。这种 Pipeline 服务类似传统的 ETL 处理流程，涵盖数据集成、访问、转换、建模、可视化、治理和交付等。偏传统 ETL 方式的集成架构，Data Fabric ETL/CDC、DataOps。
• 数据编排/Data Orchestration
  数据编排和数据编织只差了一个字，非常容易混淆。数据编排的核心是要提供跨异构存储系统的全局统一命名空间以拉通不同存储的数据，屏蔽底层存储系统的技术差异及安全框架集成的复杂性。面向上层数据计算提供统一的数据访问接口(API）以支持应用层进行灵活的数据编排、数据编织、数据虚拟化、数据网格应用。另外，通过缓存加速、策略化数据管理等方式提升数据访问/编排的效率。数据编排是介于存储计算之间的中间层设计，代表厂商有 Alluxio。
• 数据虚拟化/Data Virtualization
  数据虚拟化是一种新的数据集成策略，物理上不将数据移至新的位置，而是提供整合式的虚拟视图，源数据则保留在原处。可以建立企业数据访问层，提供对组织所有关键数据源的通用访问，在需要访问数据时，业务用户可以查询数据虚拟化层。同时提供数据连接、发现、转化、准备、交付、发布、治理等操作。核心是基于元数据层构建轻量化的虚拟数据层，管理的是元数据，数据还是停留在原来的物理数据源。代表厂商有 Denodo。
• 数据网格/Data Mesh
  数据网格目前还处于一个快速发展的初级阶段，还没有一些代表的厂商或产品，更多的是一种前沿的数据管理的架构思想。数据网格有四个基本的建设原则，分散数据所有权、数据即产品、自助数据的基础设施以及联合治理。其核心是去中心化的数据架构设计，通过将系统划分为由较小的职能团队管理各自的数据，来实现整体的数据管理，解决大型、复杂、单体数据架构问题。

Alluxio 的定位是支持数据虚拟化和数据网格等现代化架构的基石。

目前企业数据平台架构非常复杂，随着企业的发展，面临更多的集群，比如大数据集群、MPP 数据库集群、存储集群，还有更多的数据中心，包括同城的数据中心、异地的数据中心，更多的混合云和多云环境，既有本地的部署，又有公有云的部署，还可能同时跨几个公有云。另外基础组件也更加复杂，有数据湖、MPP 数据库，以及很多云原生的计算引擎等等。

我们所面临的挑战包括两个方面：

• 数据的趋势
  每天产生越来越多的数据，存放在不同的存储中，形成了数据孤岛。
  还会增加越来越多的人、越来越多的团队，以不同的方式、不同的 API、不同的业务角度使用这些数据，而且需要在这些数据之间做共享和分享。
  近年来技术栈发展速度非常快，平均 3—8 年就会创造出新的计算引擎和存储技术。
• 繁杂的平台
  从 Spark 到 Presto，再到向量化的计算引擎、流式计算的引擎、存算一体的引擎，很多新技术不断涌现，使得传统的数据共享、数据复制、数据同步成本越来越高。
  随着不同的计算引擎和存储引擎的推出，应用需要非常频繁地去适应各种 API 以及系统集成的改造。
  存算分离架构发展，本地集群、公有云、混合云和多云环境特性各不相同，也带来了很大的挑战。

升级数据平台时的场景主要有四个：

• 一是混合云或多云部署，云上应用需要访问本地数据或者本地应用需要访问云上数据。
• 二是采用新的数据架构，这种架构可以适应数据位于本地或多云环境，或者采用数据湖、数据编织、数据虚拟化等新技术。
• 三是平台扩展/增加新的应用，搭建新的数据驱动型应用需要访问位于不同位置的数据，同时扩展平台支撑新的应用团队。
• 四是从旧有系统迁移，从传统 Hadoop 架构迁移到能够原生支持云环境的现代数据栈（对象存储、数据湖、云原生数据库）。

在实现以上场景中会遇到很多挑战，比如数据孤岛、数据迁移问题，可能需要跨数据中心、区域和云环境创建数据副本，需要高昂的网络流量成本，同时云成本和硬件花费也会导致架构成本较高。还有平台扩展和租户隔离问题，需要根据应用类型使用不同数据接口，要解决应用重写及接口不一致问题。

下面来看一个具体的例子，现在普遍面临的问题——跨数据中心、跨区域、跨多云的数据孤岛问题。

可以看到图里有 4 个集群，最左下端是最传统的一个本地的大数据集群，这里是传统的大数据业务，比如有 Hadoop 集群，上面跑了很多分析的应用，包括 Hive、Spark、Presto 等。也引入了一些数据湖的应用。

随着业务的发展，企业有新的需求，比如机器学习、人工智能，企业需要构建新的基于机器学习的计算引擎，引入 PyTorch、TensorFlow 这种计算引擎。同时机器学习需要大规模的数据存储，一般会采用对象存储，因此构建了一个本地的对象存储的集群。大数据集群需要为机器学习的集群做很多前期的数据准备，比如ETL。在一个集群做完 ETL 之后，数据需要拉到另外一个集群去访问，因此存在跨区域数据拉通的问题。

随着技术的进一步发展，会把一部分的计算放到云上（谷歌云、亚马逊云），云上的计算又需要拉取本地的数据进行访问。

再下一步，企业可能实现了多云的部署，需要在 AWS 和 GCP 之间做数据的互访。传统都是通过 ETL，无论是数据迁移还是数据复制，都是人工 ETL，而且需要管理非常复杂的 ETL 任务，非常容易出错。

为了解决上述问题，引入 Alluxio 数据编排架构。在四个不同的存储集群各部署一个Alluxio 集群，这样即可拉通不同的存储系统。可以把数据湖的存储挂接上，也可以把机器学习集群中的 MINIO 集群挂载上，还可以把云上的 S3 存储挂载上，这样在 Alluxio 中就可以看到来自三个不同的数据中心的数据集群。同样在云上也可以部署一个 Alluxio 集群，同时可以挂在本地的，比如 Azure 的数据存储、S3 的数据存储，还可以把本地的设备挂载上，在云上实现全局统一的数据视图。还有一种部署方式，集群不是部署在云上，也不是部署在本地，而是部署一个共享的 Alluxio，在共享 Alluxio 集群中可以同时把 4 个地方的集群全挂载上，提供给 4 个不同的计算集群使用。

这样，通过 Alluxio 实现了四个统一，统一命名空间、统一数据访问、统一缓存加速、统一安全管控，帮助我们实现跨数据中心、跨区域、跨多云的数据分析，实现跨数据孤岛的无拷贝的数据访问，也可以实现跨计算引擎和多云环境的应用程序可移植性，不需要再针对不同的存储和不同的计算修改原有应用系统的 API 接口或应用的大规模移植和改造。

Alluxio 企业数据平台架构的核心思想是在存算分离架构上提供统一的数据编排层。数据编排层可以帮助我们实现统一的命名空间、统一的数据访问、统一的缓存加速以及统一的安全管理。解决计算存储分离架构下缺乏数据稳定性带来的性能下降问题，以及存算分离架构带来的网络成本开销问题和跨各种异构存储及计算的统一接口访问的问题。

Alluxio 的核心价值即“四个统一”：

• 统一命名空间：拉通跨区域、跨异构技术栈的不同存储系统，实现存储系统的统一数据视图。
• 统一数据访问：针对计算层提供统一的 API 接口转换及访问。
• 统一缓存加速：部署缓存应用需要的热数据，让数据离计算层更近，从而提升计算的整体性能，并节省计算跟存储之间的带宽。
• 统一安全管理：编排层可以针对计算层屏蔽不同底层存储的安全认证机制，降低安全集成的复杂性，构建统一的安全管理机制。

02

Alluxio 典型应用场景及核心能力

下面介绍 Alluxio 的典型应用场景。

Alluxio 是一个统一的数据访问和编排平台，可以帮助我们实现使用任意计算引擎、任意 API 快速访问任意存储系统。Alluxio 是一个位于存储和计算之间的数据编排层，可以针对大规模数据分析和 AI 计算进行优化。提供各种跨数据源的数据抽象，提供环境无感知的方案。

Alluxio 应用场景包括单一部署、混合云部署、跨数据中心/多云部署等。

• 单一部署
  可以基于本地也可以基于公有云，比如本地有一个大数据集群使用 Hadoop、Presto，或者是单一的公有云，比如 AWS 上的 S3 集群，上面跑 TensorFlow。Alluxio 在这样单一的环境中可以提供上述四个统一的能力。
• 混合云部署
  现在很多企业可能面临一些服务在本地集群，一些在云上。在公有云和本地部署之间，Alluxio 可以实现数据拉通、存储拉通，并实现统一的访问。
• 跨数据中心/多云部署
  更复杂的情况就是跨数据中心、跨多云的部署，既有本地的数据中心，又有跨不同公有云的数据，Alluxio 在这种架构下也可以实现数据的统一编排和统一访问。

下面来介绍一些具体的应用场景。

第一个场景是统一存储网关。存储和计算一般是整个数据架构中最大的两块。现在的存储选型非常多，在大数据里有传统的HDFS，而越来越多的云原生应用更多的是使用对象存储，比如 AWS 集群、MINIO 集群，云上 S3 对象存储等等。原来这些对象存储之间接口会存在不一致，Hadoop 是 HDFS 接口，而对象存储一般都是 S3 标准。原来跨不同的存储计算，需要做不同的接口适配，很多时候用户需要提供一个统一的虚拟存储层，提供统一的数据访问接口。

Alluxio 可以做一个统一的存储网关，连接本地 MINIO 集群、HDFS 集群、云上的 S3的集群，在这些之上可以同时提供 HDFS 接口、S3 接口，甚至提供 Presto 接口。针对上层的无论是 Spark 计算引擎，还是 Presto 或 Pytorch 机器学习的引擎，都可以提供统一的数据访问，相当于实现了一个虚拟的存储网关，不但实现了存储接口的适配，还可以提供缓存服务，使数据更靠近计算，提升计算的性能。

这里利用到了 Alluxio 统一命名空间的能力，可以提供跨不同存储系统统一的虚拟视图，将 HDFS、NFS、MINIO 等存储系统拉通。

第二个应用场景是数据湖或者数据湖联邦的场景。现在企业中数据湖的应用很多，有基于云上的，有基于本地的，通过 Alluxio 建立跨本地数据湖和跨云上数据湖的虚拟数据湖，可以打通两个不同区域的数据湖，实现统一的命名空间，统一的数据访问。

上图展示了 Alluxio 在数据湖架构中的定位。最底层是存储，无论是 HDFS 还是对象存储。上面是数据加速层，Alluxio 就是在这一层，提供对数据湖数据以及元数据的统一加速。在此之上是数据湖的公开文件格式，比如 Parquet、ORC、AVRO 等等。再上面是湖表格式，如 Hudi、Iceberg、Delta Lake。最上面是计算引擎。

Alluxio 处于相对底层的位置，为数据库底层文件层提供统一的缓存加速，统一的API 转换，统一文件系统的接口转换。

利用的核心能力是 Alluxio 的统一数据访问接口能力，跨多种不同存储引擎面向上层计算引擎提供统一访问 API。

第三个场景是 Alluxio 的 BI/OLAP 分析缓存加速。常用的计算引擎，如 Spark、Presto，在大数据量下可能存在一些性能问题，Alluxio 会提供整体缓存加速，把数据尽量拉近到计算侧，加速计算性能。不仅可以带来查询分析性能的提升，还可以对底层 HDFS 集群的负载分流。

利用到的核心能力就是 Alluxio 统一分布式缓存加速能力。Alluxio 可以利用内存、SSD 以及 HDD 做分层的缓存加速，可以把大量的热数据放到 Alluxio 里提供整体的缓存加速。

第四个场景是 AI/ML 应用场景。很多机器学习场景中存在海量小文件，目前通用的解决方案是放到对象存储中，但对象存储也可能存在性能问题，因此会在对象存储上提供加速功能，Alluxio 就可以通过它的缓存以及 POSIX 接口，为机器学习的引擎提供加速。

主要利用的能力是 Alluxio 的 POSIX API，在对象存储之上提供 POSIX 接口。现在Pytorch、TensorFlow 原生都是 POSIX 接口，提供 POSIX 接口支持现有的 native 的机器学习引擎所需要的文件接口。同时数据可以利用成本更低、可靠性更高、扩展性更好的多样存储来做海量数据的存储。

最后要分享的一个场景是跨集群/异构存储冷热数据分层及备份应用场景。历史数据以及实时数据是一个非常核心的问题，历史数据量很大，很难存在比较热的存储中，所以通常会分热存储和冷存储。比较新的方式是对象存储偏冷一点，IDS 偏热一点。要透明地实现冷热数据之间有分层存储，一般要做一些任务调度、ETL 等等。

Alluxio 具有统一策略化数据管理能力，可以实现透明的冷热数据分层。用户可以定义一些数据策略，比如定义 7 天的数据是热数据，Alluxio 会自动把这些数据放到热存储中。当数据过了 7 天之后会自动搬到冷数据上。当访问的时候又会自动地把数据从冷数据调到热数据，实现基于策略的透明化的冷热数据分层。

上图中总结了 Alluxio 在统一命名空间、统一数据访问/编排、统一缓存加速以及统一策略化数据管理四大方面的核心能力。

Alluxio 通过上述能力，带来了更高的 ROI、更低的 TCO、驱动业务敏捷性并提高营收和防止厂商锁定等一系列的商业价值，以及通过缓存减少数据拷贝、提供统一的数据访问接口、支持多租户架构等技术价值。

03

Alluxio 全球客户案例分析

最后分享一个 Alluxio 的全球客户案例，即 Expedia 构建基于公有云的跨地域虚拟数据湖的案例。

Expedia 是美国一个非常大的在线旅游酒店厂商。它之前收购了很多品牌，这些品牌在被收购之前都在 AWS 上构建了不同的数据湖，有的用的是 Databricks，有的是用传统的数据湖架构等等，形成了一些数据孤岛。并购之后需要实现跨多个数据孤岛进行集中式的数据分析，原来需要做很多 ETL，效率非常低，而且跨 region 之间存在很高的网络流量的成本。

Alluxio 为 Expedia 提供了虚拟数据湖方案。通过 Alluxio 在美东构建了一个虚拟数据湖，通过虚拟数据湖拉通了几个区域分散的数据湖，实现了统一的分析，缩短了分析时间。

该场景的技术目标是构建一个整体的虚拟数据湖，提供可定制化的数据堆栈，为用户提供性能、一致性及稳定性。面临的挑战主要就是数据孤岛间的数据复制。

Alluxio 为其提供了一个虚拟数据湖的解决方案，主要包括三部分：

• 存储集成
  基于 Alluxio 提供的统一全局命名空间，整合了不同区域的远程数据，所有的远程数据都可以挂载到 Alluxio 命名空间，这样就不需要将数据从多个存储孤岛复制到主数据源。
• 计算集成
  集成了原来数据平台上的 Databricks、Hive、Jupyter 等计算引擎，现在所有计算引擎只需要与 Alluxio 对话，不再需要从远程数据湖中获取数据。
• Catalog 集成
  集成 Waggle Dance 作为 Hive Metastore 转换服务，如果表数据存储在远程会将表路径转换为 Alluxio URI。Hive、Spark、Trino 或 Databricks 执行的 SQL 查询都指向指定位置的同一目录。

Alluxio 解决方案显著提升了查询性能，使管理非常简单方便，同时大幅节省了相关成本。

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

往期推荐

点个在看你最好看

SPRING HAS ARRIVED