Apache Iceberg 1.11.0引入File Format API开启湖仓格式插件时代；Spark 4.1以声明式管道和实时流重新定义数据工程抽象层；dbt Fusion引擎打通DuckDB与Spark 3.0——AI工具链竞争从模型走向开发基础设施

第七期追踪到DataInfra领域三条重要动态：Apache Iceberg 1.11.0于5月19日发布——这不是一个例行的维护版本，两条并行的工作线在此汇合：File Format API将Iceberg核心与物理存储格式的关系从”硬编码分支”重构为”插件模型”，添加新文件格式从”修改引擎内核”变为”实现接口并注册”，Vortex（GPU原生分析格式）、Lance（AI原生向量格式）、Nimble（ML训练宽表格式）的集成从此可行；Deletion Vectors用Roaring Bitmap存储在Puffin文件中替代V2的位置删除文件，解决了频繁UPDATE/DELETE场景下删除文件堆积导致的查询性能退化问题；Variant类型支持shredding将热点字段提取为原生列实现半结构化数据的高性能查询；GEOMETRY/GEOGRAPHY和纳秒时间戳使V3规范进入生产就绪状态。Apache Spark 4.1随Databricks Runtime 18 Beta于5月22日发布——Spark Declarative Pipelines (SDP)是Spark抽象演进的第三次飞跃（RDD→DataFrame→SDP），开发者只需定义Streaming Tables和Materialized Views及其数据流关系，Pipeline Runner自动分析数据流图、解析依赖、编排并行度、管理检查点和重试；Structured Streaming Real-Time Mode首次官方支持连续处理模式，无状态工作负载可达个位毫秒级延迟；SQL Scripting和VARIANT类型正式GA。dbt Labs 5月发布周期带来Fusion引擎两大火花——DuckDB支持Beta让本地dbt项目无需数仓账户即可运行（CI/本地测试/探索场景），Spark 3.0支持Beta让Spark项目获得Fusion的快速编译和执行（无Python运行时开销）；开发者代理可用自然语言构建、重构dbt模型和生成测试/文档；同期Confluent发布全托管MCP服务器和Agent Skills GA、开源dbt-Flink适配器——AI工具链竞争正从”谁的模型更强”转向”谁的开发基础设施更顺滑”。

Apache Iceberg 1.11.0：File Format API开启湖仓格式插件时代

事件概述

5月19日，Apache Iceberg发布1.11.0版本。这不是一个例行的维护版本——两条并行的工作线在此汇合：File Format API是对Iceberg架构的根本性重构，Deletion Vectors、Variant类型、地理空间类型和纳秒时间戳则是V3规范从”规范文本”走向”生产就绪”的里程碑。Dremio开发者关系负责人Alex Merced评价：“如果此前一直在等待Deletion Vectors、Variant类型、原生地理空间支持或纳秒精度时间戳稳定下来再采用，1.11.0就是标志着它们准备就绪的版本。”

技术解析

