链载Ai

标题: AI 时代的数据底座：火山引擎多模态数据湖的设计与实践 [打印本页]

作者: 链载Ai 时间: 1 小时前
标题: AI 时代的数据底座：火山引擎多模态数据湖的设计与实践

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;color: rgb(0, 0, 0);font-size: 14px;text-align: justify;visibility: visible;line-height: 2em;">导读随着大模型的发展和应用，文本的边界被拓宽，图像、视频、语音各种模态涌现，并给数据管理、检索、计算带来巨大挑战。火山引擎多模态数据湖解决方案则可实现海量结构化、半结构化及非结构化数据的统一精细化管理，全方位兼容各类数据格式，为 LLM 预训练、持续训练和微调全程各个环节提供更好的数据支持。

主要内容包括以下几个部分：

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;visibility: visible;">1.数据湖在 AI 时代下的难点和挑战

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

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 1.5px;line-height: 2em;">3.未来演进和思

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

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

AI 时代带来的变化之一，是非结构化数据处理占比变大。传统数据湖聚焦于处理结构化数据，而 AI 时代下需要对图像、音视频等非结构化数据进行处理。非结构化数据使用 CPU 算力处理效率不高，因此需要借助 GPU 算力资源来提高处理效率。

传统数据湖常使用基于 BSP 架构的 Spark 引擎，在调度、数据传输、资源利用率上对 GPU 不够友好。如上图所示，多个 data partition 在不同阶段使用 CPU 和 GPU 计算时，容易出现资源空闲，造成较大的成本浪费。

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

基模用户和领域大模型用户，在做数据准备中常常会遇到以下问题：

（1）存储带宽瓶颈

模型训练前的数据准备阶段，单次任务处理数据多，耗时长。一份数据在任务中会被多次读取加工。
任务直接读写对象存储 Bucket 数据，会产生很大的带宽和 QPS 压力。
单次任务的耗时、多任务并发时整体任务的吞吐量都受限于带宽和 QPS，会成为数据准备任务的瓶颈。

（2）高负载和小文件

相对传统数仓而言，高负载和小文件问题呈指数级放大，模型训练场景下会产生百万级的 Spark partition shuffle 压力，原生 Shuffle、开源集中式 Shuffle 如 celeborn，均无法稳定高效处理。
高负载和高并发下，原生的 Spark history server 容易出现崩溃或者页面无法打开等问题。
任务失败后的重试成本高。

（3）自定义运行环境

数据准备阶段的不同任务，往往需要一些第三方的库包，比如算法函数、硬件加速相关包等，不同任务依赖的库包甚至会是互相冲突。
传统大规模计算集群，在运行节点上预先安装好各种依赖包，提供环境级别的隔离，已无法满足需求，当下需要的是提供任务级别的自定义运行环境。

因此在 AI 时代下，为保障数据处理任务高效运行，急需对平台进行升级。火山引擎给出的解决方案是多模态数据湖。接下来，我将介绍火山引擎多模态数据湖的架构设计，以及对上述问题的解决方案。

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

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

火山引擎多模态数据湖可以支持数据从数据源到 Data Agent、商业智能等数据应用全流程。

（1）数据源：与传统数据库相比，除了结构化数据，还支持半结构化数据，以及非结构化数据，比如文本、图片、音频和视频。

（2）数据应用：可以承接传统的数仓任务，比如报表业务、实时数据仓库等；还可以支持模型训练、训练数据准备，以及快速搭建 AI 应用（如 RAG 应用）。

（3）多模态数据湖架构：包括湖管理、湖计算、湖存储。

湖管理：

全域数据集成 DataSail：数据入湖。

AI 数据湖服务（Lake AI Service，LAS）：提供了统一元数据及权限管理的能力。这一层之下需要接入不同的数据源，之上需要对接不同的计算引擎，要使一份数据可以被多个引擎处理，则需统一元数据管理，LAS 即为这样的平台。

