做 RAG 或 AI 应用的人都有个共同的痛点：原始文档在对象存储、结构化数据在数据仓库、向量数据在向量数据库，三套系统各管一段，元数据对不上、权限策略要配三遍、跨系统查一次数据要写好几次连接逻辑。
最近注意到 OSS 推出了三种 Bucket 形态——Object Bucket、Table Bucket、Vector Bucket，把非结构化、结构化、向量数据收进同一套存储层。这个设计思路值得拆一下。
一、三种 Bucket 的分工
先看清楚各自存什么：
| Bucket 类型 | 存什么数据 | 对应技术 |
|---|---|---|
| Object Bucket | 图片、视频、文档、任意文件 | 传统对象存储 |
| Table Bucket | 结构化表数据 | 原生 Apache Iceberg，内置 REST Catalog |
| Vector Bucket | 向量数据与索引 | 向量存储与相似度检索 |
关键点在于：这三种不是三套独立系统，而是同一套存储底座上的三种数据模型，共享同一套 SDK、权限策略（Bucket Policy）、日志审计和生命周期管理。
对 AI 应用来说，这个架构解决了一个实际问题：原始数据和派生数据可以放在一起管理。
比如一个 RAG 流水线的数据流向：
原始文档 → Object Bucket
↓ 文档解析 + Embedding
向量数据 → Vector Bucket
↓ 检索时
查询 → Vector Bucket 相似度召回
在过去这套链路的原始文档和向量分属两个系统，权限、备份、日志要各自配。现在可以统一在一套存储下，用同一套 Bucket Policy 控制访问，日志统一导出审计。
二、Vector Bucket 的检索链路
Vector Bucket 的工作机制值得单独说，因为它直接服务 RAG 场景。页面上的架构图显示了完整链路：
PutObject → OSS Bucket（海量原始数据）
GetObject →
第三方向量化（基于 ECS / 百炼等）
PutVectors → OSS 向量 Bucket（向量数据统一存储）
QueryVectors → RAG 检索 / AI Agent
ExportVectors → 表格存储（高召回率/高性能场景）
几个技术要点：
1. 向量化不在存储层做。 OSS 提供的是"存和查"，Embedding 由第三方完成（ECS 上的模型、百炼平台等），通过 PutVectors 接口写入。这个分工是合理的——Embedding 模型迭代快，不该硬编码进存储系统。
2. 元数据跟着向量一起存。 写入向量时可以带标量元数据（比如文档 ID、章节、页码、时间），检索时支持按元数据过滤。这是 RAG 精确召回的前提——光靠向量相似度不够，还要能按来源过滤。
3. 支持导出到高性能检索系统。 对于召回率和延迟要求极高的场景，可以 ExportVectors 到专门的表格存储。这个设计承认了对象存储在超高性能检索上有边界，留了升级路径。
4. 统一 SDK 管理。 原始数据和向量数据用同一套 SDK 和工具管理，不用维护两套客户端。
三、Table Bucket 为什么选 Iceberg
Table Bucket 原生支持 Apache Iceberg，内置 REST Catalog，兼容 Iceberg REST API 与 S3 Tables API，能和 Spark、Flink、Trino、Kafka 对接。
选 Iceberg 而不是自研表格式，技术逻辑是：Iceberg 已经是数据湖的事实标准，生态完整。存储层如果自研表格式，等于让用户换掉整条数据栈；兼容 Iceberg 则意味着现有的 Spark/Flink 作业可以直接读写。
值得注意的是存储侧承担了维护工作：后台自动做 Compaction（合并小文件）、快照管理、孤儿文件清理。这些在传统数据湖架构里是要单独跑定时任务的，现在下沉到存储层，计算集群不用再消耗算力做数据维护。
四、这套架构适合什么场景
适合：
- RAG 知识库：原始文档和向量数据统一管理，权限一套配置
- 多模态 AI 应用：图片、视频、文档和它们的向量表示在同一个存储下
- 数据湖 / 湖仓：Table Bucket 兼容 Iceberg，现有 Spark 生态可以直接接
- AI Agent 的长期记忆：Agent 产生的文件、结构化记录、向量记忆统一存储
需要谨慎：
- 超低延迟检索（毫秒级 P99 要求极高）：通用对象存储的检索延迟比不上专用向量数据库，高要求场景还是要走导出到高性能系统的路径
- 重度事务型业务：对象存储不是数据库，不适合高频更新单条记录的业务
- 已有成熟向量数据库栈的团队：迁移成本要评估，边缘收益可能不划算
五、一个容易被忽略的点
这套架构真正有价值的地方不是"存三种数据"，而是统一的治理层。页面里提到了几个细节：统一的 Bucket Policy、统一的日志导出审计、统一的生命周期沉降、统一的按量付费弹性。
对 AI 应用来说，数据治理的复杂度往往比存储本身更麻烦——数据在哪、谁能访问、什么时候删、怎么审计。三种数据模型共享一套治理策略，减少的是运维的心智负担。
六、写在最后
对象存储从"存文件"进化到"存任意形态的 AI 数据"，本质是把数据湖、向量库、文件存储的边界打通。理解 Object / Table / Vector 三种 Bucket 的分工，就知道什么数据该放哪、检索链路怎么走。
完整的产品能力与接口说明可以看官方页面——查看对象存储 OSS 的多模态数据底座能力说明。具体规格以页面实际展示为准。
你在做 AI 应用时数据是怎么分层的？原始数据和向量分开存还是放一起？评论区聊聊。
