2026-06-08 ~ 2026-06-14
本周无公告
Wenchen Fan 提出 -1，原因是 Scala API 文档中意外泄露了生成的 proto java 类和内部 Types Framework ops 类，导致发布了非预期的公开 API。
Hyukjin Kwon 分享了四个基于 Spark Connect 的个人项目（ADBC、Scala3、Ruby 和 Wasm），旨在展示技术可行性并评估社区兴趣。David Li 和 Yang Jie 随后指出社区中已存在类似的 ADBC 驱动和 Scala3 支持项目，引发了关于项目整合的讨论。
@Hyukjin Kwon: 发布了 Spark Connect 的 ADBC、Scala3、Ruby 和 Wasm 客户端个人项目，目前无意合并，但未来可能讨论捐献给 Apache。
@David Li: 提到已有一个支持多后端（Connect/Thrift/Livy）的 Spark ADBC 驱动，提议合作开发统一的权威驱动。
@Yang Jie: 表示自己也有一个 Spark Connect Scala3 支持的本地项目。
针对项目重复问题，Hyukjin 建议目前保持各项目独立，待未来计划将代码移至 Apache 仓库时再讨论整合。
Nicholas Chammas 提议通过让 `.remote("local")` 默认在后台启动持久化 Connect 服务器，以消除本地开发循环中 SparkSession 约 3 秒的启动延迟。Serge Rielau 对此表示支持，但 Holden Karau 担心默认启动后台进程会违背用户预期（如崩溃后重启 Python 期望服务器也重启）。讨论核心在于如何平衡开发效率提升与用户对后台进程管理的预期。
@Nicholas Chammas: 建议让 `.remote("local")` 默认在后台创建持久化 Connect 服务器，并增加 CLI 工具（如 spark connect start/stop）进行管理，将启动时间缩短至 1 秒内。
@Serge Rielau: 强烈支持该提议。
@Holden Karau: 对默认启动持久化服务器持保留意见，担心用户在驱动崩溃后重启 Python 时预期服务器也会被终止，建议需谨慎处理默认行为和用户提示。
目前处于提案征集反馈阶段，尚未达成最终共识，后续需重点解决后台进程生命周期管理与用户预期不一致的问题。
讨论主要围绕 Spark 项目对 ASF 共享 GitHub Actions 资源的高消耗问题展开，基础设施团队要求降低使用量。Tian Gao 指出 Spark 已将周使用量降至 20 万分钟以下，符合限制要求。Ismaël Mejía 则提出了具体的优化方案，通过避免重复生成 TPC-DS 数据集来节省时间。
@Robert Thomson: 指出 Spark 是资源消耗大户，要求精简构建流程以缓解 ASF 共享 Runner 资源紧张的问题。
@Tian Gao: 汇报 Spark 周使用量已降至 20 万分钟以下，低于 Apache 的 25 万分钟限制。
@Ismaël Mejía: 提出通过避免每次基准测试重复生成 TPC-DS 数据集，每次运行可节省约 10 分钟。
社区已采取措施将使用量降至限制以下，并继续通过具体的代码优化（如 PR #5647）来进一步减少资源消耗。
讨论主要关于 OIDC 凭据传播的 SPIP 提案，Kousuke 计划于下周发起投票。Kousuke 与 Parth 确认双方的提案互补且独立，将分别解决不同的身份传播问题并并行推进。
@Kousuke Saruta: 计划下周对 SPIP 发起投票；指出 Parth 的方案解决非 Kerberos 凭据的即时问题，而自己的 SPIP 针对 per-user/per-session 身份传播，两者互不依赖。
@Parth Chandra: 同意双方独立推进，并准备在等待 SPIP 审查期间开展相关工作。
双方达成共识将独立并行推进各自的提案，Kousuke 将于下周对 SPIP 发起投票。
本次讨论围绕 DSv2 中列级 UPDATE 操作的写模式缩小提案（SPIP）展开。作者更新了设计文档以阐明该方案如何扩展支持 MERGE INTO 操作，并请求社区反馈。Anton 认可该方案的合理性及其对 Delta 和 Iceberg 的价值。
@Anton Okolnychyi: 认为该方案合理，支持泛化以兼容 MERGE 操作，且对 Delta 和 Iceberg 具有重要价值。
@Anurag Mantripragada: 已根据反馈更新 SPIP 文档，增加了关于未来支持 MERGE INTO 的设计说明，并请求更多反馈以便发起投票。
方案已获得初步认可，目前处于收集更多反馈阶段，下一步计划在完善后进行投票。
Parth Chandra 提议改进 Spark 的安全令牌分发机制，旨在解决当前机制在非 Kerberos 云环境下强制要求 Kerberos 设置的问题。提案建议增加一条无需 Kerberos 限制的路径，设计上保持向后兼容且改动最小。目前正等待社区提交者审查提案文档和 JIRA 并提供反馈。
@Parth Chandra: 当前机制即使对于不需要 Kerberos 的令牌（如 Kafka）也强制要求 Kerberos 设置，给云用户带来不必要的负担。
@Parth Chandra: 提议允许第二条分发路径，除非提供者明确指示，否则不经过 Kerberos 限制，且保持向后兼容。
@Peter Toth: 感谢提案并邀请社区成员提出其他问题或观点进行讨论。
提案已提交，目前处于征求社区反馈和审查阶段。
本周新建 0 个 Issue
本周无新建 JIRA。