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

老周聊架构

发布于 2025-11-20 10:58:05

一、前言

在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.4 Daft多模计算定位

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

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

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

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

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

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

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

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

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

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

2.5 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时代数据湖的建设提供技术范式。