datainfra前沿动态 · Vol.32

Spark 4.2.0 发布：CDC原生支持、Bootstrap 5暗色UI、TIME/Geo类型就绪；ApsaraMQ for Kafka 原生数据湖摄取：零ETL直写Iceberg

本期聚焦两大技术发布：Apache Spark 4.2.0 携 CDC 连接器 API、现代 Web UI、TIME/Geo 新数据类型与 PySpark 性能优化正式发布；阿里云 ApsaraMQ for Kafka 推出 Broker 层原生数据湖摄取能力，实现 Kafka 到 Iceberg 的零 ETL 写入。

DataInfra Apache Spark Spark 4.2.0 CDC Change Data Capture Bootstrap 5 Dark Mode TIME Data Type Geometry Geography PySpark Spark Connect Kubernetes Volcano ApsaraMQ Kafka Apache Iceberg Zero-ETL Data Lake Ingestion OSS Table Bucket Alibaba Cloud Structured Streaming Stream-to-Lake

本期追踪到 DataInfra 领域两条重大发布：7 月 14 日 Apache Spark 4.2.0 正式发布，带来 CDC（Change Data Capture）原生支持、Bootstrap 5 驱动的现代 Web UI（含暗色模式）、TIME 和 Geography/Geometry 数据类型全面就绪、PySpark 多轮性能优化等重磅特性；同日阿里云 ApsaraMQ for Kafka 推出原生数据湖摄取能力，将数据写入逻辑嵌入 Broker 层，实现 Kafka Topic 到 Apache Iceberg（OSS Table Bucket）的一键零 ETL 直写。两条发布共同指向一个趋势：流处理与湖仓的边界正在从”需要外部桥接”向”引擎原生融合”加速演进。

Apache Spark 4.2.0 正式发布：CDC 原生支持、现代 Web UI、TIME/Geo 类型全面就绪

事件概述

2026 年 7 月 14 日，Apache Spark 社区宣布 Spark 4.2.0 正式发布。这是 4.x 大版本的第 7 个发行版，也是继 4.0.0 引入 Spark Connect、4.1.0 引入 Variant 类型之后，4.x 系列中功能密度最高的一个版本。此次发布涵盖 CDC 连接器 API、SQL 功能大幅扩展、Web UI 现代化重构（Bootstrap 5 + 暗色模式）、TIME 和 Geography/Geometry 数据类型全面就绪、PySpark 多轮性能优化、Kubernetes 部署能力增强、Java 25 全面支持等十余个重大主题，依赖库集体升级至 2026 年最新稳定版本。

