datainfra前沿动态 · Vol.78

Apache Iceberg 1.12.0 走到 RC2，卡住它的是许可证而不是功能；Apache Parquet 三线并进：模块化 footer 评审、VECTOR 类型之争与 ALP 落地；Apache Polaris 把「拿不到凭据」和「列表超限」都改成直接报错；阿里云给出一组数字：80% 的新增数据库实例由 Agent 创建

本期聚焦四条来自 9 月 22 至 25 日的进展：Iceberg 1.12.0 连续两个候选倒在许可证缺口上、Parquet 在 footer 与向量类型上各开一条新战线、Polaris 把静默降级改成 fail-closed，以及云栖大会披露的 Agent 成为数据库主要客户的一组数字。

DataInfra Apache Iceberg Apache Parquet Apache Polaris Apache DataFusion Lakehouse 开源治理 ALP VECTOR 阿里云 ApsaraLakebase AI Agent

9 月 22 到 25 日这四天，开放湖仓发生的事情集中在一处：当服务端交不出客户端要的东西时，它该怎么回答。Iceberg 1.12.0 的发布经理在 9 月 25 日切出第三个候选 RC2，前两个候选分别倒在 Bootstrap 样式表、Lottie 脚本和 iceberg-gcp-bundle 里一个没写进 LICENSE 的 Caffeine 上——功能早已冻结，卡住发布的是许可证卫生。Parquet 那边，Modular Footer 进入广泛评审，直指宽表必须先解析整个 Thrift footer 才能读第一列的成本；VECTOR 逻辑类型的争论则落在「要不要为 NaN 开一个口子」上。Polaris 用两处改动给出明确答案：拿不到 vended credentials 就回 HTTP 400，未分页请求超过上限就报错，而不是返回半张表、半张列表。把这三条并起来看，是同一个原则在三个项目里各自落地。第四条来自杭州：云栖大会技术主论坛上，阿里云数据库负责人杨辛军给出一组数字——过去一年 RDS PostgreSQL 新增实例环比增长超 400%，其中约 80% 由 Agent 创建，输入输出流量约 50% 由 Agent 驱动。客户端从人换成程序之后，静默降级的代价被重新估了一遍。

Apache Iceberg 1.12.0 走到 RC2：功能早已冻结，倒在两处许可证缺口上

事件概述

9 月 25 日，Iceberg 的发布经理 Neelesh Salian 在 dev 邮件列表发起 [VOTE] Release Apache Iceberg 1.12.0 RC2，对应 commit 212aa894e919ff9fdf89160da4aadcbe6858ac01 与标签 apache-iceberg-1.12.0-rc2，投票跨周末开放至 9 月 29 日下午 2 点（太平洋时间）。这是 1.12.0 的第三个候选，也是第一次出现「同一个版本连切三次候选」的情况。

前两次候选的失败原因都不在代码功能上。RC0 阶段，Xuanwo 在文档站点资源里发现一个 Bootstrap 样式表：它保留了版权行，但缺少 MIT 许可声明，根 LICENSE 也没有把它计入；Gianluca Graziadei 在同一个文件夹里发现一个 Lottie JavaScript 文件有同样的缺口。这两个文件其实从 1.9.0 起就随发布提供，两位发现者都没有把它称为 blocker，但 Salian 提交了 issue、修复合并、重新切了候选。RC1 于 9 月 22 日开投，Kurtis Wright 投出 non-binding -1：iceberg-gcp-bundle-1.12.0.jar 捆绑了 Caffeine 缓存库，而 LICENSE 文件里没有对应条目。他在邮件里披露，这个发现是让 Claude 逐个核对候选包中的许可证得到的。

