点击蓝字 关注我们
本文共计8240字 预计阅读时长25分钟
随着大模型应用进入企业生产环境，影响 AI 规模化落地的关键因素已不局限于模型能力本身，而在于是否具备承载训练、推理、检索、知识更新与持续治理的数据体系。传统数据湖在海量存储与批处理分析方面较为成熟，但 AI 场景下数据形态、访问模式与治理要求均已发生明显变化——文档、图片、音视频、向量 Embedding、标注样本与模型产物，正成为企业智能化建设的核心数据对象。
在此背景下，TBDS多模数据湖引擎 正从面向结构化数据处理，演进为面向 AI 时代多模态数据湖基础设施。该体系围绕高吞吐多模态湖存储、向量原生数据格式、异构算力调度、统一元数据服务、自动化治理五项核心能力进行重构，形成完整的产品与技术链路（底层基于 TBDS-FS、Lance、Ray、MetaService、LakeKeeper 并做企业级增强），为企业构建 AI 原生场景数据基座。
AI时代正在重新定义数据湖的能力边界
从行业演进趋势看，数据基础设施正在经历新一轮重构。传统数据湖擅长处理业务表、交易流水、行为日志等结构化与半结构化数据，以批量任务、全表扫描为主要处理方式，核心目标集中于存储扩展性与离线分析效率。
当企业开始建设知识库、推进大模型训练与微调、开展语义检索与多模态交互应用时，数据湖面临的诉求随之变化：
- 数据类型显著扩展，文本、图片、音视频、向量、标注数据与模型文件需纳入统一管理；
- 访问模式转变，从批处理转向点查、随机读取、向量检索与混合检索；
- 算力协同要求增强，CPU/GPU 异构调度、预处理与训练联动、索引构建与在线检索配合成为关键议题；
- 治理复杂度同步提升，索引维护、版本清理、小文件治理与统一元数据管理的重要性进一步上升。
AI 时代所需要的数据湖，已不再只是面向结构化分析的存储容器，而是需要发展为支持多模态数据组织、承载多样化计算模式、具备持续治理能力的数据基础设施。TBDS多模数据湖引擎 的能力演进，正是围绕这一方向展开。
传统数据湖在多模态AI场景中的典型约束
从企业实践来看，传统数据湖在支撑多模态 AI 场景时，通常面临四类约束：
一是数据承载与 AI 访问模式错配。 传统格式主要面向顺序扫描与离线分析设计，在高频随机访问、向量检索与多模态对象统一管理方面能力有限，企业往往需要多套系统并行，带来链路复杂与一致性维护难题。
二是通算和智算衔接不足。 传统体系主要围绕 CPU 资源组织，对 GPU 训练、向量生成与混合负载调度支持有限，预处理、索引构建、训练与在线服务分属不同系统，数据流转路径长、集成复杂度高。
三是元数据与权限体系无法管理多模态资产。 仅靠文件目录或简单表结构已无法统一组织多模态数据，企业需要统一的元数据服务、权限控制与标准化描述方式，以支撑跨部门的持续复用。
四是治理能力难以长期依赖人工运维。 索引重建、版本清理、小文件合并、查询优化等都是规模化运行中的常态任务，缺乏自动治理将导致性能与一致性随规模增长逐步恶化。
AI 场景对数据湖的要求并非功能叠加，而是底层架构、格式能力、计算协同、元数据体系与治理机制的整体升级。TBDS多模数据湖引擎 正是针对上述问题进行体系化设计。
TBDS多模数据湖引擎构建AI原生多模态数据底座，并构建统一能力闭环
TBDS多模数据湖引擎并非从零起步，而是在长期覆盖数据接入、数据湖存储、多引擎计算、元数据管理与治理能力的基础上，面向AI时代将既有能力重新组织为一套更适配多模态智能场景的产品体系。
从整体结构看，TBDS多模数据湖引擎向上通过SDK、RESTful API、MCP等开放接口连接传统数据工程、AI增强数据分析、数据科学分析与Data Agent等上层场景；向下以多模态数据引擎为核心，围绕四层能力形成闭环架构：
- 存储层：TBDS-FS统一纳管TBDS-Iceberg与Lance，统一承载结构化、半结构化与多模态数据；
- 计算层：同时承载数据引擎与AI引擎，支持CPU/GPU异构算力统一调度，覆盖预处理、索引构建、训练与检索等多类场景；
- 元数据层：通过MetaService提供覆盖Table、Function、FileSet与Model统一元数据服务；
- 治理层：通过LakeKeeper提供索引维护、版本清理、小文件合并与表优化的自动化治理能力，支撑长周期生产化运营。
这一设计将AI项目中分散于多个系统的关键能力纳入同一框架，使知识库、RAG、向量检索、多模态前处理及后续治理等任务在同一平台上连贯协同，推动上层应用与底层数据体系形成稳定闭环。
核心架构图
向量原生的多模态湖存储能力（基于 Lance 企业级增强&基于TBDS-FS统一存储加速）
在多模态场景下，数据格式的选择会直接影响后续检索效率、训练准备成本与数据迭代体验。TBDS多模数据湖引擎 在这一层提供向量原生的多模态数据格式能力——在同一张表中原生承载文本、图片、音视频与向量 Embedding，并内置高性能 ANN 索引与版本控制，以提升方案对多模态对象与向量数据的原生承载能力（底层基于 Lance 并结合 TBDS-FS 做访问与检索链路的企业级增强）。
Lance 的引入并不只是增加一种数据格式，而是推动数据湖从面向通用分析的数据承载层，进一步发展为能够支撑多模态对象管理与语义检索的数据基础设施。
TBDS多模数据湖引擎并非把多模态数据格式作为独立格式简单接入，而是对其访问链路与向量检索链路做了存储层面的协同加速，并兼容 S3、HDFS 等多类底层存储体系（底层基于 Lance 与 TBDS-FS 的深度配合实现）。由此，企业既可以延续既有存储基础设施，又能够在上层获得更适配 AI 场景的数据格式能力。
LanceDB 作为新一代 AI-Native 向量数据库，采用存算分离架构设计，数据持久化在对象存储，计算节点无状态、可弹性伸缩，天然适配云原生和 Kubernetes 环境。TBDS 平台围绕存算分离这一核心架构，做了大量优化：
- 多级缓存加速：构建了「内核 Page Cache → 本地 SSD 缓存 → 分布式缓存组（Cache Group）→ 远端对象存储」四级缓存穿透体系，最大程度减少对底层存储的回源访问；
- 分布式缓存共享：通过一致性哈希环组织的 Cache Group，解决弹性计算节点冷启动问题，新扩容节点可即时享受缓存加速；
- 智能预热与预取：支持显式预热、顺序预读、基于 DAG 的智能预取，主动消除冷启动延迟；
- 独立元数据服务：基于高性能 KV 引擎（FDB）管理文件元数据，实现毫秒级目录操作，消除对象存储 List/Stat 的性能瓶颈。
这些优化使得 TBDS-FS 能够为 AI 场景（向量检索、特征工程、模型训练、在线推理）提供统一的存储接入和全链路数据访问加速，让 LanceDB 在存算分离架构下依然获得强大的读写性能。
异构算力的亲和性调度能力（基于Ray的企业级增强）
如果说 Lance 更侧重解决“如何更合适地存储与组织数据”的问题，那么 Ray 所对应的则是“如何让数据处理、索引构建与 AI 计算高效协同”的问题。TBDS多模数据湖引擎 对 Ray 的集成与增强，重点在于将多模态数据处理、索引构建、训练前处理与算力调度纳入统一链路。
与传统偏 CPU 的大数据计算模式相比，Ray 更适用于 AI 场景下常见的异构资源调度。它能够支持 CPU 与 GPU 的混合资源管理，使该解决方案可以根据任务特点进行更细粒度的资源分配：例如文本解析与预处理偏向 CPU，向量生成、推理或部分训练任务偏向 GPU，复杂任务则采用混合调度。
此外，TBDS多模数据湖引擎 还强调基于 Ray 的弹性伸缩能力。海量数据预处理与索引构建通常具有明显的阶段性峰值，通过按负载动态扩缩 Worker，方案可在满足吞吐需求的同时降低长期资源占用。结合 Python-Native 的开发体验，这一方案也更贴近当前 AI 工程师的开发习惯。
从工程实施角度看，TBDS多模数据湖引擎通过异构算力协同能力（底层基于 Ray 并结合数据湖元数据做了数据亲和性调度增强），显著缩短了预处理、索引构建与训练链路之间的数据流转距离，减少跨系统搬运带来的额外复杂度。对于大规模知识库与多模态训练前处理场景而言，这种协同能力具有较高现实价值。
企业级统一元数据能力（基于MetaService的企业级增强）
在多模态数据解决方案建设过程中，存储与计算往往最容易被优先关注，但真正决定方案是否能够长期稳定运行的，通常是元数据体系。特别是在多模态场景下，如果文件、表、模型、数据集、向量索引与权限体系之间缺乏统一关系描述，方案将很难形成可持续的数据资产管理能力。
围绕这一问题，TBDS多模数据湖引擎一方面提供多模态数据资产的一站式管理能力，支持对表、向量索引、模型产物与数据集进行统一描述、归属与权限控制（TBDS与Gravitino社区合作，开发了多项多模态数据资产管理功能，在TBDS生态中称为MetaService）；
TBDS MetaService构建了覆盖全生命周期的多模态数据资产一站式管理能力，分为四个阶段：
第一阶段：资产注册。 MetaService 采用 Metalake → Catalog → Schema → Table 四层模型，将结构化表（Iceberg/Hive）、向量索引（Lance）、模型产物、训练数据集统一纳入一套描述体系。TBDS 与 Gravitino 社区合作扩展了 Lance Catalog，支持向量维度、索引类型等多模态特有元数据，使向量数据成为数据湖的一等公民。
第二阶段：权限与安全。 提供 RBAC 角色控制与细粒度 ACL，所有类型资产共享同一权限体系。通过 STS 临时密钥按需签发存储凭证，避免长期密钥泄露；结合 KMS 透明加密，满足金融、政企等合规要求。
第三阶段：治理运营。 覆盖审计日志（全操作可追溯）、数据血缘（跨格式全链路追踪，从 ETL 到向量索引到推理服务）、标签分类（业务标签与数据等级）、生命周期管理（TTL 过期与自动归档）及配额管控五大能力，确保数据资产可持续运营而非一次性消耗。
第四阶段：统一消费。 通过统一元数据入口，LanceDB 经 REST API 发现向量表，Spark/Flink 经 MetaService Catalog 直接查询，PyTorch/Ray 经 FUSE 挂载读取训练数据，数据开发 IDE 跨格式浏览全部资产——实现“一次注册，处处可用”。
多模态数据湖自动治理能力（基于自研LakeKeeper 服务）
TBDS将自动化治理能力进行工程化与产品化（底层对应 LakeKeeper 治理能力），使开源的手动治理能力升级为可被生产稳定依赖的自动化平台能力。
LakeKeeper 构建了一套全自动、可观测、可配置的治理闭环：
- 增量数据统计与索引健康评估：LakeKeeper 持续监控各 Lance 表的增量数据写入情况和索引覆盖率，通过可配置的健康评分模型（综合考虑未索引数据占比、索引碎片度、数据倾斜程度等指标），自动判断索引是否需要重建或优化，实现从"被动告警"到"主动感知"的转变。
- 索引自动构建与维护：当评估发现索引健康度低于阈值时，LakeKeeper 自动触发索引构建任务，支持 IVF_PQ、HNSW 等多种索引类型的增量构建和全量重建。对于超大规模数据集，LakeKeeper 支持分布式索引构建，将构建任务分片调度到多个计算节点并行执行，大幅缩短构建耗时，使 TB 级向量数据的索引构建从小时级降低到分钟级。
- 旧版本清理与孤儿文件回收：Lance 格式采用 MVCC（多版本并发控制）机制，频繁写入会累积大量历史版本。LakeKeeper 根据可配置的保留策略（如保留最近 N 个版本或 N 天内版本），自动清理过期版本及其关联的数据文件；同时定期扫描并回收因异常中断或并发写入产生的孤儿文件，有效遏制存储空间的无序膨胀。
- 小文件合并（Compaction）：高频追加写入场景下，数据文件碎片化严重。LakeKeeper 自动识别碎片化程度较高的分区或片段，触发 Compaction 任务将小文件合并为大文件，减少文件数量，提升顺序读性能和底层对象存储的访问效率。
- 检索服务常驻化：LakeKeeper 支持将热点向量表的检索服务常驻部署（类似于 Serving 模式），预加载索引到内存/GPU 显存，消除冷启动延迟，为在线推理和 RAG 场景提供稳定的低延迟检索能力。
开源组件 vs TBDS 企业级能力增强
面向 AI 时代企业级数据基础设施建设的真实挑战，TBDS 团队并未停留在对开源能力的简单集成，而是基于在政务、金融、能源、互联网等行业的多年落地经验，系统性地在 TBDS-FS、Lance、LanceDB、Ray、MetaService、LakeKeeper 等开源组件之上，自主研发了一整套企业级增强能力——具体覆盖 HDFS 存储接入与存储加速、多集群异构算力调度、企业级统一认证、统一元数据服务、自动化治理、开放接口与集成 六大关键维度。这些能力并非对开源的简单封装，而是精准对标客户在生产环境中普遍遇到的六类真实痛点：既有 HDFS 存储资产无法承接 AI 负载、算力分散在多个 K8s 集群导致 GPU 利用率低、向量 / 多模态数据湖缺少 LDAP / Kerberos 难以满足金融政务合规、表与向量索引与模型产物血缘断裂难以复用、治理动作依赖人工巡检导致运维人力居高不下、各组件独立 API 使上层应用接入成本高昂，并逐一打磨出工程化解决方案。正是依托这套增强能力，TBDS多模数据湖引擎得以把碎片化的开源组件整合为一套可被客户稳定依赖、长期演进的企业级数据底座。下表即是对这些增强能力及其客户价值的集中呈现。
面向知识库与RAG的体系化支撑能力
知识库与 RAG 已成为当前企业 AI 落地中最具代表性的场景之一。一方面，这类应用离业务较近，价值衡量相对明确；另一方面，它对底层数据体系的要求也较高：文档、书籍、图片与多模态附件需要统一管理，文本检索与向量检索需要协同工作，Embedding 生成与模型服务节点需要稳定配合，召回结果还需进一步进入大模型推理链路。
TBDS多模数据湖引擎 给出的路径，是以多模态数据湖作为知识库建设的底层基础。多种类型的文档与多模态文件先统一沉淀到数据湖中，再由 TBDS-Ray 集群承担文本处理、向量生成与模型服务节点管理，将文本、向量与多模态对象统一写入体系；在查询侧，方案通过 AI 检索服务同时支持文本检索与向量检索，再将召回结果提供给上层模型服务进行答案生成。
这种架构的意义在于，它尽量减少“离线数据湖”“在线向量库”“推理服务体系”之间的系统割裂，将知识入湖、向量生成、索引维护、检索召回与问答生成组织为一条较为连贯的链路。随着数据规模增加、知识更新频率提升以及应用范围扩大，这种一体化能力通常更有利于该解决方案的长期演进。
知识库/RAG场景图
在知识库与 RAG 场景中，TBDS多模数据湖引擎的定位并不仅停留在底层存储能力层，而是贯通数据组织、索引构建、算力调度与模型服务协同的全链路能力，以支撑企业级智能问答与知识增强应用的持续运行。
多模态数据湖生产实践案例
业务价值最终要回到真实落地。某大型金融机构的知识库建设实践，就是 TBDS多模数据湖引擎面向 AI 时代交出的一份有说明力的答卷。
改造前：10TB+ 知识沉淀撞上"存算一体"老架构的天花板
这家金融机构的知识库已沉淀超过 10TB的文本数据，业务侧不仅要支持关键词检索，更要在智能问答、合规审查、客户服务等场景中引入语义级别的向量检索能力。然而原有系统采用的是存算一体的检索服务架构——即便在访问负载相对平稳的时段，底层算力也必须 7×24 小时常驻，硬件投入居高不下、资源利用率却长期走低，扩容成本与业务增长之间的矛盾日益突出。
改造后：从"中心化检索服务"走向"AI 数据湖架构"，一套底座跑通文本 + 向量检索
面对这一典型的"旧架构承载新 AI 负载"难题，TBDS多模数据湖引擎为客户规划并落地了一条清晰的演进路径：以多模态数据湖作为统一底座，将原先中心化的文本/向量检索服务平滑迁移至 AI 数据湖架构，通过存算分离彻底重构知识库底层。存储层统一沉淀文本与向量数据，计算层按业务负载弹性伸缩；文本检索与向量检索不再依附于两套独立系统，而是通过统一体系协同运行、统一调度。
成效：硬件成本节省 70%+，检索能力不降反增
重构完成后，这家金融客户在保留原有统一检索能力的同时，取得了两项关键成果：
- 硬件成本节省 70%+——存算分离带来的资源按需扩缩，直接消解了"算力常驻"的成本包袱；
- 检索能力同步升级——文本与向量混合召回一体化运行，为上层智能问答与知识增强应用打下稳定基础。
行业意义：可复制到金融、政务、能源等对稳定性与成本同等敏感的行业
这一案例的价值不止于一个客户的成本账单。它验证了多模态数据湖方案在严谨行业场景中，能够同时兑现"架构现代化 + 成本大幅下降 + 检索能力增强"三重收益的可能性。对于金融、政务、能源等同样承载海量知识资产、同时对稳定性与 TCO 高度敏感的行业而言，TBDS多模数据湖引擎给出了一条已经被真实业务跑通的参考路径。
面向AI原生场景的数据基础设施
从更长周期视角看，TBDS多模数据湖引擎 此次能力升级的意义，并不仅仅在于集成 Lance、增强 Ray 或新增治理模块，而在于它尝试将企业在 AI 时代最核心、最分散、也最容易形成系统割裂的数据能力，重新组织为一套更完整的基础设施方法。
这一方法至少体现在四个方面。第一，强调多模态数据的原生承载，不再将文本、图片、音视频与向量视作外围对象；第二，强调数据处理与 AI 计算协同，而非将 AI 能力孤立于数据解决方案之外；第三，强调统一元数据与持续治理，将长期可运营性纳入方案设计重点；第四，强调开放接口与应用承接能力，使知识库、RAG、AI 增强分析与 Agent 类场景能够更顺畅地接入。
TBDS多模数据湖引擎正在推动多模态数据解决方案从“支持传统分析任务的基础设施能力”向“适配 AI 原生场景的数据基础设施”演进。对许多企业而言，这种演进的意义不仅在于单点性能或成本指标的变化，更在于底层架构是否具备支撑未来几年智能化建设持续扩展的能力。
结语
AI 应用的竞争正在逐步从模型层延伸至数据基础设施层。对于企业而言，能否高效组织多模态数据、稳定协同数据与算力、并以更可控的成本支撑知识库与智能应用持续演进，将在很大程度上影响 AI 项目的长期落地效果。
TBDS多模数据湖引擎所展示的技术路径，是以高吞吐多模态湖存储作为统一底座、以向量原生数据格式提供多模态与向量数据能力、以异构算力协同调度支撑数据与 AI 计算流转、并以统一元数据服务与自动化治理完成长周期闭环（底层技术选型分别对应 TBDS-FS、Lance、Ray、MetaService 与 LakeKeeper 的企业级增强），从而推动多模态数据湖解决方案向可落地、可运营、可持续演进的企业级能力体系发展。
从数据工程，到知识库，到 RAG，再到未来更多 AI Agent 与多模态智能应用场景，TBDS多模数据湖引擎所构建的，正在逐步从单一产品能力延展为面向 AI 时代的数据基础设施底座。
END
关注腾讯云大数据╳探索数据的无限可能
往期精彩
