datainfra前沿动态 · Vol.36

Apache Iceberg 1.6.0 发布：S3 双层加密与 Manifest 加密就位；Databricks Variant 正式 GA；多表事务补齐湖仓 ACID 最后拼图

本期聚焦 DataInfra 三大基础能力升级：Apache Iceberg 1.6.0 带来 S3 DSSE-KMS 加密和 Manifest 加密，将湖仓安全从存储层上推到格式层；Databricks Variant 类型与 Variant Shredding 正式 GA，半结构化数据首次获得结构化级别的查询性能；Databricks 多表多语句事务正式 GA，湖仓终于具备传统数仓级别的 ACID 能力。

DataInfra Apache Iceberg Iceberg 1.6.0 S3 DSSE-KMS Manifest Encryption Databricks Variant Variant Shredding 半结构化数据 Delta Lake Catalog Commits Multi-table Transactions ACID Unity Catalog 数据安全 湖仓

本期追踪到 DataInfra 领域三条围绕”基础能力补全”的动态：2026 年 7 月 23 日，Apache Iceberg 1.6.0 正式发布，由 Fokko Driesprong 主导，带来 S3 DSSE-KMS 双层加密、Manifest 加密、Bloom Filter FPP 可配置等安全与运维增强——标志着湖仓安全从”存储层加密”向”格式层原生加密”的演进；7 月 22 日，Databricks 2026 年 7 月平台发布中两项核心功能正式 GA：Variant 类型与 Variant Shredding 让半结构化数据（JSON、Avro、Kafka 消息等）首次获得接近结构化列式数据的查询性能，以及多语句多表事务基于 Catalog Commits 协议正式全面可用，湖仓终于具备了传统关系型数据库的跨表 ACID 保证。三条动态共享同一个叙事内核：DataInfra 基础设施正在补齐”企业级生产环境”所需的最后几块能力拼图——安全、灵活数据模型、事务一致性。

Apache Iceberg 1.6.0 发布：S3 DSSE-KMS 双层加密、Manifest 加密、安全与运维全面增强

事件概述

2026 年 7 月 23 日，Apache Iceberg 社区由 Fokko Driesprong 主导发布了 Iceberg 1.6.0。这是继 1.5.0（2024 年 12 月）之后的一个大型累积版本，包含来自 main 分支的 1,491 个 commits。虽然未引入 V3/V4 格式级别的变更，但 1.6.0 在安全、云集成和开发者体验三个维度进行了系统性增强——其中 S3 DSSE-KMS 双层加密和基本 Manifest 加密两项安全特性尤其值得关注。

技术解析

  • S3 DSSE-KMS 双层加密：DSSE-KMS（Dual-layer Server-Side Encryption with KMS）是 AWS 在 2023 年推出的最高级别 S3 加密方案，在标准 SSE-KMS 之上增加了第二层加密——数据先用一个独特的请求级密钥加密，再被 KMS 主密钥加密。Iceberg 1.6.0 通过 #8370 (Aajisaka) 新增了对该加密模式的原生支持，使得写入 Iceberg 表的数据文件可以享受 AES-256-GCM 双层保护，且密钥策略由 AWS KMS 集中管理。对于金融、医疗等合规行业，这意味着 Iceberg 湖仓的存储层安全可直接对标最严格的云安全标准。

  • 基本 Manifest 加密：PR #8252 (Gershinsky) 引入了 Manifest 文件的基本加密能力。Manifest 是 Iceberg 元数据树的核心中间层——记录数据文件列表及其列级统计信息。对 Manifest 加密意味着即使攻击者获取了对象存储的读取权限，也无法直接解析表的元数据结构（哪些文件属于哪个分区、各列的 min/max 统计值等），从而增加了一层”元数据混淆”的防御深度。虽然目前仍为基础实现（basic manifest encryption），但这标志着 Iceberg 安全模型从”依赖存储层加密”向”格式层原生加密”的重要一步。

  • Bloom Filter FPP 可配置：PR #10149 (Huaxin Gao) 新增了 Bloom Filter 的假阳性率（FPP）配置选项。Bloom Filter 是高基数列数据跳过的核心机制——通过概率数据结构快速判断”这个数据文件是否可能包含我需要的值”。此前 FPP 使用固定默认值，现在允许用户根据列的数据分布特征和查询模式精细调优：高基数列用更低 FPP（更精确、更节省扫描 I/O）、低基数列用更高 FPP（更节省索引存储）。这在超大规模分区表的点查场景中可直接转化为查询延迟和计算成本的降低。

  • AWS Glue Catalog 改进：1.6.0 修复了 Glue Catalog 中列注释（#10276）和表描述（#10199）在更新 Iceberg 表后被清零的问题，同时新增了 DynamoDB LockManager 的资源清理（#10132）和 S3 UserAgent 中嵌入 Iceberg 版本号（#9963）——后者对云端的可观测性和问题排查有实际价值。

  • API 增强与开发者体验：List APIs 新增分页支持（#9782），Spark 配置解析器新增 EnumConfParser（#10311），新增 Iceberg Proposals 的 Issue 模板和文档（#9932），以及 Stale PR 自动管理（#10134）——这些看似”家务活”的改进实际上反映了社区在 1.6.0 发布周期中对治理成熟度的投入。