技术解析

  • 验证规模：这一轮的验证密度是近几年少见的。Manu Zhang 报告 api、core、parquet 三个套件 10,991 个测试通过、零失败；Xuanwo 报告 common、API、core、data 模块 10,470 个测试通过；Szehon Ho 报告 8,400 个 core 测试通过，并在由已验证源码构建的 Spark 4.2 上跑通 Spark 测试；Xin Huang 把 tarball 与 commit 之间的全部 7,083 个共同文件逐一比对，结果完全一致；Anoop Johnson 从 tag 重新构建 source tarball 并确认一致（仅两个生成的版本文件除外）。Yuya Ebihara 确认 Trino 的 CI 对暂存产物通过，覆盖 HMS、Glue、PostgreSQL JDBC，以及 Polaris、Unity、S3 Tables、Tabular 等 REST catalog，还有 Nessie 与 Snowflake。
  • 会写进 release notes 的行为变更：一个 PR 让 GeometryType 与 GeographyType 的 toString() 始终输出已解析的默认值。一个普通的 geometry 现在打印成 geometry(OGC:CRS84)，geography 打印成 geography(OGC:CRS84, spherical)。原作者 Xin Huang 说明，PR 的真实目标是把已解析的 CRS 与算法值持久化进元数据（即使它们等于默认值），toString() 的变化是他没识别出来的副作用，并准备了回退 PR。Szehon Ho 主张保留：两个相等的 geography 类型过去会「因为用户是否显式设置过默认值」而打印成不同字符串，这本身看起来像 bug，新形式也匹配规范 Appendix C 的规范序列化。Huaxin Gao 补了一条更实际的理由——函数定义 ID 是由参数类型字符串拼出来的，两个相等类型打印不同会被当成两个不同的重载。社区最终同意保留，并把它列在 release notes 的 “Behavior Change” 下。旧元数据仍能加载，因为 geometry 与 geometry(OGC:CRS84) 解析为同一类型。
  • 一个下游要提前检查的依赖变化：1.12.0 移除了读写分区统计的旧 helper 逻辑，新逻辑依赖基于 Hadoop 的 Parquet 客户端，而部分下游项目禁止引入该依赖。Yuya Ebihara 在几个月前就提过这个 caveat。
  • 已知但不阻塞的缺陷：Gianluca Graziadei 报告，读取 variant 列时若 classpath 上的 commons-lang3 老于 3.13，会抛 NoSuchMethodError——iceberg-parquet 用到了一个方法却没有声明依赖。这个缺陷在 1.11.0 上同样存在，Salian 计划在 release branch 上补修，不阻塞发布。
  • 随 1.12 一起发布与被推迟的内容：Alex Reid 请求的 Kafka Connect 修复（阻止 connector 在某些 rebalance 期间重复提交已提交的文件）已合并，随 1.12 发出；他追问的 REST client 侧 referenced-by 支持（去年加入的规范字段）被推迟到 1.13.0 里程碑，因为它不阻塞发布。

行业影响

许可证卫生正在成为 ASF 数据项目的发布瓶颈——同一周里，Iceberg 1.12.0、Polaris 1.8.0、Polaris catalog migrator、pyiceberg-core 与 Ossie 0.3.0 都遇到了 LICENSE、NOTICE 或文件头问题。这已经不是个别项目的疏漏，而是「产物里嵌了第三方前端资源与打进 bundle 的 Java 依赖」之后必然出现的检查项。另一个值得注意的变化是 AI 辅助评审正在进入发布流程且被公开披露：Kurtis Wright 用 Claude 核许可证，Ajantha Bhat 用 Codex，Xin Huang 用 GPT 5.6 辅助验证，三人都在邮件里写明了工具来源。

对使用者来说，这一轮的取舍很清楚：1.12.0 的功能集合已经稳定，真正影响升级决策的反而是两件夹带物——分区统计新逻辑拉进来的 Hadoop Parquet 客户端依赖，以及 commons-lang3 的版本下限。前者是硬约束，后者是 classpath 上的定时炸弹。geospatial 的 toString() 变更属于「看起来是字符串问题、实际是函数签名问题」，用到 UDF 的团队值得在升级前先跑一遍函数定义 ID。

相关链接

事件概述

