datainfra前沿动态 · Vol.83

Iceberg 社区一次性通过两项治理新规范：read restrictions 与 catalog labels；AWS 把 Iceberg V3 从「能存」推到「能运维」；EMR Serverless 的 shuffle 上限从 200GB 抬到 1TB；Lakebase 把恢复从数据搬运改成元数据指针

本期聚焦 9 月 30 日至 10 月 1 日的四件事：Apache Iceberg 社区通过 read restrictions 与 catalog labels 两项 REST Catalog 新规范，把治理从「系统内部」推到「系统之间」；AWS 在两天内让 Glue Data Catalog、S3 Tables 与物化视图一起补齐 Iceberg V3；EMR Serverless 的单作业 shuffle 上限提高五倍并引入溢写；Databricks 的 Lakebase Postgres 用分支把 100TB 数据库的恢复压到秒级。

DataInfra Apache Iceberg Iceberg REST Catalog 数据治理 Unity Catalog AWS Glue S3 Tables Iceberg V3 Amazon EMR Apache Spark Lakebase Postgres Lakehouse

9 月 30 日到 10 月 1 日这两天，数据基建的动静集中在同一个方向上：把「规模变大以后会出什么事」从一条靠经验传递的隐性知识，改成一个可以查表、可以引用、可以写进设计文档的参数。Apache Iceberg 社区一次性通过两项 REST Catalog 新规范，让治理决策第一次有了跨引擎、跨目录的标准交接方式，代价是策略必须先降级到规范定义的词汇表。AWS 在两天内连发四条公告，把 Iceberg V3 从「能写进去」补到「能自动维护、能算统计、能爬到」，并把系统托管物化视图的写入权收归 Glue 自己。EMR Serverless 把单作业 shuffle 上限从 200 GB 抬到 1 TB，顺带给出溢写能力——这条数字此前只存在于失败作业的报错里。Databricks 的 Lakebase Postgres 把恢复从「部署实例 + 拉快照 + 回放 WAL」三步换成在某个 LSN 上开一个分支，100 TB 和 10 GB 花的时间一样。四件事分处规范层、目录层、计算层与 OLTP 层，动作却一致：把天花板写成数字，或者把天花板拆掉。

Iceberg 两项新规范：read restrictions 与 catalog labels，把治理推到系统之间

事件概述

10 月 1 日，Databricks 由 Daniel Weeks、Ryan Blue 与 Andrei Tserakhau 联合撰文，介绍 Apache Iceberg 社区刚刚通过的两项 Iceberg REST Catalog 规范扩展：read restrictions（读取限制）与 catalog labels（目录标签）。两者解决的是两个不同方向的交接问题：前者把策略的执行权委托给可信引擎，后者让治理上下文在目录之间可移植。

文章把跨引擎治理拆成三种模型，并明确给出各自的适用条件。集中式执行（centralized enforcement）由源目录在自己的可信边界内完成过滤，未授权数据根本不会到达引擎，Unity Catalog 的 Cross-Engine ABAC 就是这种做法——把过滤集群挡在 Iceberg REST Catalog 的 scan/plan API 后面。委托式执行（delegated enforcement）由目录评估策略、把结果交给引擎执行，read restrictions 就是为此提供的标准契约。目录到目录的联邦则由 catalog labels 负责。

