尧图网站建设 
Spark 4.1 来了Gluten、Iceberg、cudf 集体跟进适配升级前必看的兼容清单Spark 4.1.x 发布后围绕它的一轮生态适配动作已经在多个开源仓库里同时出现Gluten 提出支持 Spark 4.1.x 的 Issue、Iceberg 有针对 Spark 4.1 新异步微批规划器的 PR、NVIDIA 的 cudf-spark 同时出现支持 4.1.1与补齐新物理算子两类需求、Deequ 发起整体移植 PR另有多个下游项目把 pyspark 依赖一路抬到 4.1.1[1][2][3][4][5][6][7]。这构成一种非常典型的节奏主计算引擎先发布周边生态开始补课。对于正在评估升级的数据平台团队真正的问题不是4.1 好不好而是我栈里的哪些组件在等谁、等多久、等不到怎么办。本文以 GitHub 上可核验的 Issue/PR 与依赖升级记录为一手证据给出适配进度矩阵、三类迁移成本模型、可执行的兼容清单和分阶段升级节奏。在开始之前必须先把证据边界说清楚否则很容易读成一篇生态已就绪的通稿。先校准预期本文能证明什么不能证明什么本次整理的来源存在两个硬约束。第一所有条目的热度字段均为 0无法做热度排序或热度加权除一条 SeaTunnel 2.3.12 发布记录带有 2025-10-27 的明确时间戳外其余来源的发布时间字段基本为空[14]。因此本文不使用近期热议热度第一之类的表述适配潮仅指多个仓库在同一窗口内出现适配动作的证据密度不是热度或时间线结论。第二也是更关键的一点Issue 的存在只证明有人在做这件事不证明已经合入、已经发版、已经可用于生产。本文对证据统一做四级区分证据形态能证明什么不能证明什么功能/移植 Issue如 Gluten #11339已识别到兼容缺口或适配需求缺口已修复移植 PR如 Deequ #751适配工作正在进行已合入、已发布依赖升级 PR如 Drift #29有下游用户在试跑新版本生产可用打包/分发侧 PR如 macports #31673分发渠道在跟进上游官方支持状态正文中所有未由来源直接确认的信息是否合入、产出版本号、发布日期、GPU 支持矩阵、二进制兼容承诺一律标注⏳待核实并在文末汇总成待核实清单。发布前应逐条补齐未补齐的部分不能写成结论。一、适配全景谁在跟进跟进到哪一步1.1 四个核心项目的适配信号Apache Gluten执行计划兼容。仓库中已提出 Issue #11339标题为[VL] Support Spark 4.1.x[1]。VL 即 Velox 后端。Gluten 这类基于 Spark 物理计划做拦截与替换的项目对 Spark 版本最敏感Spark 升级往往会新增、拆分或重命名物理计划节点后端必须逐节点覆盖否则只能回退到原生执行或直接在计划校验阶段失败。该 Issue 当前状态、目标版本、是否覆盖 ClickHouse 后端均为 ⏳待核实[1]。Apache Iceberg流式规划器对接。PR #15299 标题为Spark 4.1: New Async Spark Micro Batch Planner[2]。这里有一个必须谨慎的定性问题从标题看它可能属于为适配 Spark 4.1 而对接新的异步微批规划器也可能是借助 Spark 4.1 的新能力做功能增强。两者叙事完全不同——前者意味着升级阻塞项后者意味着升级红利。该 PR 的性质、合并状态、落入的 Iceberg 版本号均为 ⏳待核实[2]。NVIDIA cudf-sparkGPU 算子白名单。仓库中同时出现两个信号Issue #14056Add support for Spark 4.1.1属于整体版本支持需求[3]Issue #14150[FEA] Support OneRowRelationExec introduced in Spark 4.1.x (SPARK-52060)属于具体物理算子的补齐需求[4]。后者尤其有代表性它直接指出 Spark 4.1.x 引入了新的物理节点OneRowRelationExec对应 SPARK-52060GPU 执行层需要为它增加支持。至于该节点未被支持时是回退 CPU 还是直接报错来源未说明⏳待核实[4]。需要说明的是这两个 Issue 的编号跨度较大仓库是否为 monorepo、编号是否从其他仓库迁移而来需在引用前到仓库主页核对⏳待核实。awslabs Deequ整体移植。PR #751 标题为Port to spark 4.1[5]。Deequ 是编译期绑定 Spark API 的数据质量库Spark 大版本升级通常需要整体重新编译与测试。该 PR 的合并状态与产出的 Deequ 版本号、Maven Central 上是否已有支持 Spark 4.1 的发行版⏳待核实[5]。1.2 外围与分发侧那些隐性跟随者除了四个核心项目还有几类动作值得放进视野因为它们往往是最容易被忽略的阻塞项。依赖机器人触发的跳跃式升级。AmadeusITGroup/Drift 的 PR #29 由 Dependabot 发起把 pyspark 从 3.5.2 升到 4.1.1[6]databrickslabs/geobrix 的 PR #16 把 Python 侧约束从4.0.0放宽到4.1.1[7]。前者跨了两个大版本号线这类 PR 的 diff 往往是隐性破坏点清单最好的来源如果连 CI 配置、测试代码都跟着改说明破坏面不小如果只改版本号说明该项目的测试覆盖可能不足以暴露问题。两个 PR 是否连带代码修改⏳待核实[6][7]。打包系统跟进。macports/macports-ports 的 PR #31673 标题为apache-spark2.4 through apache-spark4.2: new ports[8]。标题中的 “4.2” 含义存疑可能是端口命名也可能指向尚未被本文来源证实的版本序列。不能据此断言Spark 4.2 已发布⏳待核实[8]。生命周期视角。endoflife.date 维护有 apache-spark 的生命周期条目[9]。它是判断能等多久的依据之一当前生产版本的支持截止时间决定了观察期的上限。具体截止日期需到该条目核对⏳待核实[9]。1.3 适配进度矩阵下表是本文的核心交付物之一。所有状态列只反映来源证据强度不代表项目实际发布状态。项目证据证据类型适配切入点已知缺口/风险核实状态apache/gluten#11339 [1]IssueVelox 后端物理计划覆盖覆盖范围、是否含 ClickHouse 后端未知⏳待核实apache/iceberg#15299 [2]PR异步微批规划器对接性质适配 or 增强未定性⏳待核实NVIDIA/cudf-spark#14056 [3]Issue整体版本支持正式支持版本未知⏳待核实NVIDIA/cudf-spark#14150 [4]Feature Issue新算子OneRowRelationExec未支持时的回退行为未知⏳待核实awslabs/deequ#751 [5]移植 PR整体 Port产出版本号未知⏳待核实AmadeusITGroup/Drift#29 [6]依赖升级 PRpyspark 3.5.2 → 4.1.1diff 范围未知⏳待核实databrickslabs/geobrix#16 [7]依赖升级 PRpyspark 约束放宽至 4.1.1测试覆盖未知⏳待核实macports/macports-ports#31673 [8]打包 PR端口树新增“4.2” 含义存疑⏳待核实endoflife.dateapache-spark 条目 [9]生命周期数据支持窗口具体日期未核⏳待核实从这张表能得出的稳健结论只有一个多个独立仓库同时出现了针对 Spark 4.1.x 的适配动作覆盖计算加速、数据湖、数据质量、依赖管理、打包分发五类角色。这说明适配工作是真实且多点展开的但它不能说明任何单一组件已经可用。二、为什么会集中出现适配动作Spark 4.1 变了什么虽然来源没有提供 Spark 4.1 的官方变更日志但可以从适配动作反推出三类变更点。这是一种推断请与已核实事实区分。2.1 从 Issue 反推的三处变更点第一物理计划新增或变更了节点。cudf-spark #14150 明确提到OneRowRelationExec由 Spark 4.1.x 引入并关联到 SPARK-52060[4]。对于任何拦截物理计划的执行层GPU 后端、向量化后端、自研加速器物理节点集合的变化都是硬兼容点白名单里没有这个节点就意味着回退或失败。Gluten #11339 这种支持 Spark 4.1.x的宽口径 Issue大概率也包含同类工作[1]。SPARK-52060 的具体内容需查 Apache JIRA 与 Spark 4.1 release notes 核实⏳待核实。第二流式/微批规划接口发生了演进。Iceberg #15299 的标题直接指向New Async Spark Micro Batch Planner[2]。规划器接口的变化会影响流式写入的调度语义批间隔如何计算、checkpoint 何时提交、失败重跑是否幂等都是需要逐项验证的点。第三新的编程模型带来新的一致性问题。来源中出现了关于 Spark Declarative Pipeline 的独立文档与真实提问[10][11]。其中 Stack Overflow 上的问题在 availableNow 触发器下如何保证 Declarative Pipeline 中两个查询处理同一批行正是一致性语义的典型疑问[11]。需要注意该提问并未在来源标题中说明所用 Spark 版本因此只能作为Spark 流处理通用痛点引用不能归因于 4.1⏳待核实。2.2 三类迁移成本模型把上面的变更点抽象一下升级成本大致可以分三类每一类的排查手段和阻塞属性都不同。一、执行计划/算子兼容成本Gluten、cudf-spark 侧。特征是编译通过但运行期回退或报错因为问题出在计划节点匹配层。风险在于它可能是静默的任务跑得通但加速率从 80% 掉到 20%没有任何异常堆栈。这类成本必须用回退率指标来量化而不能只看任务成功与否。二、SQL 与语义兼容成本Iceberg、Declarative Pipeline 侧。特征是结果不对但不报错。规划器变化、触发器语义、时间语义、checkpoint 提交时机都会影响结果集的完整性与一致性。这类成本最隐蔽必须靠数据正确性校验兜底。三、依赖与二进制兼容成本Deequ、Drift、geobrix 侧。特征是构建期或类加载期直接失败反而最容易发现。典型问题包括 Scala 大版本后缀如 artifact 名中的_2.12/_2.13不匹配、JDK 支持范围变化、provided依赖冲突、Python 包装层对 py4j 与 Python 版本下限的要求变化。Spark 4.1 的 Scala 默认版本、JDK 支持范围与二进制兼容承诺来源未覆盖⏳待核实务必以官方文档为准。2.3 小项目依赖升级 PR 的启示Drift #29 与 geobrix #16 这类纯依赖升级看起来琐碎实则价值很高[6][7]。它们是第三方替你做的一次免费试跑如果 Dependabot 的 PR 只改了一个版本号就通过 CI说明该项目对 Spark 的使用面较窄或测试覆盖不足如果 CI 失败后 PR 长期挂着失败日志就是一份现成的不兼容清单如果 PR 连带修改了测试代码、CI 配置、文档中的版本要求说明破坏面已经外溢到工具链。建议在升级前把这类 PR 的 diff 与 CI 记录完整读一遍成本极低收益很高。同理macports #31673 这类打包 PR 的 diff 会暴露构建脚本层需要处理的版本、路径与依赖变化[8]。三、分项目迁移踩坑点这一节只讲会怎么踩、该怎么避不重复进度矩阵。3.1 GlutenVelox 后端算子覆盖与回退典型症状有三种执行计划校验阶段直接失败任务能跑但大量算子回退到原生执行性能不升反降。排查路径建议如下。先用EXPLAIN或 Spark UI 的 SQL 页看物理计划确认哪些节点被 Gluten 接管、哪些回退再在 Gluten 日志里检索 unsupported 相关关键字拿到未覆盖节点清单最后把清单与 #11339 声明的适配范围对照[1]。对不上就说明你的作业用到了该 Issue 范围之外的算子此时应把它当作已知缺口管理而不是当作 bug 反复重试。# 计划层排查骨架先看物理计划再看后端回退日志# 具体日志关键字与配置项以所用 Gluten 版本文档为准$SPARK_HOME/bin/spark-shell\--confspark.pluginsorg.apache.gluten.GlutenPlugin\--confspark.gluten.enabledtrue3.2 Iceberg运行时 artifact 与流式语义Iceberg 与 Spark 的耦合点通常落在iceberg-spark-runtime-*这类运行时 artifact 上其命名会随 Spark 大版本与 Scala 大版本变化。在 4.1 下应使用哪个 artifact 名、是否仍带 Scala 后缀来源未提供⏳待核实请以 Iceberg 官方 Getting Started 文档为准不要凭经验手写坐标。!-- 坐标占位模板artifact 名与版本号必须查官方文档后填写不猜 --dependencygroupIdorg.apache.iceberg/groupIdartifactId!-- 待核实对应 Spark 4.1 的 runtime artifact --/artifactIdversion!-- 待核实 --/version/dependency流式侧的验证重点是三项checkpoint 是否能在异常后正确恢复availableNow触发器下批次边界与行集合是否稳定可参考 SO 上关于两查询行一致性的提问[11]失败重跑是否产生重复写入。如果规划器对接改变了批间隔或提交时机这三项都会受影响[2]。3.3 cudf-sparkGPU 算子白名单与新节点GPU 栈的升级从来不是单点动作至少要对齐四件事Spark 版本、RAPIDS/cudf 版本、CUDA 运行时版本、GPU 驱动版本。具体支持矩阵必须查 NVIDIA 官方文档来源未提供任何版本对应关系本文不给出臆造矩阵。对OneRowRelationExec这类新节点验证方法很直接构造一个会触发该节点的最简查询例如不带表的常量投影查询观察它是被 GPU 接管、回退 CPU 还是失败⏳待核实其默认行为[4]。同时应统计一段时间内的回退率把它作为 GPU 栈升级成功与否的硬指标而不是只看任务成功率。3.4 Deequ 与数据质量链路Deequ 这类库在编译期绑定 Spark APISpark 大版本升级后必须重新编译因此能不能编过本身就是一道门槛。在 #751 对应的版本正式可用前[5]可行的过渡方案有两类一是把数据质量校验隔离在独立集群上继续跑旧版 Spark与主计算链路解耦二是临时降级校验范围只保留行数、非空率、唯一性等不依赖复杂 API 的基础检查。两种方案都要明确写下哪些检查暂时不生效避免质量覆盖率在升级窗口内无声下降。3.5 PySpark 侧Python 包装层Python 侧的升级约束容易被忽略。pyspark 包装层升级后至少要核对Python 解释器版本下限、py4j 版本配套关系、pandas/Arrow 互操作相关配置是否需要调整。这些内容必须查对应版本的官方 release notes来源未覆盖⏳待核实。Drift #29 把 pyspark 从 3.5.2 一步抬到 4.1.1[6]这类跨大版本跳跃尤其要检查 Python 环境而不是只改 requirements 文件。3.6 症状速查表症状可能根因排查动作关联证据物理计划校验失败新节点未被后端覆盖EXPLAIN 比对节点集合[1][4]GPU 加速率骤降但任务成功算子静默回退统计回退率、查后端日志[3][4]流式任务批次边界异常规划器/触发器语义变化检查 checkpoint 与批间隔[2][11]类加载或 NoSuchMethodError二进制不兼容、依赖冲突dependency:tree排查冲突[5][6][7]重跑产生重复数据任务重试与写入非幂等分区级 checksum 比对[13]Python 侧启动失败pyspark 与 Python/py4j 不匹配核对版本下限与配套关系[6][7]其中重跑产生重复数据一行并非理论风险Stack Overflow 上确有mapPartitions在任务重试时向 BigQuery 重复插入数据的真实提问[13]。它说明正确性风险在升级窗口内会被放大必须用校验兜底。四、升级前的兼容清单这是全文的核心交付物建议直接转成工单模板。4.1 依赖与构建矩阵升级前先锁定一张版本矩阵所有目标值填完才能进入试点。维度当前值目标值证据来源状态Spark / Spark-submit 环境待填待填官方 Downloads⬜Scala 大版本待填待核实Spark 官方文档⬜JDK 版本待填待核实Spark 官方文档⬜Gluten 版本待填待核实#11339 及 Releases[1]⬜Iceberg runtime artifact待填待核实官方 Getting Started⬜cudf-spark / RAPIDS 版本待填待核实#14056 及官方矩阵[3]⬜CUDA / GPU 驱动版本待填待核实NVIDIA 官方矩阵⬜Deequ 版本待填待核实#751 及 Maven Central[5]⬜pyspark / Python 版本待填4.1.1 线其余待核实[6][7]⬜依赖冲突排查可以先用下面的命令骨架拿到事实再决定是否需要 exclusion# 构建期看 Scala/Spark 相关依赖是否被意外传递mvn dependency:tree-Dincludesorg.scala-lang mvn dependency:tree-Dincludesorg.apache.spark# 运行期确认实际加载的 jar 与版本jar tf path/to/your.jar|grep-ispark|headspark-submit--version4.2 功能回归范围回归至少覆盖四类每类都要有明确用例来源。批处理 SQL业务 SQL 全量回放外加 TPC-DS 子集作为通用基准。子集规模按团队既有基准环境确定本文不虚构数字。流式微批模式、availableNow触发器、异常恢复、Declarative Pipeline若在用。重点验证批次边界与行集合稳定性[11]。数据湖读写Iceberg 的写入、快照读、compaction、schema evolution以及与旧版本混跑时的元数据兼容。数据质量校验Deequ 检查项全量比对确认升级后无静默降级[5]。4.3 数据正确性与幂等校验升级最容易出的不是崩溃而是静默错数。建议固定三层校验行数比对按分区比对升级前后结果表行数校验和比对对关键列做分区级 checksum能发现行数相同但内容漂移的情况幂等验证对同一批输入强制重跑两次确认结果一致。mapPartitions重试导致重复写入的案例说明任务重试与外部写入的幂等性必须显式验证[13]。4.4 性能基准与观测判断升级成功而不只是升级能跑需要固定三样东西固定数据集、固定 SQL 集、固定观测口径。对比指标至少包括 P50/P95 耗时、资源消耗executor 内存与 GC 时间、失败重试次数。GPU 栈额外增加两个指标算子回退率、GPU 利用率。基线数据应在升级前用旧版本采集避免事后补录。4.5 可勾选清单版本矩阵九项全部填满且每项目标值有官方来源依赖树中无重复或冲突的 Spark/Scala artifact批处理 SQL 全量回放结果一致流式三种触发模式各跑通一次含异常恢复Iceberg 读写、compaction、schema evolution 回归通过与旧版本混跑的表元数据兼容性已验证Deequ 检查项无静默降级行数、分区 checksum、幂等三项校验通过性能基线与升级后数据可对比无明显回退GPU 栈回退率已量化并达标回滚方案已写明并演练过一次双版本并行窗口与灰度维度已确定五、升级节奏建议观察期、试点、全量5.1 三阶段模板与放行信号观察期。这一阶段不改生产只做跟踪与预研。跟踪对象是四个核心项目的合入状态与首个正式版本而不是 Issue 创建时间[1][2][3][5]。同时查 endoflife.date 中当前 Spark 版本的支持截止时间[9]它决定了你能等多久。放行信号栈内所有阻塞组件都已有可用的正式版本且版本矩阵能填满。试点。选一条非关键链路最好同时覆盖 Iceberg 读写和一个加速后端把第四节的清单完整跑一遍。放行信号清单全绿且性能指标无不可接受的回退。全量。按集群或业务线灰度推进保留双版本并行窗口。放行信号灰度期内正确性校验持续通过且回滚演练有效。相对时间刻度可以用 T2 周、T6 周、T12 周这类模板表达具体周数由团队排期决定本文不提供绝对日期因为来源无法支撑任何时间断言。5.2 等谁的决策树判断阻塞项的思路很直接栈内是否使用 Gluten 或 GPU 加速cudf 系若是这两个通常是硬阻塞因为它们直接绑定物理计划[1][3][4]。栈内是否重度依赖 Iceberg 流式写入若是需等待规划器相关适配的明确定性[2]。栈内是否依赖 Deequ 等编译期绑定 Spark API 的库若是需等待对应移植版本发布[5]。若三项都否仅依赖纯批 SQL 与 PySpark升级风险相对可控可较早进入试点但仍需完成依赖矩阵与正确性校验。5.3 回滚与风险对冲回滚预案至少包含四件事镜像与依赖包的版本快照配置项差异清单数据层回滚策略回滚演练记录。其中数据层最容易被忽略——如果升级过程中写入了新格式的数据或变更了表格式版本回滚后旧引擎能否正确读取是必须提前验证的问题。Iceberg 表格式版本升级是否可逆来源未涉及⏳待核实务必在演练中实测不要假设。六、结语把追版本变成可管理的工程动作这轮适配动作给出的真正启示不是Spark 4.1 该不该升而是版本升级应当被当作一个有证据、有清单、有门槛的工程流程用证据分级管理预期用兼容清单管理风险用门槛信号管理节奏。Issue 只是信号合入与发版才是事实任务跑通只是下限数据正确与性能不回退才是及格线。6.1 待核实事实总表以下事项在发布前必须逐条补齐未补齐项在正文中保持⏳待核实。#待核实项建议渠道1Spark 4.1.x 的确切版本序列与发布日期Spark 官方 Downloads / Release notes2SPARK-52060 与OneRowRelationExec的变更细节Apache JIRA / Spark 4.1 release notes3Gluten #11339 的状态、目标版本、覆盖后端GitHub Issue 页、Gluten milestone4Iceberg #15299 的性质、合并状态、落入版本GitHub PR 页、Iceberg Releases5cudf-spark 仓库身份与 #14056/#14150 编号对应关系GitHub 仓库主页与 Issue 页6cudf-spark 对 Spark 4.1.1 的正式支持版本与 CUDA/驱动矩阵NVIDIA 官方文档7Deequ #751 状态与产出版本号GitHub PR、Maven Central8Spark 4.1 的 Scala 默认版本、JDK 支持范围、二进制兼容承诺Spark 官方文档9Icebergspark-runtimeartifact 命名与 Scala 后缀Iceberg 官方 Getting Started10macports #31673 中 “4.2” 的准确含义PR diff、macports 端口树11Drift #29 / geobrix #16 的 diff 是否连带代码修改GitHub PR diff12Spark 3.x 各版本的支持截止日期endoflife.date/apache-spark13SO #79866196 等问答发生时的 Spark 版本问题正文中的版本信息14Iceberg 表格式版本升级的可逆性官方文档 实测演练参考资料[1] [VL] Support Spark 4.1.x · Issue #11339 · apache/glutenGitHubhttps://github.com/apache/gluten/issues/11339[2] Spark 4.1: New Async Spark Micro Batch Planner · Pull Request #15299 · apache/icebergGitHubhttps://github.com/apache/iceberg/pull/15299[3] [FEA] Add support for Spark 4.1.1 · Issue #14056 · NVIDIA/cudf-sparkGitHubhttps://github.com/NVIDIA/cudf-spark/issues/14056[4] [FEA] Support OneRowRelationExec introduced in Spark 4.1.x (SPARK-52060) · Issue #14150 · NVIDIA/cudf-sparkGitHubhttps://github.com/NVIDIA/cudf-spark/issues/14150[5] Port to spark 4.1 · Pull Request #751 · awslabs/deequGitHubhttps://github.com/awslabs/deequ/pull/751[6] chore(deps): bump pyspark from 3.5.2 to 4.1.1 · Pull Request #29 · AmadeusITGroup/DriftGitHubhttps://github.com/AmadeusITGroup/Drift/pull/29[7] Update pyspark requirement from 4.0.0 to 4.1.1 in /python/geobrix · Pull Request #16 · databrickslabs/geobrixGitHubhttps://github.com/databrickslabs/geobrix/pull/16[8] apache-spark2.4 through apache-spark4.2: new ports · Pull Request #31673 · macports/macports-portsGitHubhttps://github.com/macports/macports-ports/pull/31673[9] endoflife.date/products/apache-spark.md · endoflife-date/endoflife.dateGitHubhttps://github.com/endoflife-date/endoflife.date/blob/master/products/apache-spark.md[10] rocket-ship/Spark Declarative Pipeline.md · shauryashaurya/rocket-shipGitHubhttps://github.com/shauryashaurya/rocket-ship/blob/main/Spark%20Declarative%20Pipeline.md[11] Ensure two queries in a Spark declarative pipeline process the same rows when using the availableNow triggerStack Overflowhttps://stackoverflow.com/questions/79866196/ensure-two-queries-in-a-spark-declarative-pipeline-process-the-same-rows-when-us[12] Spark job fails with UnsafeExternalSorter OOM when using groupBy collect_list sortStack Overflowhttps://stackoverflow.com/questions/79866787/spark-job-fails-with-unsafeexternalsorter-oom-when-using-groupby-collect-list/79895144[13] Java Spark mapPartitions retry causing duplicate inserts into BigQuery on task failureStack Overflowhttps://stackoverflow.com/questions/79905259/java-spark-mappartitions-retry-causing-duplicate-inserts-into-bigquery-on-task-f[14] Apache SeaTunnel 2.3.12 发布核心引擎升级、连接器生态再扩张2025-10-27 14:24Giteehttps://gitee.com/seatunnel/SeaTunnel/releases/tag/2.3.12 Spark 4.1 来了：Gluten、Iceberg、cudf 集体跟进适配，升级前必看的兼容清单
Spark 4.1 来了Gluten、Iceberg、cudf 集体跟进适配升级前必看的兼容清单Spark 4.1.x 发布后围绕它的一轮生态适配动作已经在多个开源仓库里同时出现Gluten 提出支持 Spark 4.1.x 的 Issue、Iceberg 有针对 Spark 4.1 新异步微批规划器的 PR、NVIDIA 的 cudf-spark 同时出现支持 4.1.1与补齐新物理算子两类需求、Deequ 发起整体移植 PR另有多个下游项目把 pyspark 依赖一路抬到 4.1.1[1][2][3][4][5][6][7]。这构成一种非常典型的节奏主计算引擎先发布周边生态开始补课。对于正在评估升级的数据平台团队真正的问题不是4.1 好不好而是我栈里的哪些组件在等谁、等多久、等不到怎么办。本文以 GitHub 上可核验的 Issue/PR 与依赖升级记录为一手证据给出适配进度矩阵、三类迁移成本模型、可执行的兼容清单和分阶段升级节奏。在开始之前必须先把证据边界说清楚否则很容易读成一篇生态已就绪的通稿。先校准预期本文能证明什么不能证明什么本次整理的来源存在两个硬约束。第一所有条目的热度字段均为 0无法做热度排序或热度加权除一条 SeaTunnel 2.3.12 发布记录带有 2025-10-27 的明确时间戳外其余来源的发布时间字段基本为空[14]。因此本文不使用近期热议热度第一之类的表述适配潮仅指多个仓库在同一窗口内出现适配动作的证据密度不是热度或时间线结论。第二也是更关键的一点Issue 的存在只证明有人在做这件事不证明已经合入、已经发版、已经可用于生产。本文对证据统一做四级区分证据形态能证明什么不能证明什么功能/移植 Issue如 Gluten #11339已识别到兼容缺口或适配需求缺口已修复移植 PR如 Deequ #751适配工作正在进行已合入、已发布依赖升级 PR如 Drift #29有下游用户在试跑新版本生产可用打包/分发侧 PR如 macports #31673分发渠道在跟进上游官方支持状态正文中所有未由来源直接确认的信息是否合入、产出版本号、发布日期、GPU 支持矩阵、二进制兼容承诺一律标注⏳待核实并在文末汇总成待核实清单。发布前应逐条补齐未补齐的部分不能写成结论。一、适配全景谁在跟进跟进到哪一步1.1 四个核心项目的适配信号Apache Gluten执行计划兼容。仓库中已提出 Issue #11339标题为[VL] Support Spark 4.1.x[1]。VL 即 Velox 后端。Gluten 这类基于 Spark 物理计划做拦截与替换的项目对 Spark 版本最敏感Spark 升级往往会新增、拆分或重命名物理计划节点后端必须逐节点覆盖否则只能回退到原生执行或直接在计划校验阶段失败。该 Issue 当前状态、目标版本、是否覆盖 ClickHouse 后端均为 ⏳待核实[1]。Apache Iceberg流式规划器对接。PR #15299 标题为Spark 4.1: New Async Spark Micro Batch Planner[2]。这里有一个必须谨慎的定性问题从标题看它可能属于为适配 Spark 4.1 而对接新的异步微批规划器也可能是借助 Spark 4.1 的新能力做功能增强。两者叙事完全不同——前者意味着升级阻塞项后者意味着升级红利。该 PR 的性质、合并状态、落入的 Iceberg 版本号均为 ⏳待核实[2]。NVIDIA cudf-sparkGPU 算子白名单。仓库中同时出现两个信号Issue #14056Add support for Spark 4.1.1属于整体版本支持需求[3]Issue #14150[FEA] Support OneRowRelationExec introduced in Spark 4.1.x (SPARK-52060)属于具体物理算子的补齐需求[4]。后者尤其有代表性它直接指出 Spark 4.1.x 引入了新的物理节点OneRowRelationExec对应 SPARK-52060GPU 执行层需要为它增加支持。至于该节点未被支持时是回退 CPU 还是直接报错来源未说明⏳待核实[4]。需要说明的是这两个 Issue 的编号跨度较大仓库是否为 monorepo、编号是否从其他仓库迁移而来需在引用前到仓库主页核对⏳待核实。awslabs Deequ整体移植。PR #751 标题为Port to spark 4.1[5]。Deequ 是编译期绑定 Spark API 的数据质量库Spark 大版本升级通常需要整体重新编译与测试。该 PR 的合并状态与产出的 Deequ 版本号、Maven Central 上是否已有支持 Spark 4.1 的发行版⏳待核实[5]。1.2 外围与分发侧那些隐性跟随者除了四个核心项目还有几类动作值得放进视野因为它们往往是最容易被忽略的阻塞项。依赖机器人触发的跳跃式升级。AmadeusITGroup/Drift 的 PR #29 由 Dependabot 发起把 pyspark 从 3.5.2 升到 4.1.1[6]databrickslabs/geobrix 的 PR #16 把 Python 侧约束从4.0.0放宽到4.1.1[7]。前者跨了两个大版本号线这类 PR 的 diff 往往是隐性破坏点清单最好的来源如果连 CI 配置、测试代码都跟着改说明破坏面不小如果只改版本号说明该项目的测试覆盖可能不足以暴露问题。两个 PR 是否连带代码修改⏳待核实[6][7]。打包系统跟进。macports/macports-ports 的 PR #31673 标题为apache-spark2.4 through apache-spark4.2: new ports[8]。标题中的 “4.2” 含义存疑可能是端口命名也可能指向尚未被本文来源证实的版本序列。不能据此断言Spark 4.2 已发布⏳待核实[8]。生命周期视角。endoflife.date 维护有 apache-spark 的生命周期条目[9]。它是判断能等多久的依据之一当前生产版本的支持截止时间决定了观察期的上限。具体截止日期需到该条目核对⏳待核实[9]。1.3 适配进度矩阵下表是本文的核心交付物之一。所有状态列只反映来源证据强度不代表项目实际发布状态。项目证据证据类型适配切入点已知缺口/风险核实状态apache/gluten#11339 [1]IssueVelox 后端物理计划覆盖覆盖范围、是否含 ClickHouse 后端未知⏳待核实apache/iceberg#15299 [2]PR异步微批规划器对接性质适配 or 增强未定性⏳待核实NVIDIA/cudf-spark#14056 [3]Issue整体版本支持正式支持版本未知⏳待核实NVIDIA/cudf-spark#14150 [4]Feature Issue新算子OneRowRelationExec未支持时的回退行为未知⏳待核实awslabs/deequ#751 [5]移植 PR整体 Port产出版本号未知⏳待核实AmadeusITGroup/Drift#29 [6]依赖升级 PRpyspark 3.5.2 → 4.1.1diff 范围未知⏳待核实databrickslabs/geobrix#16 [7]依赖升级 PRpyspark 约束放宽至 4.1.1测试覆盖未知⏳待核实macports/macports-ports#31673 [8]打包 PR端口树新增“4.2” 含义存疑⏳待核实endoflife.dateapache-spark 条目 [9]生命周期数据支持窗口具体日期未核⏳待核实从这张表能得出的稳健结论只有一个多个独立仓库同时出现了针对 Spark 4.1.x 的适配动作覆盖计算加速、数据湖、数据质量、依赖管理、打包分发五类角色。这说明适配工作是真实且多点展开的但它不能说明任何单一组件已经可用。二、为什么会集中出现适配动作Spark 4.1 变了什么虽然来源没有提供 Spark 4.1 的官方变更日志但可以从适配动作反推出三类变更点。这是一种推断请与已核实事实区分。2.1 从 Issue 反推的三处变更点第一物理计划新增或变更了节点。cudf-spark #14150 明确提到OneRowRelationExec由 Spark 4.1.x 引入并关联到 SPARK-52060[4]。对于任何拦截物理计划的执行层GPU 后端、向量化后端、自研加速器物理节点集合的变化都是硬兼容点白名单里没有这个节点就意味着回退或失败。Gluten #11339 这种支持 Spark 4.1.x的宽口径 Issue大概率也包含同类工作[1]。SPARK-52060 的具体内容需查 Apache JIRA 与 Spark 4.1 release notes 核实⏳待核实。第二流式/微批规划接口发生了演进。Iceberg #15299 的标题直接指向New Async Spark Micro Batch Planner[2]。规划器接口的变化会影响流式写入的调度语义批间隔如何计算、checkpoint 何时提交、失败重跑是否幂等都是需要逐项验证的点。第三新的编程模型带来新的一致性问题。来源中出现了关于 Spark Declarative Pipeline 的独立文档与真实提问[10][11]。其中 Stack Overflow 上的问题在 availableNow 触发器下如何保证 Declarative Pipeline 中两个查询处理同一批行正是一致性语义的典型疑问[11]。需要注意该提问并未在来源标题中说明所用 Spark 版本因此只能作为Spark 流处理通用痛点引用不能归因于 4.1⏳待核实。2.2 三类迁移成本模型把上面的变更点抽象一下升级成本大致可以分三类每一类的排查手段和阻塞属性都不同。一、执行计划/算子兼容成本Gluten、cudf-spark 侧。特征是编译通过但运行期回退或报错因为问题出在计划节点匹配层。风险在于它可能是静默的任务跑得通但加速率从 80% 掉到 20%没有任何异常堆栈。这类成本必须用回退率指标来量化而不能只看任务成功与否。二、SQL 与语义兼容成本Iceberg、Declarative Pipeline 侧。特征是结果不对但不报错。规划器变化、触发器语义、时间语义、checkpoint 提交时机都会影响结果集的完整性与一致性。这类成本最隐蔽必须靠数据正确性校验兜底。三、依赖与二进制兼容成本Deequ、Drift、geobrix 侧。特征是构建期或类加载期直接失败反而最容易发现。典型问题包括 Scala 大版本后缀如 artifact 名中的_2.12/_2.13不匹配、JDK 支持范围变化、provided依赖冲突、Python 包装层对 py4j 与 Python 版本下限的要求变化。Spark 4.1 的 Scala 默认版本、JDK 支持范围与二进制兼容承诺来源未覆盖⏳待核实务必以官方文档为准。2.3 小项目依赖升级 PR 的启示Drift #29 与 geobrix #16 这类纯依赖升级看起来琐碎实则价值很高[6][7]。它们是第三方替你做的一次免费试跑如果 Dependabot 的 PR 只改了一个版本号就通过 CI说明该项目对 Spark 的使用面较窄或测试覆盖不足如果 CI 失败后 PR 长期挂着失败日志就是一份现成的不兼容清单如果 PR 连带修改了测试代码、CI 配置、文档中的版本要求说明破坏面已经外溢到工具链。建议在升级前把这类 PR 的 diff 与 CI 记录完整读一遍成本极低收益很高。同理macports #31673 这类打包 PR 的 diff 会暴露构建脚本层需要处理的版本、路径与依赖变化[8]。三、分项目迁移踩坑点这一节只讲会怎么踩、该怎么避不重复进度矩阵。3.1 GlutenVelox 后端算子覆盖与回退典型症状有三种执行计划校验阶段直接失败任务能跑但大量算子回退到原生执行性能不升反降。排查路径建议如下。先用EXPLAIN或 Spark UI 的 SQL 页看物理计划确认哪些节点被 Gluten 接管、哪些回退再在 Gluten 日志里检索 unsupported 相关关键字拿到未覆盖节点清单最后把清单与 #11339 声明的适配范围对照[1]。对不上就说明你的作业用到了该 Issue 范围之外的算子此时应把它当作已知缺口管理而不是当作 bug 反复重试。# 计划层排查骨架先看物理计划再看后端回退日志# 具体日志关键字与配置项以所用 Gluten 版本文档为准$SPARK_HOME/bin/spark-shell\--confspark.pluginsorg.apache.gluten.GlutenPlugin\--confspark.gluten.enabledtrue3.2 Iceberg运行时 artifact 与流式语义Iceberg 与 Spark 的耦合点通常落在iceberg-spark-runtime-*这类运行时 artifact 上其命名会随 Spark 大版本与 Scala 大版本变化。在 4.1 下应使用哪个 artifact 名、是否仍带 Scala 后缀来源未提供⏳待核实请以 Iceberg 官方 Getting Started 文档为准不要凭经验手写坐标。!-- 坐标占位模板artifact 名与版本号必须查官方文档后填写不猜 --dependencygroupIdorg.apache.iceberg/groupIdartifactId!-- 待核实对应 Spark 4.1 的 runtime artifact --/artifactIdversion!-- 待核实 --/version/dependency流式侧的验证重点是三项checkpoint 是否能在异常后正确恢复availableNow触发器下批次边界与行集合是否稳定可参考 SO 上关于两查询行一致性的提问[11]失败重跑是否产生重复写入。如果规划器对接改变了批间隔或提交时机这三项都会受影响[2]。3.3 cudf-sparkGPU 算子白名单与新节点GPU 栈的升级从来不是单点动作至少要对齐四件事Spark 版本、RAPIDS/cudf 版本、CUDA 运行时版本、GPU 驱动版本。具体支持矩阵必须查 NVIDIA 官方文档来源未提供任何版本对应关系本文不给出臆造矩阵。对OneRowRelationExec这类新节点验证方法很直接构造一个会触发该节点的最简查询例如不带表的常量投影查询观察它是被 GPU 接管、回退 CPU 还是失败⏳待核实其默认行为[4]。同时应统计一段时间内的回退率把它作为 GPU 栈升级成功与否的硬指标而不是只看任务成功率。3.4 Deequ 与数据质量链路Deequ 这类库在编译期绑定 Spark APISpark 大版本升级后必须重新编译因此能不能编过本身就是一道门槛。在 #751 对应的版本正式可用前[5]可行的过渡方案有两类一是把数据质量校验隔离在独立集群上继续跑旧版 Spark与主计算链路解耦二是临时降级校验范围只保留行数、非空率、唯一性等不依赖复杂 API 的基础检查。两种方案都要明确写下哪些检查暂时不生效避免质量覆盖率在升级窗口内无声下降。3.5 PySpark 侧Python 包装层Python 侧的升级约束容易被忽略。pyspark 包装层升级后至少要核对Python 解释器版本下限、py4j 版本配套关系、pandas/Arrow 互操作相关配置是否需要调整。这些内容必须查对应版本的官方 release notes来源未覆盖⏳待核实。Drift #29 把 pyspark 从 3.5.2 一步抬到 4.1.1[6]这类跨大版本跳跃尤其要检查 Python 环境而不是只改 requirements 文件。3.6 症状速查表症状可能根因排查动作关联证据物理计划校验失败新节点未被后端覆盖EXPLAIN 比对节点集合[1][4]GPU 加速率骤降但任务成功算子静默回退统计回退率、查后端日志[3][4]流式任务批次边界异常规划器/触发器语义变化检查 checkpoint 与批间隔[2][11]类加载或 NoSuchMethodError二进制不兼容、依赖冲突dependency:tree排查冲突[5][6][7]重跑产生重复数据任务重试与写入非幂等分区级 checksum 比对[13]Python 侧启动失败pyspark 与 Python/py4j 不匹配核对版本下限与配套关系[6][7]其中重跑产生重复数据一行并非理论风险Stack Overflow 上确有mapPartitions在任务重试时向 BigQuery 重复插入数据的真实提问[13]。它说明正确性风险在升级窗口内会被放大必须用校验兜底。四、升级前的兼容清单这是全文的核心交付物建议直接转成工单模板。4.1 依赖与构建矩阵升级前先锁定一张版本矩阵所有目标值填完才能进入试点。维度当前值目标值证据来源状态Spark / Spark-submit 环境待填待填官方 Downloads⬜Scala 大版本待填待核实Spark 官方文档⬜JDK 版本待填待核实Spark 官方文档⬜Gluten 版本待填待核实#11339 及 Releases[1]⬜Iceberg runtime artifact待填待核实官方 Getting Started⬜cudf-spark / RAPIDS 版本待填待核实#14056 及官方矩阵[3]⬜CUDA / GPU 驱动版本待填待核实NVIDIA 官方矩阵⬜Deequ 版本待填待核实#751 及 Maven Central[5]⬜pyspark / Python 版本待填4.1.1 线其余待核实[6][7]⬜依赖冲突排查可以先用下面的命令骨架拿到事实再决定是否需要 exclusion# 构建期看 Scala/Spark 相关依赖是否被意外传递mvn dependency:tree-Dincludesorg.scala-lang mvn dependency:tree-Dincludesorg.apache.spark# 运行期确认实际加载的 jar 与版本jar tf path/to/your.jar|grep-ispark|headspark-submit--version4.2 功能回归范围回归至少覆盖四类每类都要有明确用例来源。批处理 SQL业务 SQL 全量回放外加 TPC-DS 子集作为通用基准。子集规模按团队既有基准环境确定本文不虚构数字。流式微批模式、availableNow触发器、异常恢复、Declarative Pipeline若在用。重点验证批次边界与行集合稳定性[11]。数据湖读写Iceberg 的写入、快照读、compaction、schema evolution以及与旧版本混跑时的元数据兼容。数据质量校验Deequ 检查项全量比对确认升级后无静默降级[5]。4.3 数据正确性与幂等校验升级最容易出的不是崩溃而是静默错数。建议固定三层校验行数比对按分区比对升级前后结果表行数校验和比对对关键列做分区级 checksum能发现行数相同但内容漂移的情况幂等验证对同一批输入强制重跑两次确认结果一致。mapPartitions重试导致重复写入的案例说明任务重试与外部写入的幂等性必须显式验证[13]。4.4 性能基准与观测判断升级成功而不只是升级能跑需要固定三样东西固定数据集、固定 SQL 集、固定观测口径。对比指标至少包括 P50/P95 耗时、资源消耗executor 内存与 GC 时间、失败重试次数。GPU 栈额外增加两个指标算子回退率、GPU 利用率。基线数据应在升级前用旧版本采集避免事后补录。4.5 可勾选清单版本矩阵九项全部填满且每项目标值有官方来源依赖树中无重复或冲突的 Spark/Scala artifact批处理 SQL 全量回放结果一致流式三种触发模式各跑通一次含异常恢复Iceberg 读写、compaction、schema evolution 回归通过与旧版本混跑的表元数据兼容性已验证Deequ 检查项无静默降级行数、分区 checksum、幂等三项校验通过性能基线与升级后数据可对比无明显回退GPU 栈回退率已量化并达标回滚方案已写明并演练过一次双版本并行窗口与灰度维度已确定五、升级节奏建议观察期、试点、全量5.1 三阶段模板与放行信号观察期。这一阶段不改生产只做跟踪与预研。跟踪对象是四个核心项目的合入状态与首个正式版本而不是 Issue 创建时间[1][2][3][5]。同时查 endoflife.date 中当前 Spark 版本的支持截止时间[9]它决定了你能等多久。放行信号栈内所有阻塞组件都已有可用的正式版本且版本矩阵能填满。试点。选一条非关键链路最好同时覆盖 Iceberg 读写和一个加速后端把第四节的清单完整跑一遍。放行信号清单全绿且性能指标无不可接受的回退。全量。按集群或业务线灰度推进保留双版本并行窗口。放行信号灰度期内正确性校验持续通过且回滚演练有效。相对时间刻度可以用 T2 周、T6 周、T12 周这类模板表达具体周数由团队排期决定本文不提供绝对日期因为来源无法支撑任何时间断言。5.2 等谁的决策树判断阻塞项的思路很直接栈内是否使用 Gluten 或 GPU 加速cudf 系若是这两个通常是硬阻塞因为它们直接绑定物理计划[1][3][4]。栈内是否重度依赖 Iceberg 流式写入若是需等待规划器相关适配的明确定性[2]。栈内是否依赖 Deequ 等编译期绑定 Spark API 的库若是需等待对应移植版本发布[5]。若三项都否仅依赖纯批 SQL 与 PySpark升级风险相对可控可较早进入试点但仍需完成依赖矩阵与正确性校验。5.3 回滚与风险对冲回滚预案至少包含四件事镜像与依赖包的版本快照配置项差异清单数据层回滚策略回滚演练记录。其中数据层最容易被忽略——如果升级过程中写入了新格式的数据或变更了表格式版本回滚后旧引擎能否正确读取是必须提前验证的问题。Iceberg 表格式版本升级是否可逆来源未涉及⏳待核实务必在演练中实测不要假设。六、结语把追版本变成可管理的工程动作这轮适配动作给出的真正启示不是Spark 4.1 该不该升而是版本升级应当被当作一个有证据、有清单、有门槛的工程流程用证据分级管理预期用兼容清单管理风险用门槛信号管理节奏。Issue 只是信号合入与发版才是事实任务跑通只是下限数据正确与性能不回退才是及格线。6.1 待核实事实总表以下事项在发布前必须逐条补齐未补齐项在正文中保持⏳待核实。#待核实项建议渠道1Spark 4.1.x 的确切版本序列与发布日期Spark 官方 Downloads / Release notes2SPARK-52060 与OneRowRelationExec的变更细节Apache JIRA / Spark 4.1 release notes3Gluten #11339 的状态、目标版本、覆盖后端GitHub Issue 页、Gluten milestone4Iceberg #15299 的性质、合并状态、落入版本GitHub PR 页、Iceberg Releases5cudf-spark 仓库身份与 #14056/#14150 编号对应关系GitHub 仓库主页与 Issue 页6cudf-spark 对 Spark 4.1.1 的正式支持版本与 CUDA/驱动矩阵NVIDIA 官方文档7Deequ #751 状态与产出版本号GitHub PR、Maven Central8Spark 4.1 的 Scala 默认版本、JDK 支持范围、二进制兼容承诺Spark 官方文档9Icebergspark-runtimeartifact 命名与 Scala 后缀Iceberg 官方 Getting Started10macports #31673 中 “4.2” 的准确含义PR diff、macports 端口树11Drift #29 / geobrix #16 的 diff 是否连带代码修改GitHub PR diff12Spark 3.x 各版本的支持截止日期endoflife.date/apache-spark13SO #79866196 等问答发生时的 Spark 版本问题正文中的版本信息14Iceberg 表格式版本升级的可逆性官方文档 实测演练参考资料[1] [VL] Support Spark 4.1.x · Issue #11339 · apache/glutenGitHubhttps://github.com/apache/gluten/issues/11339[2] Spark 4.1: New Async Spark Micro Batch Planner · Pull Request #15299 · apache/icebergGitHubhttps://github.com/apache/iceberg/pull/15299[3] [FEA] Add support for Spark 4.1.1 · Issue #14056 · NVIDIA/cudf-sparkGitHubhttps://github.com/NVIDIA/cudf-spark/issues/14056[4] [FEA] Support OneRowRelationExec introduced in Spark 4.1.x (SPARK-52060) · Issue #14150 · NVIDIA/cudf-sparkGitHubhttps://github.com/NVIDIA/cudf-spark/issues/14150[5] Port to spark 4.1 · Pull Request #751 · awslabs/deequGitHubhttps://github.com/awslabs/deequ/pull/751[6] chore(deps): bump pyspark from 3.5.2 to 4.1.1 · Pull Request #29 · AmadeusITGroup/DriftGitHubhttps://github.com/AmadeusITGroup/Drift/pull/29[7] Update pyspark requirement from 4.0.0 to 4.1.1 in /python/geobrix · Pull Request #16 · databrickslabs/geobrixGitHubhttps://github.com/databrickslabs/geobrix/pull/16[8] apache-spark2.4 through apache-spark4.2: new ports · Pull Request #31673 · macports/macports-portsGitHubhttps://github.com/macports/macports-ports/pull/31673[9] endoflife.date/products/apache-spark.md · endoflife-date/endoflife.dateGitHubhttps://github.com/endoflife-date/endoflife.date/blob/master/products/apache-spark.md[10] rocket-ship/Spark Declarative Pipeline.md · shauryashaurya/rocket-shipGitHubhttps://github.com/shauryashaurya/rocket-ship/blob/main/Spark%20Declarative%20Pipeline.md[11] Ensure two queries in a Spark declarative pipeline process the same rows when using the availableNow triggerStack Overflowhttps://stackoverflow.com/questions/79866196/ensure-two-queries-in-a-spark-declarative-pipeline-process-the-same-rows-when-us[12] Spark job fails with UnsafeExternalSorter OOM when using groupBy collect_list sortStack Overflowhttps://stackoverflow.com/questions/79866787/spark-job-fails-with-unsafeexternalsorter-oom-when-using-groupby-collect-list/79895144[13] Java Spark mapPartitions retry causing duplicate inserts into BigQuery on task failureStack Overflowhttps://stackoverflow.com/questions/79905259/java-spark-mappartitions-retry-causing-duplicate-inserts-into-bigquery-on-task-f[14] Apache SeaTunnel 2.3.12 发布核心引擎升级、连接器生态再扩张2025-10-27 14:24Giteehttps://gitee.com/seatunnel/SeaTunnel/releases/tag/2.3.12