Parquet 社区在同一周里推进三条彼此独立但互相牵连的战线。9 月 22 日，官方博客发布《ALP: Adaptive Lossless Floating-Point Encoding in Apache Parquet》，把这个随 2.14.0 格式（9 月 11 日发布）进入规范的新编码正式讲了一遍。同期，Jiayi Wang 在数月的双周工作组会议后把 Modular Footer 提案提交广泛评审，附带 parquet-format PR 与追踪 issue。Rok Mihevc 则在一个专题社区会议之后提交了基于 LIST 的 VECTOR 逻辑类型 PR，引发一场关于「Parquet 该不该为 embeddings 定义专用类型」的争论。

技术解析

  • ALP 已经落地：ALP 全称 Adaptive Lossless floating-Point，来自 CWI 研究者在 SIGMOD 2024 发表的论文。官方博客的描述是：压缩比接近 zstd，解压快得多，支持随机访问，对 GPU 与 SIMD 友好。浮点列在 AI 负载里无处不在——传感器读数、价格、模型打分、embedding——更好的浮点压缩意味着更小的文件和更快的扫描。这条线与 2.14.0 里同批进入的 FILE 逻辑类型一起，构成 Parquet 面向多模态与 AI 负载的格式侧准备。
  • Modular Footer 解决的是宽表成本：提案覆盖动机、格式设计、兼容性与基准测试。核心问题被原文讲得很直白——今天一个 reader 在读取任何一列之前，必须先解析完整的 Thrift footer，而这个成本随列数增长；模块化 footer 让读者只加载自己需要的部分。Micah Kornfield 此前要求 Wang 把讨论搬到邮件列表以提高可见性，并了结旧的 footer 追踪 issue。
  • 未知版本怎么办：footer 工作牵出一个更根本的问题——reader 遇到不支持的格式版本时该怎么做。Xiening Dai、Fokko Driesprong 与 Steve Loughran 都选了「遇到未知版本直接失败」。Driesprong 的理由是：footer 这类破坏性变更本来就会让旧 reader 失效，而规范是这个项目唯一真正控制得住的东西，静默的部分读取会侵蚀信任；他建议把 path-in-schema 这类较小的加速捆绑进新的 footer 版本，而不是在规范上偷工减料。Loughran 补上了反方向的重量：正因为 reader 必须对未知版本 fail fast，升到新版本就需要非常充分的理由；目前让 FlatBuffers 与 Thrift 并存的工作，目标是在保持兼容的前提下拿到速度，而他勾勒的未来「2.0」库会读写两种布局、默认仍写出 classic 文件。
  • VECTOR 类型的规则与分歧：Mihevc 的提案规定，每个非空 vector 恰好有 num_elements 个值，元素必须非空、有限、为数值或布尔原生类型、不可嵌套；不认识 VECTOR 的 reader 把它当成普通 LIST 来读；物理布局变更、向量索引与量化均不在范围内。Antoine Pitrou 反对这套窄规则：Parquet 是通用格式，NumPy 的张量数据里就有 NaN，为什么要禁掉？他主张定义一个通用的 fixed-size list 类型，把专用类型留给领域软件，就像 Arrow 把 schema 存在 Parquet metadata 里那样。Mihevc 为范围辩护：向量库本身就拒绝非有限值与嵌套值，统计信息也常常不写或不读；他进而抛出关键问题——「Parquet 定义一个逻辑类型的门槛是什么」，并问如果去掉有限性规则提案是否就能被接受。

行业影响

VECTOR 这条争论决定的是 embedding 未来若干年以什么形态落进 Parquet 文件。窄定义的代价是张量数据、含 NaN 的科学数据要另寻出口；宽定义的代价是 Parquet 要为一批它并不理解的语义背书。对把向量和业务数据存在同一套湖仓里的团队，这场讨论的结果会直接影响 schema 写法与跨引擎互通。

Modular Footer 的意义则更工程化：宽表现在是湖仓的常态，列数上千的表让 footer 解析从「可忽略的固定开销」变成「随 schema 宽度线性增长的前置成本」。而社区在未知版本上一致选择「失败」这一点，把格式演进的成本明码标价——每升一次版本，等于要求所有 reader 升级，这反过来解释了为什么 Loughran 会坚持「升版本需要很好的理由」。ALP、FILE、VECTOR、Modular Footer 四件事放在一起看，Parquet 正在从「一个稳定的列存格式」变成「一个仍在高速加功能的规范」。