技术解析

  • CDC（Change Data Capture）原生支持：这是 4.2.0 最重要的架构级新增。Spark 首次引入 DSv2 CDC 连接器 API 和 SQL CHANGES 子句，允许用户通过统一的 CHANGES(table_name) 语法查询表的变更数据流。同时提供了 DataFrame API、Spark Connect 和 PySpark 三套 CDC 查询接口，覆盖批处理 CDC 后处理（删除残留 + 计算更新）。这意味着 Spark 从”只能读快照”升级为”原生理解变更流”——过去需要通过 Delta Lake CDF 或外部 CDC 工具（如 Debezium + Kafka）读取变更日志，现在 Spark SQL 层面即可直接表达 CDC 语义。

  • Web UI 现代化：Bootstrap 5 + 暗色模式 + SQL 计划对比：Spark Web UI 从 Bootstrap 4.6.2 升级到 5.3.8，D3.js 升级到 7.9.0，原生支持暗色模式（CSS 自定义属性驱动）。SQL 计划可视化被彻底重构：节点更紧凑、支持详情侧面板、并排 SQL 计划对比（A/B 两个查询的执行计划直接并列呈现）、SQL 计划节点可点击链接到对应 Stage/Job 页面、复制执行计划文本 + 一键分享链接。Environment 页面从单表变为标签式布局，非默认配置自动高亮，支持导出配置到 JSON。

  • TIME 和 Geography/Geometry 数据类型全面就绪：TIME 类型在 4.2.0 中获得完整的序列化支持——JSON、CSV、XML、ORC、Avro 五种格式全覆盖，并支持从字符串到 TIME 的隐式转换。Geography 和 Geometry 类型突破性地支持 WKB（Well-Known Binary）解析和写入、Parquet 读写（此前被阻止写入 Parquet）、ST_GeomFromWKB 函数支持可选的 SRID 值、Geo 类型间转换和 Catalyst 类型系统中的一等公民地位。

  • PySpark 多轮性能优化与 API 增强：toPandas() 避免了中间 Pandas DataFrame 创建，Arrow→Pandas 转换路径重构，多轮 Py4J 调用优化显著降低 JVM 往返开销。新增 DataFrame.zipWithIndex、SparkSession.Builder.create、DataFrame.toJSON 返回 DataFrame、Copy-on-Write 模式、__dataframe__ 交换协议等 API。Python 3.12 正式支持，Pandas 3 兼容，PyPy 退休。

  • Structured Streaming 状态存储升级：TransformWithState Operator 获得测试框架 TwsTester、更好的错误提示、State Store 行校验和、自动快照修复、多列族支持（Repartition Writer + State Reader）、离线重分区 State Writer。新增事件时间键编码器将以事件时间作为一等公民嵌入状态存储 API，以及 OffsetMap 按名称追踪流处理进度。

  • Kubernetes 部署能力增强：支持 K8s Deployment API、Volcano 升级至 1.14.1 并默认启用配置、内置 ExecutorResizePlugin、recovery-mode Executor、NetworkPolicy 支持、扩展现有 PVC 重用。K8s 版本支持升级至 1.35，停止支持 v1.32。

  • SQL 功能大幅扩展：QUALIFY 子句、管道操作符 | 作为 |> 替代、SQL Scripting 游标（CURSOR）、IDENTIFIER 子句和参数标记、PIVOT 别名、array_agg/collect_list/collect_set 支持 IGNORE NULLS/RESPECT NULLS、TIMESTAMP WITH LOCAL TIME ZONE、INSERT INTO ... BY NAME、DSv2 schema evolution for INSERT/MERGE。新增 SQL Metric View（CREATE METRIC VIEW，YAML 定义 + 维度/度量查询）。

  • 性能优化：多聚合 Join 消除、BooleanSimplification 规则效率改进、Broadcast 块清理性能优化、MergeRowExec 代码生成、LongHashedRelation 堆外模式、FilterExec 全阶段代码生成中子表达式消除、向量化 Parquet 布尔读取优化（查找表 + 批量缓冲区）。

  • 依赖库大规模升级：Hadoop 3.4.3→3.5.0、Parquet 1.17.0、ORC 2.3.0、Arrow Java 19.0.0、Netty 4.2.10.Final、Jackson 2.21.2、Scala 2.13.18、Kafka 3.9.2、Zookeeper 3.9.5、RoaringBitmap 1.6.0、Zstd-jni 1.5.7-7、ICU4J 78.2、Kubernetes-client 7.6.1。

  • JDK 25 全面支持：修复 JDK25+G1GC 可能导致数据损坏的关键 Bug、MemoryConsumer 死锁、BlockInfoManager 竞态条件、ClosureCleaner 重新设计、Spark-Shell 在 Java 22-25 上的兼容性问题。

行业影响

Spark 4.2.0 的 CDC 原生支持标志着 Spark 从”批处理+微批流”引擎向”变更数据感知平台”的关键转型。过去，Spark 用户需要依赖 Delta Lake、Iceberg 等表格式的 Change Data Feed 功能，或 Debezium+Kafka 等外部 CDC 管道来获取增量变更——CDC 语义在 Spark 层是隐式的。4.2.0 通过 CHANGES 子句和 DSv2 CDC API，将 CDC 提升为 SQL 层的一等公民，这意味着：(1) 任何支持 DSv2 CDC API 的连接器都可以被 Spark 的 CDC 查询统一消费；(2) CDC 语义不再与特定表格式绑定；(3) 批处理、流处理和 CDC 处理在 Spark SQL 中形成统一的编程模型。

