Spark 社区周报

💬 讨论 (5)

2 条回复 · 3 位参与者

ASF 基础设施团队因共享 GitHub Actions 资源池过载，要求 Spark 项目作为资源消耗大户减少构建时间和并发数。Spark 贡献者回应称项目用量已降至 Apache 限额以下并询问合规性，同时有成员指出未来需求将激增，仅靠节约策略可能不足。

@Robert Thomson: 因共享 Runner 资源池接近极限，要求 Spark 项目优化构建流程、减少并发或考虑使用自托管运行器。

@Tian Gao: Spark 过去一周用量已降至 20 万分钟（低于 25 万限额），询问当前状态是否已符合要求。

@Allen Geer: 预测 CI 需求将随新工具应用指数级增长，认为仅呼吁减少使用不足以解决问题，建议采取不同策略。

目前尚无明确结论。Spark 虽已将用量降至硬性限额以下，但仍需确认是否满足基础设施团队针对“顶级消费者”的整改要求，且社区需评估未来应对资源压力的长期策略。

0 条回复 · 1 位参与者

讨论主要围绕 Spark 4.2.0 RC1 的发布进度展开。此前阻塞发布的 DSv2 事务修复问题（SPARK-56695 和 SPARK-56995）已解决并回移植。Huaxin Gao 计划即刻启动 RC1 构建，并询问是否还有其他遗留的阻塞问题。

@Huaxin Gao: 宣布阻塞发布的 DSv2 事务修复已完成回移植，计划当天构建 RC1。

@Anton Okolnychyi: 确认相关修复方案已达成一致，相关工作将迅速收尾。

@Huaxin Gao: 此前 RC1 构建因等待 SPARK-56695 和 SPARK-56995 的修复而推迟。

初步结论是阻塞问题已全部解决。下一步行动是 Huaxin Gao 将立即着手构建 Spark 4.2.0 RC1。

0 条回复 · 1 位参与者

讨论确认了两个 OIDC 凭据传播提案互补且独立，可并行推进。Parth 同意各自独立开展工作，并将着手准备相关实现，同时等待 SPIP 审查。

@Kousuke Saruta: 两个提案互不依赖，Parth 的方案解决非 Kerberos 凭据的燃眉之急，而自己的 SPIP 针对每用户/会话身份传播，两者互不阻塞。

@Kousuke Saruta: 鉴于 Spark Connect 多租户的新需求，需改变 Spark 与 UGI 的交互方式，不再沿用旧有逻辑。

@Parth Chandra: 同意双方独立进行，将在等待 SPIP 审查期间先行准备相关内容。

双方达成共识，将独立并行推进各自的提案，互不阻塞。

0 条回复 · 1 位参与者

讨论主要关于 PySpark 捆绑的 Netty 和 ZooKeeper 依赖因存在 CVE 漏洞被企业安全扫描器拦截的问题。维护者确认已在开发分支完成升级，但未回移至 branch-4.x，理由是这些漏洞不影响 Spark 本身，属于误报。

@Alam, Shahnoor: PySpark 捆绑的旧版 Netty 和 ZooKeeper 触发了高危 CVE 警报，导致企业级 Docker 镜像构建失败，请求升级依赖版本。

@Hyukjin Kwon: 相关依赖已在 dev 分支通过 PR #56373 升级，但未回移至 branch-4.x，因为这些漏洞对 Spark 本身无直接影响，属于误报。

开发分支已解决该问题，但维护者目前不打算将其回移到 branch-4.x 及更早版本。

0 条回复 · 1 位参与者

讨论主要围绕 PySpark 中 Netty 和 ZooKeeper 依赖的升级请求，旨在解决企业安全扫描发现的 CVE 问题。Shahnoor 询问特定 PR 是否已覆盖相关漏洞及补丁发布时间，而 Hyukjin Kwon 反对在未进行适当评估的情况下盲目升级旧分支的依赖。

@Hyukjin Kwon: 反对在未进行适当评估的情况下盲目升级旧分支的依赖，认为仅列出 CVE 列表是不够的。

@Alam, Shahnoor: 询问特定 PR (#56373) 是否解决了列出的 CVE，并希望确认补丁发布时间以满足企业容器安全合规要求。

暂未达成一致，Hyukjin 计划稍后抽出时间查看，但明确表示需要先进行适当评估，反对盲目升级。