航向追踪
Apache Spark 4.1.0-preview4 发布
Spark 4.1.0-preview4相比Spark 4.1.0-preview3的核心变化：
- Python 兼容性升级： 新增并完善了对 Python 3.14 的支持，确保 PySpark 紧跟最新语言标准。
- Spark Connect 增强： 进一步完善 Connect 生态，重点增强了 JDBC Driver for Spark Connect 的功能与可用性。
- SQL 与数据源优化： 标准化了 GEOGRAPHY、TIME 等新数据类型，并加强了 Data Source V2 的约束（Constraints）支持。
- 流计算实时性： 针对 Structured Streaming Real-Time Mode 进行了重点优化，提升流处理在低延迟场景下的表现。
- 稳定性冲刺： 作为正式发布前的最后预览版，集中修复了大量关键 Bug，为 Release Candidate (RC) 奠定基础。
前线研讨
Spark Scala 3支持路径：从核心重构转向独立Connect客户端的架构定调
现象与痛点
- 背景
- Spark 项目中使用的 antlr4-runtime 库面临版本升级与兼容性挑战。发起人 Vlad 指出，ANTLR 4 是生态系统中极为通用的基础库（例如 Hive 3.x 和 4.x 均重度依赖）。
- 痛点
- 破坏性变更：ANTLR 4.10+ 版本与 4.9 版本不符合语义化版本（Semver）兼容性原则。
- 运行时异常：当类路径（Classpath）中混合不同版本的 ANTLR（如 4.9.3 与 4.10）时，会抛出 java.io.InvalidClassException，具体表现为 ATN（Augmented Transition Network）序列化版本不匹配（Expected 4, got 3）。这导致 Spark 在集成第三方库时极易发生"依赖地狱（Dependency Hell）"。
预期与目标
发起人（Vlad）初衷：通过 Shade（及 Relocation） 技术，将 Spark 内部使用的 antlr4-runtime 进行隔离。目标是彻底规避 Spark 自身依赖与用户环境或第三方库（如 Hive）中存在的 ANTLR 版本冲突。
关键利益方期望：
稳定性：确保 Spark 能够安全升级 ANTLR 版本而不破坏下游生态。
扩展性：Spark SQL 的扩展开发者（编写自定义解析器或关键字插件的人）依然能够顺利开发，不受依赖隔离的负面影响。
各方见解
- Vlad （发起人）：
- 核心论点：必须对 antlr4-runtime 进行 Shade 处理。
- 技术依据：ANTLR 4.10 引入了不可逆的二进制不兼容（ATN 版本变更）。由于 Hive 等重磅组件也依赖此库，若不隔离，用户在混合使用时必然遭遇崩溃。
- 解决方案：通过 Maven Shade Plugin 重命名包路径，使 Spark 拥有独立的 ANTLR 运行时副本。
- 对扩展性的回应：针对 Sem 的担忧，他明确表示，如果下游只需要扩展 Spark SQL，他们应当直接引用 Spark 提供的 Shaded ANTLR classes（即重命名后的包），而不是原生的 org.antlr.* 包。
- Sem (社区成员)：
- 潜在风险预警：关注 Spark SQL 扩展性（Extension）场景。
- 具体疑问：如果实施 Shade，现有的开发模式是否会受阻？具体来说，开发者在添加新关键字时，通常将 ANTLR 标记为 provided。Shade 之后，这种依赖引入方式是否失效？
总结复盘
- 核心共识：
- ANTLR 的版本不兼容问题是客观存在的严重隐患，Shade 是解决此类传递性依赖冲突的必要手段。
- 虽然 Shade 会改变下游插件开发的依赖路径（包名变更），但这是为了系统整体稳定性必须付出的代价。
- 后续行动 (Next Steps)：
- 推进 JIRA：继续推进 SPARK-53753 的代码合并。
- 开发指引更新：需要明确告知 Spark SQL 插件开发者，未来在扩展语法时，需引用 Spark 内部重定位（Relocated）后的 ANTLR 类，而非开源社区版原名类。
- 遗留风险：
- 迁移成本：现有的 Spark SQL 扩展插件如果依赖了原生的 org.antlr 包，在升级到该版本 Spark 时将无法通过编译或运行，需要修改代码以适配新的 Shaded 包名。这属于 Breaking Change。
方案思辨
告别 ESS：基于 Remote Storage 的 Spark Shuffle 下一代架构解析
核心动机
- 项目背景：Spark 传统的 Shuffle 机制诞生于物理机和本地磁盘时代，遵循"移动计算比移动数据更经济"的准则，强依赖计算节点的本地存储 。
- 核心痛点：在云原生和 K8s 环境下，现有架构面临"不可能三角"（低成本、高可靠、高性能）的困境 ：
- 动态分配悖论：Executor 缩容会导致其本地 Shuffle 数据丢失，迫使系统维持"僵尸执行器"以充当数据服务器，造成资源浪费 。
- 存储容量瓶颈：本地磁盘受限，在大规模 Join 场景下频繁触发 No space left on device 错误 。
- 稳定性隐忧：Spot 实例（竞价实例）的随机回收会导致严重的 FetchFailedException 和级联重算，影响作业 SLA 。
- 问题核心：如何在不引入复杂第三方 RSS 集群的前提下，利用云原生对象存储（如 S3/GCS）实现 Shuffle 数据的彻底存算分离 。
关键设计
本方案通过 ShuffleVault 抽象与 Shuffle Consolidation Stage 协作，实现了与 Spark 核心调度器的深度集成：
- ShuffleVault 接口：定义了统一的远程存储语义，负责路径隔离、生命周期管理（自动清理残留数据）以及安全凭证集成 。
- Shuffle Consolidation Stage (SCS)：这是最具颠覆性的设计。为了避免直接写 S3 导致的小文件 IO 延迟和限流问题，在 Map 和 Reduce 之间插入了一个显式的"整理"阶段 ：
- 合并逻辑：Consolidation Task 将成百上千个微小数据块合并为较大的对象（如 100MB），并将随机写转为顺序写 。
- 读取优化：Reduce Task 通过 HTTP Range Read 精确读取合并文件中的特定偏移量，提高 IO 效率 。
- AQE 强力加持：由 Wenchen Fan 提出，利用 Adaptive Query Execution 动态决策是否启动 SCS 。若 Shuffle 数据量极小，可跳过 SCS 以降低延迟；若存在数据倾斜，则由 AQE 指挥 SCS 进行智能分片 。
影响价值
- 系统效率与稳定性：
- 消除级联重算：由于 Shuffle 数据持久化在对象存储中，计算节点失效不再导致重算，大幅提升了长作业的SLA（稳定，可靠，准时）。
- 极致弹性：支持激进地使用 Spot 实例，且任务完成后可立即释放 Executor，彻底消除了"僵尸执行器" 。
- 运维与开发体验：
- 运维零负担 (Ops-Free)：相比 Apache Celeborn 等需要自建 master/worker 的 RSS 方案，该方案直接利用全托管的云存储，无需维护额外集群 。
- 可观测性增强：Shuffle 数据以标准文件形式存在于 S3 上，方便开发者直接下载分析倾斜和分布情况 。
社区探讨
- 赞成观点与核心论据：
- 云原生必然性：Karuppayya (AWS) 强调存算分离是终局，利用现有的 Hadoop FS API 是最具普适性的方案 。
- 架构简洁性：内置于 Spark Core 比引入外部中间件（如 RSS）具有更小的故障域 。
- 动态控制：Enrico Minack 认为这能解决 K8s 动态分配的顽疾。
- 反对/质疑观点与担忧点：
- 延迟回退：Enrico 和部分用户担心增加 SCS 阶段会导致交互式查询的端到端延迟增加。
- 大文件读取风险：Rishab Joshi 担心文件过大时，连接中断会导致重新读取，建议设置文件大小上限并增加压缩选项。
- 线程池压力：Ángel Álvarez Pascua 提出需关注该方案对 Netty 传输线程及执行器内存压力的具体影响。
- 共识形成：
- 自适应机制：明确方案为"可选项"，由 AQE 决定是否启用，从而在小作业中回退到传统模式 。
- 分阶段实施：Phase 1 聚焦稳定性，Phase 2 深度集成 AQE，Phase 3 探索 S3 Select 等高级特性 。
- 拥抱竞合：该方案定位为云原生/Serverless 场景的最佳实践，与 Celeborn 等 RSS 方案在生态中长期共存 。
生态拓扑
Apache Spark Kubernetes Operator 0.6.0发布
https://github.com/apache/spark-kubernetes-operator/releases/tag/0.6.0
Apache Spark Kubernetes Operator 是一种云原生控制平面，它将 Spark 作业和集群抽象为 Kubernetes 的自定义资源（CRD），从而实现通过标准 K8s 工具链自动化部署、管理及扩展 Spark 应用。
- 兼容性扩展：全面支持 K8s 1.32-1.34 以及 Spark 3.5、4.0 和 4.1预览版。
- 核心功能增强：CRD 升级至 v1 正式版，SparkCluster 新增 HPA 自动伸缩支持。
- 生态与示例：正式上线 Artifact Hub，新增 Apache Iceberg 集成及 StatefulSet 部署示例。
- 架构升级：构建环境与 CI 流程全面升级至 JDK 25。