【Spark 核心内参】2026.3：Auto CDC 声明式增量视图提案引爆社区，AI 代码自动化防御网关提上日程

【Spark 核心内参】2026.3：Auto CDC 声明式增量视图提案引爆社区，AI 代码自动化防御网关提上日程

航向追踪

Apache Spark 4.2.0-preview3

重要指数: ⭐⭐⭐⭐

关键更新:

• 释出 4.2.0-preview3 供社区进行广泛测试。
• 包含了对 Variant 类型支持的改进。

主要影响: 允许社区在 4.2.0 正式版发布前测试主要特性和 API。

相关链接:

• Download：https://dist.apache.org/repos/dist/release/spark/spark-4.2.0-preview3

编者按: 这是大版本切割前关键的压测窗口，特别提到了对 Variant 类型的增强，标志着 Spark 对非结构化数据处理能力的进一步下沉。

前线研讨

锁定 PySpark 依赖防范供应链攻击 (Pinning PySpark dependencies?)

• 综合指数: ⭐⭐⭐⭐

问题现象: 针对近期频发的 PyPi 恶意包事件，讨论是否通过锁定 PySpark 依赖版本来降低供应链攻击风险。

问题痛点: 严格锁定依赖可能会导致一直使用旧版 PySpark 的用户面临难以解决的依赖冲突。

预期和目标: 找到一个平衡点，例如提供一个可选的依赖约束文件 (constraints.txt)。

各方观点:

• Holden Karau: 担忧供应链安全，建议提供可选的依赖锁定。
• Tian Gao: 对框架级别锁定依赖持怀疑态度。

编者按: 在“防范攻击”与“生态兼容”之间走钢丝。对于像 Spark 这样的基石级组件，强制锁定依赖无疑是灾难性的，但提供官方验证过的“安全基线”约束文件，是一种非常务实的中间路线。

移除对 PyPy 的支持 (Drop support for pypy)

• 综合指数: ⭐⭐⭐

问题现象: 提议正式放弃对 PyPy 的支持。

问题痛点: PyPy 缺乏维护，相关的 CI 长期失败，且上游核心库如 NumPy 和 PyArrow 均已放弃支持。

预期和目标: 将宝贵的 CI 资源重新分配给更主流的 CPython 平台。

各方观点:

• Ruifeng Zheng: 赞同放弃，指出由于依赖缺失，PyPy 在 Spark 中的测试覆盖率其实已经极低。

编者按: 这是生态演进的自然淘汰。随着 CPython 自身的性能优化（如 3.11+ 的专项提速）以及生态库向 Rust/C++ 的底层收敛，PyPy 的历史使命在数据工程领域正走向终结。

在 V2 DataSource 中实现高吞吐覆盖写入 (Implementing SaveMode.Overwrite in my v2 DataSource)

• 综合指数: ⭐⭐⭐

问题现象: 开发者在为 MonetDB 构建 V2 DataSource 时，发现默认的 JDBC 写入性能极差。

问题痛点: 默认的 JDBC 写入采用单条 INSERT 语句，对于分析型数据库而言吞吐量极其低下。

预期和目标: 期望利用 DataSource V2 API 实现原生的 COPY BINARY INTO 以实现批量加载。

各方观点:

• Mich Talebzadeh: 解释了 Spark 内部使用 JDBC Connector 时的逐行拉取/写入限制。

编者按: 这揭示了为什么大厂都要自己写原生的 Connector，而不是凑合使用 Generic JDBC。DataSource V2 API 的核心价值正是在于允许底层存储接管物理 IO，从而实现如 COPY INTO 般的降维打击。

寻求 PR 跟进流程的建议 (Seeking advice on PR follow-up process)

• 综合指数: ⭐⭐⭐

问题现象: 贡献者不知道如何推动一个停滞的 PR。

问题痛点: 原作者或维护者不活跃时，PR 容易被淹没。

预期和目标: 寻求合适的渠道请求代码评审。

各方观点:

• Mich Talebzadeh: 建议使用 dev@ 邮件列表而非 user@ 来跟进 PR 状态。