相关链接

Polaris 把两处静默降级改成 fail-closed，Iceberg-DataFusion 集成换到 DataFusion 仓库

事件概述

Apache Polaris 在本周做了两个方向一致的改动。第一处关于 vended credentials：当客户端发送 X-Iceberg-Access-Delegation 而 catalog 无法满足时（例如对没有 STS 的 S3 兼容存储请求 vended credentials，或在未实现 remote signing 的服务器上请求 remote signing），Polaris 直接返回 HTTP 400。Iceberg REST 规范的措辞读起来像是服务器也可以改返回一个不带 delegation 的表。第二处关于列表上限：当配置了 max page size 时，分页请求受上限约束，未分页请求在上限之内返回完整列表，未分页请求超过上限则以错误失败，不再返回带 continuation token 的部分列表。

同期，Iceberg 与 DataFusion 的集成从 apache/iceberg-rust 迁出，落进由 DataFusion 项目拥有的新仓库 apache/datafusion-iceberg（GitHub 上创建于 9 月 9 日）。两个投票线程都全票通过，DataFusion 侧的接纳投票拿到 14 个 +1。

技术解析

  • credentials 那条线的论证过程：Youngrae Kim 提出规范对齐问题后，Ayush Saxena 纠正了一个前提——规范里其实有一个信号，200 响应中的 storage-credentials 字段为空，客户端必须检查；他的反对意见被原文压缩成一句话：“must check” is not “does check”。Dmitri Bourlatchkov 给出架构层面的看法：客户端用本地凭据还是 vended 凭据是部署决策，不是运行时选择，已经持有凭据的客户端没有理由再去请求 delegation。Alex Dutra 补充说，「必须先检查」的措辞是为了向后兼容，这也正是 Polaris 在两个位置都 vends credentials 的原因；Iceberg 1.12 新增的 remote-signing-config 字段同样遵循双位置模式。讨论的结论是 fail-fast 加写文档，Kim 随后把问题带到上游 Iceberg，询问规范中的 “any or none” 是否允许服务器直接拒绝请求。
  • 列表上限那条线的转折：Yufei Gu 发现一个规范层面的问题——设置 max page size 后，服务器会对从未请求分页的客户端返回部分列表加 continuation token，这违反 REST 规范。Ayush Saxena 解释原意是大型目录面临内存压力与 DoS 风险，而一个豁免未分页请求的 cap 等于没有限制。Gu 要求证据并给出了量级估算：一个含 100,000 张表、表名各 100 字符的 namespace 产生约 13 MiB 未压缩 JSON，他认为这算不上明显危机。Prithvi S 指出了真正的危险：对一个从未请求分页的请求返回带 continuation token 的 200 响应，本质是一个「静默不完整的列表」，而 PyIceberg 0.10 与 0.11 只发一次无参数 list 调用就直接返回。Bourlatchkov 提出的修复被所有人接受：配置上限后，分页请求受 cap 约束，未分页请求在 cap 内拿到完整列表，未分页且超出 cap 的请求报错。Vignesh A 补了两点工程细节：以 max+1 探测，避免服务器在抛错前把全部内容载入内存；错误信息要写清楚。Ayush Saxena 开 PR，Yufei Gu 在 9 月 21 日签署同意。
  • 一个配套开关：Yufei Gu 另提议把 LIST_PAGINATION_ENABLED 默认值从 false 翻到 true——当前默认为 false，客户端不经服务器设置无法使用分页。Jean-Baptiste Onofré 指出 max page size 默认为 unlimited，翻转该 flag 不会破坏省略分页参数的老客户端。该 flag 会作为逃生口保留几个版本。
  • 集成换仓库的分工：Andrew Lamb 报告两个投票线程全票通过。dev 列表上的评价是：Iceberg Rust 专注表格式库，DataFusion 拥有查询引擎的粘合层，它的维护者最清楚 planner 与 execution 的内部结构。新仓库第一周的工作包括：Gabriel（gabotechs）合并把 iceberg-rust 历史移植过来的 PR，随后让项目在 Kevin Liu review 后编译并通过测试；Andrew Lamb 修掉一个命名错误的 .asf.yaml（此前导致 GitHub issues 被禁用）；一位贡献者重新提交了把 IcebergTableProvider::try_new 设为 public 的 PR——唯一支持写入的 provider 需要 public 构造函数，而原始 PR 在迁移过程中丢失了。

