【Spark 核心内参】2026.1：JIRA vs GitHub Issues 治理模式大讨论与 4.2.0 预览版首发
编者按
2026年的开篇，Spark 社区展现出了前所未有的变革活力。一方面，治理模式面临从传统的 JIRA 向现代 GitHub Issues 迁移的重大抉择，这不仅是工具的更替，更是社区开放度与治理效率的博弈；另一方面，Spark 4.2.0 预览版的发布以及关于 3.5 LTS 延长安全支持周期的深度辩论，彰显了社区在快速迭代与生产稳定性之间的平衡艺术。
航向追踪
Apache Spark 3.5.8
重要指数: ⭐⭐⭐
关键更新:
- 稳定维护：作为 3.5 LTS 分支的第八个维护版本，合入了自 3.5.7 以来累积的 34 个补丁。
- 质量基石：重点修复了正确性（Correctness）和安全性（Security）领域的关键问题。
主要影响: 为仍在使用 3.5 分支的生产用户提供更坚实的稳定性和安全保障，是目前生产环境的首选稳定版本。
相关链接:
- Official：https://spark.apache.org/releases/spark-release-3-5-8.html
- Download：https://spark.apache.org/downloads.html
编者按: 3.5.8 是生产环境的"定心丸"。值得关注的是，本次发布过程也验证了社区自动化发布流水线的改进补丁，这为后续的快速响应维护奠定了基础。
Apache Spark 4.2.0-preview1
重要指数: ⭐⭐⭐⭐
关键更新:
- 抢先体验：首个 4.2.0 预览版，旨在让社区尽早测试新功能并提供反馈。
- 演进窗口：提供了验证新 API 和内部架构变动的关键机会。
主要影响: 帮助开发者和下游库维护者识别潜在的回归问题，确保在正式版发布前达成生态兼容。
相关链接:
编者按: 预览版的发布频率加快，预示着 Spark 正在适应更高强度的发布节奏。作为架构师，我建议深度用户尽快在测试环境跑通现有作业，预览版反馈的质量将直接决定 4.2.0 的成熟速度。
前线研讨
4.0.2 发布计划与发布经理确认 (Release Apache Spark 4.0.2)
- 综合指数: ⭐⭐⭐⭐
问题现象: 自 4.0.1 标签创建以来，已有 82 个补丁合并入主干，包括多项正确性和安全性修复。
问题痛点: 4.0.x 分支目前的进度略滞后于预期，用户急需这些已合并的修复以增强生产信心。
预期和目标: 推进 4.0.2 版本的发布，计划在 2026 年 2 月初发布第一个 RC。
各方观点:
- Dongjoon Hyun: 提议发布并自荐担任发布经理。
- Wenchen Fan / Kent Yao / Hyukjin Kwon 等: 全票赞成 (+1)，支持快速交付。
编者按: 这是典型的版本协调过程，反映了社区对 4.0 系列稳定性的高度重视。82 个补丁的规模预示着 4.0.2 将是一个非常关键的修复版本。
LTS 支持周期延长之争 (Extend LTS release support period w/security fixes)
- 综合指数: ⭐⭐⭐⭐
问题现象: Holden Karau 提议将 LTS 版本的安全修复支持期在标准 bug-fix 期结束后再延长 24 个月。
问题痛点: 企业用户和云厂商（如 Databricks, Amazon）对 LTS 版本（如 3.5）的支持往往长达 5 年以上，社区官方窗口的关闭导致了安全维护的断层。
预期和目标: 将 3.5.x 的安全修复支持延长至 2027 或 2028 年，以对齐企业需求。
各方观点:
- Holden Karau: 强调延长支持能整合社区资源，减少重复造轮子。
- Dongjoon Hyun: 表达了担忧，认为如果没有明确的发布经理轮岗和 CI 维护计划，该提案过于脆弱。
- Steve Loughran: 支持但提醒安全修复是"尽力而为"，特别是涉及破坏性依赖更新时。
编者按: 这是一场关于"责任"的辩论。延长 24 个月听起来很美好，但谁来长期 review 安全补丁、谁来维护日益老旧的 CI 任务，是必须要解决的"阵痛"。
远程 Shuffle 存储项目的架构转向 (Remote Storage as a Shuffle Store)
- 综合指数: ⭐⭐⭐⭐⭐
问题现象: 原有的原生远程 Shuffle 存储提案在社区遇到阻力。
问题痛点: 社区担心与现有项目（如 Celeborn, Uniffle）功能重叠，且直接修改 Spark 内核实现该功能过于复杂。
预期和目标: 寻找更务实的阶段性替代方案或架构演进方向。
各方观点:
- Karuppayya: 承认原有提案受阻，但重申原生低开销方案的价值。
- Wenchen Fan: 提出了一个关键的差异化思路：增加一个同步的、与 AQE 集成的"Shuffle 整合阶段"（Shuffle Consolidation Stage）。
- Mridul Muralidharan: 认为显式的 sort stage 变动过大，需谨慎权衡。
编者按: 这是一个架构层面的重大转向。相比"暴力"接入远程存储，利用 AQE 在运行时动态决策是否进行"Shuffle 整合"，能更优雅地解决小文件 I/O 痛点，这才是真正具有 Spark 基因的优化路径。
方案思辨
治理模式转型：从 JIRA 迈向 GitHub Issues (SPIP: Migrate from JIRA to Github issues)
核心动机: 降低贡献者的参与门槛。目前 JIRA 账号申请需 PMC 手动审批，常导致新人的贡献热情被流程阻断；同时寻求与 GitHub 生态更紧密的自动化集成。
关键设计: 提议全面停用 JIRA 转而使用 GitHub Issues。设计中包含一个"双轨并行"阶段，用于观察 committer 的使用习惯并完善配套的自动化脚本（如 PR 关联、发布日志生成）。
影响价值: 显著提升社区反馈效率，降低参与门槛，提供更现代的 MD 支持和交互体验。
相关链接
社区探讨:
- 赞成观点: Tian Gao 等人认为 GitHub 的 UI/UX 远超 JIRA，且能统一认证体系。
- 反对观点: Dongjoon Hyun 警告此举可能引入大量 AI 生成的低质量内容（AI slop），且会抛弃已沉淀多年的治理经验和脚本。
- 其他观点: 讨论尝试达成折中方案，如先开放 GitHub Issues 作为预讨论区，而不立即废除 JIRA。
编者按: 这是 Spark 治理模式的分水岭。JIRA 虽然陈旧但可控，GitHub 虽然现代但面临治理压力。这场讨论反映了项目在成熟期如何通过改进工具链来焕发社区活力。
Catalog 支撑的代码字面量函数 (SPIP: Catalog-backed Code-Literal Functions)
核心动机: 解决 Spark 无法以标准方式从外部 Catalog 加载 SQL/Python 函数体的问题，减少对会话级注册的依赖。
关键设计: 引入 CodeLiteralFunctionCatalog Java SPI。SQL 函数支持解析并内联；Python/Pandas 函数通过现有 UDF 运行时执行，并支持在 spec 中声明环境约束（如 pythonVersion）。
impact_value: 规范化了跨 Catalog 的函数管理，增强了自定义逻辑的可移植性和治理能力。
相关链接
编者按: 这是 DSv2 迈向成熟的重要一步。将 SQL/Python 函数视为 Catalog 中的一等公民，极大地方避了在共享环境中部署复杂业务逻辑的难度。
Spark Connect 的网络延迟优化 (SPIP: Asynchronous Metadata Resolution & Lazy Prefetching)
核心动机: 修复 Spark Connect 中因 eager analysis 导致的性能退化。频繁的元数据查询（如 df.columns）在网络延迟高的情况下会成为瓶颈。
关键设计: 引入客户端元数据跳过层（Metadata Skip-Layer），包括计划捎带（Plan-Piggybacking）、本地 Schema 缓存以及批量解析 API。
影响价值: 确保 Spark Connect 拥有与 Classic 模式一致的流畅交互体验，实测在复杂迭代流中可提升 50 倍以上性能。
相关链接
编者按: 对于 Connect 架构的生产化落地至关重要。消除了"1000 次 RPC 之死"，Connect 才能真正承载起大规模 ETL 框架（如 Great Expectations）的运行。
生态拓扑
Apache Spark Kubernetes Operator 0.7.0
重要指数: ⭐⭐⭐
关键更新:
- 同步演进：与 Apache Spark 4.1.1 完美对齐。
- 运维增强：提升了在 K8S 环境下管理 Spark 应用的稳定性和易用性。
主要影响: 强化了 Spark 的云原生叙事，是容器化大规模部署的首选工具。
相关链接:
编者按: Operator 的成熟是 Spark 生态向云原生转型的标志。
Apache Spark Connect Swift Client 0.5.0
重要指数: ⭐⭐⭐
关键更新:
- 语言边界扩张：发布 Swift 客户端，进一步落实 Connect 的多语言愿景。