先看一个做大模型训练数据的同学每天都在接的需求：“帮我筛一批 Token 数 1000 以下、非 QA、社科类、不是合成的数据。”

一句话的需求，真做起来往往要两天：先搞清楚每个特征（Token 数、是否 QA、是否合成）在哪张表、怎么算的、口径可不可信，一个个探查取值范围，再拼出一条又长又容易错的 SQL，跑完还得核对。

慢不在 SQL 难写，而在底下这套数据栈是拼出来的，各层割裂：

• 存储用的是数据湖里的文件格式，加一个特征列就要复制数据、反复 Join、整表重写；
• 特征散落在数据清洗 pipeline 各个组件的 UDF 里，过滤和计算混在一起，血缘说不清，新数据进来特征列还是空的，得手动跑回刷；
• 筛选是漏斗式的，一层 UDF 算分只放大于阈值的进下一阶段，做不了特征交叉，也看不到全部特征的分布去自由组合；
• 筛完的数据子集不记逻辑，不能复现、不能审计、不能共享。

这些问题单拎出来都能打补丁，但本质原因是：存储、计算、特征管理、数据治理和数据服务被拆在了多套系统里，数据在系统之间来回搬，一致性和可追溯性最后都靠人来兜。

OceanBase DataStudio 要解决的，正是这个问题。

OceanBase DataStudio 是运行在 OceanBase Lakebase 之上的数据生产、治理与服务工作台。

它不是单独再做一套存储或计算系统，而是基于 OceanBase Lakebase 的湖库一体底座，把“数据进来、加工、管好、发出去、看清楚”这条链路组织成一套可操作的工作流。

在这套体系里，OceanBase Lakebase 提供底层能力：结构化、半结构化、非结构化与向量数据可以在统一架构下被管理；数据库的事务、一致性、实时服务能力，与数据湖的开放存储、开放计算能力结合在一起；标量、全文和向量可以在同一数据底座上做混合搜索。

OceanBase DataStudio 则把这些能力产品化成数据团队能使用的工作台：数据接入、数据加工、任务编排、语义建模、质量治理、权限管理、血缘分析、数据集发布和数据服务，都可以在一条链路中完成。换句话说，OceanBase DataStudio 的价值不是替你多写几条 SQL，而是把原来散落在湖、计算引擎、特征平台、搜索系统和治理工具里的流程，收到一个平台里。

一体化大宽表存储，加列即用

一条数据从原始文件、到可训练数据、再到各种衍生特征，全部挂在同一张大宽表的不同列上，用 UUID 关联。图片、视频这类大对象放在 Volumes 里，表里只存路径。

这张表配成列存，带来两个直接的好处：加一个新特征就是加一列，不用复制数据、不用反复 join；加减特征列也不会触发整表重整。这样频繁加减特征列就是轻量操作，不再牵动整张表。

底座是 OceanBase，所以它天生带着数据库的能力：行锁、按 UUID 做 UPSERT / MERGE INTO 的行级更新、强一致。而且 OceanBase 支持混合检索，标量、全文、GIS、向量放在一起查。训练数据场景里常要做向量召回，又要按结构化条件过滤，这一条正好用得上。

除了上面这些，还有两个底座自带的能力。

一个是 AI 列——你可以理解成表上挂的实时计算列，数据写进来的时候自动跑 Embedding、打标之类的模型计算，结果直接写回表里，而且带事务保证：一批音频要么全部算完，要么全部失败回滚，不会出现“算了一半”的脏状态，特征回刷最怕的就是这种中间态。

另一个是 Fork Database——像 Git 拉分支一样，秒级复制出一个完整的数据库副本，底层是 Copy-on-Write 只占增量空间。你在分支上随便试各种特征加工口径、筛选条件，搞成了 MERGE 回主干，搞砸了直接扔掉，代价几乎为零。做训练数据本来就是大量试错，这个能力可以让你大胆放手试。

Daft on Ray 处理多模态

特征生产经常要处理图片、音频，要调模型。传统离线引擎（比如 Spark）在这件事上有两个老问题：每批任务都要重新加载模型，代价高；CPU 和 GPU 没法同时喂饱，资源浪费。