编者按: 社区协作的“暗知识”。了解并遵守 Apache 社区的运转潜规则，往往比写出优秀的代码更能决定 PR 的存活率。

GSoC 2026: Spark Connect 客户端元数据缓存项目 (GSoC 2026 Applicants for Client-Side Metadata Caching)

• 综合指数: ⭐⭐⭐

问题现象: 多位 Google Summer of Code (GSoC) 学生为 SPARK-55163 项目提交提案并进行自我介绍。

问题痛点: 需要协调多位申请人并为他们的初期 PoC PR 提供反馈。

预期和目标: 评审提案并指导初期 PR 开发。

各方观点:

• 暂无。

编者按: Spark Connect 正在成为吸引新一代开发者的重镇。客户端元数据缓存将是降低 Connect RPC 开销的关键战役，期待年轻血液能带来不一样的解法。

方案思辨

为 Apache Spark 引入 Auto CDC 支持 (SPIP: Auto CDC support for Apache Spark)

核心动机: 彻底改变开发者消费 CDC 数据并应用到目标表的复杂现状，避免手写极易出错的 MERGE 语句。

关键设计: 在 Spark SQL 和 Python 中引入声明式的 Auto CDC 数据流原语，底层自动处理 SCD Type 1/2 逻辑和流式乱序数据。

影响价值: 大幅降低湖仓一体架构中数据入湖的工程复杂度。

相关链接

• Google Doc：https://docs.google.com/document/d/1Hp5BGEYJRHbk6J7XUph3bAPZKRQXKOuV1PEaqZMMRoQ

社区探讨:

• 赞成观点: Shixiong Zhu (Proposal Shepherd) 表示，他在实际场景中看到太多因为手写 MERGE 逻辑处理乱序数据而导致的线上事故，这一抽象极其必要；DB Tsai 也表达了强烈支持 (+1)。
• 反对观点: 暂无。
• 其他观点: 暂无。

编者按: 湖仓建设的圣杯级特性。让计算引擎原生理解 CDC 语义，标志着 Spark 正在从“单纯的计算引擎”向“端到端数据集成平台”进行范式跃迁。

升级 Apache Hive 依赖至 4.x (SPIP: Upgrade Apache Hive to 4.x)

核心动机: 使 Spark 与最新的 Hadoop 生态系统版本对齐，享受 Hive 4.x 的稳定性和新特性。

关键设计: 将 Spark 内置的 Hive 依赖版本跃升至 4.x。

影响价值: 保证了现代数据栈的兼容性，但必须妥善处理新的 Metastore Schema 变更。

相关链接

• Google Doc：https://docs.google.com/document/d/1ejaGpuBvwBz2cD3Xj-QysShauBrdgYSh5yTxfAGvS1c

社区探讨:

• 赞成观点: 暂无。
• 反对观点: 暂无。
• 其他观点: 开发者分享了在实际升级中的踩坑经验，特别指出了 Hive 4 Metastore 事务计数器表（如 NEXT_TXN_ID, NEXT_LOCK_ID）损坏导致的死锁假象。

编者按: 基础设施升级的真实写照。虽然外界热炒现代湖仓格式，但大量企业依然在旧有 Hive Metastore (HMS) 上苟延残喘，兼容并平滑过渡是 Spark 无法推卸的责任。

Apache Spark 自动化完整性校验 (AIV) 门控 (SPIP: Automated Integrity Validation (AIV) Gate for Apache Spark)

核心动机: 保护代码库免受大量含有结构性缺陷的 AI 生成代码（AI Slop）的冲击，减轻维护者负担。

关键设计: 在 CI 管道中实现基于 AST（抽象语法树）的解析器，以确定性的方式拦截 AI 幻觉导致的结构错误。

影响价值: 防止低质量代码合入内核，降低 Reviewer 倦怠。

相关链接

• Google Doc：https://docs.google.com/document/d/1-PCSq0PT_B45MbXVxkJ_E3GUHvK-8VV6WxQjKSGEh9o

社区探讨:

