湖仓十月：给AI数据上个正式户口

十月的开源湖仓社区，表面安静，底下却发生了一次'宪法级'修订：AI数据第一次被写进了正式规范。

上周的Apache Data Lakehouse Weekly透露了一个清晰信号——Apache Iceberg在v4规范里正式引入FILE类型，Polaris在争文件进目录后的归属权，Parquet在定义向量到底是什么。与此同时，Databricks用一篇实测博客把向量检索的成本账算到了小数点后两位。三条线索汇成一句话：AI数据不再是湖仓的'附件'，正在成为一等公民。

这不是概念，是写进投票记录的事实。

💡 8个+1票，Iceberg给非结构化文件开了门

一个格式规范的修改，通常不会上新闻。但这次不一样。

由Talat Uyarer发起的FILE类型工作组投票正式关闭：8票绑定赞成，来自Steven Wu、Péter Váry、Daniel Weeks、Gang Wu、Sung Yun、Amogh Jahagirdar、Yufei Gu和Russell Spitzer——这基本是Iceberg核心PMC的顶配阵容；另有19票非绑定赞成。这个投票结果在开源数据社区里属于罕见的'高共识度'。

新FILE类型能做什么？它可以把一段字节内联存储，或者作为外部对象的引用挂进表列，并带有URI、offset、size、content type和checksum五个固定子字段。翻译成人话：图片、PDF、音频，可以像普通数据一样坐进表里，带着真实的元数据和统计信息。

值得注意的是Kurtis Wright投出的那票+0：他提醒，维护作业需要信号来识别这些文件。这句话看似技术细节，实则点中了要害——非结构化文件一旦入表，compaction、快照过期、垃圾回收这些'物业工作'就全变了。

产业逻辑很直白：过去RAG和多模态训练的数据通常散落在对象存储里，靠外围脚本拼凑血缘和版本。FILE类型入规范后，这些能力收回到表引擎手中。据多位接近社区的人士观察，这一步之后，'湖仓存AI原始数据'从工程惯例变成了标准动作。

🗂️ 文件进了表，归谁管？目录层的权责之争

标准落地只是上半场，下半场在目录层。

Community Over Code Glasgow大会散场后，hallway里的讨论被延续到了邮件列表：Polaris社区在激烈争论一个根本问题——当非结构化文件坐进了Iceberg表，它们背后的目录归属到底算谁的？

这个问题不抽象。文件是引用外部对象存的，那对象存储上的实际字节、目录里的表元数据、以及AI应用读出来的语义，三者可能分属不同的owner。目录系统原本只管'表和分区'，现在突然要管'一段二进制和它的checksum'。权限模型、生命周期、审计，全都要重新对表。

放在数据要素流通的大背景下看，这场争论的分量不小：目录是权限与计量的天然锚点，文件归属权定了，AI数据资产的定价、审计、授权才有抓手。社区现在吵得越细，将来企业落地时踩的坑就越少。

📏 Parquet的难题：向量到底是什么？

同一周，最底层的Parquet社区在回答一个哲学味很浓的问题：什么是一个向量？什么算一次格式版本升级？

Embedding已经是AI管道里最常见的数据类型，但它在列式存储里长期处于'寄居'状态——要么存成二进制blob，要么靠外部约定解析。Parquet正在讨论把向量作为一等逻辑类型，同时厘清格式版本的语义边界：旧reader读到新类型时该怎么办，向下兼容的线画在哪。

这是典型的'底层先行'路径：存储格式定义了向量的语义，其上的Iceberg元数据、目录权限、检索引擎才有统一的地基。链路自下而上，一环扣一环。

对使用者来说，短期内感知不大；但两三年后回看，'向量在格式层有了名字'很可能是AI数据和结构化数据彻底合流的一个分水岭。

🚀 Databricks把账算明白了：4毫秒和31美元

标准在演进，工程实践也在同步交卷。

10月15日，Databricks在官方博客发布工程实测文章《Sizing Lakebase Search：Lessons from a Real App and 4 Million Passages》，用公司内部应用Slide Hub和MIRACL英文数据集，把Lakebase Postgres的混合检索容量规划做成了一份可复用的工程指南。

核心数字很硬：

4毫秒意味着什么？意味着'湖仓内做在线向量检索'不再需要默认外挂一个独立的向量数据库。0.5 CU月31~40美元，则给了中小团队一个明确的成本锚点——按这个单价线性外推，检索层第一次拥有了可预判的TCO。

一位做过类似容量规划的工程师私下评价：这份实测的价值不在数字本身，而在Databricks愿意把内部应用的真实选型过程摊开讲。成本透明，正在成为数据库产品的核心竞争力。

⚠️ 布局策略的老账本：Liquid Clustering不是银弹

存储和检索的账能算清，物理布局这笔'老账'却更难。

InfoQ刊出的工程师Kushal Kumar Vishwakarma的文章，在Delta Lake上横向对比了Liquid Clustering、ZOrdering和传统分区四种负载下的表现，结论耐人寻味：作者发现了两种未被官方文档记录的失败模式——也就是说，今天的生产系统里，很可能有团队正踩在这些坑上而不自知。

文章给出了一套布局策略决策框架，这正是社区当前最缺的东西。物理数据布局是湖仓工程里后果最重的决策之一：选错了，轻则查询慢十倍，重则compaction风暴拖垮管道。

这一节的判断是：AI数据入表，不只是加一个类型，物理层的一切假设都要重算。分区键怎么定、聚簇键是否包含embedding、文件大小与checksum的维护成本——这些问题的答案，短期内都还没有标准答案。

小结：名分已给，剩下的都是脏活

回到开头：十月这一周，Iceberg给了文件名分，Parquet给了向量名分，Polaris在争治理权，Databricks给出了成本锚点，独立工程师补上了布局的认知盲区。开源湖仓拥抱AI数据，已经从叙事进入施工阶段。

接下来值得关注的是Polaris目录归属之争的结论，以及FILE类型在维护作业信号上的补全。标准定了，接下来拼的是物业能力——垃圾回收、成本核算、权限审计，全是脏活，但也全是真壁垒。

本文事实来自Apache Data Lakehouse Weekly（2026年10月14-21日）、Databricks官方博客及InfoQ公开报道。