湖仓开始给AI数据上户口

10月下旬的一周，Apache Iceberg 邮件列表里通过了一项投票：把「文件」正式写进 v4 规范。同一时间，Apache Polaris 在争论这些文件进目录后归谁管，Apache Parquet 在定义什么是一个向量，阿里云则端出了 Agent 时代数据基础设施的完整链路构想。

这不是巧合。我的判断很直接：湖仓正在进行第二次扩容——从结构化数据的仓库，变成文件、向量、语义等 AI 数据的操作系统。 这次扩容的主导权，一半在开源社区手里，一半在云厂商手里。

🧊 一封邮件投票，把图片音频写进了表

故事从格拉斯哥的 Community Over Code 大会说起。会场散了，参与者还在回程航班上，但邮件列表没有停——走廊里没聊完的话题，搬回了邮件里继续。

最大的产出，是 Talat Uyarer 发起的 FILE 类型工作组投票：为 Iceberg v4 规范新增一个 File 类型。投票以 8 个 binding +1 通过，来自 Steven Wu、Péter Váry、Daniel Weeks、Gang Wu、Sung Yun、Amogh Jahagirdar、Yufei Gu 和 Russell Spitzer，另有 19 个非 binding +1。

这个新类型能干什么？它把一段字节——可以是内联存储，也可以是对外部对象的引用——放进表的一个列里，并带上固定的子字段：URI、偏移量、大小、内容类型和校验和。设计与 Parquet 的 FILE 逻辑类型对齐。换句话说，图片、PDF、音频，从此可以作为一个带真实元数据和统计信息的列，坐在表里。

不是没有保留意见。Kurtis Wright 投了 +0，理由是维护任务需要一种信号来区分——你不能让 compaction 这类后台作业把一个 500MB 的音频文件当普通小文件反复重写。

产业逻辑在这：过去十年，数据治理的对象是行和列；现在，非结构化文件第一次被纳入 schema、事务和统计信息的管辖范围。对 AI 管线来说，这是「可治理」三个字从承诺变成协议的时刻。 训练数据的血缘、检索语料的版本、多模态样本的版本对齐，终于有了底层锚点。

🔑 文件进了表，归属权吵起来了

金句先放这：文件进了表，麻烦才刚进门。

Iceberg 投票通过后，Apache Polaris 那边紧接着一个绕不开的问题：这些文件一旦坐在 catalog 背后，所有权归谁？是写它的引擎、建表的 catalog，还是底层对象存储？这不是哲学问题，而是权限、生命周期管理和计费的实际分界线。

与此同时，Parquet 社区在讨论两件事：什么是一个「向量」，以及格式版本号到底意味着什么。听起来枯燥，实则关键——embedding 要不要作为一等公民进文件格式，直接决定下游引擎读取向量时要不要做昂贵的格式转换。

把三层放在一起看，分工正在重新划定：

逻辑很清楚：AI 数据横跨了这三层——原始文件在对象存储、特征向量在文件格式、语义入口在表和 catalog。任何一层单独改版都不够，必须协同。而归属权之争的本质，是开放标准在防止任何一家引擎或云厂商把 catalog 做成新的锁定点。

🤖 阿里云把 Agent 链路一次说全

换个视角看国内。微博博主「诗班酒」（阿里云 相关账号）发了一条长文，问了一个问题：Agent 时代，数据基础设施的完整链路是什么？然后自问自答，给出了四个环节：

• 采集与接入：OpenLake 全模态湖仓，让一份数据被多引擎平权计算——注意「全模态」三个字，和 Iceberg 的 FILE 类型是同一个方向；
• 清洗与转换：Agent-Ready 数据管线，从人构建走向 Agent 自主构建；
• 存储与治理：ApsaraLakebase 湖库同源，口号是「放得下、放得起、醒得快」——成本与时效两个老问题的 Agent 版表述；
• 数据语义：业务语义本体加知识图谱，从记忆到知识是「可控的」。

这四个环节串起来看，云厂商的叙事已经变了：不再卖单点组件，而是卖一条 Agent 可以端到端走通的链路。原因也不难懂——Agent 是一种全新的数据消费者，它不点开 BI 看板，它高频发起小查询、自己拼管线、需要机器可读的语义。传统为人类分析师设计的数据平台，接口和粒度都对不上。

据多位跟踪开源生态的人士观察，OpenLake 强调的「一份数据多引擎平权」，与 Iceberg 生态「多引擎共享一张表」的理念高度同构——只是把话语体系从「表」换成了「模态」。

📊 三层协议同时改版，这不是巧合

把这一周的动静摊开，会发现一个罕见的现象：文件格式、表格式、数据目录、云厂商产品线，四条线在同一个月里同时动。

AI 数据是共同的驱动力，开源社区拿标准，云厂商拿落地。

embeddings、文件、语义模型，正在同时成为开放湖仓的一等公民。Iceberg 负责「文件怎么进表」，Parquet 负责「向量怎么存」，Polaris 负责「文件和向量归谁管」，阿里云的 OpenLake/ApsaraLakebase 负责「这一整套在真实业务里怎么跑得又便宜又快」。

用一张四象限来看当前格局（我的推演，坐标是方向性的）：

两点判断：第一，开放表格式生态技术门槛最高但商业变现要靠云厂商落地，双方是共生关系——开源定协议，云卖 SLA 和运维；第二，单点向量数据库的位置最危险，当 Iceberg v4 和 Parquet 都原生支持向量语义后，独立向量库的护城河会被从协议层侵蚀。

也要泼一盆冷水。Kurtis Wright 那个 +0 生态圈里私下被反复提起：文件类型会让表变得「重」——维护作业的信号机制、大文件的事务开销、catalog 的权限粒度，都是 v4 规范通过之后才会真正暴露的工程账单。协议上的赢家，不自动等于运维上的赢家。

🧭 真正的战场是数据消费权

再往深一层看：这一周所有讨论的交汇点，是「谁定义 AI 数据的消费方式」。

过去，数据的消费者是 SQL 引擎和人类分析师，表格式只需服务好这两类。现在消费者多了：训练管线要批量读文件、RAG 要毫秒级取向量、Agent 要理解语义本体。三类消费模式对应三种读取路径，谁能把它们统一在一份存储、一套元数据之下，谁就掌握了下一代数据平台的入口。

Iceberg v4 的 FILE 类型 + Polaris 的归属权机制 + Parquet 的向量语义，构成的是开放侧的完整答案；阿里云的「全模态湖仓 + Agent-Ready 管线 + 湖库同源 + 语义本体」，是云厂商侧的完整答案。两边用的词汇不同，画的却是同一张图。

接下来的 12 个月值得盯三件事：一是 v4 规范落地后，各引擎对 FILE 类型的实际支持进度；二是 Polaris 能否给出一个中立的文件归属与权限模型——这是开放生态能不能防住厂商锁定的胜负手；三是 Agent 自主构建管线的可靠性到底能到几分，这决定了「数据放得下」之后，「知识控得住」是不是一句空话。

结语

给 AI 数据上户口，听起来只是加一个字段，实际上是数据平台权力结构的重排。文件、向量、语义成为一等公民之后，表格式、catalog 和云厂商产品线的边界都要重画。

开源社区这一周拿出了协议，云厂商拿出了链路。真正的分晓，要等第一波把图片、音频、embedding 全部塞进一张 Iceberg 表的生产系统跑上一年——账单和故障，会比投票结果更诚实。