• 赞成观点: 暂无。
• 反对观点: 暂无。
• 其他观点: 暂无。

编者按: AI 辅助编程的双刃剑终于逼迫基础软件社区祭出硬核防御手段。这是开源治理在后 LLM 时代的一次重要进化，AST 校验门控或许将成为未来各大名源项目的标配。

变更数据捕获 (CDC) 支持接口 (SPIP: Change Data Capture (CDC) Support)

核心动机: 为 Spark 统一和标准化 CDC 日志的表达方式，抹平底层存储差异。

关键设计: 确立基于“格式-版本”的变更边界语义（例如 Iceberg 的 snapshot ID 或 Delta 的 log version）。

影响价值: 为前文提到的 Auto CDC 以及外部工具提供了一致的底层读取抽象。

相关链接

• Google Doc：https://docs.google.com/document/d/1-4rCS3vsGIyhwnkAwPsEaqyUDg-AuVkdrYLotFPw0U0

社区探讨:

• 赞成观点: 暂无。
• 反对观点: 暂无。
• 其他观点: Mich Talebzadeh 提示 CDC 有多种层面（时间、LSN、版本），而此提案偏向版本；Anton Okolnychyi 澄清该提案原生支持基于时间戳范围和通用版本概念。

编者按: 与 Auto CDC (下游消费) 遥相呼应，这是上游数据吐出的基建提案。将 CDC 抽象为一种 Data Source V2 能力，彻底统一了流式读取与增量批处理的边界。

延长 Spark 3.5 LTS 版本的安全修复支持期 (SPIP: Extending Spark 3.5 LTS Period With Security Fixes)

核心动机: 支持那些由于生态链尚未完全向 4.x 迁移，而无法快速升级的大型企业用户。

关键设计: 破例延长 branch-3.5 的长期支持 (LTS) 窗口，但在此期间仅接收安全补丁。

影响价值: 为维护旧有环境的企业提供了至关重要的稳定性与安全兜底。

相关链接

• Google Doc：https://docs.google.com/document/d/15fb-7DNztzpQMF1MQovK75UmpC6um7KgO8cg_X5oa1I

社区探讨:

• 赞成观点: Holden Karau 表示支持，并指出虽然依赖 3.5 的周边项目会慢慢减少，但这将是一个平缓的过渡期，一如当年的 Spark 2.4。
• 反对观点: 暂无。
• 其他观点: 暂无。

编者按: 致敬当年坚挺了数年的 Spark 2.4。大版本的切换永远伴随着阵痛，提供超长待机的安全补丁支持，体现了 Apache 顶级项目对企业用户的责任担当。

生态拓扑

Apache Spark Kubernetes Operator 0.8.0

重要指数: ⭐⭐⭐

关键更新:

• 引入了重要的 Spark 资源安全增强功能 (SPARK-55100)。

主要影响: 提升了在 Kubernetes 集群上运行多租户 Spark 负载的安全管理与资源隔离能力。

相关链接:

• Official：https://s.apache.org/spark-kubernetes-operator/
• GitHub：https://github.com/apache/spark-kubernetes-operator/releases/tag/0.8.0

编者按: 随着 K8s 逐渐成为 Spark 部署的绝对主流，云原生环境下的多租户安全隔离问题被推向台前。0.8.0 版本补齐了这一云原生拼图上的关键安全短板。

Apache Auron (Incubating) v7.0.0

重要指数: ⭐⭐⭐

关键更新:

• 发布 v7.0.0 大版本，为中间数据（如 Shuffle 数据、Spill 数据）提供高弹性、高效率的存算分离服务。

主要影响: 显著改善 Spark 在处理大规模 Shuffle 时容易出现的性能瓶颈和稳定性问题。

相关链接:

• Download：https://auron.apache.org/archives/v7.0.0-incubating.html

编者按: Remote Shuffle Service (RSS) 赛道持续火热，Auron (前身为 Celeborn) 的迭代为解决 Spark 架构中最令人头疼的 Shuffle 可靠性问题提供了强有力的生态武器。