表的边界，正在被AI撑破

过去一周，开放湖仓社区发生的事，表面看是一堆邮件列表投票和版本发布，实际上是一件事：AI的原始数据，正在被正式写进开放表格式的设计核心。

十月中旬，Community Over Code 格拉斯哥大会刚散场，不少贡献者还在返程航班上，Apache Iceberg、Parquet、Apache Polaris 的邮件列表就已经接上了走廊里没聊完的话题。Iceberg投票通过在v4规范里加入FILE类型；Polaris在争论这些非结构化文件进了目录之后归谁管；Parquet那一周在定义"一个向量到底是什么"。

如果你只看标题，会觉得这是格式规范的琐碎修订。但懂工程的人知道，表格式规范的每一次扩容，都是一次产业权力的重新划界。

🧊 图片和音频，第一次真正住进了表里

表格式的边界，从来不是技术问题，是地盘问题。

先看这周最实质的进展：Apache Iceberg 社区投票通过了在v4规范中新增File类型的提案。由 Talat Uyarer 发起的FILE类型工作组投票，最终以8张绑定+1票通过——Steven Wu、Péter Váry、Daniel Weeks、Gang Wu、Sung Yun、Amogh Jahagirdar、Yufei Gu 和 Russell Spitzer，另有19张非绑定+1票。

这个新类型能存储一段字节，既可以内联存放，也可以作为对外部对象的引用，并带有URI、偏移量、大小、内容类型和校验和五个固定子字段。它刻意对齐了 Parquet 的FILE逻辑类型——这意味着，图片、PDF、音频可以真正放进一个表列里，还带着真实的元数据和统计信息。

投票里有个细节值得玩味：Kurtis Wright 投了+0。他的理由是，维护作业需要一个信号来判断哪些文件仍被引用、哪些可以清理。这看似是工程细节，实则是文件进表后的第一道生命周期难题——行可以合并小文件、可以快照过期，但一段外部引用的字节，删与不删，牵动的可能是整个训练数据集。

一位长期参与Iceberg社区的贡献者私下说，FILE类型的通过与当年分区演进、模式演进的投票不同，它的反对声几乎为零，"大家太清楚不做的后果了"。

产业逻辑很直白：过去十年，数据团队把结构化数据搬进湖仓，靠的是"表"这个抽象。现在多模态AI的数据——图片、音频、文档切片——如果继续游离在表格式之外，就没有版本、没有快照、没有事务、没有血缘。AI数据要治理，第一步就是让它"进表"。Iceberg这一票，是把AI数据从文件系统的野孩子，正式收编进开放表格式这个户口本。

🗳️ 文件进了目录，权属成了新战场

规范写完只是上半场，下半场是钱和权。

FILE类型通过的同一周，Apache Polaris 社区开始争论一个更尖锐的问题：这些非结构化文件一旦坐在目录（catalog）后面，归谁所有、归谁管。这不是哲学问题——目录厂商的商业模式、云厂商的对象存储计费边界、企业内部数据团队和AI团队的责任划分，全押在这个问题的答案上。

回头看整个栈的分工就明白了：

Iceberg管表格式的物理布局，Polaris管谁能在什么权限下看到哪些表。现在FILE类型把字节数据塞进了表列，物理上可能是一段内联字节，也可能是一个指向外部对象的URI——权限、审计、生命周期管理的链条突然变长了。目录层如果不接住这件事，AI数据的治理就断在中间。

这周的投票分布也侧面说明了社区的参与热度：

27票赞成对1票保留，这个比例在Apache基金会的规范投票里算得上高度共识。共识越强，说明玩家越急——每一个都在赶AI数据基础设施这班车。

🌊 K2：把事件流直接建在对象存储上

湖仓的边界，还在往另一头扩张：实时。

Cloudflare 本周把 K2 推入公测——一个基于 R2 对象存储实现持久化日志的无服务器事件流服务。官方口径是生产端p99延迟约1秒；有测试者实测端到端p99为7.5秒，团队回应称高于预期。计费上，消费端每GB费用与生产端对齐。