OceanBase DataStudio 选了 Daft on Ray 作为多模态计算引擎。借 Ray 的 Actor 模式，模型加载一次就能在多批数据里复用；每个算子按微分区动态调度，把 CPU 处理和 GPU 处理串成流水线。大批多模态特征的回刷和加工，正是靠这两点提速。

在它之上构建特征平台，更简单

OceanBase DataStudio 本身不是一个特征平台，它不直接提供特征注册、回刷这些功能。但它把构建特征平台所需的底座都备好了，在它之上搭建训练数据生产所需的能力，会比从零拼装简单得多，也更易用。

以一个特征平台常见的几项能力为例：

• 特征注册与血缘：把每个特征的计算逻辑（SQL/UDF）、类型、来源列登记在册。借助平台的 SQL 解析（Calcite）能力，可以自动从计算逻辑里提取血缘，说清这个特征是怎么算出来的。
• 自动回刷补齐：新数据导入或特征定义更新后，按登记的逻辑批量算出缺失的特征列。底层依托宽表的行级 UPSERT / MERGE 和 Daft on Ray，回刷做起来顺畅。
• 特征分布可视化：枚举特征看各取值占比，连续特征看 min / max / 中位数 / 均值。这些统计直接基于 OceanBase 的查询能力就能算出。
• 可追溯的交叉筛选：把 feature_A in (‘x’,‘y’) AND feature_B > 100 这样的多条件交叉，转成 SQL 在宽表上执行生成数据子集，并记录每次筛选的完整逻辑，可复现、可审计、可共享。

这些能力之所以好建，是因为存储、计算、混合检索这些底座 DataStudio 都提供了，不需要自己再拼一套。回到开头那个需求：特征都注册好、分布看得见、能交叉筛、筛完可追溯，“Token 数 1000 以下、非 QA、社科类、非合成”就是一条 SQL 的事。

前面分三层讲了技术实现，这里把它串成一条完整的链路。

原始数据进来——图文、音视频、日志批量导入大宽表，大对象丢 Volumes、表里只存路径；然后跑加工——用 Daft on Ray 编排拆分、抽帧、Embedding、打标这些算子，把非结构化内容变成可计算的特征列（AI 列在写入时就能自动补上）；加工完做注册——每个特征的计算逻辑、类型、来源列登记入册，血缘自动抽取；接着筛选——feature_A in (…) and feature_B > 100 这样的交叉条件直接在宽表上跑，出数据子集的同时把筛选逻辑记下来；最后发布——子集作为可复现、可审计、可共享的数据集交给下游训练。

开头那个“两天”的需求，走完这条链路就是一次可追溯的 SQL。

AI 训练数据生产这个场景，业界已经有不少产品在做，Feature Store 管特征，开放表格式管湖上数据，Spark / Ray / Daft 管计算，向量库和搜索引擎管召回。

这些工具各自都有价值，但如果企业要自己把它们拼起来，复杂度会很高。存储一套，计算一套，特征管理一套，搜索一套，治理再来一套。每一层之间都要搬数据、对权限、补血缘、处理失败重试和一致性问题。

但大多只解决其中一层，OceanBase DataStudio 的差异化来自 OceanBase Lakebase 的一体化，把 AI 数据生产中最核心的链路收到了一个统一底座上。

对比 Feature Store（Tecton / Feast / Hopsworks）

这类产品专做特征管理，能力很专，但本质是特征层的中间件：它们自己不管底层的多模态存储和计算，得架在别人的数据湖和计算引擎之上。用 Tecton，底下还是要配一套存储和一套 Spark/Ray，再把它们对接起来。

如果基于 OceanBase DataStudio 来构建特征平台，情况不一样：存储（大宽表、列存、Volumes）、计算（Daft on Ray）、混合检索、行级更新这些底座都是现成的。构建一个特征平台更简单、更易用，也不需要在特征层和存储之间反复搬数据、对一致性。

对比开放湖仓格式 / 平台（Lance / LanceDB / Databricks）

