‌Daft：AI 驱动的多模态数据融合引擎

2025-09-21
广东
本文字数：8211 字
阅读完需：约 27 分钟

一、前言

在 AI 应用快速发展的今天，海量多模态数据的处理已成为构建高质量 AI 系统的核心挑战。火山引擎推出的 LAS Daft 数据处理引擎，正是为解决这一难题而设计的创新解决方案。

LAS Daft 基于云原生湖仓一体架构，整合了开源分布式执行引擎 Daft 的强大能力，实现了对图文、音视频、点云等多模态数据的统一处理。该系统覆盖了从数据清洗、格式转换到零拷贝对接训练框架的完整数据处理流程。

本文主要讲解 Daft 在分布式 Python 计算、多模算子处理、流式调度等方面的核心设计，以及在智能驾驶大规模数据处理、LLM 离线推理等实际应用场景中的落地经验，探讨如何在保证成本可控的前提下，实现 AI 数据处理能力的可扩展性与工程化落地。

二、AI 带来的数据湖变革

2.1 AI 在 Data 场景下的新兴需求

新兴需求呈现为四层金字塔结构，每层包含核心变革方向及具体表现。

从应用层来看，其核心是“智能形态涌现”。当下，像 ChatBI、Agent、智驾、基模、具身等各类智能应用不断出现，这表明 AI 在实际应用中的形态变得更加丰富多样，不再局限于单一的功能实现，而是向更复杂、更智能的方向发展。
管理层的关键在于“元数据模式变更”。传统的数据管理主要围绕 Database 展开，而现在逐渐转向 Dataset；同时，管理对象也从 Table/View 转变为 Volume/Model/Function。这种变更意味着数据管理的范围和方式都发生了显著变化，需要以更全面、更灵活的方式来管理元数据，以适应 AI 时代数据的特点和需求。
计算层体现出“处理范式的变更”。在硬件方面，从 CPU 向 GPU 转变，GPU 强大的并行计算能力更能满足 AI 计算的需求；在数据处理方式上，从 SQL 转向 Dataframe，Dataframe 在处理大规模数据和复杂数据结构时具有更大的优势；服务模式也从 SaaS 向 MaaS 转变，这反映了 AI 技术在服务提供方式上的创新，使得模型能够更便捷地被使用和部署。
存储层的变革在于“存储介质和格式变更”。一方面，训练对数据 I/O 加载要求不断提升，这就需要存储介质在读写速度等方面有更好的性能；另一方面，存在标签结构化字段与多模数据的统一管理需求，这要求存储格式能够支持多种类型数据的整合和管理，以提高数据的利用效率。

2.2 AI 时代下的技术瓶颈与市场需求

AI 技术的爆发式发展推动数据处理从‌纯文本场景‌向‌文本、图片、音视频等多模态联合场景‌快速演进，多模态数据管理在数据规模、处理复杂度、存储与合规性等方面面临全新挑战，需从技术、安全、效率等维度系统应对。

2.2.1 数据计算需求：规模与复杂度的双重挑战

数据量大‌：多模态数据规模呈指数级增长，PB 级起步，甚至达数百 PB 级。大规模数据对存储、计算资源提出极高要求，高效处理是保障大模型训练稳定性与速度的关键。
‌数据处理难‌：非结构化数据（图文音视）格式多样、结构不规则，且缺乏明确逻辑分块、标识与处理算子，导致数据质量参差不齐，影响后续分析与应用。
作业类型复杂‌：大模型训练与微调需整合多类型、多来源数据，数据类型、格式、质量差异大，作业流程复杂且负载混合（CPU+GPU），需额外资源调度以提升利用率。

‌2.2.2 数据存储需求：异构与合规的双重压力

