如果你最近在做 RAG、多模态检索、推荐、AIGC 训练数据，应该多少都踩过同一类坑。
原始 PDF、图片、音频、视频扔在对象存储里；结构化元数据放在数仓；embedding 又放进向量库；OCR、切块、标签、caption、审核结果再各存一份；训练时再导出成另外一套样本格式；线上服务为了低延迟，又单独维护一层索引和缓存。
一开始看起来都合理。等系统跑起来，问题就来了：
同一份数据被复制很多次；同一个字段在不同系统里口径不一致；模型换一次 embedding，就要把整条链路重跑一遍；出了问题也很难回答一句最基本的话——线上这个结果，到底对应的是哪一版数据、哪一版特征、哪一版索引？
这件事本质上不是“向量库不够强”，也不是“对象存储不够大”，而是 AI 把数据底座从“表”为中心，硬生生推成了“样本”为中心。你不再只是管理几张事实表和维表，而是在管理一整套会持续演化的 原始模态、解析结果、特征、标签、索引和模型输入输出。
也正因为这样，过去主要服务 BI 的湖仓，开始被重新定义。到 2026 年上半年，AWS 的 S3 Tables 直接把表存成 Iceberg 格式；微软 OneLake Table APIs 已经 GA，并提供兼容 Iceberg REST Catalog 的接口；Snowflake 让外部引擎通过 Horizon Catalog/Polaris 去读写 Snowflake 管理的 Iceberg 表；Databricks 一边继续做 UniForm，一边把 Iceberg v3 推到了 public preview。你会发现，主流平台虽然路线不同，但都在往一件事上收敛：开放表格式 + 开放目录协议 + 可被多引擎消费的数据底座。
而在这条主线上，Iceberg + Ray 是一个很值得架构师认真研究的组合。前者负责把数据变成“可治理、可版本化、可共享的事实层”，后者负责把多模态 ETL、embedding 生成、训练喂数、批量推理和在线服务串成一条真正跑得动的执行链。
我对这个组合的判断先放在前面：
Iceberg + Ray 不是一个“万能大一统产品”，但它是今天最接近开放、多模态、AI-ready 湖仓底座的一条务实路线。
更准确一点说，未来真正成熟的多模态湖仓，大概率不是只有一个格式，而会是：
Iceberg 做事实层和事务层，Ray 做执行层，AI-native 格式或索引层做检索加速层。
理解了这一点，很多技术选型就不会拧巴了。
一、先把概念说清楚：多模态数据湖仓，不是“把图片放进 S3”这么简单
我比较认同的定义是：
多模态数据湖仓 = 在同一个开放架构里，同时管理原始模态数据、结构化元数据、衍生特征、检索索引、训练样本和治理策略，并且让分析、训练、推理、检索都能围绕同一份事实源运转。
这里面至少有五件事要同时成立。
第一，它得能接住原始数据。
图片、音频、视频、PDF、网页快照、日志、事件流，这些原料不可能都规规矩矩变成整齐的二维表。
第二，它得能接住衍生结果。
OCR 文本、切块结果、字幕、caption、embedding、质量评分、标签、审核标记、模型输出，这些东西不是“附属品”，而是 AI 系统里的主数据。
第三，它得能复现。
训练集、评测集、RAG 语料、召回索引，最好都能回答“这是谁在什么时候，用哪一版快照生成的”。
第四，它得能治理。
权限、血缘、保留期、删除策略、合规审计，不能因为数据变成了 PDF 或图片就消失。
第五，它得能跑得动。
不是只支持离线 SQL，还要支持分布式预处理、批量 embedding、训练喂数、在线检索、服务化推理。
这也是为什么我一直不太认同“多模态湖仓就是对象存储 + 向量库”这种说法。那更像是把问题拆开了，却没有真正统一。对象存储只负责存，向量库只负责查，真正麻烦的 版本、事务、演化、共享、治理、回放，还是散落在系统之间。
二、为什么偏偏是 Iceberg + Ray 这个组合，最近越来越像一条主线
先说 Iceberg。
Iceberg 的价值从来不只是“表放在对象存储上”。它真正厉害的地方，是把对象存储上的文件，变成了一种接近数据库表体验的开放抽象：支持隐藏分区、分区演化、时间旅行、回滚、乐观并发、可串行化隔离，以及跨引擎共享。官方文档一直强调这件事：Iceberg 通过原子替换 metadata file 来保证一致性，读者始终读取一致快照；查询不依赖目录 listing；多写者通过 optimistic concurrency 重试提交；分区布局还能在不改查询的情况下演化。对于要长期维护的 AI 数据资产来说，这些能力不是加分项，是底线。
再说 Ray。
Ray 的独特之处，在于它不是传统意义上的 SQL 引擎，而是一套 Python-first、异构资源友好、能把数据处理、训练和服务串起来的分布式执行底座。Ray Data 官方现在已经把自己的定位写得很明确：它是为 AI workload 设计的数据处理库，支持 batch inference、preprocessing、training data loading，而且用 streaming execution 让 CPU 和 GPU 这两类资源都尽量别闲着。它支持的数据形态也不是只盯着 Parquet，文档里明确写了 Lance、images、JSON、CSV、audio、video 等多种 AI 常见格式。Ray Train 可以直接把 Ray Data 变成流式喂数通道，Ray Serve 则把多模型部署、独立扩缩容和在线服务打通。
最关键的一点在于，这两个项目已经不是概念上的“能组合”，而是接口层面已经开始对接。Ray Data 官方已经提供了 read_iceberg 和 write_iceberg，底层走的是 PyIceberg；读取时可以指定 snapshot，写入时支持 append、overwrite、upsert，还能给 snapshot 写自定义属性。对 AI 团队来说，这个细节非常重要：它意味着 Python 侧的数据加工、embedding 生成、模型批推理，不需要再绕回 JVM 世界做一次“中间翻译”。
而 PyIceberg 本身也是这个组合越来越像主线的原因之一。它是 JVM-free 的 Python 实现，配置方式是 catalog-centric；如果 REST catalog 开启了 scan planning，还可以做 server-side scan planning。说白了，Iceberg 原来很强，但在 Python/AI 圈子里离一线开发体验还有点距离；PyIceberg 把这段距离补上之后，Ray + Iceberg 这条路才真正顺了起来。
所以从架构上看，Iceberg + Ray 的价值不是“一个负责存，一个负责算”这么简单。更准确一点是：
- Iceberg 负责把数据资产变成可共享、可版本化、可治理的事实层。
- Ray 负责把多模态预处理、批量推理、训练和服务，变成同一个执行体系。
- 两者之间通过开放 catalog 和 Python API 接起来，尽量少做数据搬运和格式折腾。
这就是它为什么很适合 Data+AI 场景。
三、但别高兴太早：Iceberg 很重要，却不是多模态湖仓的全部答案
这里有一个特别容易搞错的点。
很多人一听“多模态数据湖仓”，就会下意识觉得：那是不是以后图片、视频、embedding、ANN 检索，全都直接放进 Iceberg 就行了？
我的判断是：没那么简单。
Iceberg 很适合作为 system of record，也就是事实层、版本层、事务层。
但它不是天生为所有 AI 访问模式设计的，尤其不是为“高频随机访问 + 向量相似检索 + 混合检索”设计的。
这不是 Iceberg 的短板，而是职责边界。
1）Iceberg 擅长的是“表的正确性”，不是“所有访问模式的极致性能”
Iceberg 的强项在于元数据组织、快照一致性、分区裁剪、schema/partition evolution、跨引擎事务语义。它的设计初心是让大规模分析表在对象存储上也能拥有数据库式体验。这个定位非常清晰。
但多模态 AI 的很多访问模式，不是传统分析扫描。比如：
- 从海量图片样本里随机抽样做训练；
- 在线按向量近邻召回；
- 同时做 BM25 + vector + SQL filter 的 hybrid search；
- 从超大视频或文档对象里按片段、页、frame 随机取局部数据；
- 对 embedding 和原始 blob 做高频点查而不是全表扫。
这些需求背后，往往更看重 random access、二级索引、向量索引、lazy loading，而不是只有 scan。
Iceberg 社区自己其实也在承认这个现实。2026 年 2 月，Iceberg 官方宣布 File Format API 定型，明确说过去的格式处理逻辑不利于新格式演进，而新一代格式更强调 fast random access、GPU-native encodings、flexible layouts、built-in indexing。更关键的是，这篇官方文章直接点名了 Lance 和 Vortex 这类格式，表示新的 API 会让它们更干净地接入 Iceberg 生态。这个动作很有信号意义：社区不是要把 Iceberg 变成单一万能格式，而是在把它升级成一个能容纳新型 AI-native 格式的开放表层。
2）Iceberg v3 对 AI 很关键，但它解决的是“更好的事实层”，不是“终极检索层”
到 2026 年，Iceberg 讨论最多的方向已经很明显是 v3。官方规范里，v3 带来了几件对 AI 场景很重要的事：
- Row Lineage：给新增行维护
_row_id和_last_updated_sequence_number，这对增量数据追踪、样本可追溯和后续审计很有价值。 - Deletion Vectors：把单文件删除位置编码成 bitmap，减少频繁重写整文件的成本。
- VARIANT：支持半结构化数据。
- Default Values：宽表或复杂 schema 迭代时更友好。
- Geometry/Geography 等扩展类型。
这些能力对多模态数据很有帮助。比如文档解析出来的 metadata、模型推断结果、弱监督标签，本来就很像半结构化对象；Row Lineage 对训练样本集的可回放也很有意义；Deletion Vectors 能让样本过滤、数据删除、迟到修正没那么粗暴。
但它们本质上仍然是在强化 表层的表达力和事务能力，不是在直接替代一个 ANN 引擎。
3）Puffin 很有意思，但它也更像“旁路索引/统计容器”，不是一键变向量库
Iceberg 还有一个经常被忽视的东西，叫 Puffin。官方定义很直接：它是一个用来存储索引和统计信息的文件格式，承载那些没法直接塞进 manifest 的 blob；Deletion Vector 也是通过 Puffin blob 来存的。
这说明 Iceberg 并不是只会“metadata.json + manifest”。它也在给辅助索引和扩展统计留空间。
但从今天的工程现实看，Puffin 更像是 增强 scan planning 和删除/统计的配套机制。要直接把它当成高性能向量检索层，还太早。这个判断很重要，因为它决定了你怎么设计整套多模态湖仓：
你应该把 Iceberg 当作 authoritative truth，而不是强迫它去扮演所有在线检索角色。
四、所以真正成熟的多模态湖仓，应该是分层的，而不是“大一统”
如果让我用一句话概括今天这个领域最重要的架构判断，那就是：
多模态湖仓不是一个格式吃掉全世界，而是一个分层体系。
我自己更推荐把它拆成下面这几个角色来理解：
1）Iceberg：事实层 / 版本层 / 事务层
它负责回答的是：
- 哪些数据是系统认可的事实源；
- 当前和历史快照分别是什么；
- schema 怎么演化；
- 哪个 branch/tag 对应哪次实验；
- 哪些引擎可以共享读写；
- 访问控制和目录发现怎么统一。
这层更像“账本”。
2）Ray：执行层
它负责回答的是：
- 原始 PDF、图片、音频怎么批量解析；
- embedding、caption、OCR、审核结果怎么并行生成；
- 训练时怎么把 CPU 预处理和 GPU 训练解耦；
- 批量推理和在线服务怎么放在同一套资源体系里；
- 任务怎么随着 CPU/GPU 需求自动扩缩。
这层更像“工厂”。
Ray Data 的 streaming execution，允许不同 operator 独立扩缩；但也要注意，这种流式优势主要体现在非 shuffle 场景，像 sort、groupby 这类 all-to-all 操作仍然会触发 materialization。这个细节在多模态 ETL 里非常关键，因为很多人会误以为“流式执行 = 所有场景都不落盘”，实际不是。
3）AI-native 检索/存储层：加速层
这里不一定非得是 Lance，但 Lance 这条路线现在非常值得关注。
官方文档把 Lance 定义成“面向 multimodal AI 的 open lakehouse format”，强调 hybrid search、random access、native multimodal data support、feature engineering；Polaris 也在 2026 年初宣布可以通过 Generic Table API 同时管理 Iceberg 和 Lance 表，放进同一个 catalog 里。更值得玩味的是，Iceberg 自己的新 File Format API 也明确提到了 Lance。整个生态给出的信号非常一致：未来的开放多模态湖仓，很可能不是 Iceberg 和 AI-native 格式二选一，而是它们并存，各守职责。
如果你非要我用一个特别接地气的比喻：
- Iceberg 是账本
- Ray 是工厂
- Lance / 向量索引层是加速器
把这三件事混成一个盒子，系统一定会很别扭。
五、从架构师视角看，一套能落地的 Iceberg + Ray 多模态湖仓该怎么搭
我给一个我自己比较认可的参考架构，不追求“最炫”，追求的是可落地。
这张图里，有几个关键原则。
原则一：原始大对象尽量留在对象存储，Iceberg 管“事实元数据”和“衍生结果”
别一上来就想着把大 blob 全塞进 Parquet 列里。
真实工程里，更稳妥的做法通常是：
- 原始文件留在对象存储；
- Iceberg 表记录稳定主键、URI、来源、checksum、许可信息、创建时间、基础属性；
- OCR、chunk、caption、embedding、审核分、标签等衍生结果再进 Iceberg 的派生表。
一个最简单的资产主表，大概长这样：
CREATE TABLE media.assets (
asset_id STRING,
media_type STRING, -- image / pdf / audio / video / text
uri STRING,
source STRING,
sha256 STRING,
created_at TIMESTAMP,
license STRING,
width INT,
height INT,
duration_ms BIGINT,
metadata VARIANT
)
USING iceberg
PARTITIONED BY (days(created_at), media_type);
如果你当前引擎对 Iceberg v3 的 VARIANT 还没完全吃透，就先用 JSON 字符串或者把高频字段拆平，别死磕。规范走得很快，但各引擎支持速度不完全一致，这个现实要接受。Iceberg 当前稳定发布到 1.10.1，社区一边在继续补 v3 相关能力，一边准备把 File Format API 放进 1.11.0。Databricks 也才在 2026 年 4 月把 Iceberg v3 放到 public preview。
原则二：把“解析单元”和“资产本体”分开
对文档来说，解析单元可能是 page、chunk；
对视频来说，可能是 shot、segment、frame；
对音频来说，可能是 utterance、time window。
这一层最好单独建表，而不是把所有派生结果都回填到原始资产表里。原因很简单：一份 PDF 可以切成几百个 chunk，一段视频可以出成千上万个 frame。你如果把这些强行塞回一张“资产宽表”，后面 join、过滤、版本管理都会乱。
更实用的设计是：
assets：资产级主表units：chunk/page/frame/segment 粒度表features：embedding/caption/tag/score 表labels：人工或自动标签表training_sets：训练/评测切分和快照映射表
原则三：embedding 可以落 Iceberg，但高并发 ANN 不要只靠 Iceberg
这是很多团队一开始最容易误判的地方。
如果你的 embedding 主要用于：
- 离线分析；
- 训练样本构造；
- 批量相似度计算；
- 少量低频检索；
那把 embedding 当作 Iceberg 中的一个派生表，完全没问题。
但如果你要的是：
- 高并发 ANN；
- hybrid search；
- 秒级重建或热更新索引；
- 大规模随机点查；
那就别只盯着 Iceberg 了。你大概率还是需要一层专门的检索加速层，Lance 或向量数据库都可以，取决于你更看重开放格式、嵌入式集成还是纯服务化体验。Lance 官方把自己的重点直接放在 hybrid search、fast random access 和 multimodal blob 上；Polaris 也已经允许 Iceberg 和 Lance 共用 catalog。
所以我更推荐的思路是：
Iceberg 里存“权威特征表”，Lance/向量层存“服务索引”。
索引坏了可以重建，权威事实别丢。
原则四：让 Ray 把离线处理、训练喂数和服务串成一条线
这条线是 Iceberg + Ray 最值钱的地方。
Ray Data 负责大规模 ingest、清洗、切块、embedding；
Ray Train 负责把预处理和训练 workers 串起来；
Ray Serve 负责把在线推理和 agent 入口接住；
KubeRay/Ray Autoscaler 负责根据任务资源需求扩缩 CPU/GPU 节点。
一个很常见的处理链，大概会是这样：
import ray
ray.init()
# 1. 从对象存储读原始文件
docs = ray.data.read_binary_files(
"s3://my-bucket/raw-docs/",
include_paths=True
)
# 2. 解析 PDF / DOCX / 图片
parsed = docs.map_batches(parse_and_chunk, batch_size=32, num_cpus=2)
# 3. 生成 embedding / caption / OCR 修正
features = parsed.map_batches(embed_and_enrich, batch_size=128, num_gpus=1)
# 4. 落到 Iceberg 事实表
features.write_iceberg(
table_identifier="ai.features",
catalog_kwargs={"name": "prod", "type": "rest"},
snapshot_properties={"job": "embed_v2"}
)
如果你要从 Iceberg 某个快照复跑，也可以直接按 snapshot 读：
ds = ray.data.read_iceberg(
table_identifier="ai.features",
snapshot_id=123456789,
catalog_kwargs={"name": "prod", "type": "rest"}
)
这些接口都已经在 Ray 官方文档里给出来了。
六、Iceberg + Ray 真正难的，不是“搭起来”，而是这些细节
讲真，今天这个领域最容易让人误判的地方，是 demo 都不难，难的是一上量就开始变形。
1. 小文件和写放大，永远是第一批爆炸点
Ray Data 的执行单位是 block。官方文档明确提到，Ray 会动态决定 block 数量和大小；如果 block 太小，元数据和调度开销会很高；如果 block 太大，又容易吃爆内存。文档甚至直接建议用 ds.stats() 去观察 block 大小，理想上别太碎。与此同时，Iceberg 天生就需要 compaction 来把文件布局整理回来。
这件事在多模态场景更麻烦，因为：
- 原始文件大小分布非常不均匀；
- 解析后每行数据可能也很大；
- embedding 生成又会引入新的派生写入；
- 你还可能频繁局部覆盖某些分区或样本集。
我的建议很直接：
把写入策略和表维护当成产品能力，不要当 cron 杂活。
包括：
- 控制 block/file size；
- 明确 append / partial overwrite / upsert 的使用边界；
- 定期 compaction；
- 管理 snapshot retention；
- 不要让训练中间产物无限制地污染主分支。
2. Ray 的 streaming execution 很香，但一遇到 shuffle 就别想当然
Ray Data 的 streaming execution 确实很适合 AI 预处理链，特别是 CPU 解析 + GPU embedding 这种流水线。不同 stage 可以独立并发和占用不同资源。
但官方文档也说得很清楚：sort()、groupby() 这类 shuffle 操作需要 materialize，会中断 streaming。对多模态样本工程来说，这意味着很多“看着像普通 DataFrame 操作”的语句，一旦涉及全局重排、去重、全局聚合，成本会突然跳上去。
所以别把 Ray Data 当成“自动无限流式处理器”。
它更像一台很强的异构流水线，但遇到全局洗牌，代价还是得付。
3. 大二进制文件会把内存和 object store 打得很疼
Ray 官方性能文档里专门点出来了：大文件、超大行、object spilling 都会让性能掉得很明显；Dataset 的中间 block 放在 object store 里，超出容量会 spill 到磁盘；而大于 1GiB 的 binary file、本身就是已知高风险场景。
这对多模态任务太关键了。因为图片、视频、PDF 恰恰最容易命中这些问题。
经验上我会这么做：
- 原始超大文件尽量先做外部切分，不要单文件直接喂整条链；
map_batches控制 batch size，不要贪大；- 用 CPU 节点做重预处理，GPU 节点专心做 embedding / 推理；
- 限制某些 stage 的并发，不要让 object store 溢出；
- 真要做大规模视频处理，优先按 segment/frame 组织中间结果，而不是每次反复回读整段视频。
4. 不要把 Iceberg branch/tag 当成炫技功能，它在 AI 数据集里特别有用
Iceberg 的 branching / tagging 官方一直推荐用于审计、保留历史快照、测试新作业。放到 AI 场景里，这东西特别实用。因为 AI 数据处理天然有“实验分支”的需求：新一版切块策略、新一版过滤规则、新一版标签器、新一版 embedding 模型，都可能先想在隔离分支里验证，再决定要不要 merge 到主线。
这套东西一旦用起来，你会发现它不只是“好看”，而是能把很多过去只能靠目录命名解决的问题，变成真正的表级版本管理。
5. 最容易被忽视的，不是存储，而是目录和治理
我越来越强烈的一个感受是：
多模态湖仓的真正战场，正在从“文件格式”转向“目录协议和控制面”。
Iceberg REST Catalog 官方就把问题说得很明白：随着语言和引擎越来越多，catalog 如果各搞各的，兼容性会变得很差，所以社区才做了 REST catalog protocol，目的是让新语言和引擎只实现一个 client 就能接任意 catalog。它还顺带带来了 server-side deconfliction、metadata 管理简化、lazy snapshot loading、多表提交等能力。
这也是为什么 2026 年整个市场都在往 catalog 收敛：
- Polaris 在 2026 年 2 月正式毕业成 Apache Top Level Project，定位就是 vendor-neutral 的 Iceberg catalog。
- Snowflake 的 Horizon Catalog 用 Polaris 做互操作层，让外部引擎通过开放 REST 协议查询甚至写入 Snowflake 管理的 Iceberg 表。
- 微软 OneLake Table APIs 已经 GA，并支持 Iceberg REST Catalog 风格的元数据操作。
- Databricks 也明确在推 Unity Catalog 作为 Iceberg 生态的中心枢纽之一。
站在架构师视角，这意味着什么？
意味着你以后最不应该做的事，就是继续让每个引擎各自 path-based 地直读直写对象存储。
那样短期方便，长期一定失控。
七、市场到今天，其实已经给出了一些很清楚的方向
如果把 2025 到 2026 这段时间的市场动作放在一起看，趋势其实非常明显。
方向一：Iceberg 正在从“开放表格式”升级成“开放数据底座”
截至 2026 年 4 月，Iceberg 官方稳定发布已经到 1.10.1；社区又在推进 1.11.0，把新的 File Format API 带进来。这意味着 Iceberg 不再只是在 Parquet/ORC/Avro 那套老世界里做得更好，而是在主动给新一代 AI-native 格式和文件布局留接口。
方向二：目录协议正在变成“数据交换的通用语言”
Iceberg REST Catalog 官方就是按这个思路设计的，而 Polaris 的成长也说明社区正在把“vendor-neutral catalog”当成真正的战略层。Snowflake 甚至在工程博客里直接把 Iceberg REST Catalog 叫作 data exchange 的 definitive language。这个说法虽然带厂商立场，但趋势判断没问题：开放表格式这场仗，下一阶段真正比拼的是 metadata/control plane。
方向三：多模态湖仓不会只有一个格式
这点非常关键。
Polaris 2026 年初已经宣布能通过 Generic Table API 管 Lance 这类非 Iceberg 表；Iceberg 自己的新 File Format API 也点名 Lance/Vortex；Lance 则把自己定义成 open lakehouse format for multimodal AI。行业在承认一个现实：分析事实层和检索加速层，未必是同一种物理格式。
方向四：Data 和 AI 的执行层正在被重新统一
Ray 这条线特别明显。Ray Data 负责 ingest 和 batch inference，Ray Train 负责训练，Ray Serve 负责服务；ray.data.llm 还能直接接 vLLM / SGLang，做 batch LLM/VLM 处理。对于多模态系统来说，这个统一非常重要，因为过去数据工程和 AI 工程常常是两条完全断开的链。现在它们开始真的共用一套分布式执行底座了。
八、那 Iceberg + Ray 到底适合什么团队，不适合什么团队？
我不想把这个话题讲成“所有公司都该立刻上多模态湖仓”。那不现实。
比较适合的场景
如果你满足下面这些特征，Iceberg + Ray 很值得认真看：
- 数据形态确实已经不再是纯表，而是文档、图片、音视频、网页、日志混合；
- 你有比较重的 Python/模型处理链；
- 你不希望被单一云厂商或单一数仓绑定死；
- 你希望分析、训练、批推理、服务能围绕同一套数据事实层来跑；
- 你对版本回放、审计、合规、实验可追溯有明确要求。
不那么适合的场景
如果你的需求仍然主要是 BI + 一点点 embedding 检索，系统规模不大，团队也没有明显的多引擎诉求，那没必要一上来就把架构做这么重。很多时候，“一个成熟数仓 + 一个向量服务 + 一点流程治理”就够了。
架构不是越先进越好，而是越匹配问题越好。
九、从商业价值看，多模态湖仓真正值钱的，不是“省一套存储钱”
很多团队一聊湖仓，就容易把价值落在“更便宜”。这当然是一个点，但在多模态 AI 里，真正大的价值通常不止成本。
1）它会显著降低数据复制和口径漂移
过去一套 AI 系统里，原始数据、衍生特征、训练样本、检索索引，往往是四个世界。你每接一个新模型、新向量库、新服务，就复制一遍。
一旦有了统一的事实层和版本层，复制不一定完全消失，但会明显收敛。
2）它会大幅缩短“数据改一次，系统全体重来”的周期
例如：
- 你想把 chunk 规则从 512 token 改到 1024；
- 你想试一版新 OCR；
- 你想把过期图片从训练集中剔掉；
- 你想重新生成一批 caption 或 embedding。
如果底座是开放的、版本化的，这些动作至少是可回放、可比对、可逐步发布的。
如果底座是碎片化的，你基本只能“重灌全家桶”。
3）它让 AI 系统第一次真正拥有了“数据可审计性”
这点在金融、医疗、制造、政企场景里会越来越重要。
AI 结果不再只是模型问题，很大一部分责任会回到数据来源、标签版本、过滤规则和特征快照上。
没有一层统一的版本与治理，很多事根本说不清。
4）它让“开放”和“高性能”终于没那么对立了
过去很多公司对开放架构最大的顾虑是：开放是不是就意味着性能一般、治理一般、体验一般？
到今天这个答案正在变化。Iceberg 在事务与多引擎上已经足够成熟；Ray 在 AI 执行链上越来越完整；Polaris/REST catalog 把控制面统一起来；AI-native 格式又在补齐 random access 和 hybrid retrieval。
这条路线的意义就在于：你不需要在“开放”和“能打”之间永远二选一。
十、最后说说我的几个判断
判断一：多模态湖仓的终局，不会是“一个格式打天下”
更可能的终局是分层协同：
- Iceberg：事实层、版本层、事务层
- Ray：执行层
- Lance/向量索引：检索加速层
- REST Catalog：控制面
谁想把这几件事硬揉成一个封闭产品，短期也许很顺，长期大概率会重新走回锁定和重复建设。
判断二：Iceberg 会越来越像“开放数据底座”，而不只是“开放表格式”
v3 已经把 row lineage、deletion vectors、variant 这些对 AI 更友好的能力拉进来了；File Format API 又把下一代格式接入的路打开了。
Iceberg 最有价值的，不一定是把所有模态都原生吞进去，而是成为那个能把不同引擎、不同格式、不同 workload 接到同一个事实层上的核心抽象。
判断三：Ray 这类“统一执行层”会比很多人预想得更重要
AI 工作负载不是单一 SQL，也不是单一训练框架。它是 CPU 预处理 + GPU 推理 + 训练喂数 + 在线服务 的组合。能把这些放进同一套资源调度和编程模型里，价值会越来越大。Ray 现在已经在沿着这条路把 Data、Train、Serve 和 LLM pipeline 连起来了。
判断四：真正的战略高地，会慢慢从“存什么格式”转向“谁控制目录、权限和语义边界”
我甚至觉得，这会是接下来两三年最核心的变化。
因为文件可以是开放的，数据如果没有统一 catalog、统一 policy、统一 discovery，开放就只是表面开放。Polaris、OneLake Table APIs、Horizon Catalog、Unity Catalog 的一系列动作，其实都在说明这件事。
写在最后
如果你问我，多模态数据湖仓到底值不值得做，我的回答是：
值得，但别把它理解成“再上一个大平台”。
它真正要解决的，不是“把图片和 PDF 放哪里”，而是让 原始数据、衍生特征、训练样本、检索索引、批量推理和在线服务，终于能围绕同一份可治理、可回放、可共享的事实源运转起来。
从这个角度看，Iceberg + Ray 之所以值得聊，不是因为它们俩刚好能拼在一起，而是因为它们分别踩中了多模态 Data+AI 架构里最关键的两层：
- Iceberg 让数据资产变得像数据资产，而不是一堆文件。
- Ray 让 AI 计算链变得像生产系统，而不是一堆脚本。
至于再往前走一步，我的判断很明确：
真正成熟的多模态湖仓，不会只是一套 Iceberg + Ray，而会是以 Iceberg 为事实层、以 Ray 为执行层、再叠加 AI-native 检索加速层和开放 catalog 控制面的组合体。
这条路不一定最简单，但很可能是未来几年最不容易走死的一条路。
