datainfra前沿动态 · Vol.63

Iceberg 目录标签让治理上下文跨目录流转；Lakebase Postgres 把缓存收回数据库内；Spark 自动改写接住 Iceberg 物化视图；Redshift 接入 ChatGPT Work

本期聚焦治理、缓存、查询优化与访问入口四层上的同一件事：把原先靠人肉或靠内核中转的判断，下沉成可声明、可验证、可版本化的接口。

DataInfra Apache Iceberg Lakebase PostgreSQL Spark 物化视图 Amazon Redshift AI Agent 数据治理

9 月 10 日这一天，四家厂商在四个不同层次上做了同一类动作。Iceberg 社区把「治理上下文」做成了可跨目录搬运的标签字段；Databricks 把 Lakebase Postgres 的缓存从内核手里收回到数据库自己手里，顺带用大页解决了地址翻译的开销；AWS 让 Spark 优化器自动接住 Iceberg 物化视图，慢查询不必再改一行 SQL；Redshift 则以插件形式进了 ChatGPT Work，把自然语言到 SQL 的翻译交给可版本化的 skills。四处改动的共同点不是加了一层，而是省掉了一次转译——跨目录不必翻译策略语义，缓存不必在数据库与内核之间对译意图，查询不必被人工重写成预计算，业务问题不必被翻译成 SQL。四处也各自留下了没被省掉的那一层：标签搬得动元数据却搬不动含义，大页方案目前只覆盖固定规格的大计算，自动改写给每个查询都加了优化开销，插件的正确性则压在 skills 的质量上。

Iceberg 目录标签：把治理上下文做成可搬运的字段

事件概述

Databricks 在 9 月 10 日发布《Unifying governance across engines and catalogs in the Open Lakehouse》，作者是 Daniel Weeks、Ryan Blue 和 Andrei Tserakhau。文章梳理了 Apache Iceberg 社区近期在 REST Catalog 上推进的两项新增：read restrictions 与 catalog labels。

前者解决「把执行委托给可信引擎」，此前已随 Snowflake 的工程博客出现过。这次的增量是把两项能力放进同一个模型里，形成三条清晰的路径：不可信引擎走集中执行，可信引擎走 read restrictions，目录与目录之间走 catalog labels。

本期重点在后一项——catalog labels 已被 Iceberg 社区采纳，是 governance context 第一次有了标准载体。

技术解析

  • 字段形态：LoadTableResponse 增加一个可选的 labels 字段，分表级与列级。列级标签按 field ID 引用列，schema 演进之后标签依然对得上原来的列。标签由目录在每次 loadTable 请求时根据自身内部系统生成，不写进表的元数据文件，引擎可以用也可以完全忽略。
  • 工作流程：消费方目录通过联邦加载生产方目录的表时，生产方在响应里返回表级与列级标签；消费方把这些标签映射成自己的分类体系、属性或原生 tag 模型，再用自己的身份体系与策略做评估，在自己的运行时里执行。生产方标注 ssn 列为 pii=ssn，消费方就能对带该标签的列套用一条标签策略做掩码。
  • 三条硬约束：企业级统一治理方案必须做到保留策略表达力（属性策略、复杂子查询都要能定义并一致执行）、每个目录能独立出审计与合规证据（管理员不必跨系统对账）、不能把另一个目录服务放进关键路径。第三条最具体：权限感知的资产发现不能每次都去问对端，否则目录浏览与 typeahead 每用户每资产都要一次决策，难缓存，还会把性能与可用性绑在另一个服务上。
  • labels 的边界：规范只定义不透明键值对，没有共享语义，没有稳定标识符，血缘也不出源目录。消费方拿到的只是解析后的 key 和 value，拿不到「这个标签是为资产发现、访问控制、成本归摊还是别的目的而设」。结论写得很直白——元数据变得可移植，含义并没有。企业仍需共享约定或显式映射才能一致解释。
  • read restrictions 那侧的边界：引擎拿到的不是管理员定义的策略原文，而是针对某个 principal 计算出的结果，表现为过滤或掩码指令。初始规范定义了九种预定义的 column-projection 动作与标准化行过滤表达式（比较、集合成员等）。依赖子查询、查找表或自定义 UDF 的策略，无法用这套词汇表达——只有当目录能把策略结果归约到标准词汇之内，策略才被完整表示，否则语义就丢了。
  • Spark 算不算「可信引擎」：文章引用了 Spark 自身的安全指引——用户提交的代码在行为上不受限制，用户可控制分配给应用的资源。Spark 可以通过扩展实现 read restrictions，但这个部署只有在管理员控制运行时、并堵死每一条绕过执行的路径之后，才算得上「可信」，原因是 Spark 连表级访问控制 API 都没有，更不用说细粒度。

行业影响