这张表把本周事件串起来看，节奏感更强：

用mermaid时间线看更直观：

K2的意义不在"又一个Kafka平替"。传统消息队列的存储层是自建的日志分段文件，K2直接把持久化日志架在对象存储上——这和当年Apache Iceberg把表架在S3上是同一条路径：对象存储是云上最便宜、最耐久的地基，一切数据基础设施迟早要搬上去。 1秒的produce p99说明这条路线在延迟上已经可以接受，7.5秒的端到端实测则提醒大家，新鲜东西的工程账单还没付完。

对数据平台架构师来说，信号很明确：批、流、表、文件，正在收敛到同一个对象存储底座上。未来选型时，"存储计算分离"不再是加分项，而是入场券。

⚡ Polars 2.0：一次没人求着你要的破坏性升级

基础设施变快的代价，往往是悄悄改掉你依赖的默认行为。

Polars 2.0于10月6日发布，由创始人 Ritchie Vink 在发布文章中用一句话说清了变化：LazyFrame.collect() 现在默认运行流式引擎。听起来是纯性能优化，实际上埋了三个雷：

1. 行序不再保证。 对 join、group_by 和 unpivot，除非显式设置 maintain_order，输入行序不被保留。有团队在自己的测试里验证：200万行的inner join，默认配置下返回行的顺序和输入不一致；加上 maintain_order 后恢复。如果你的下游代码逐行比对结果，或者按位置读文件——同一个查询，在不同机器上会给出不同答案。

2. 核外处理默认开启。 内存用到约80%时开始向磁盘溢写，默认磁盘预算64GB。

3. 基准数据的表述很谨慎。 发布文章里的基准是厂商自己的运行结果，脚注明确写着与官方TPC结果不可比。

为什么一个Python数据框库的版本发布，值得和Iceberg、Polaris放在同一篇文章里讲？因为它是同一股力量的另一个切面：算力预算约束下的引擎重构。 流式引擎和核外处理，本质是承认"内存不够"是常态，用磁盘换规模、用乱序换并行度。这和K2把日志放到对象存储、湖仓把计算和存储分离，是同一个哲学：在成本约束下重新设计执行模型。

据一些升级过的团队反馈，绝大多数ETL任务改完默认值后直接就跑，但那些"碰巧依赖行序"的老管道，是最危险的一类静默bug——它不报错，只是数据悄悄错位。

🔮 共同主线：AI数据的一等公民化

把这四件事叠起来看，脉络非常清楚。

Parquet 本周在定义"一个向量是什么"——嵌入向量要不要成为逻辑类型、格式版本号意味着什么。加上Iceberg的FILE类型、Polaris的权属讨论，嵌入、文件、语义模型正在同时向开放湖仓的"一等公民"位置移动。

对买家（企业数据平台团队）来说，判断标准可以很朴素：你的图片、音频、PDF切片，能不能像一行订单数据一样，有schema、有快照、有权限、有血缘？两年前答案是不行，现在规范层面正在补齐，剩下的看各引擎和目录厂商的落地速度。

对厂商来说，赛道位置也在重新洗牌：

一个可以推演的判断：未来12到18个月，"支持Iceberg v4 FILE类型"会成为多模态数据管道选型的硬指标，就像当年"支持ACID"之于湖仓一样。而目录层的文件权属之争，大概率会演变成云厂商与中立目录厂商之间新的博弈点——谁控制元数据和生命周期，谁就控制AI数据资产的入口。

这一周开放湖仓社区真正讲的故事只有一句：AI数据的治理，正在从口号变成规范条款。 表格式的边界撑大之后，目录、引擎、对象存储每一层都要重新回答"你能管住什么"。下一阶段值得盯两件事：各引擎对FILE类型和向量类型的落地速度，以及目录层权属之争会不会催生新的标准之争。规范先行，落地竞赛才刚刚鸣枪。