大模型时代来了，文本、图像、视频、语音……多模态数据大量涌入，传统数据湖已难以应对。数据规模暴涨、计算资源从CPU向GPU迁移、处理任务对效率与灵活性的要求急剧提升——这些变革正在推动数据管理方案进行一次系统性升级。火山引擎多模态数据湖方案正是为应对这些新挑战而设计。

本文从三个层面展开：首先剖析AI时代数据湖面临的实际痛点，然后拆解火山引擎多模态数据湖的架构与设计思路，最后探讨其未来的演进方向。

01 数据湖在 AI 时代下的难点和挑战

1. 计算资源从 CPU 扩展到 GPU

AI时代最显著的变化是非结构化数据成为主角。传统数据湖主要处理结构化数据，但大模型训练需要大量图像、音视频等非结构化数据。这类数据用CPU处理效率偏低，必须引入GPU算力。

然而，传统数据湖普遍采用基于BSP架构的Spark引擎，对GPU并不友好——调度机制、数据传输方式、资源利用率都难以适配。例如，多个数据分区在不同阶段交替使用CPU和GPU时，容易产生计算资源闲置，造成不小的成本浪费。

2. 数据处理任务对效率、稳定性和灵活性要求高

无论是基模训练还是领域大模型的应用，数据准备阶段都会遇到几个“硬骨头”：

（1）存储带宽瓶颈

• 单次任务需要处理海量数据，耗时较长，且同一份数据往往被反复读取加工。
• 直接从对象存储Bucket读写数据，会给带宽和QPS带来巨大压力。
• 无论是单个任务的耗时，还是多任务并发的吞吐量，都受制于带宽与QPS，成为整个数据准备流程的瓶颈。

（2）高负载和小文件

• 相比传统数仓，AI场景下的高负载和小文件问题被指数级放大。模型训练会产生百万级的Spark partition shuffle压力，原生Shuffle机制甚至开源的Celeborn都无法稳定高效处理。
• 在高负载和高并发下，原生的Spark History Server经常崩溃或页面无法打开。
• 任务一旦失败，重试成本非常高。

（3）自定义运行环境

• 数据准备阶段的不同任务，往往需要不同版本的第三方库包（如算法函数、硬件加速包），这些依赖之间还可能互相冲突。
• 传统做法是在集群节点上预装各种依赖包、提供环境级隔离——如今已无法满足需求，实际需要的是任务级别的自定义运行环境。

因此，在AI时代要保证数据处理任务高效运行，平台必须升级。火山引擎给出的答案，就是多模态数据湖。

02 火山引擎多模态数据湖介绍

1. 火山引擎多模态数据湖架构

火山引擎多模态数据湖覆盖了从数据源到数据应用的全流程。与传统数据库不同，它不仅能处理结构化数据，还能处理半结构化和非结构化数据（文本、图片、音频、视频）。

在数据应用层，它可以承接传统数仓任务（报表、实时数仓等），也能支撑模型训练、训练数据准备，以及快速搭建AI应用（如RAG应用）。

架构本身分为三块：

• 湖管理：包括全域数据集成DataSail（负责数据入湖）、AI数据湖服务LAS（提供统一元数据和权限管理，让一份数据能被多个引擎处理）、大数据研发治理套件DataLeap（提供Data+AI统一开发平台，支持自然语言生成SQL等功能）。
• 湖计算：支持火山引擎多款数据产品，如EMR（大数据平台）、Flink（流计算）、ByteHouse（OLAP引擎，支持向量化读写）。
• 湖存储：存储结构化和非结构化数据，支持开放的湖格式（Iceberg、Hudi、Paimon），以及湖存储加速引擎Proton。

2. 火山引擎多模态数据湖设计理念

这套方案的设计理念可以概括为六个关键词：

• 开箱即用（进得来）：企业上云时往往已有多云部署趋势，AI公司尤其需要数据湖透明、数据开放。
• 开源兼容（出得去）：完全兼容开源技术栈，用户可以无缝迁移到其他环境，不会被锁定。
• 轻量运维（管得住）：垂直类模型公司的工程师以算法为主，不擅长底层运维，必须降低运维门槛。
• 成本优化（用得省）：通过全托管、弹性伸缩、冷存归档，以及预约按量付费等计费方式，帮用户节省成本。
• 极致性能（算得快）：优化计算引擎内核和计算链路，实现实质性提效。
• AI云原生（做得强）：专门为多模态数据设计，让大数据和AI协同发展。

3. 方案涉及的产品

（此处为原文图片，保留产品全景图）

4. EMR 多产品形态提供 Data 和 AI 计算引擎

（此处为原文图片，展示EMR产品架构）

2024年，EMR扩充了大量Data for AI能力，正式商业化了Serverless和容器形态，提供Spark和Ray两套AI引擎，支持CPU+GPU异构计算。它的特点包括：

• 允许用户基于基础镜像灵活打入第三方包，通过自定义镜像实现任务级别的运行环境自定义。
• 针对高负载和小文件问题做了性能优化——基于原生Celeborn改进后，能支持500万级别的Partition Shuffle，远超传统数仓容量，同时提升了Spark History Server的稳定性。
• 抖音集团内部孵化的Spark Native Engine，相比开源版本性能提升2.5倍以上。
• 提供了丰富的弹性伸缩类型和付费方式，适应各类场景。
• EMR可以与DataSail、DataLeap等产品高度配合，提供一站式Data+AI开发、调试、运行和诊断平台。

5. 使用 Ray 对多模态数据做高效处理

与Spark的BSP架构相比，Ray的Pipeline模式能更充分地利用资源，同时减少数据落盘的IO操作，在内存中处理数据，整体性能更高。EMR结合Ray的自动伸缩能力，灵活保障资源利用率，并丰富了监控指标——在原有Ray Dashboard基础上增加Ray History Server，提供持久化的任务日志，还集成了各种湖格式，实现开箱即用的数据读写。

6. 使用 Proton 实现数据湖加速

Proton是EMR团队自研的数据湖加速引擎，旨在消除不同负载和存储之间的鸿沟。其核心特性包括：兼容Hadoop FileSystem语义；数据加速功能与引擎组件解耦，对存储透明——非Proton写入的数据在读取时也能加速；提供元数据加速能力，大幅减少对象存储的QPS需求；支持灵活的淘汰机制（白名单、黑名单、关键词匹配），用户可自定义缓存策略。

03 未来展望与思考

（此处为原文图片，展示未来演进方向）

从横向看，火山引擎计划进一步拓展应用场景——把数据湖能力从数据准备阶段扩展到离线推理、模型部署阶段，同时支持用户快速构建AI应用。

从垂直看，会增强现有能力，提升GPU链路的产品能力（包括可观测性和资源效率），同时提升产品易用性，持续降低数据处理功能的使用门槛。

从根本上说，多模态数据湖的演进不仅是一次技术升级，更是整个数据基础设施在AI时代的一次重新定义。