行业影响

「失败要响亮，并把行为写进文档」是本周贯穿 Polaris、Iceberg 与 Parquet 三个项目的同一条原则。它最大的受益者其实是 Agent：一个静默拿到「没有凭据的表」的 Agent 会重试、猜测，或者退回到更宽的权限；一个只拿到半张表列表的 Agent 会带着完整自信给出错误答案。这两类失败在人工排查时都要花很久才能定位，而一个明确的 400 或一条明确的错误信息把定位成本压到一次调用。

集成换仓库则是一次职责边界重划：格式库不该为引擎胶水层背负 review 负担，PR 停滞的真正原因是「懂 DataFusion 的人不在 Iceberg 仓库的 reviewer 名单里」。对下游（例如等待 iceberg-rust 才能升级 DataFusion 的 Comet）来说，这条路径变短了，代价是用户需要换 crate 名、把 iceberg-rust 版本与集成版本对齐，并把 issue 提到新仓库。

相关链接

阿里云：80% 的新增数据库实例由 Agent 创建，ApsaraLakebase 用共享存储与零拷贝分支接住 Agent 规模

事件概述

9 月 22 日，2026 云栖大会技术主论坛上，阿里云智能集团研发副总裁、数据库产品事业部负责人杨辛军发表《让 Agent 更具生产力，智能体时代的数据底座全面升级》主题演讲，发布 Agent Context 与 ApsaraLakebase 两款产品，并给出一组数字：过去一年阿里云 RDS PostgreSQL 的新增实例数量环比增长超过 400%，其中约 80% 的新增实例由 Agent 创建，输入输出流量中约 50% 由 Agent 交互和驱动。

ApsaraLakebase 被定义为面向 Agent 规模化运行的新一代多模态数据底座。它要解决的矛盾被讲得很具体：一个企业级应用背后往往有几十上百个 Agent 并发运行，若每个 Agent 独占一个数据库实例，成本会成倍蹿升；而 Agent 的使用方式与人完全不同——一次任务里拉起成百上千个实例、用不同路径试错、刚写入一条数据就要求毫秒级反馈。

技术解析

  • 成本不随 Agent 数量线性膨胀的做法：每个 Agent 拥有独立视图与隔离环境，底层共享存储。配合沙箱热池、Serverless 弹性与 Scale to Zero，Agent 需要时快速唤醒、空闲时释放计算资源。
  • Copy-on-Write 数据分支：Agent 可以基于同一份底数派生独立分支，进行探索、试错、回滚与销毁，不污染生产数据。这把「每个 Agent 一份副本」换成「一份数据加一层分支元数据」。
  • 开放格式与单一事实源：基于云原生共享底座构建，以对象存储为单一事实源，数据只存一份；支持 Lance、Apache Iceberg、Apache Paimon 等开放数据格式，叠加缓存、引擎、语义与接口能力，让结构化数据、非结构化文件、向量索引、图关系和上下文记忆在同一套体系内流转。
  • PolarDB 承载元数据后解锁的能力：毫秒级快照初始化（免拷贝数据）、对话粒度 Branching（让中断任务断点续跑）、多级缓存优化小 IO 读写、子目录与租户级 Quota 保障多租户隔离、运行时动态挂载切换预热 ECI 支撑高并发算力池复用，以及用 TTL 治理承接 Agent 的脉冲式负载。会话记忆统一入库，向量与全文混合检索让上下文跨任务复用。
  • 一个规模案例：头部基模厂商昆仑万维的 Agent 平台深度应用 ApsaraLakebase，为每个 Agent 分配独立云端沙箱，支撑海内外 300 万+ Agent 的独立工作空间、10 万级并发连接峰值，深度睡眠后沙箱拉起挂载的 P99 达到秒级。
  • Agent Context 侧的数字：官方表述是，围绕研发协同、运维支持、技术服务、数据分析等知识密集型场景，Agent Context 对复杂知识任务的准确率可提升高达 50 个百分点，并能在单个工作空间内调度上万个智能体；在小红书的落地中，它以统一上下文底座支撑 DBA、开发、算法等 3000+ 员工的子 Agent 协同作业，官方称 Token 使用效率可提升 3 倍。