Lance 这类 AI 原生的开放湖仓格式，擅长 AI 训练数据和向量检索，是很好的方向。但它的底座是对象存储上的文件格式：偏追加写，行级更新和事务能力弱。训练数据回刷里最常见的操作“按 UUID 更新某一行的某一列”，在文件格式上往往意味着重写文件，而在 OceanBase 这种数据库底座上，就是一次普通的行级 update。

Databricks 是成熟的 Lakehouse 平台，但底座同样是文件格式加 Spark，事务和更新走的是表格式那一套。

OceanBase DataStudio 用数据库做底座，行锁、UPSERT / MERGE、强一致、加列即用、原生混合检索都是现成的。这是 Base 相对纯 Lake 的价值：该有数据库能力的地方就有数据库能力。

对比计算引擎（Spark / Ray Data / Daft）

很多平台的多模态处理还压在 Spark 上，模型加载贵、CPU/GPU 利用率上不去。OceanBase DataStudio 选的是 Daft on Ray 这条更适合多模态的技术路线（Daft 在官方 TPCH 基准上也快过 Spark 数倍，这是厂商口径，具体以各自测试为准），并把它做进了平台的开发和调度流程里，而不是让用户自己去搭一套 Ray 集群。

一体化的价值，省掉搬数据

Feature Store 管特征层，开放湖仓格式管存储层，计算引擎管算力，各自只覆盖一层。

OceanBase DataStudio 作为 Lakebase 产品，把这三层底座合在一起，在它之上构建训练数据生产这类场景，省掉的是系统之间搬数据和对一致性的代价。既要多模态、又要频繁更新、还要混合检索的场景里，这种一体化最划算。

AI 训练数据生产只是一个场景。它背后这套“湖的多模态能力，加上库的事务与检索能力”合一的底座，在结构化与非结构化深度融合、需要强事务和频繁更新的更多业务里同样成立。

智驾每天产生大量视频、图片、传感器数据和 GPS 轨迹。业务团队要从海量行车数据中找到极端天气、异常路况、碰撞风险等场景，不能只靠人工翻素材。数据需要先被拆分、抽帧、识别、向量化，再结合地理位置、时间、车型、场景标签做混合搜索。这里需要的不是单点工具，而是一套能统一管理和处理多模态数据的底座。

证券行业也类似。行情、交易、财务、客户数据是结构化的，研报、公告、制度文件、新闻舆情是非结构化的。真正的业务价值，往往来自这两类数据的结合。研报解析、制度合规问答、投研知识检索，都需要把结构化业务数据和非结构化文本放在同一套数据服务体系中。

当 Agent 开始成为数据的使用者，这件事会更加重要。Agent 需要的不只是一次查询结果，而是持续、可信、可追溯的上下文。它需要访问业务数据、文档、向量、状态、记忆和执行记录，也需要在权限和治理边界内安全调用这些数据。

这正是 OceanBase DataStudio 和 OceanBase Lakebase 组合起来的价值。

OceanBase Lakebase 提供湖库一体的数据底座，OceanBase DataStudio 把数据生产、治理和服务流程组织起来。前者解决数据在哪里、如何统一管理和计算；后者解决数据如何被生产、治理、交付和复用。

完成一个训练数据筛选需求，从两天压到一条可追溯的 SQL，靠的不是某一个特殊功能，而是底层数据架构的变化。

过去，数据散在多套系统里，靠人搬、靠脚本拼、靠经验兜底。到了 AI 时代，这种方式会越来越难支撑模型和 Agent 的高频调用。

OceanBase DataStudio 的价值，是把数据接入、加工、治理、筛选、追溯和服务化放到一条链路里；OceanBase Lakebase 的价值，是让这条链路运行在一个具备多模态、混合搜索、事务一致性和开放计算能力的数据底座上。

训练数据生产只是第一个典型场景。更长远地看，AI 应用要真正进入生产系统，企业首先要把自己的数据管好、组织好、服务好。

这也是 OceanBase AI 数据库希望解决的问题：不是只给数据库加几个 AI 功能，而是让企业数据真正成为模型和 Agent 可以持续理解、检索和调用的生产级数据资产。

立即试用 OceanBase 企业版，体验国产数据库能力立即试用 OceanBase 企业版，体验国产数据库能力