技术解析

  • read restrictions 交付的是结果，不是策略：引擎拿不到管理员写下的那条规则，只拿到「针对这个主体，在这张表上该施加什么」的指令。规范定义的是一套有界词汇：九个预定义的列投影动作，加上比较、集合成员判断这类标准化的行过滤表达式。子查询、查找表、自定义 UDF 撑起来的企业策略无法在这个词汇表里表达，此时策略语义会丢失。
  • 可信引擎的判定权不在协议里：规范只定义可信引擎必须执行什么，不定义目录如何建立信任。客户端自称可信不够，社区讨论过 mTLS 与 OAuth，但信任最终仍留在协议之外，由管理员按环境选择机制。
  • 谁能当可信引擎有明确边界：Spark 与 DuckDB 在用户掌控运行时时属于不可信——用户可以执行任意代码或直接读底层文件。配置妥当的 Trino 属于可信，因为它原生支持行过滤与列掩码。Apache Spark 自己的安全说明也写明用户提交的代码不受限制，Spark 扩展只有在管理员控制运行时、堵死每一条绕过路径时才算可信。
  • catalog labels 是不透明的键值对：生产目录在联邦读取时随表与列一起返回标签，消费目录再映射成自己的分类、属性或原生标签模型，之后用自己的身份与策略做判定。一个 ssn 列被标成 pii=ssn，消费目录就能用标签策略给它套上掩码。
  • 标签传递的是元数据，不是语义：标准没有定义共享语义，也没有稳定标识符，标签的血缘不会延伸到源目录之外。消费目录拿到的只是解析后的键与值，无从判断这个标签本意是给发现、给访问控制、给成本归因还是别的用途。企业仍需要共享约定或显式映射。
  • 联邦场景下不能每次都打电话：权限感知的发现如果在目录 A 里每查一个用户、一个资产就调一次目录 B，目录浏览器加载与 typeahead 搜索会变成每个用户上千次判定，缓存无从下手，性能与可用性也被绑到另一个服务上。标签的设计目标正是把这类上下文缓存下来、按需刷新。
  • 三种模型各有一笔账：集中式执行要付出过滤集群的延迟与运维依赖，且表响应变成用户专属之后无法跨用户复用缓存；read restrictions 的表达力受词汇表限制，审计记录被拆在源端与目的端两套系统里；catalog labels 则由目的端保留完整的原生策略表达力与端到端审计。

行业影响

这两项规范的通过，标志着开放湖仓的治理重心从「一个目录内部怎么管」转到「目录与引擎、目录与目录之间怎么交接」。Iceberg 此前解决的是数据的可移植性，现在开始解决治理上下文的可移植性——这是开放表格式能真正支撑多引擎、多目录企业架构的前提。

值得留意的是它划出的那条边界：委托式执行成立的先决条件是策略能被降级成标准词汇。换句话说，规范给出的不是「所有策略都能跨引擎」，而是「能表达的那部分策略才能跨引擎」。企业在规划跨引擎治理时，需要先审计自己的策略里有多少依赖子查询与 UDF，那部分不会随规范自动迁移。信任机制的缺位同样是留给实施者的作业——规范管契约，不管身份认证怎么做。

相关链接

AWS 两天四条公告：Iceberg V3 从「能存」补到「能运维」

事件概述

AWS 在 9 月 30 日至 10 月 1 日的约三十小时内，围绕 Iceberg V3 与 S3 Tables 连发四条公告。10 月 1 日的两条分别是 Glue Data Catalog 开始支持 V3 表的表优化、统计信息与爬虫，以及 S3 Tables 每个区域每个账户的 table bucket 上限从 10 个提到 100 个。9 月 30 日的两条是 S3 Tables 补齐 V3 全部数据类型，以及 Iceberg 物化视图增加系统托管写保护。

这组动作的意义不在单条功能，而在它填的是哪一段空白。V3 的类型与格式能力此前已经有引擎侧支持，托管服务侧缺的是配套的运维能力——没有自动压缩、没有统计信息、爬不到表，V3 表在生产里就只是「能写进去」。