• File Format API——架构性重构：1.11.0之前，添加新文件格式需要修改Iceberg引擎内核——Parquet支持走一条代码路径，ORC支持走另一条，每种格式的读取器/写入器/特性处理在各引擎（Spark、Flink、Java通用实现）中各自维护，形成大量分支代码路径和功能支持不一致。File Format API引入三层抽象：FormatModel（格式实现描述：名称/读取器构造/写入器构造/格式特有能力）、FormatModelRegistry（注册表，解耦引擎与具体格式）、Read/Write Builder（统一构建接口，通过FormatModelRegistry.readBuilder(fileFormat, clazz, inputFile)获取）。添加新格式从”编辑引擎内核”变为”实现接口并注册”——这是插件模型，不是分支模型。Iceberg官方博客明确指出：“Iceberg不再需要挑选一个赢家——不同的表可以使用不同的格式，而目录、元数据层和事务语义在所有格式中保持一致。”
• 新格式的集成路径：社区正在通过File Format API集成三个新格式——Vortex（高性能分析格式，支持GPU直接解压、压缩数据上评估过滤表达式、模块化列编码）、Lance（AI原生格式，高维向量数据高性能随机访问，当前属于LanceDB生态但File Format API使Iceberg集成实验首次可行）、Nimble（ML训练宽表格式，优先解码速度而非压缩比）。当前状态：API已最终确定、通用模型已实现、引擎集成已合并、TCK（技术兼容性套件）开发中。
• Deletion Vectors——解决删除文件堆积：V2规范的位置删除文件机制在频繁UPDATE/DELETE场景下有扩展性问题——每次不触发文件重写的删除操作都创建一个位置删除文件，这些文件随时间堆积，查询时引擎必须打开并应用所有删除文件才能重建当前状态，性能逐步退化。V3的Deletion Vectors用Roaring Bitmap存储在Puffin文件格式中，标记数据文件中哪些行被删除——不再为每次删除创建新文件，而是在现有位图中追加标记。查询时读取位图跳过已删除行，性能不随删除操作数量增长而退化。1.11.0使Deletion Vectors进入生产就绪状态。
• Variant类型与shredding：半结构化数据（JSON）在数据湖中的常见做法是存储为STRING列——这失去了类型信息和查询优化机会。Variant类型提供原生半结构化数据支持，1.11.0引入的shredding机制将热点字段从Variant值中提取为原生类型列（如将variant.field_a提取为INT列），冷字段保留在Variant值中——热点字段走列式查询路径，冷字段走JSON解析路径，兼顾性能和灵活性。
• 地理空间与纳秒精度：V3规范新增GEOMETRY和GEOGRAPHY类型原生支持，配合GeoParquet 1.1.0规范中的边界框（bounding box）元数据实现空间过滤优化；timestamp_ns和timestamptz_ns类型填补高频交易和物联网场景的微秒精度缺口。
• 引擎适配更新：Spark 4.1运行时JAR（iceberg-spark-runtime-4.1_2.13）、Flink 2.0/2.1运行时JAR、Spark 3.4支持被标记为弃用、Java 11支持被移除。

行业影响

Iceberg File Format API的深层意义不是”又多了一个API”，而是湖仓格式的竞争范式正在从”赢者通吃”转向”生态共存”。此前的湖仓格式竞争是Parquet vs ORC vs Avro的零和博弈——Iceberg选择Parquet作为默认格式，ORC和Avro作为二等公民。File Format API改变了这个格局：Parquet/ORC/Avro是”内置格式”，Vortex/Lance/Nimble是”插件格式”，它们共享同一套目录、元数据层和事务语义，但各自发挥不同的优势。

这与Vol.5报道的DuckDB Lance扩展形成互补——DuckDB从SQL引擎侧支持Lance格式，Iceberg从表格式侧支持Lance格式。两者共同指向一个趋势：AI工作负载正在驱动湖仓格式从”结构化数据专用”向”结构化+半结构化+向量+地理空间多模态”演进，而插件模型是这个演进的技术基础。

Deletion Vectors的生产化则解决了Iceberg在CDC和GDPR场景下的长期痛点——此前用户必须在”删除文件堆积导致查询变慢”和”频繁触发文件重写导致写入放大”之间二选一。Deletion Vectors用O(1)的位图操作替代O(n)的删除文件扫描，使Iceberg在频繁更新场景下的竞争力显著提升——直接对标Delta Lake的类似机制。

相关链接

• Introducing the Apache Iceberg File Format API
• What’s New in Apache Iceberg 1.11.0 (Dremio)
• Apache Iceberg 1.11.0 Releases

---

Spark 4.1 + Databricks Runtime 18：声明式管道与实时流重新定义数据工程抽象层

事件概述

5月22日，Databricks发布Runtime 18 Beta，搭载Apache Spark 4.1.0。Spark 4.1不是一次增量更新——Spark Declarative Pipelines (SDP)代表了Spark抽象演进的第三次飞跃（RDD”怎么做”→DataFrame”做什么”→SDP”要什么结果”），Structured Streaming Real-Time Mode首次官方支持连续处理模式突破亚秒延迟门槛，SQL Scripting和VARIANT类型正式GA。Databricks Runtime 18还引入统一发布说明格式，不再为每个小版本（18.0/18.1/18.2）维护独立页面。

技术解析