对已经把多个目录联邦起来的企业，这条规范改变的是集成成本结构。过去要在 N 个目录之间对齐治理，要么把策略翻译成对方的语言（表达力必损），要么每次访问都跨目录问一次（性能与可用性受制于人）。labels 给出的是第三种：只搬运轻量上下文，判断留给本地，审计留在本地。

代价同样清楚。labels 让每个目录都能说「这一列是 PII」，却没说清「PII 在你的体系里意味着什么」。跨组织的语义对齐工作从「写一套映射规则」变成了「维护一套共享约定」，工作量挪了位置，没有消失。对国内一并跑着 Unity Catalog、Polaris、Lake Formation 与自建目录的团队，先约定内部标签词表再谈联邦，比直接上 labels 更实际。

相关链接

Lakebase Postgres 缓存改造：把 shared buffers 提到 75%，用大页扛住地址翻译

事件概述

同一天，Databricks 发布了 Lakebase Postgres 计算缓存改造的第一部分（作者 David Wein、Sunil Kamath、Haoyu Huang）。核心结论是：在固定规格的大计算上关掉本地文件缓存层，把 shared buffers 直接提到 DRAM 的 75%，并配显式 2MB 大页。生产环境实测吞吐最高翻倍，存储层读取降到约五分之一。

文章也明确了这是过渡方案。最终目标是让 shared buffers 随负载动态伸缩并吃到 75% 可用内存，弹性计算上的实现留到第二部分。

技术解析

  • 标准 Postgres 的两个老问题：一是双层缓冲——4GB 内存的计算里给 shared buffers 分 1GB，页面从磁盘读入时要经过内核 page cache，同一份数据在内存里存了两遍，1GB 缓存实际吃掉 2GB；二是内核 page cache 不了解 shared buffers 与 Postgres 内部状态，替换哪些页只能靠通用算法猜。
  • 存算分离带来的三个新挑战：Lakebase 的读路径不经过 OS 文件系统和 page cache，标准双层缓存直接失效；shared buffers 是静态参数，改了要重启数据库，对 serverless 自动伸缩系统几乎不可用；Postgres 每个活跃连接一个进程，shared buffers 给得越大，内核为每个连接要维护的内存管理结构越多。
  • 过渡层 LFC：本地文件缓存（local file cache）落在计算节点本地 NVMe 上，与 shared buffers 组成最多两层的计算缓存，合计最多占用 75% DRAM。shared buffers 此前被保守地压在上限 1GB，其余容量归 LFC。工作集一大，多数缓存命中只能走较慢的 LFC 层。
  • 这次的改动：固定规格且 CU ≥ 80 的计算上，直接禁用 LFC，把 shared buffers 设为 DRAM 的 75%，去掉那个约 1GB 的上限，让热页留在最快的内存层。验证方式是连上 Postgres 执行 show shared_buffers，80 CU 的 Lakebase 端点应返回 20971520。
  • 为什么必须配大页：Postgres 每个后端进程都要把 shared buffers 映射进自己的地址空间，每份映射需要自己的页表项。1GB shared buffers 对应每进程 262,144 个页表项；32GB shared buffers 配 512 个后端，约 43 亿项，也就是用约 32GB 页表去映射 32GB 缓存。这个工作集还远超 TLB 容量，即便命中 shared buffers 也要付 TLB miss 与页表遍历的代价。换成 2MB 大页后页表缩小 512 倍。Databricks 的基准测试里，尾读延迟最多降约 40%，CPU 利用率最多降约 30%。
  • 虚拟化环境里的大页：Lakebase 跑在裸金属主机上的轻量 guest VM 里，地址翻译涉及两层虚拟化。要吃到大页收益，必须从主机预留、虚拟机管理程序为 VM 内存提供 backing、到 guest 内核整条链路一致实现，任何一层掉链子收益都会打折。Databricks 选择显式 2MB HugeTLB，而不是 best-effort 的透明大页；大计算对应的 VM 初始化时按足够 Postgres 启动的量预分配大页，计算启动后自动释放超出需要的部分。验证方式是 show huge_pages，80 CU 端点应返回 on。
  • 三个生产样例：某大端点在 8 月 11 日 06:10 UTC 前后生效，每秒访问的 Postgres block 翻倍（文中用它作为吞吐代理），存储层 GetPage/s 从约 8K 降到约 1.5K，客户报告 p50 与 p99 低于前一日、前一周与前一月；另一个端点 8 月 14 日 01:30 UTC 生效，吞吐提升约 43%，计算缓存命中率接近 100%，请求几乎全部由 shared buffers 供给；第三个负载 8 月 15 日生效后 CPU 从 20 核降到 4 核，命中率接近 100%，吞吐翻倍。

行业影响