技术解析

  • Glue Data Catalog 的表优化覆盖 V3 类型：支持用 binpack、sort 与 z-order 三种策略做压缩，并清理过期快照与孤儿文件以压低存储成本。这三种策略明确支持 V3 数据类型，包含 variant、地理空间类型与纳秒精度时间戳。
  • NDV 统计进目录：可以为 V3 表生成 number of distinct values（NDV）统计，供分析引擎做查询计划。这是把 V3 表接进成本优化器的那一步——没有它，引擎只能按猜测估算基数。
  • 爬虫能发现 S3 上的 V3 表：Glue crawler 可以扫描 Amazon S3 中的 V3 表并注册进 Glue Data Catalog，使其对任何兼容 V3 的引擎可见。
  • S3 Tables 补齐 V3 类型：新增 geometry、geography、unknown 与纳秒时间戳，以及列默认值。至此 V3 引入的类型全部受支持，此前已有的还包括 variant、deletion vectors 与 row lineage。
  • 原生类型替代字符串编码：geometry 与 geography 列直接存点、线、多边形，车队跟踪与资产映射类负载可以在查询时按位置过滤；纳秒时间戳让遥测与金融负载保留源端精度。列默认值给新增列填充既有行，不需要回填。
  • 系统托管物化视图只让 Glue 写：预计算结果本身是数据湖里一张开放的 Iceberg 表，任何有写权限的人都能通过目录或直接写 S3 文件改动它。系统托管模式把这个缺口堵上——只有 Glue 能写该视图的数据与定义，结果保持与计算时完全一致。用户写定义 SQL 与可选的刷新计划，Glue 把结果存成 S3 Tables 桶里的标准 Iceberg 表，任何兼容引擎都能直接读。
  • table bucket 配额提高十倍：从每区域每账户 10 个提到 100 个，叠加后单区域单账户最多可建 100 万张表。这让「每个数据集、每个负载或每个团队一个桶」成为可行划分，桶级加密、访问策略与复制也能各自独立配置。配额默认对所有账户生效，不额外收费。

行业影响

Iceberg V3 的落地节奏在这里出现了一个清晰的分工：社区负责把格式能力写进规范，云厂商负责把「这张表怎么长期养着」变成托管服务兑现的承诺。压缩策略、过期快照清理、NDV 统计、爬虫注册，这四件事此前是每张 Iceberg 表都得自建的一套运维作业，现在成了目录的一个开关。

系统托管物化视图那条更值得琢磨。它承认了一个开放格式自带的矛盾：正因为结果是开放表，谁都能改，所以「预计算一次、多引擎复用」的可信度不成立。AWS 的解法不是加一层权限校验，而是把写入权收归服务本身——开放读、封闭写。这与 S3 Tables 的整体思路一致：格式开放，维护托管。

相关链接

EMR Serverless 的 shuffle 上限从 200GB 抬到 1TB：把隐形天花板写成数字

事件概述

10 月 1 日，AWS 宣布 Amazon EMR Serverless 的无服务器存储能力增强，单作业 shuffle 支持上限提高到 1 TB，此前是 200 GB。这个改动随 emr-7.14 与 emr-spark-8.1 及更高版本提供，覆盖 EMR Serverless 可用的 18 个 AWS 区域，官方文档给出各区域的具体限额。公告一并提到新增了溢写（spill）支持，内存密集型操作可以把数据卸载到磁盘。

shuffle 是 Spark 作业里最难绕开的一段：join、聚合、排序都要在分区之间搬运数据。托管与无服务器形态下，用户不再拥有 executor 本地盘，shuffle 数据往哪里放、能放多少，就变成一个由平台决定的参数。

技术解析

  • 上限提高五倍：从每作业 200 GB 提到 1 TB。官方给出的典型受益负载是跨多 TB 数据集的大表 join，以及需要对高基数数据做深度聚合、shuffle 量很大的作业。
  • 溢写补齐可靠性短板：新增的 spill 支持让作业在内存不足时把数据落到磁盘，而不是直接失败。这一条对 shuffle 量大的作业尤其关键——内存打满原本是这类作业最常见的终局。
  • 版本与区域约束明确：需要 emr-7.14、emr-spark-8.1 或更高版本，且只在 EMR Serverless 可用的 18 个区域内生效。各区域适用限额不同，需要查文档确认。
  • 迁移语境：公告把这条能力直接对标「把生产级负载迁到 Serverless」这个场景——此前团队要先把 shuffle 量压到 200 GB 以下，或者放弃 Serverless 改回自管集群。