• Spark Declarative Pipelines (SDP)：SDP的核心抽象是Streaming Table（由流式查询管理的表）和Materialized View（由特定查询结果定义的表）。开发者只需声明目标表状态和数据流关系，Pipeline Runner自动完成：分析整个数据流图→预验证捕获模式不匹配→自动依赖解析→并行执行无依赖查询→串行执行有依赖查询→检查点管理→失败重试。支持Python和SQL混合定义，通过spark-pipelines CLI编译和执行，通过Spark Connect支持多语言客户端。示例：定义raw_orders（Kafka摄入）、customers（维度刷新）、fact_orders（连接事实表）三个Streaming Table，SDP自动并行执行前两个、串行执行第三个。
• Structured Streaming Real-Time Mode (RTM)：Spark Structured Streaming此前仅支持微批处理模式，延迟在数百毫秒到秒级。RTM首次官方支持连续处理模式——p99延迟达个位毫秒级（无状态工作负载）。用户只需一个配置变更即可激活，无需重写代码或更换平台，继续使用熟悉的Structured Streaming API。Spark 4.1初始支持无状态、单阶段Scala查询（含Kafka源和Kafka/Foreach汇），后续版本将扩展支持范围。
• SQL Scripting GA与递归CTE：SQL Scripting在Spark 4.1中正式GA并默认启用，支持变量声明、条件逻辑、循环、异常处理和游标操作（Databricks Runtime 18.1新增DECLARE CURSOR/OPEN/FETCH/CLOSE）。递归CTE支持在SQL中实现层级遍历和图查询。SQL作为数据工程一等语言的地位进一步巩固。
• VARIANT类型GA与shredding：VARIANT类型从预览版升级为GA，支持shredding优化——半结构化数据的常用字段被提取为原生类型列，实现更快的读取性能。与Iceberg 1.11.0的Variant shredding形成呼应，两者从不同层面（引擎侧 vs 格式侧）优化半结构化数据处理。
• PySpark优化：新增Arrow原生UDF和UDTF装饰器，直接使用PyArrow执行无需Pandas转换开销；Python Data Source支持过滤下推减少数据移动；Python Worker Logging捕获UDF日志并通过内置表值函数暴露。
• Spark Connect增强：Spark ML on Connect正式GA（Python客户端），支持更智能的模型缓存和内存管理；zstd压缩protobuf计划、分块Arrow结果流和大本地关系增强支持提升了大规模工作负载的稳定性。
• 近似数据草图：新增KLL和Theta近似草图，支持分布式top-K聚合和基数估计——这在超大规模数据集上的探索性分析中非常有用。

行业影响

Spark SDP的发布标志着数据工程抽象层的第三次跃迁。第一次是2015年的DataFrame API——从”告诉Spark怎么做”（RDD）到”告诉Spark做什么”（声明式变换），这是从命令式到函数式的跃迁。第二次是2024年的Spark 4.0——从”写代码做变换”到”用SQL做变换”（Spark Connect + SQL增强），这是从编程语言到SQL的跃迁。第三次是SDP——从”定义每个变换步骤”到”定义目标状态和数据流”，Pipeline Runner自动处理执行细节——这是从”怎么算”到”算什么”的跃迁。

这与Vol.5报道的RocketMQ for AI有异曲同工之处——RocketMQ用Session-as-Topic让开发者不再管理连接状态，SDP让开发者不再管理管道执行状态。两者共同指向一个趋势：数据基础设施正在从”开发者编排执行”转向”开发者声明意图，基础设施编排执行”——这正是AI代理时代所需的基础设施抽象层级，因为AI代理更适合声明”我要什么结果”而非编排”每一步怎么执行”。

RTM的发布则补上了Spark在实时流处理领域的关键缺口——此前Flink在亚秒延迟场景中几乎没有竞争对手，RTM让Spark用户无需引入新平台即可获得可比的延迟性能。

相关链接

• Introducing Apache Spark 4.1
• Databricks Runtime 18 Release Notes
• Databricks Runtime 18.1 Beta

---

dbt Fusion打通DuckDB与Spark 3.0——AI工具链竞争从模型走向开发基础设施

事件概述

dbt Labs 5月发布周期带来Fusion引擎的两个重大扩展：DuckDB支持进入Beta（本地dbt项目无需数仓账户，适用于测试/探索/CI场景），Apache Spark 3.0支持进入Beta（Fusion引擎CLI编译执行，无Python运行时和子进程开销）。开发者代理进入Beta/Preview，支持自然语言构建/重构dbt模型、生成测试/文档/语义模型。Fusion发布轨道提供Nightly/Stable/Extended/Fallback四档更新节奏，新项目默认Fusion Stable。