存算分离把「读路径」从单机假设里抽走了，缓存层级必须重新设计。Databricks 给出的答案有普遍参考价值：缓存决策要放回最了解数据语义的那一层（数据库自己），而不是留给通用内核；消除双层缓冲之后，单位内存能装下的有效缓存直接翻倍。

限制需要一并看。当前收益只覆盖固定规格且 CU ≥ 80 的计算——这恰恰是因为 shared buffers 还没动态化。弹性计算上要一起伸缩 shared buffers 和大页，协议更复杂，这是第二部分的题目。对正在自建存算分离 OLTP 的团队，「先做固定规格、再做弹性」这条增量路径本身比大页技巧更值得抄。

相关链接

Spark 自动改写接住 Iceberg 物化视图：TPC-DS 3TB 上 5x 到 20x

事件概述

AWS Big Data Blog 在 9 月 10 日发布《Accelerating Spark queries with Iceberg materialized views》（作者 Yuzhou Sun、Henry Laih、Srikanth Kandula 等）。在 Amazon EMR 7.12.0+ 与 AWS Glue 5.1+ 上，建在 AWS Glue Data Catalog 里的 Apache Iceberg 物化视图，可以被 Spark 优化器自动接住——业务 SQL 一行都不用改。

此前本专栏讲过用三条 CREATE MATERIALIZED VIEW 重建 Medallion 的做法，那次的重心在编排与增量怎么折叠进表格式。这次讲的是优化器怎么把已有查询匹配到物化视图上，以及三档粒度的实测取舍。

技术解析

  • 两种匹配策略：结构改写面向定义为单一 SELECT-FROM-WHERE-GROUP-BY 且基于 INNER JOIN 的物化视图，改编自 Amazon Redshift——优化器能把物化视图的聚合上卷到更粗粒度，也能把查询里的额外谓词拉到物化视图扫描上。精确匹配改写则处理 window function、outer join 等形态，把物化视图主体规范化后与查询计划的子树比对。
  • 子树替换：物化视图不必覆盖整个查询。匹配上哪一段，就替换哪一段子树，查询其余部分照原样跑在改写结果之上。
  • 新鲜度怎么保证：物化视图按 SCHEDULE REFRESH EVERY 1 DAY 之类的计划刷新，刷新时检查源表的 Iceberg snapshot ID（Parquet 源表则检查文件 ETag），只在源表确实变了才真正刷新。优化阶段还会再查一次 staleness，源表变过就跳过该物化视图，所以改写不会返回陈旧结果。也可以 REFRESH MATERIALIZED VIEW 手动强制刷新。
  • 几个关键开关：spark.sql.optimizer.answerQueriesWithMVs.enabled=true 是必需的，自动改写默认关闭；commandBlockingEnabled=false 才能在 INSERT、MERGE 等写命令的子查询里启用改写；Parquet（V1）源表还要开 v1SourceTables.enabled 与 v1ETagVersioning.enabled，缺了 ETag versioning，Spark 判不出源表版本就会跳过物化视图；EMR 7.13.0+ 会比对物化视图里存的 IMV_sparkVersion 与集群版本，可用 sparkVersionCompatibilityCheck.enabled=false 绕过。
  • TPC-DS 3TB 三档实测：Tier 1 只按客户键预聚合 store_sales，加速约 5 倍，体积是原表的 0.07%，复用范围最广，任何按客户的聚合都能吃；Tier 2 预 join customer 并预应用一个过滤条件，加速约 10 倍，体积 0.04%；Tier 3 把整个查询主体（含 RANK() 窗口与 Top 100 过滤）原样物化，加速 20 倍以上，只存约 100 行，复用范围最窄。
  • 一个反直觉的点：创建耗时峰值不在 Tier 3 而在 Tier 2。Tier 2 预先 join 并聚合了所有国家的优选客户，物化的数据工作量最大；Tier 3 提前应用了两个过滤条件，处理行数反而更少。
  • 限制清单：自动改写只发生在 AWS 优化过的 Spark runtime 上（Athena、EMR、Glue），Redshift 与第三方 Iceberg 引擎可以直接读物化视图但不会自动改写；源表必须是 Iceberg 或 Parquet 且注册在 Glue Data Catalog，并与物化视图同 Region 同账号；开启后会话里每个查询都要在优化阶段多付一次候选评估开销，包括最终没匹配上的那些；从物化视图读取可能产生更少的 task 或引入数据倾斜，并行度反而不如直接扫分布更均匀的基表。
  • 怎么确认改写生效：看执行计划的叶子节点是否出现 BatchScan <mv_catalog>.<mv_db>.<mv_name>；EMR 7.14.0+ 会在 INFO 日志里打 AQMV outcome: rewritten=true, mvs=[...], duration=12ms，没改写时可从 Spark Event Log 的 MVRewriteMetricsEvent 里取跳过原因。另外物化视图元数据缓存是懒加载的，第一个可改写查询做优化时才加载，表或物化视图太多还可能撑爆 driver 内存——这是「明明配了却不改写」最常见的两类原因。