异构数据管理难度大‌：多模态数据（如文本/文件元信息、视频字幕）与视频/图片等常存储于不同介质与物理区域，管理、检索、计算成本高，技术门槛显著提升。
缺乏有效溯源手段‌：数据集缺乏逻辑血缘与版本信息，数据问题排查效率低，数据准备周期长，阻碍业务敏捷性。
‌安全合规‌：多模态数据含大量敏感隐私信息，对数据使用与运营者的安全合规要求极高，需兼顾数据价值释放与风险管控。

‌‌2.2.3 多模态数据管理的行业实践与技术应对

为破解上述瓶颈，产业界从‌技术工具、治理框架、场景应用‌等维度探索解决方案：

技术工具‌：火山引擎“算子广场”通过语义分块、OCR、AI 工作流编排等能力，助力企业高效处理多模态数据（如社交平台智能化内容审核中，将音视频数据识别准确性与时效性提升至 99.5%）；
治理框架‌：腾讯云“PAI”方法论（流程化、自动化、智能化）与百分点科技“多模态数据治理体系框架”，从理论到实践指导数据治理落地，解决异构数据整合、数据融合场景挖掘等难题；
‌场景应用‌：阿里云瑶池数据库通过“云原生数据库 3.0 架构+AI 内嵌+生态协同”，打造面向 Data+AI 的新型数据管理底座，应对多模态数据的存储与处理需求。

2.2.4 未来趋势：技术融合与生态协同

多模态数据管理需结合‌生成式 AI、联邦学习、知识图谱‌等技术，突破存储、处理、合规等瓶颈。医疗、金融、城市治理等场景的持续验证，将推动多模态数据治理成为数字经济核心基础设施，释放数据要素乘数效应，助力人类社会向“智能共生”新文明迈进。‌2.3 LAS 产品全景图（LakeHouse AI Service）

从图中可以看到 LAS 产品全景图（LakeHouse AI Service）整体呈现出分层架构，各部分相互关联，共同构建起一个全面的 LakeHouse AI 服务体系。

先看最上层，是数据处理的核心流程环节，涵盖数据采集、数据清洗、特征工程、企业搜索、数据洞察和模型训练。这些环节依次衔接，从数据的获取开始，经过清洗和特征工程的处理，为后续的搜索、洞察以及模型训练提供了高质量的数据基础。

中间部分是整个产品的核心功能模块，分为统一元数据、多模态算子平台和智能检索三大块。统一元数据包含了多种集合类型，像 Table 集合、Volume 集合等，还有数据血缘、模型集合等重要组成部分，它就如同整个系统的数据管理中枢，对各类数据和模型进行统一的组织与管控。多模态算子平台则集成了 Source/Sink 算子、Embedding 算子等多种算子，并且提供了算子 API 服务和 Pipeline 模板仓库等，支持多模态数据的处理和流转。智能检索部分能够进行向量索引构建、全文索引构建以及 Hybrid Search 等操作，还具备结果排序和 LLM 检索增强等功能，实现了高效准确的信息检索。

在中间核心功能模块的周围，分布着一些辅助性的功能组件。左侧有库表、文本、图像、语音等不同类型的数据入口，为系统提供了多样化的数据来源。右侧是湖管理和湖计算，湖管理负责对数据湖进行整体的管理，湖计算则支持数据湖中的计算任务。还有数据集管理、任务/工作流编排等功能，它们协同工作，保障了整个系统的稳定运行和高效协作。

最下层是基础支撑部分，包括结构化数据湖和非结构化数据湖，为数据提供了存储场所，而 TOS 对象存储则进一步为数据存储提供了支持，整个架构层次清晰，功能完备。

2.3 Daft 多模计算定位

2.3.1 技术维度：五大“统一”构建全场景数据处理能力

Daft 以“多模态数据湖计算”为核心定位，通过技术架构突破传统工具的场景限制，实现‌数据形态、计算资源、任务阶段、生态工具、部署模式‌的全面兼容：