Web UI 的 Bootstrap 5 升级看似”换皮”，实际对运维效率影响深远：暗色模式直接回应了数据工程师在夜间值班时对低光环境的刚需；并排 SQL 计划对比让 A/B 查询优化从”截图并排对比”变成”一个页面两个视图”；节点到 Stage/Job 的链接打通了 SQL 调试的”最后一公里”——工程师不再需要在 SQL 计划和 Stage 页面之间手动跳转。

TIME 和 Geo 类型的全面就绪则让 Spark 在时序分析（TIME）和空间分析（Geo Parquet）两个高增长领域的竞争力大幅提升。尤其是 Geo 类型从”不能写 Parquet”到”Parquet 原生支持 Parallel 读写”，解除了将 Spatial SQL 结果直接持久化到湖仓的关键技术限制。

相关链接

阿里云 ApsaraMQ for Kafka 原生数据湖摄取：Broker 层零 ETL 将流式数据直写 Apache Iceberg

事件概述

2026 年 7 月 14 日，阿里云消息团队正式宣布 ApsaraMQ for Kafka 推出原生数据湖摄取（Native Data Lake Ingestion）能力。通过将数据格式转换、Schema 提取、分区路由和 Iceberg 元数据提交内嵌到 Kafka Broker 层，用户只需在控制台为 Topic 启用该功能，即可实现流式数据到 Apache Iceberg（基于 OSS Table Bucket）的一键零 ETL 写入。该能力已于 2026 年 6 月进入 Public Beta，计划于 9 月 GA。

技术解析

  • 零 ETL 架构：Broker 即摄取引擎：传统 “Kafka→数据湖” 管道需要为每个 Topic 部署独立的 Spark/Flink 作业或 Kafka Connect 集群进行消费、转换和写入，Schema 变更需多团队同步修改 ETL 逻辑。ApsaraMQ 的方案将数据转换和写入逻辑嵌入 Broker 层——内置 Worker 组件自动将 Kafka Record 转换为 Parquet 格式写入 OSS Table Bucket，用户无需部署任何外部计算任务。系统提供 Exactly-Once 语义保障，确保转储过程中数据不重复、不丢失。

  • 双模式摄取：Append + CDC/Upsert：(1) Append 模式面向日志和事件流等纯追加场景，数据通过 Append 操作写入 Iceberg 表，支持高效批量提交；(2) CDC 模式面向数据库 CDC 场景（Debezium 等捕获的变更流），原生支持 Upsert 操作——用户指定 Key 字段后，系统基于 Iceberg 的增量文件机制高效执行 Insert/Delete/Update。同时提供 Raw Archiving 和 Structured Archiving（Flatten/Debezium）两种灵活转换策略。

  • Schema Registry 深度集成：统一 Schema 真理源：该能力与 Kafka Schema Registry 深度集成，将原本散落在 Producer 代码、Flink 作业和 Iceberg 表定义中的 Schema 定义集中管理。Producer 发送数据时自动校验注册 Schema；Schema 演化时，系统自动提取新版本信息并将变更同步到 Iceberg 表结构——利用 Iceberg 原生 Schema Evolution 能力实现列增删、类型修改而无需重写数据集或中断下游任务。

  • OSS Table Bucket：10 倍性能的 Iceberg 原生存储底座：底层存储基于阿里云 OSS Table Bucket 服务，它原生实现 Apache Iceberg 表语义，完全兼容 Iceberg REST API 和 S3 Table API。得益于 OSS 底层架构的端到端深度优化，Table Bucket 在大规模读写场景下的 TPS 是自建 Iceberg on generic bucket 的 10 倍以上。同一份表数据可被 Spark、Flink、Trino、StarRocks 等主流查询引擎直接读写，彻底终结 “ETL 复制 + 多份数据副本” 的烟囱式架构。Table Bucket 后台自动执行小文件合并、过期快照清理和孤儿文件删除——零用户计算资源消耗。

  • 智能分区与自动运维：用户通过简单配置即可定义多列分区策略（如按日期分区），查询引擎可利用分区剪枝避免全表扫描。OSS Table Bucket 后台自动执行 Compaction、Snapshot Expiration、Orphan File Cleanup 等湖仓运维任务。