大数据研发治理套件 DataLeap：提供了 Data+AI 的统一数据开发平台，具有找数助手、开发助手、运维助手等功能，例如可以通过自然语言生成 SQL 并检索展示数据。
湖存储：存储结构化和非结构化数据，支持开发的湖格式(Iceberg、Hudi、Paimon)，以及湖存储加速引擎 Proton。
湖计算：支持火山引擎多款数据产品，包括大数据平台 E-MapReduce、流计算 Flink、自研支持向量化读写的 OLAP 引擎 ByteHouse。

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

开箱即用（进得来）：在传统企业上云场景下，已经有多云部署的趋势，在AI时代下，特别是模型算法公司，需要数据湖是透明、数据 Open。
开源兼容（出得去）：与开源技术栈完全兼容，可无缝多环境迁移部署，不 Lock In 用户。
轻量运维（管得住）：垂直类模型公司的工程师以算法为主，不擅长底层设施的维护，需要尽可能降低运维的门槛。
成本优化（用得省）：通过全托管、弹性伸缩、冷存归档等手段，结合预约按量付费实例等计费方式，降低用户的使用成本。
极致性能（算得快）：通过优化计算引擎内核、计算链路，实现实质性提效。
AI云原生（做得强）：专为多模态数据设计，与AI混合大数据协同发展，以适应各种场景需求。

3. 火山引擎多模态数据湖方案产品

以上是火山引擎多模态数据湖方案涉及的产品。

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

上图中展示了 EMR 产品架构。

2024 年 EMR 扩充了很多 Data for AI 相关能力，正式商业化了 Serverless 和容器形态，提供 Spark 和 Ray 两套 AI 引擎，支持 CPU+GPU 异构计算架构，具备以下特点：

允许用户基于 EMR 基础镜像，灵活打入第三方包。通过自定义镜像方式实现任务级别的运行环境自定义。
针对高负载和小文件等问题，进行了性能优化。基于原生 Celeborn 实现优化，支持 500 万级别的 Partition Shuffle，远超传统数仓容量规模，并提高了 Spark History Server 的稳定性。
抖音集团内部孵化 Spark Native Engine，相比 Spark 开源版本，性能提升达到了 2.5 倍以上。
此外，针对用户体验进行了优化，提供了丰富的弹性伸缩类型和付费方式，满足各种场景需求。
EMR 产品可以与其它云产品，如数据集成 DataSail、大数据研发治理套件 DataLeap 等高度适配，提供一站式 Data+AI 开发、调试、运行和诊断平台。

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

相比 Spark BSP 架构，Ray 的 Pipeline 模式能更充分地利用资源，同时减少数据落磁盘 IO 操作，在内存中处理数据，提高整体性能。

EMR 针对性地结合 Ray 的 autoscale 能力，灵活伸缩保证资源利用率，还丰富了监控指标，在原有 Ray Dashboard 的基础上，通过 Ray History Server 提供持久化的任务日志，并且集成了各种湖格式，提供开箱即用的数据读写。

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

Proton 是一款 EMR 团队自研的数据湖加速引擎，旨在消除不同负载和存储间的 GAP。

Proton 的核心特性包括：兼容 Hadoop FileSystem 语义；数据加速功能与引擎组件解耦，对存储透明，非 Proton 写入的数据也可在读取时加速；提供了元数据加速的能力，可大幅减少对象存储 QPS 需求；提供了灵活的淘汰机制，如白名单、黑名单、关键字匹配，用户可自定义缓存策略以满足不同需求。

未来展望与思考

横向看，我们将进一步拓展应用场景，将数据湖能力从数据准备阶段，扩展到离线推理、模型部署阶段；同时，支持用户快速构建 AI 应用。

垂直看，我们将增强现有能力，提高 GPU 链路产品能力，包括可观测性和资源效率的提升；另外，提升产品易用性，持续降低数据处理功能的使用门槛。

如果大家对以上多模态数据湖解决方案感兴趣，欢迎填写问卷、免费试用：

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

欢迎光临链载Ai (https://www.lianzai.com/)