单机与分布式统一‌
支持“Single（单机）↔ Distributed（分布式）”的无缝切换，既满足小规模场景的轻量部署，又能适配大规模数据的分布式计算需求，降低技术选型与运维成本。
‌多模与结构化统一‌
既兼容结构化数据（如关系型数据库、数据仓库的表结构数据），又能处理多模态数据（如图片、音频、视频等非结构化内容），打破数据形态的处理壁垒，满足 AI 场景下“多模态数据融合分析”的核心需求。
‌CPU 与 GPU 异构统一‌
通过 CPU 与 GPU 的协同调度，兼顾“CPU 的通用计算能力”与“GPU 的并行加速能力”：CPU 负责通用数据处理，GPU 则针对多模态数据（如图像特征提取、音频处理）提供高性能加速，实现计算资源的最优利用。
‌DataFrame 与 SQL 统一‌
同时支持‌DataFrame（AI 团队熟悉的数据处理范式）‌与‌SQL（传统数据分析师/DBA 熟悉的语言）‌，让不同技术背景的团队（如 AI 算法团队、数据分析师）都能高效协作，降低技术门槛。
‌预处理+推理+训练统一‌
覆盖 AI 全流程（数据预处理→模型推理→模型训练），实现“数据准备→模型应用→模型优化”的闭环，减少工具切换成本，提升 AI 开发效率。

2.3.2 生态维度：多工具协同构建完整数据处理链路

Daft 通过整合‌数据存储、ETL、模型训练、多模态处理、搜索与推荐‌等领域的主流工具，形成覆盖“数据全生命周期”的生态网络：

‌数据存储层‌：与 Elasticsearch（实时搜索）、Milvus（向量数据库）等工具协同，实现多模态数据的高效存储与检索。
‌ETL 层‌：支持 Apache Spark、Hive、StarRocks 等工具的 ETL 任务，完成数据清洗、转换与加载。
模型训练层‌：与 Tensor、PyTorch、Dataloader、LLM 等工具联动，支撑深度学习模型的训练与优化。
‌多模态处理层‌：通过 RAY、Audio/Img/Video 等工具，处理图片、音频、视频等多模态数据的特征提取与分析。
‌向量化与嵌入层‌：与 Emb（嵌入模型）、Dataloaders 等工具结合，完成多模态数据的向量化与嵌入表示，为后续分析提供基础。

2.3.3 景价值：AI 时代的“数据处理枢纽”

Daft 的“多维度统一”与“生态整合”能力，使其成为 AI 场景下‌数据湖计算的核心引擎‌：

在‌多模态数据处理‌领域，解决传统工具“存储/计算分离、资源浪费、性能瓶颈”等问题，实现“多模态数据的高效存储、统一计算、全流程处理”。
在‌AI 全流程协同‌中，打通“数据准备→模型训练→模型推理”的技术壁垒，让不同团队（AI、数据、业务）基于同一工具链高效协作，加速 AI 应用落地。

综上，Daft 通过技术架构的创新与生态工具的整合，成为 AI 时代“多模态数据湖计算”的关键基础设施，为数据驱动的业务创新提供底层支撑。

2.4 Daft 计算框架

Daft 计算框架围绕分布式数据处理构建，其核心逻辑分为接口层、优化层、执行层和运行时层，各模块协同工作以实现高效的数据处理。以下是对框架结构的详细解析：

接口层（Interface）提供了双入口支持，降低了使用门槛。Daft 支持 Python API 和 SQL 两种接口形式，开发者可以根据场景灵活选择。Python API 通过 read_parquet、read_csv 等函数加载数据，支持链式调用，实现数据处理流程的直观定义。SQL 接口则通过 Planning 模块将 SQL 翻译为逻辑执行计划，与 Python API 的逻辑计划统一处理，确保接口一致性。

优化层（Optimizer）是框架性能的核心环节，通过 Optimize 模块对数据处理流程进行逻辑优化与物理优化。逻辑优化主要对 join、select、limit 等操作的执行顺序、数据分区策略进行优化，减少冗余计算与数据传输。物理优化则将逻辑计划翻译为可执行的物理计划，如 ScanTaskSource、HashJoinBuild 等，并生成 LogicalPlan，为后续执行层提供高效执行路径。