行业影响

Iceberg 1.6.0 是一个典型的”平台成熟期”版本——没有震撼性的新数据类型或格式变更，但在安全、运维和开发者体验三个方向进行了系统加固。DSSE-KMS 和 Manifest 加密的引入特别值得关注，因为它们代表了湖仓安全模型的一个微妙但重要的转向：从”信任底层存储的加密能力”到”格式层自己控制加密语义”。

这种转向的驱动力是多云和混合部署的现实需求。当一张 Iceberg 表的数据文件可能分布在 AWS S3、Azure ADLS 和本地 MinIO 三种存储后端时，依赖各云厂商的加密机制意味着三套不同的密钥管理策略和合规审计链路。而格式层原生加密（Manifest Encryption 是第一步，未来可能扩展到 Data File Encryption）使得安全策略可以在表级别统一声明和审计，不受底层存储的异构性影响。从这个角度看，1.6.0 的安全增强是 Iceberg 向”企业级多引擎多云端湖仓标准”迈进的一个重要节点。

相关链接

Databricks Variant 类型与 Variant Shredding 正式 GA：半结构化数据获得结构化级别查询性能

事件概述

2026 年 7 月 22 日，作为 Databricks 2026 年 7 月平台发布的一部分，Variant 类型和 Variant Shredding 正式宣布 GA。Variant 是一种专为半结构化数据（JSON 文档、Kafka 消息、REST API 响应、无模式数据库导出等）设计的灵活列类型，其关键创新在于：通过 Variant Shredding 自动将嵌套的半结构化字段提取为内部列式结构，使查询引擎可以像访问结构化列一样高效地访问 JSON 字段——无需用户手动展平（flatten）或预定义 Schema。

技术解析

  • Variant 解决的核心矛盾：在数据湖中，半结构化数据（JSON、Avro 等）长期处于一个尴尬位置——要么以原始文本/二进制 blob 存储，查询时全量解析（慢）；要么通过 ETL 预展平为固定列（丢失灵活性且管道脆弱）。Variant 类型的核心设计哲学是”存入灵活，查询高效”：数据保持半结构化的灵活性（无需预定义 Schema，字段可以随时变化），但物理存储和查询执行采用了列式引擎的高效路径。

  • Variant Shredding 的自动优化机制：从 Databricks Runtime 17.3 开始，创建包含 VARIANT 列的新表时 Variant Shredding 自动启用。其工作原理是将 JSON 文档中高频出现的字段路径自动提取为内部子列（sub-columns），分别存储和压缩——类似于 Parquet 的列式编码但作用于嵌套结构的内部。对于最佳查询性能（包括 Variant 统计信息收集和数据跳过），Databricks 推荐 Runtime 18.1 及以上。这意味着在最优配置下，对 Variant 列的过滤查询（如 WHERE variant_data.user.city = '北京'）可以实现与结构化列类似的 partition pruning 和数据文件跳过——而不需要全表扫描和逐行 JSON 解析。

  • 典型使用场景：流式数据源（Kinesis、Event Hub、Kafka）的原始消息直接落入 Variant 列，绕过传统的”解析→展平→写回”ETL 阶段；REST API 的 JSON 响应作为数据湖中的一等公民，无需预判未来分析需求而提前定义所有可能字段；无模式数据库（MongoDB、DynamoDB 等）的数据直接映射到 Variant 列，保留灵活性的同时获得列式查询引擎的加速。

行业影响

Variant GA 的意义不仅在于 Databricks 平台新增了一个数据类型，更在于它代表了半结构化数据处理范式的第三步演进：第一步是”存储灵活，查询慢”（JSON blob + 全量解析），第二步是”ETL 展平，查询快但僵化”（Schema-on-Write），第三步就是 Variant 所代表的”存储灵活，查询也快”（Schema-on-Read + 自动列式优化）。

将 Variant GA 与 Apache Iceberg 社区的 Parquet File 逻辑类型（7 月中旬 18:0 全票通过，Vol.34 已覆盖）和向量类型（float[768]）提案放在一起看，可以清晰地看到：列式存储格式和查询引擎正在同时向”多模态数据”方向扩展其类型系统。Variant 解决的是”半结构化嵌套数据如何在列式引擎中获得结构化级别的性能”，Parquet File 逻辑类型解决的是”图像/音频/文档等非结构化数据如何作为表的一等公民参与事务和查询优化”，向量类型解决的是”AI embedding 如何获得原生类型支持”。三者共同构成了 2026 H2 数据基础设施向 AI 时代演进的”类型系统三件套”。

相关链接

Databricks 多表事务正式 GA：湖仓终于补上 ACID 最后一块拼图

事件概述

