湖仓开源三巨头，全在为AI让路

2026年10月中下旬的这一周，对开放湖仓生态来说不平静。Apache Iceberg 投票通过在 v4 规范里新增 FILE 类型，Parquet 在争论向量到底是什么，Polars 2.0 直接把流式引擎设为默认，Cloudflare 推出了跑在 R2 对象存储上的无服务器事件流 K2。

这四件事看似分散，其实指向同一个判断：AI 数据——embeddings、原始文件、语义模型——正在从湖仓的"附件"升级为"一等公民"，而承载它的基础设施，正在用改默认值的方式完成一次硬切换。

本周关键节点，按时间捋一遍：

• 2026-10-06：Polars 2.0 正式发布，collect() 默认走流式引擎
• 2026-10 中旬：Community Over Code Glasgow 结束，讨论从线下延续到邮件列表
• 2026-10-14~21：Apache Iceberg FILE 类型工作组投票关闭，8 票 binding +1
• 同期：Cloudflare K2 进入公测，主打跑在 R2 上的持久化日志

🧊 表格第一次装下了非结构化的世界

金句：当一张表里能放一张图，数据湖才算真正接住了 AI。

先说这周最重的锤子：Apache Iceberg 社区投票通过了在 v4 规范中新增 File 类型。提案由 Talat Uyarer 发起，最终拿到 8 个 binding +1——来自 Steven Wu、Péter Váry、Daniel Weeks、Gang Wu、Sung Yun、Amogh Jahagirdar、Yufei Gu 和 Russell Spitzer——外加 19 个非约束性 +1。

这个新类型不复杂，但意义重大：它把一段字节序列（inline 存储，或指向外部对象的引用）作为表里的一个列值，并带有 URI、offset、size、content type、checksum 这些固定子字段。它直接对标 Parquet 的 FILE 逻辑类型。换句话说，图片、PDF、音频从此可以带着真实的元数据和统计信息，坐在一张 Iceberg 表的列里——而不是像过去那样，被丢进对象存储的某个前缀目录，靠一张外部清单来"认领"。

不过投票里有个耐人寻味的细节：Kurtis Wright 投了 +0。他的理由是，维护作业（maintenance jobs）需要某种信号，来判断哪些文件是活的、哪些可以清理。这个担忧很实际——一旦非结构化文件成为表数据，Iceberg 的快照过期、孤儿文件清理这些老活儿，复杂度会上一个台阶。

产业逻辑很清楚：AI 训练数据的治理，过去发生在数据湖之外（各种 Dataloader、清单文件、自研元数据服务），现在正在被吸进表格式这一层。表格式正从"管理表格"升级为"管理一切字节"。

🔐 File 进了规范，然后谁说了算

金句：规范定得再漂亮，最后都要回答一个问题——这些文件归谁管。

FILE 类型投票的余波，直接传导到了另外两个社区。

Parquet 花了一整周在讨论两件事：向量（vector）到底是什么，以及格式版本（format version）到底意味着什么。这不是文字游戏。当 embeddings、dense vector 要在物理格式层有一等公民的地位，定义不清就会导致上下游实现分裂——一个列到底是固定宽度数组还是新的逻辑类型，决定了十年后的兼容性包袱。

Apache Polaris 那边吵的是另一个问题：文件一旦进了 catalog 管辖的范围，所有权归谁。这本质上是湖仓架构里"存储"与"目录"的边界之争——catalog 只管元数据和授权，还是可以下沉到管文件生命周期？据邮件列表里的讨论看，两派都有拥趸，而这恰恰决定了未来厂商在目录层的商业模式空间。

把这几家放到一张竞争地图上看会更直观：技术门槛越高的位置，护城河越深，但收敛风险也越大。

看得出来，表格式和物理格式卡在右上角——门槛高、粘性强，是这一轮 AI 数据基础设施之争真正的咽喉。

⚡ Polars 2.0：用一次默认值变更，换流式未来

金句：最强的破坏往往不来自新功能，而来自一个被改掉的默认值。

10 月 6 日发布的 Polars 2.0，做了一件很多数据管道毫无察觉、却可能因此翻车的事：LazyFrame.collect() 现在默认跑在流式引擎上。创始团队负责人 Ritchie Vink 在发布帖里用一句话概括了这个切换，称它带来了"巨大的内存与性能优势"。

但代价写得清清楚楚：对 join、group_by、unpivot 这三类操作，流式引擎不再承诺保持输入行序，除非你显式设置 maintain_order。有开发者实测验证：在 polars 2.0.0 上跑一个 200 万行的 inner join，默认配置下输出行序乱了；在 join 上设 maintain_order 后，输入顺序得以保留。

更激进的是 out-of-core（超内存处理）也默认开启了——内存用到约 80% 就开始向磁盘溢写，默认磁盘预算 64 GB。这意味着 Polars 正在从"单机快的 DataFrame 库"变成"能硬扛超内存负载的流式批处理引擎"。至于官方基准测试，发布帖脚注自己承认：结果与官方 TPC 成绩不可比。

对工程团队来说，这是一次实打实的适配成本：如果你的代码逐行比较输出，或者写出的文件被下游按位置读取，同一份数据在不同机器上可能给出不同的答案。一句话，管道里所有隐式依赖行序的代码，现在都欠着一笔技术债。

把本周三个关键变更放到一张表里对比，规律会更清楚：

三件事的共同点：都在打破旧默认，都指向 AI 数据负载。

☁️ K2：把日志搬到对象存储上，省的是真金白银

金句：流处理的下一场仗，不在消息队列，而在对象存储的账单上。

Cloudflare 这周把 K2 推入了公测。这是一个无服务器事件流服务，实现方式是在 R2 对象存储上构建持久化日志。官方宣称 produce 延迟 p99 约 1 秒；不过有测试者报告端到端 p99 达到 7.5 秒——一位替团队回应的评论者承认，这个数字高于预期。计费上，consume 与 produce 按同样的每 GB 价格收费。

1 秒和 7.5 秒的差距说明：对象存储做日志，在写路径上已经接近可用，但端到端链路仍有优化空间。对于要求毫秒级的金融交易类场景，K2 现在还够不着；但对于 AI 数据管道这种典型场景——采集埋点、日志归集、训练数据入湖——秒级延迟完全够用，而省下的运维成本是真金白银：没有 broker 集群、没有分区再均衡、没有跨可用区副本调优。

这和 Polars 的流式化、Iceberg 的文件化，是同一个产业趋势的三个切面：为 AI 数据服务的管道，正在全面向"对象存储 + 开放表格式 + 弹性计算"的湖仓底座收敛。专用系统（Kafka 式日志集群、专用向量化引擎）不会被取代，但它们的护城河正在从"性能"退守到"极端延迟场景"。

最后用一张结构图收束本周的观察——这一轮变革，显性的是规范和版本号，隐性的是生态位之争：

小结

这一周，开放湖仓用四件事完成了一次集体表态：AI 数据不再是数据湖的过客，而是要被表格式、物理格式、计算引擎、事件流逐层接住的正经公民。Iceberg v4 的 FILE 类型定了什么是"表里的文件"，Parquet 在定"什么是向量"，Polars 用行序换性能，K2 用延迟换账单。接下来一年，值得盯住的暗线只有一个：这些文件的 catalog 所有权之争——谁掌握了它的定义权，谁就掌握了 AI 时代数据基础设施的收税权。