执行层（Execution）负责将优化后的计划转化为实际计算任务，包含任务调度与执行引擎两部分。任务调度通过 Scheduler 模块将任务分发到 TaskContext，并由 Runner（如 Swordfish、Flotilla）执行。执行引擎则分为 Swordfish Local Engine 和 Flotilla Distributed Engine，前者适用于单机资源处理，后者基于 Ray 实现，可扩展至多节点集群，支持大规模数据并行处理。

运行时层（Runtime）决定了框架的执行模式，支持单机与分布式模式切换。Local Machine 模式适合小规模数据处理或开发调试，而 Ray Cluster 模式则通过 Ray 集群扩展计算资源，满足大规模数据的并行处理需求。框架的核心特性包括分布式模式切换、执行器架构和优化器规则，这些特性共同确保了 Daft 在分布式数据处理中的灵活性、可扩展性与性能。

三、Daft 的核心场景

3.1 Python 分布式

从图中可以看到，整个流程起始于 TOS/vePFS，里面存储着多份 Data。这些 Data 首先会经过数据拆分环节，被拆分成多份 Data，之后这些拆分后的数据会流向 Daft。Daft 会对数据进行自动分片以及通过 Rust download 处理。

原本存在需要手工绑定 Task 和手写 Python S3 SDK 这样的操作，但经过 Daft 处理后，数据会被分配到不同的 Node，像 Node1、Node2、Node3，每个 Node 上都有对应的 Task 来对数据进行处理。

同时，图中还展示了使用 daft 库进行分布式处理的代码示例，包括 Task 级别和 Class 级别的定义，通过装饰器 @daft.udf 来指定返回数据类型、CPU 和 GPU 资源等，体现了从单机代码轻松转换为分布式任务的方式，实现单机调试后在集群跑生产的目标。

3.2 CPU/GPU 异构流式调度

该结构图展示了基于 Daft on Ray 的 CPU/GPU 异构流式调度系统，通过分层设计实现从数据源到模型推理的全流程高效协同。数据源以 Webdataset 形式接入，包含图像和文本/JSON 等原始数据，首先进入 CPU Node 模块进行预处理，通过 Lance 组件完成数据转换（如 JSON 展开、类型转换）和清洗（如图像解码、字段提取），将原始数据转化为标准化中间格式。

随后数据进入异构节点池并行处理阶段，CPU Node Pool 负责轻量级任务（如文本过滤、图像列合并），利用 CPU 的逻辑控制优势高效完成；A10 Node Pool 则专注于计算密集型任务（如美学评分、图像描述生成），借助 NVIDIA GPU 的并行算力提升处理效率。两者通过 Ray 的分布式流式调度机制协同工作，实现数据在节点间的智能流转，形成“轻量任务 CPU 做、密集任务 GPU 扛”的异构分工。

预处理后的数据流入 PyTorch 模块进行核心推理操作（如图像编码生成、SDIP 流程），最终通过 Iterator 接口输出处理结果，支持流式数据连续接入。该系统技术特性突出表现为：CPU+GPU 异构协同通过 Ray 调度实现资源最优配置；基于 Ray 的流式计算框架保障多节点高效协作；少参数并发控制策略显著降低开发运维复杂度，为 AI 任务提供灵活易用的异构计算解决方案。

3.3 多模 Lazy 计算

上图是多模态数据处理的两种框架流程。上方为 Ray Data 流程，从 ReadImage 和 ReadText 读取图像与文本数据，以 pandas 或 pyarrow 表格格式存储，经两个 Map_Batches 处理后，通过 write_parquet 或 write_lance 写入数据。中间以紫色圆柱代表含图片、文本、音频等多种文件的多模态数据源，下方标注 Transform、Inference、Write 为核心处理环节。下方是 Daft 流程，左侧输入含 url 的 Text Meta Files 和 Image Meta Files（均为 parquet/csv 格式），经 Meta Join 关联元数据得到 Series，再经 Meta Filter 过滤，利用 with_column 依次完成 Url Download、vector decode、UDF Inference 操作，最终同样通过 write_parquet 或 write_lance 输出。两种框架均涵盖多模态数据的读取、处理、推理和写入，Ray Data 侧重直接读取原始数据并批处理，Daft 则先基于元数据关联过滤，再加载处理实际数据。