行业影响

这类公告的价值在于它量化了一个过去只以失败形式存在的约束。shuffle 上限此前不在容量规划清单上，只在作业跑到一半报存储错误时才被看见，之后团队的应对往往是调分区数、加盐、换集群形态——一堆与业务逻辑无关的妥协。现在它成了迁移评估表里可以逐行核对的一项：这个作业的 shuffle 量是多少，目标区域的上限是多少。

放大看，这也是无服务器数据计算走向生产级的一条必经路径。Serverless 卖的是不用管集群，代价是平台必须把自己替用户做的每一个决定都显性化——内存给多少、shuffle 放哪里、上限是多少。200 GB 到 1 TB 这一步走完之后，剩下的问题就是这套数字能不能像自管集群那样被监控和告警。

相关链接

Lakebase Postgres 的分支式恢复：100TB 数据库在秒级回到过去

事件概述

10 月 1 日，Databricks 由 Cassie Murray 与 Carlota Soto 撰文，介绍 Lakebase Postgres 的 branch-based restores（基于分支的恢复）。这套机制把恢复从「部署实例 + 拉快照 + 回放 WAL」的多小时流程，换成在历史时间线上开一个分支的元数据操作。文章给出的口径是：恢复一个 100 TB 的数据库只需数秒，且与数据库大小无关。

传统 Postgres 的 PITR 由两部分构成：基础备份与之后的归档 WAL。托管环境里（例如 Amazon RDS）基础备份通常是对象存储里的一个快照，「恢复到时刻 T」实际要做三件事——先部署一台同等规格的新实例，再把快照从 S3 拉到 Postgres 的磁盘上，最后从快照时刻回放 WAL 到 T。

技术解析

  • 「available」不等于可用：RDS 不会等快照完全落地才把实例标记为 available。大卷恢复时，多数表页与索引页仍在 S3 上，查询碰到尚未本地化的块会当场从 S3 拉取，其余部分在后台继续水化。这种延迟对内部检查尚可，对生产不行。真正「恢复完成」的判据是工作集已经落在本机卷上，大库这一步以小时计。
  • 存算分离拆掉搬运：Lakebase 里计算负责跑 SQL、做 MVCC、管锁、生成 WAL，不持有数据的持久化副本。持久化与历史由三个组件分工——Safekeepers 接收 WAL 并在仲裁确认后认定事务已持久化；pageserver 把 WAL 物化成 Postgres 读取的页面，能按 key 在任意 LSN 重建页面；对象存储保存不可变的长期历史，计算不直接读它。
  • 历史是一条可寻址的时间线：提交事务与物化页面被拆开之后，旧页面版本不会被覆盖。历史不再是一份被反复改写的副本，而是堆积起来、可以指过去的时间线。
  • 恢复即开分支：控制面把选定的时间戳映射到存储历史中的确切位置（对应 LSN），建分支并挂上计算。新分支有独立的计算与独立的连接串，可以完全脱离生产查询。它不是原实例的一个副本，但用起来没有区别。
  • 可以先验证再提交：选时间戳这一步可以在真正恢复之前先跑查询检查，确认无误再让控制面建分支。
  • 恢复时间不随数据量增长：传统路径下恢复是一项数据搬运作业，复制与回放没走完，数据库就不「在那里」。Lakebase 里数据库已经在那里，恢复只是把某个历史点暴露成一个分支。10 GB 与 100 TB 的恢复流程一致。
  • 引用的一组调查数字：Neon 对 50 位运行 1 TB 以上生产 Postgres 的开发者做的调查显示，59% 在过去 12 个月经历过严重生产故障，30% 停机超过 3 小时（部分超过半天），只有 21% 在 60 分钟内恢复；40% 报告业务显著中断，52% 收到客户负面反馈，72% 对「下次能否快速恢复」只有「有点信心」。
  • 短到可以让 Agent 调用：恢复简化成「在时间戳上建分支」之后，这个循环短到能被当作一次普通工具调用。Replit、v0 这类平台的产品化路径是：Agent 改应用连带改数据库，平台把检查点存为 main 的快照并把 ID 与代码版本放在一起，用户点撤销时按检查点恢复到活分支，schema 与数据瞬间回到与旧代码匹配的版本。传统 PITR 太慢太重，撑不起在线工作流。