同日，Confluent在Current London大会上发布全托管MCP服务器和Agent Skills GA——开发者可用自然语言让AI代理探索/管理/调试Kafka/连接器/Schema Registry/指标等资源，Agent Skills封装Confluent领域最佳实践（Schema Registry/Kafka Streams/Python Kafka Client/CDC to Tableflow四个技能包）。开源dbt-Flink适配器让数据工程师沿用dbt工作流定义/测试/部署Flink SQL流式管道。Flink SQL内置ML函数支持PII检测和遮蔽。

5月18日，Anthropic宣布收购Stainless——自Anthropic API早期即为所有官方SDK生成提供技术支持的公司，Stainless将API规范转化为TypeScript/Python/Go/Java/Kotlin等多语言SDK和MCP服务器工具。Anthropic平台工程负责人Katelyn Lesse直言：“代理只有在能连接到系统时才有用。”

技术解析

• Fusion引擎DuckDB支持Beta：dbt项目可在本地运行无需数仓账户——这对CI/CD（零仓库成本运行测试）、本地开发（快速迭代无需等待远程编译）和探索性分析（数据工程师快速验证逻辑）场景意义显著。DuckDB作为嵌入式分析引擎，与Fusion引擎的Rust编译器天然匹配，无需Python运行时。
• Fusion引擎Spark 3.0支持Beta：Spark项目的Fusion编译执行路径绕过了传统dbt-spark适配器的Python子进程开销——Fusion引擎用Rust编译SQL模型直接提交到Spark，更快编译和执行。当前仅支持Apache Spark 3.0。
• 开发者代理（Developer Agent）：Beta/Preview阶段，支持自然语言构建/重构dbt模型、生成SQL/测试/文档/语义模型。代理的命令在Studio IDE命令标签页中显示Copilot图标，可区分手动和代理执行的命令。超时自动取消卡住的调用并返回重试友好消息。
• Fusion发布轨道：四档节奏——Nightly（最新功能/最高风险）、Stable（默认/推荐）、Extended（保守/低频更新）、Fallback（回退/紧急修复）。新环境默认Fusion Stable，开发者可按团队稳定性需求选择轨道。
• dbt compare：从本地开发到CI的模型级差异比较——本地开发时VS Code扩展预览编辑对数据的影响（增删行/连接验证），CI阶段Fusion自动运行model-level diff作为管道门控。
• Confluent MCP服务器GA：全托管MCP服务器处理认证/限流/API版本管理，开发者通过自然语言让AI代理探索Kafka/连接器/Schema Registry/指标，检查连接器状态/配置/日志/错误摘要，Confluent平台新功能上线后对应MCP工具自动出现。
• Confluent Agent Skills GA：四个技能包——Schema Registry（扫描项目/提取模式/标记PII/生成Terraform注册）、Kafka Streams（端到端设计/构建/调试）、Python Kafka Client（脚手架生产级生产者/消费者项目含Schema Registry序列化）、CDC to Tableflow（端到端CDC管道：数据库源→Debezium→Flink→Tableflow→Iceberg/Delta Lake）。与Claude Code/Cursor/Windsurf等AI编码工具兼容。
• dbt-Flink适配器：免费开源插件，让数据工程师沿用dbt命令和项目结构定义/测试/部署Flink SQL流式管道。支持使用mock数据的单元测试，实时输出的数据质量测试即将推出。同时发布confluent-sql驱动，将Flink开放给Python生态（Airflow编排/Pandas分析/AI框架）。
• Flink SQL PII检测与遮蔽：内置ML函数在流处理过程中检测和遮蔽个人可识别信息，无需自定义代码/外部服务/先搬运数据到仓库——在金融/医疗/保险等高度监管行业直接解锁更多AI用例。
• Anthropic收购Stainless：Stainless自2022年成立以来为数百家公司生成SDK/CLI/MCP服务器，是Anthropic官方SDK的幕后技术提供者。收购的核心逻辑是”代理只有在能连接到系统时才有用”——SDK和MCP服务器工具是代理连接系统的桥梁，控制桥梁等于控制代理的触达范围。

行业影响

dbt Fusion引擎DuckDB和Spark 3.0支持的深层意义是数据转换引擎正在从”绑定数仓”走向”绑定格式”。此前dbt的价值主张是”SQL-first transformation on your warehouse”——你必须有一个Snowflake/BigQuery/Redshift/Databricks仓库才能用dbt。DuckDB支持打破了这个约束——你只需要一个文件（DuckDB数据库文件），Fusion引擎就能编译和执行。这对CI/CD场景尤其重要：每次PR都运行全量dbt测试的成本从”仓库计算费用”变为”本地CPU时间”。