3.4 多模类型处理

3.5 LLM 离线推理

数据从 TOS 存储层流入后，经‌清洗、视觉理解、图文向量化、文本生成‌等多模态处理，再通过 ‌Daft‌ 整合为统一数据集，全流程由平台级能力（任务编排、资源监控等）保障稳定，最终输出的多模态数据集可直接服务于下游 AI 应用。

3.6 Dataloder + Daft Iter_batches

3.6.1 Pytorch 的缺陷分析

性能与资源占用问题
训练速度较慢：基于 Python 实现，处理大规模数据时易受 Python 性能瓶颈制约，训练效率低于部分底层优化的框架。
内存占用高：大规模神经网络训练时，内存消耗显著增加，可能引发“内存不足”风险。
数据处理与扩展性短板
数据读取效率不足：与 TensorFlow 等框架相比，在数据预处理、批量读取环节的效率有待提升，限制大规模数据集应用。
复杂算法扩展性弱：动态图优势下，部分复杂算法（如特定优化策略、模型架构）的实现难度较高，灵活性不如静态图框架。
生态与部署限制
生产部署工具成熟度不足：相比 TensorFlow，Pytorch 在工业级部署的工具链、经验积累上相对薄弱，大规模生产场景适配性稍弱。

3.6.2 Daft Remote 的优势总结

性能层面：突破 Python GIL 限制‌
Python 的全局解释器锁（GIL）会限制多线程并发效率，而 Rust 无 GIL 特性，天然支持多线程并发，可大幅提升训练与数据处理的并行性能，解决 Pytorch 因 Python GIL 导致的性能瓶颈。
架构层面：分布式与异步设计‌
‌分布式集群（Daft Cluster）‌：通过多节点协同，实现数据并行处理（如图中 get_items 分布式调用），突破单机资源限制，支持更大规模数据集训练。
‌异步客户端（async client）‌：训练端与数据端采用异步通信，避免阻塞等待，进一步提升数据读取与训练的并发效率，优化端到端流程。
‌生态层面：跨语言与底层优化‌
Rust 语言的底层性能优势（如内存安全、编译优化），结合分布式架构，为深度学习任务提供更高效、可扩展的底层支持，弥补 Pytorch 在生产级部署与大规模任务中的生态短板。

四、Daft+Lance 数据湖新范式

4.1 Lance 是什么

统一存储：突破 Parquet rowgroup 限制，实现标签列与多模列统一访问
传统列式存储（如 Parquet）在处理多模态数据（文本、图像、点云等）时，需为不同模态数据单独设计存储逻辑，易导致数据分散、访问效率低。Lance 通过‌统一列式存储架构‌，将标签列（如元数据、文本）与多模列（如图像嵌入向量、点云数据）统一存储，打破 Parquet rowgroup 对数据列大小差异的限制，实现‌“多模态数据统一存储、统一访问”‌，大幅简化数据管理与查询流程。
零成本数据演进（Zero-Cost Data Evolution）：动态扩展数据列，无需重写历史数据
在 AI 应用场景中，数据列的动态扩展（如新增特征工程实验、新模态数据）是常态。Lance 的‌Zero-Cost Data Evolution‌功能，允许工程师‌无需重写历史数据包‌，即可动态添加或删除数据列（如新增音频列、删除冗余列）。这一特性既避免了数据冗余存储的成本，又降低了数据版本管理的复杂度，为 AI 应用的快速迭代提供底层支持。
高性能随机点查：低成本支持 MapDataset/IterableDataset 加载
传统列式存储（如 Parquet）在处理“少量数据点查”时，需加载整个 row group 数据，效率极低。Lance 通过‌高性能随机点查优化‌，支持 MapDataset/IterableDataset 方式的数据加载，且 shuffle 操作仅按行数计算，‌成本极低‌。这一特性完美适配 AI 训练中“小批量数据加载、快速迭代”的需求，大幅提升数据处理效率。
透明编码：容器式操作类型，灵活适配多模态数据压缩
多模态数据（如图像、点云）的存储需兼顾“压缩效率”与“访问灵活性”。Lance 的‌透明编码‌机制，采用“容器式操作类型”，可对不同特性（如点云数据）实现‌自定义编码方式‌，并内置压缩编码降低存储成本。这种灵活性既满足多模态数据的存储需求，又通过压缩技术优化存储效率，是 Lance 区别于传统列式存储的关键创新之一。

