17认证网作者 | OceanBase资深技术专家 张易
全文共 3277 字，阅读约需 6 分钟
OceanBase 一直沿着“一体化数据库”的方向演进：从核心交易场景的分布式在线交易，到 Oracle 兼容、HTAP、多模型能力和混合搜索。在刚刚过去的 OceanBase Hours 上，OceanBase 正式发布了湖库一体的 AI 数据库。
这不只是负载类型和数据模型的又一次升级，而是一个更根本的变化——数据库的用户变了。
AI 数据库不是为了支持图片、PDF 或向量，而是因为数据库第一次迎来了一类新的用户——Agent。
这件事带来的第一个挑战，就是 Agent 的数据困境。
当一个 Agent 在处理一次决策请求时，它可能需要同时调用用户画像（非结构化数据）、历史对话摘要（文本）、知识库中的 PDF 原文、向量召回的语义结果，以及实时业务状态。
这些数据今天分散在对象存储、搜索系统、向量库、业务数据库和离线数仓中。它们之间没有统一事务，没有一致性快照，没有血缘关系。当 PDF 更新了但 embedding 还指向旧版本时，Agent 给出的答案就可能是错的——而你甚至不知道它错了。
这不是一个“多存几种数据类型”的问题，而是一个数据治理问题：当多模态数据进入核心生产链路后，谁来保证它们版本一致、计算完整、可追溯、可信赖？
多模表就是在这个背景下提出的。
多模表是 OceanBase 刚刚发布的湖库一体 AI 数据库中的多模态数据管理能力。
它把多模态数据——图片、音视频、PDF、网页快照、向量、JSON、结构化字段——作为数据库的一等数据对象统一管理，并在同一套体系内提供事务、一致性、实时高可用、混合搜索、分析计算和在线服务能力。
一句话概括：多模表让你像管理关系数据一样管理多模态数据，像查询结构化字段一样检索非结构化内容。
核心能力一览：
Agent 面向的业务对象天然是多模态的。
它的输入可能是自然语言、图片、PDF、网页、表格或业务上下文；运行时依赖的内容包括用户记忆、知识库、RAG 结果、结构化业务数据、语义画像和模型推理中间结果。
- 非结构化数据进入核心生产链路。 它不再是对象存储里的附件，而是 Agent 做出决策的关键输入。
- 数据访问模式变成混合搜索。 一次请求可能同时涉及结构化查询、全文检索、向量召回和过滤分析。
- 实时性要求陡增。Agent 需要 7×24 在线决策，传统 T+1 报表无法满足。
- 特征是动态生成的。很多字段不是写入时直接给出，而是由模型从原始多模态数据中异步提取。
因此，多模表要解决的核心问题是：如何在数据库内统一管理多模态原始数据、结构化字段、动态衍生特征和异步计算结果，并让它们共同服务在线交易、分析处理和混合搜索——同时保证一致性和可见性。
多模表将多模态数据纳入数据库的事务和版本管理体系。图片、音视频、PDF、网页快照等大对象支持三种存储形态：
- 行内存储： 小对象或关键元数据直接存放在行内；
- 行外存储：大对象脱离行内，但仍由数据库管理引用关系和事务边界；
- 库外存储：对象本体放在对象存储等外部系统，数据库保存访问地址、版本和可见性信息。
关键不在于对象存放在哪里，而在于数据库管理它的唯一标识、访问地址、版本、可见性和事务边界。这保证了原始对象和它衍生出的摘要、标签、embedding、风险分等特征始终对应同一个数据版本——避免“对象已更新，特征仍指向旧内容”的不一致。
多模态数据具有“富模态”特性：
同一份原始数据可以不断提取新的语义、结构、质量和业务特征。例如文本可以生成主题、摘要、embedding、安全标签、语言类型、质量评分；图片可以不断追加 OCR 结果、标签、风险分和业务特征。
传统方案下，每新增一个特征都需要 DDL 变更，带来缓存更新、增量写入放大和后台合并压力。多模表采用轻量的动态列机制：特征扩展无需表结构变更，同时保留 SQL 可查、分析可优化、混合搜索可命中的结构化语义。
这不是一个退化为键值结构的方案。键值结构虽然灵活，但无法自然支撑 SQL 分析和搜索优化。多模表在结构化可优化和动态扩展之间做了明确的工程取舍。
多模表中大量列不是用户直接写入的，而是由计算任务生成——embedding、摘要、OCR、质量分、全文索引和向量索引。这些计算由数据库内置模型能力、后台任务或外部计算链路承载。
模型推理耗时通常在数百毫秒到数秒，不能阻塞在线写入。
3.系统在近实时范围内让衍生数据可见；
4.读请求按一致性位点读取完整可用的数据视图。
这里的设计判断是：追求所有衍生列强同步是不现实的，也是不必要的。正确的取舍是在实时性、吞吐、存储效率和一致性之间建立可控的平衡点。计算任务负责生成衍生值，多模表负责让这些值成为可治理、可搜索、可分析、可一致读取的数据资产。
异步计算引入了新的可见性难题。一行原始数据写入后，特征 A、特征 B、embedding、全文索引、质量标签可能由不同任务、不同模型在不同时间完成。
如果查询时看到特征 B 已完成但特征 A 未完成，业务计算就可能出错。多模表通过列组级一致性解决这个问题：某个业务列组只有在相关衍生列全部完成后，才形成新的可见快照。查询和混合搜索读取的始终是一致性快照，而不是半成品数据。
多模态数据体量大且持续增长——文档、图片、视频、向量和衍生特征会不断累积。如果全部按在线热数据方式存放，成本不可接受。
基于共享存储的存算分离架构，多模表实现了冷热数据一体化管理：
- 近期数据（如 90 天内） 缓存在 SSD 中，保证低延迟访问；
- 历史数据（如 90 天以上）沉淀到低成本共享存储，仍可被同一套查询、搜索和分析能力访问。
对用户而言，查询热数据和冷数据不需要切换系统，也不需要在在线库、对象存储、离线数仓之间手工拼接。同一个数据视图下，兼顾访问性能、存储成本和查询连续性。
一个 embedding 由哪段文本生成？一个安全标签由哪个审核模型打出？一份摘要对应哪个 PDF 版本？
如果这些信息缺失，系统就无法判断数据是否完整、是否可信、是否可以被业务读取。血缘与 Unified Catalog 是多模表的元数据底座，它记录原始对象、结构化字段、动态特征列、模型任务、版本和权限之间的关系。
- 触发： 后台任务根据血缘关系自动触发特征提取、索引构建和回填；
- 完整性判断：系统判断某个列组或快照是否已完成全部衍生计算，决定是否推进可见性；
- 可追溯性：当 Agent 给出回答时，可以追溯它依赖了哪些原始文档、图片、业务记录和衍生特征。
多模表不是纯存储结构，而是三类工作负载共同依赖的数据底座：
- 在线交易： 业务写入、事务保障、一致性和高可用；
- 分析处理：大规模扫描、聚合、过滤、join 和特征分析；
- 混合搜索：组合结构化条件、全文检索、向量召回、标签过滤和业务排序。
Agent 的访问模式天然复杂——一次请求可能先用结构化条件过滤业务对象，再用全文检索查描述，用向量召回找语义相似内容，最后还要按标签、质量分、时间和权限排序。这是典型的混合搜索场景，任何单一引擎都无法独立覆盖。
核心取舍是近实时而非强同步。搜索和分析场景通常不需要衍生特征在写入事务内立刻完成，但需要在较短时间内可见，并且读取时看到一致的数据快照。这样，同一份多模表数据可以同时支撑在线写入、混合检索和分析查询，消除业务在多个系统之间反复同步和拼接的成本。
多模表适合那些既有多模态数据，又需要在线访问、实时更新和统一治理的场景：
OceanBase 多模表解决的问题，不是 AI 数据库能不能存图片、PDF 或向量，而是当 Agent 成为数据库的第一用户后，数据库如何继续管理完整的业务对象，而不是一堆彼此孤立的数据类型。
从这个角度看，多模表不是一个单点功能，而是 OceanBase AI 数据库面向 Agent 和多模态时代的数据模型升级。它把结构化数据、非结构化数据、AI 衍生特征与业务语义统一到同一套事务、治理和计算体系，让数据库真正成为 Agent 的数据底座。
过去，数据库统一的是数据；AI 时代，数据库需要统一的是数据、语义与智能运行。
多模表，就是 OceanBase AI 数据库向这一目标迈出的第一步。
转自：OceanBase
版权申明：内容来源网络，版权归原创者所有，如有侵权请联系删除
想了解更多干货，可通过下方扫码关注
可扫码添加上智启元官方客服微信👇