行业影响

这组数字真正的分量在于它推翻了一个隐含前提：数据库的主要用户正在从「人」换成「程序」。人的操作谨慎而低频——建实例、改数据、跑分析，每一步都确认权限与影响范围；Agent 的行为是批量、短生命周期、脉冲式的。按「给人看报表」的思路设计的数仓分层、字段口径与权限模型，在这个前提下会整体落后一代。

具体到工程上，变化落在两处。一是实例生命周期从「月」压缩到「秒」， provisioning、快照与销毁必须廉价到可以被反复调用，这正是「毫秒级快照初始化免拷贝数据」与「Scale to Zero」成为卖点的原因。二是隔离粒度从「数据库实例」下移到「数据分支」，成本模型从「实例数」变成「分支数」——这也是 ApsaraLakebase 与 Databricks Lakebase、AnalyticDB 数据分支在走同一条路的原因。这条路与 Polaris 本周的 fail-closed 是同一件事的两面：当客户端是每秒拉起成百上千个实例的 Agent 时，静默降级不再是「体验差一点」，而是会被以 Agent 的速度放大成规模化错误。

需要提醒的是，上述增长率、占比与提升幅度均来自厂商在自家大会上的口径，属于单方数据；「准确率提升 50 个百分点」与「Token 效率提升 3 倍」未附带评测方法与基线说明，引用时建议保留出处与限定条件。产品层面的可用性（公测范围、是否需要工单或邀请）也尚未在公开发布材料里给出。

相关链接

编者评

本期四条看起来分散在三个 ASF 项目和一场国内大会，收紧的是同一条线：系统与客户端之间的契约正在从「尽量给出点东西」改成「给不了就明确报错」。Polaris 的 400 与列表超限报错是最直白的两例；Parquet 在未知格式版本上选择 fail on unknown、在 footer 上宁可让所有 reader 升级，是同一原则在文件格式层面的投影；Iceberg 1.12.0 连切三个候选，表面是许可证问题，实质也是一次「规范说什么就必须做到什么」的自我校准——规范是这个项目唯一真正控制得住的东西，这句话在本周被 Driesprong 说给 Parquet，也同样适用于 Iceberg。

而这条线之所以在这个时间点收紧，答案藏在第四条里：当 80% 的新增实例由 Agent 创建、50% 的流量由 Agent 驱动时，客户端的行为模式变了。人会察觉异常并停下来问，Agent 会把半张列表当成完整列表，把一个没有凭据的表当成权限不足去绕。契约越松，Agent 出错的速度越快、规模越大、「看起来越自信」。这解释了为什么「失败要响亮」会在同一个星期里被三个项目各自独立地选上。

两个值得继续盯的点是：Iceberg 1.12.0 的 RC2 投票在 9 月 29 日截止，Caffeine 许可证缺口是否还留有第三个隐患，决定了这个版本能否在九月内落地；VECTOR 类型的 NaN 之争还没收敛，它决定的是 embedding 以什么形态进 Parquet，进而决定湖仓里「向量列」未来几年的互操作方式。本期未展开的线索：Databricks 于 9 月 25 日宣布收购电子表格产品 Row Zero，方向是把受治理的电子表格界面接到 Genie 与 Unity Catalog 上，官方发布页尚未取得可核验链接；AWS Glue Data Quality 的 Advanced 模式规则推荐（9 月 22 日，15 个区域）仍在观察期；LanceDB 停留在 v0.40.0-beta.11 预发布，DuckDB、Delta Lake、Daft、Ray、Arrow、Trino、Flink、Spark 在本窗口均无正式新版，AWS Big Data Blog 最新一篇仍停在 9 月 24 日。