行业影响

这套东西把「哪些查询值得预计算」这件事从人的判断搬进了优化器，人只剩一个决定：物化视图要建在哪个粒度档位上。Tier 1/2/3 的三档数据给了可抄的标尺——加速比与复用范围成反比，创建成本却不单调。

值得留意的是开放性与锁定并存：物化视图本身以 Iceberg 表存于 S3（通用桶或 S3 Tables 桶），Athena、EMR、Glue、Redshift 以及任何 Iceberg 兼容引擎都能读；但自动改写能力只锁在 AWS 自家的 Spark runtime 里。数据资产是开放的，加速能力不是——这个组合在未来几年会反复出现。

相关链接

Redshift 走进 ChatGPT Work：NL2SQL 的正确性交给 skills

事件概述

9 月 10 日，AWS 宣布推出面向 ChatGPT Work 里 Data agent 的 AWS Data Analytics 插件。业务人员在对话里用自然语言提问，插件把问题翻译成 Redshift SQL 并在客户自己的环境里执行，结果可以直接转成可分享的交互式仪表盘。

插件覆盖 Redshift 预置集群与 Serverless workgroup 两类形态，可接入已有的多集群、多 workgroup 环境，沿用客户已经配好的成本与安全控制。覆盖范围还包括 AWS Glue Data Catalog、S3 Tables、Athena 与向量检索。

技术解析

  • 会话中能完成的六件事：发现用户有权访问的 schema、表、列与数据类型；把自然语言问题翻译成 Redshift SQL；在客户自己的 Redshift 环境里执行；以表格或简短说明呈现结果；用追问做过滤、对比与下钻；把一次分析转成可分享、可继续探索的仪表盘。
  • 正确性的交付形态是 skills 而非提示词：插件基于 Agent Toolkit for AWS 里的 Amazon Redshift skills 构建，这些 skills 提供经过测试的操作流程与针对该服务的具体指引。这是本次最值得注意的一点——自然语言取数的准确性被打包成可版本化、可评审、可分发的工程工件。
  • 治理边界：分析跑在客户已有的数据之上，沿用客户现有的访问控制；如果 Redshift 环境一并查询数仓与数据湖，通过受管控数据集暴露给插件的那部分也可以被问到。文章明确写了这套会话流程不替换分析团队已经建立的数据模型、指标定义与治理实践。
  • 为什么说「不只是把提示词丢给数据库」：agent 需要理解 Redshift 特有的 SQL 方言、发现元数据、选对表与列，并构造符合服务最佳实践的查询。这四件事原本靠资深分析师的经验，现在被拆进 skills。

行业影响

数据仓库厂商开始把访问入口前移到通用 agent 前端，而不是各自造一个聊天框。Redshift 这次的选择是做插件而非自建入口，意味着「用户在哪问」与「数据在哪存」正式解耦。

对数据团队，真正需要评估的不是插件本身，而是 skills 的质量与可维护性：谁来维护 Redshift SQL 的最佳实践、指标口径变了怎么同步、skills 版本升级如何回归。这几个问题目前还没有行业标准答案。可以确定的一点是，指标口径的定义权仍在数据团队手里——插件只是让更多人能用到它，没有替你重新定义它。

相关链接

编者评

把这四件事排在一起看，动作的方向是一致的：都在消掉一层转译。跨目录治理过去要把策略翻译成对方的语言，现在只搬标签、判断留在本地；缓存过去要在数据库意图与内核策略之间对译，现在把缓存整体收回数据库，代价是从零开始解决页表与 TLB；慢查询过去要人工重写成预计算，现在交给优化器匹配，人只选粒度档位；业务问题过去要翻译成 SQL，现在交给 skills，skills 是可版本化的代码而不是一段提示词。

有意思的是四处都留下了没被消掉的那一层，而且形态高度相似——都是「可移植性有余，语义不足」。标签搬得动元数据搬不动含义；大页方案只覆盖固定规格的大计算，弹性场景要等下一部分；物化视图以开放 Iceberg 格式存放、谁都能读，自动改写却只锁在自家 runtime；插件接进了通用前端，正确性却压在一份需要人维护的 skills 上。

这提示了一种判断新技术的实用方法：看它省掉了哪一层转译，再看它把语义责任留给了谁。被省掉的那一层通常是工程量，被留下的那一层通常是长期成本。本期四条的长期成本分别落在共享约定、弹性支持、跨引擎改写能力和 skills 维护上——都是需要持续投入的活，没有一项是一次性配置能解决的。