但更重要的是dbt-Flink适配器、Confluent MCP/Agent Skills和Anthropic-Stainless收购所共同指向的趋势：AI工具链竞争正在从模型层下移到开发基础设施层。此前的竞争是”谁的模型更强”（GPT vs Claude vs Gemini），现在竞争变成”谁的开发者工具链更顺滑”——Anthropic收购Stainless控制SDK/MCP服务器工具链，Confluent发布MCP服务器+Agent Skills让AI代理直接操作流数据基础设施，dbt推出开发者代理让自然语言成为数据工程的接口。

将Vol.1-7串联，一个更完整的图景浮现：2026年DataInfra领域的竞争正在从”能力竞争”转向”开发者体验竞争”。Vol.1-3的AI Gateway/Agent Skills/Pulumi是”让基础设施支持AI代理”（能力），Vol.4-5的MemKV/OTel毕业/RocketMQ for AI是”为AI代理重新设计基础设施”（效率），Vol.6的KVCache精细化/可观测性湖仓化是”优化AI基础设施的运行效率”（精调），Vol.7则进入新阶段——让AI代理成为基础设施的原生操作者（SDP声明式管道让AI代理声明”要什么”而非编排”怎么做”，MCP/Agent Skills让AI代理直接操作Kafka/Flink/dbt，Stainless让AI代理触达更多系统）。当AI代理成为基础设施的原生操作者时，开发者体验就是基础设施的竞争力。

相关链接

• What’s shipped in dbt — May 2026
• Confluent AI Developer Tools Now GA: MCP Servers & Agent Skills
• New in Confluent Cloud: Making Data & Pipelines Accessible for AI-Ready Streaming
• Anthropic acquires Stainless

---

编者评

第七期的三条动态，与前六期的主线形成了又一次维度跃迁。Vol.1-2确立了”AI原生基础设施”和”基础设施AI代理化”两条主线，Vol.3-4追踪到AI代理趋势渗透到治理层和存储/芯片层，Vol.5看到横切面基础设施（可观测性、消息引擎）为AI代理重新定义角色，Vol.6见证了AI推理基础设施的精细化，本期则看到了两条新线索的浮现：湖仓格式的插件化和AI代理成为基础设施的原生操作者。

Iceberg File Format API的深层意义不是”又多了一个API”，而是湖仓格式的竞争范式从”赢者通吃”转向”生态共存”。当Parquet/ORC/Avro、Vortex/Lance/Nimble共享同一套目录和事务语义时，格式选择不再是”选阵营”而是”选工具”——这降低了新格式（尤其是AI原生格式）的采用门槛，与Vol.5报道的DuckDB Lance扩展从引擎侧和格式侧两个方向共同推动湖仓生态的多模态演进。

Spark SDP则标志着数据工程抽象层的第三次跃迁——从”怎么做”（RDD）到”做什么”（DataFrame）到”要什么结果”（SDP）。这个跃迁的方向恰好与AI代理的运作模式一致：AI代理更适合声明”我要什么结果”而非编排”每一步怎么执行”。SDP让Spark管道从”人类编排的命令式流程”变为”AI代理可声明的意图描述”——这是Spark为AI代理时代所做的根本性架构准备。

dbt Fusion + Confluent MCP + Anthropic-Stainless则共同指向一个更具战略意义的趋势：AI工具链竞争从模型层下移到开发基础设施层。当模型能力趋于同质化（GPT-5 vs Claude 4 vs Gemini 2.5的差距在缩小），竞争焦点转向”谁的AI代理能更顺滑地操作开发基础设施”——SDK工具链、MCP服务器、Agent Skills、开发者代理成为新的竞争壁垒。Anthropic收购Stainless的信号意义在于：控制代理与系统的连接层，就是控制AI生态的战略制高点。

将七期主线串联，一个完整的演进图景浮现：DataInfra正在经历从”为人设计”到”为人+代理协同设计”的范式迁移，而2026年5月是这个迁移从”能力建设”（Vol.1-3）到”效率优化”（Vol.4-6）到”代理原生”（Vol.7）的转折点。当Spark管道、dbt模型、Kafka集群、Flink作业都可以被AI代理用自然语言声明和操作时，数据工程的本质从”写代码定义变换”变为”描述意图让基础设施编排执行”——这正是Vol.1开篇所追踪的”AI原生基础设施”的最终形态。