与 Variant GA 同一天（2026 年 7 月 22 日），Databricks 宣布多语句多表事务（Multi-statement, Multi-table Transactions）正式 GA。该功能基于 2026 年 5 月 12 日 GA 的 Catalog Commits 协议构建——使用 BEGIN ATOMIC ... END 或 BEGIN TRANSACTION ... COMMIT 语法，将跨多张 Delta 表的多个 SQL 语句封装为一个原子操作：全部成功或全部回滚。这是湖仓历史上首次在对象存储上实现跨表 ACID，消除了”跑数仓负载必须保留传统关系型数据库”的最后一个架构理由。

技术解析

  • 从单表到多表的 ACID 跨越：Delta Lake 自诞生之初就提供了单表 ACID（通过乐观并发控制和事务日志），但跨多张表的原子写入一直是开放的湖仓格式的软肋。传统数据仓库（如 Teradata、Oracle）支持多表事务是因为它们控制整个存储和计算栈；而开放的湖仓格式面对的是”不同引擎各自写各自的文件到共享的对象存储”的分布式环境，协调跨表提交是一个分布式共识问题。Catalog Commits 协议通过将 Unity Catalog 升级为”表状态协调中枢”来解决这个问题：所有引擎通过 Catalog 的标准化 API 提交事务，Catalog 成为全局串行化点（serialization point），保证了跨表 ACID。

  • 事务语法的两层设计：BEGIN ATOMIC ... END 提供轻量级的多语句原子性——同一事务内的多条语句作为一个单元提交，适合 ETL 管道中的多步写入；BEGIN TRANSACTION ... COMMIT 在此基础上增加了隔离性保证。事务中所有涉及的表必须已启用 Catalog Commits（即 delta.feature.catalogManaged = 'supported'），且事务目前仅支持写入操作（INSERT/UPDATE/DELETE/MERGE），不支持跨事务的读取一致性快照（即当前实现为 Read Committed 隔离级别而非 Serializable）。

  • 引擎生态覆盖：当前支持多表事务的引擎包括 Databricks Runtime 18.0+、Delta Spark、Delta Flink（4.2.0+）、Starburst Trino、DuckDB（通过 Unity Catalog 扩展）和 StreamNative。通过 Delta Kernel 的标准化 API，任何引擎都可以相对低成本地接入 Catalog Commits 并获得多表事务能力。

行业影响

多表事务 GA 补齐了湖仓相对于传统数据仓库的最后一个关键能力缺口。回顾湖仓 ACID 的演进脉络：单表 ACID（Delta Lake 2019）→ Catalog Commits 协议标准化（2026-02 提案，2026-05 GA）→ 多表事务（2026-07 GA），这条路线走了大约 7 年。对于企业架构决策来说，这意味着”湖仓不能做事务性数仓负载”的技术障碍已经被移除——供应链、金融交易、库存管理等工作负载理论上可以完全迁移到湖仓，不再需要维护传统数据仓库作为事务层。

从更广的视角看，多表事务的 GA 进一步强化了”Catalog 成为数据平台的神经系统”这一趋势。Vol.34 报道了 Iceberg Terraform Provider 将湖仓引入 IaC 时代，本期报道的 Catalog Commits 和多表事务则将 Catalog 升级为 ACID 事务的协调者。两者共同指向一个方向：Catalog 不再只是一个”表目录”，而是数据平台的控制平面（Control Plane）——负责发现、授权、审计、事务协调、自动优化。DataInfra 的架构重心正在从”存储格式”向”目录服务”转移。

相关链接

编者评

本期三条动态虽然来自不同的项目和厂商，但共享一个清晰的架构演进方向：DataInfra 基础设施正在从”功能可用”向”企业级生产就绪”过渡。Iceberg 1.6.0 用 DSSE-KMS 和 Manifest 加密回答了”数据在湖仓中安全吗”的问题；Databricks Variant GA 用自动列式优化回答了”半结构化数据在湖仓中能跟结构化数据一样快吗”的问题；多表事务 GA 用跨表 ACID 回答了”湖仓能替代传统数仓的事务性负载吗”的问题。

这个趋势与前几期形成了递进关系：Vol.33 展示了”如何让查询更快”（Comet 加速 + Celeborn Shuffle），Vol.34 展示了”格式如何演进”（Iceberg V4 社区进程 + Parquet File 逻辑类型），Vol.35 展示了”架构如何重写”（dbt Rust 重写 + EMR AIOps），而本期展示了”能力如何补齐”——安全、灵活数据模型、事务一致性，这些不是性感的新概念，但它们是 DataInfra 进入金融、医疗、政务等强监管行业的入场券。

对于 DataInfra 从业者来说，2026 年 H2 的关键信号是：湖仓的基础设施完备性（feature completeness）正在快速接近传统数据仓库的水平，但成本结构和开放生态的优势远超后者。 当安全、半结构化数据、跨表事务这些最后的差距被填平后，决策的天平将从”哪些场景可以用湖仓”转向”哪些场景还必须用传统数仓”——而后者的列表正在迅速缩短。