4.2 Daft+Lance 表象矛盾的思路

通过结合 Lance 多模列式存储与 Daft 延迟读取能力，可实现以下优化效果：

‌Url 延迟 Download‌：采用 DataFrame 串联 url 方式，实现元数据读取与分布式下载的 Lazy 处理，避免过早加载 Raw files 导致的内存溢出（oom），解决多系统维护预处理流程的碎片化问题。
‌文件与结构化列统一存储‌：将文件以多模列式存储，利用 Lance 的压缩优势降低存储成本，同时解决裸文件带来的高 QPS、带宽膨胀问题，以及元数据与数据分开管理的一致性问题。

最终达成"1+1>2"的协同效果，实现非结构化数据与结构化数据的高效统一管理。

4.3 Daft url & Lance row id

多模对象的 KV 方式访问：

Lance 保存了 url 之外的元数据信息，path/size/label 等
同时拥有了 Lance 压缩、点查等能力和 Daft 延迟计算的能力
两者都是 Python+Rust 的生态，数据接口都是 Arrow，能够很好的融合

4.4 Daft+Lance 带来的组合优势

Daft 与 Lance 的结合，为 AI 领域的‌湖计算‌与‌湖存储‌打造了针对性技术方案，核心优势可从‌分布式能力、表达式下推、多模态存储‌三方面展开：

分布式执行能力：PB 级数据的高效处理
Daft 支持分布式执行 Lance 操作（如 read/write、add_column、build_index、compaction），能将大规模（PB 级）数据的处理任务分发至水平扩展的计算资源上执行。这种分布式设计突破了单机处理的性能瓶颈，让 AI 场景中对海量多模态数据（如图片、视频）的计算需求得以高效落地。
表达式下推：从基础到多模态的深度优化
表达式下推是数据处理中“将计算逻辑推送到数据存储层执行”的技术，Daft 在该领域实现分层优化：
‌基本表达式下推‌：支持 agg（聚合）、limit（限制行数）、filter（过滤）、project（投影）、pushdown（下推）等基础操作，通过减少数据传输量提升效率。
多模表达式下推‌：Daft 兼容自定义表达式，能将多模态场景的计算需求（如 io 放大、图片 resize、视频抽帧等）下推至 Lance 层执行，进一步降低计算开销，精准适配 AI 场景中多模态数据的复杂处理逻辑。
N→1 聚合 UDF：低成本多模存储的实现
Daft 通过 N→1 聚合 UDF（用户定义函数），将多模态数据（如图片）聚合为更紧凑的类型（如视频），从而实现‌低成本多模存储‌。这种设计让多模态数据在存储层面更高效，为 AI 模型训练与推理阶段的“数据读取 IO 速度”需求提供底层支撑，解决传统存储方式下多模态数据处理效率低的问题。

综上，Daft 与 Lance 的组合从分布式执行、表达式下推到多模存储，全方位适配 AI 场景中多模态数据“存储、计算、管理”的技术需求，为 AI 时代数据湖的建设提供技术范式。