行业影响

ApsaraMQ for Kafka 的原生数据湖摄取是“流批一体”基础设施从”上层桥接”走向”底层融合”的标志性事件。回顾 Kafka 与数据湖的集成史：第一代方案是独立的 Spark/Flink 作业消费 Kafka 写入 HDFS/S3（需要为每个 Topic 维护至少 1 个作业）；第二代方案是 Kafka Connect Sink Connector（统一了连接器范式但仍需部署和维护 Connect 集群）；第三代为 Confluent 的 Tableflow 和 WarpStream 的 Agent 模式（云厂商将写入能力嵌入托管服务但仍是旁路架构）。ApsaraMQ 的方案是第四代架构——将摄取能力直接嵌入 Broker 进程，这意味着：(1) 摄取延迟从”Flink 作业启动+处理+提交”的数十秒级别缩短为 Broker 内部提交级别；(2) 不再有”Flink 作业 OOM""Kafka Connect 任务停滞""分区再平衡”等运维故障模式；(3) 资源成本和运维人力成本趋近于零。

将本期 ApsaraMQ 的零 ETL 摄取与同期发布的 Spark 4.2.0 CDC 支持并列观察，可以看到一条清晰的行业趋势线：流处理引擎（Spark）在向”原生理解变更数据”方向进化，消息中间件（Kafka）在向”原生写入数据湖”方向进化——两者从上下游两端同时向中间靠拢，最终将消除”流批之间的人造 ETL 鸿沟”。

不过，该方案当前的核心局限在于生态锁定：Broker 层内置的 Parquet 写入器和 Iceberg 元数据提交目前仅支持阿里云 OSS Table Bucket 作为存储后端，无法直接写入 AWS S3 或 GCS 上的自建 Iceberg 表。对于多云部署的企业，这可能意味着数据被物理绑定在阿里云上。但从技术架构角度看，这种”Broker 内嵌存储写入”模式一旦被验证成熟，AWS MSK 和 Confluent Cloud 跟进类似能力只是时间问题。

相关链接

编者评

本期两条发布虽分属不同产品（计算引擎 vs 消息中间件）和不同厂商（Apache 基金会 vs 阿里云），但技术脉络高度一致——都在消除”流”与”湖”之间的工程摩擦。Spark 4.2.0 从 SQL 层面原生支持 CDC 语义（CHANGES 子句），让”查询变更数据”像”查询快照数据”一样简单；ApsaraMQ for Kafka 将摄取能力下沉到 Broker 层，让”写入数据湖”像”发送一条消息”一样简单。这两个方向叠加的结果是：未来从 Kafka 到 Iceberg 再到 Spark 查询的整条链路，可能不再需要任何人工编写的 ETL 代码——Kafka Broker 自动写 Parquet 到 Iceberg，Spark SQL 用 CHANGES 子句直接读取增量变更。这种从”工程师写管道代码连接系统”到”系统原生互相理解对方语义”的范式转移，是 DataInfra 在 2026 年最值得关注的深层结构性变化。Spark 4.2.0 的 CDC API 和 ApsaraMQ 的 Broker 层摄取，分别是这场变革在”消费者端”和”生产者端”的两块关键拼图。