行业影响

这条公告的真正命题不是「恢复变快了」，而是「恢复不再是只能由人谨慎执行的一次性动作」。当恢复的成本从小时级降到秒级、且与数据规模无关，它就从灾备预案里的一节，变成可以被写进产品逻辑的一个原语——撤销、版本对比、Agent 试错，这些都建立在同一个分支操作上。

架构侧的取舍也很清楚：代价是把持久化与历史整体搬到计算之外，引入 Safekeepers 与 pageserver 两层新组件，以及一整套新的故障域。换来的是「规模不再让运维变可怕」。文章自己点出了这个交换——传统托管 OLTP 里，越是 downtime 成本最高的大型生产库，等待恢复的时间越长；分支式恢复把这个相关性直接切断。

相关链接

编者评

这四件事分处规范层、目录层、计算层与 OLTP 层，指向的却是同一个转移：规模相关的隐性知识正在被逐个翻译成可查、可引用、可写进设计文档的显式参数。Iceberg 的两项新规范把「治理能不能跨系统」变成一个可判定的条件——策略能否降级到规范词汇表、引擎是否在可信清单里。AWS 的 Iceberg V3 系列把「这张表怎么长期养着」从团队自建作业变成目录服务上的一组开关。EMR Serverless 把 shuffle 上限从一个只在报错里出现的数，变成迁移评估表上的一行。Lakebase 把恢复耗时从随数据量增长的函数，变成一个与数据量无关的常数。

翻译的代价在每一条里都写得很明白。read restrictions 接受策略表达力降级，且审计记录被拆到两套系统；catalog labels 只搬元数据不搬语义，稳定标识符与标签血缘都留给未来；Glue 的托管优化意味着表维护策略由服务定义，团队自定义的压缩逻辑要让位；EMR 的 1 TB 是每作业上限，跨作业的 shuffle 总量与区域级配额仍需逐区核对；分支式恢复要求接受存算分离后新增的两层组件与新的故障域。这些不是缺陷，是选择——平台替你做决定的那一刻，也替你划定了决定的边界。

本期还有两条同等量级但未单独成篇的动静，值得记在这里。一是 AWS 于 10 月 1 日发布的 Amazon MSK 新一代消费者重平衡协议实践指南，把 KIP-848（自 Apache Kafka 4.0 引入）的启用路径讲透：服务端新增 group.consumer.heartbeat.interval.ms、group.consumer.session.timeout.ms 与 group.consumer.assignors 三个参数，客户端侧的 heartbeat.interval.ms、session.timeout.ms、partition.assignment.strategy 不再受支持，MSK Express 上这些服务端配置只读；文档还给出「静态成员未优雅退出要等满 45 秒会话超时」这一容器化环境里最常见的慢重平衡成因，以及用 SIGTERM 处理触发 LeaveGroup 的写法。二是 Amazon Redshift 同日支持跨区域查询数据湖，配合增强型 VPC 路由让 S3 与 Redshift 之间的查询流量留在自有 VPC 内，跨区域查询无需先复制数据。

另外需要说明的是，本轮扫描中中文来源没有出现可报道的新内容：阿里云社区最新条目仍停留在 9 月 25 日的云栖大会报道，火山引擎开发者社区首页已全面转向 Agent 开发方向，腾讯云未见数据基建侧的新发布。