💬 讨论 (10)
12 条回复 · 8 位参与者
讨论主要围绕 FLIP-577 提案，旨在通过引入多模态类型系统、RpcOperator 及增强的 Checkpoint 机制，使 Flink 成为 AI-Native 的数据处理基础设施。虽然部分开发者对提案范围和功能打包方式提出质疑，但核心贡献者澄清了 Flink 定位于 AI 数据基础设施而非 AI 框架，并强调了其在容错和流式处理方面相比 Ray/Daft 的独特优势。
@Guowei Ma: 澄清 'AI-Native' 意指原生支持 AI 数据处理中的核心对象（如 Tensor）与执行模式（如推理），而非将 Flink 变为 AI 框架；强调 Flink 相比 Ray/Daft 在容错方面的结构性优势。
@Martijn Visser: 担忧该提案将不相关的引擎改进打包，认为 RpcOperator 属于服务编排（应由 K8s 处理），并指出 Flink 功能矩阵已显稀疏，担心进一步恶化开发体验。
@Zhu Zhu: 阐述 RpcOperator 的核心价值在于故障隔离与独立扩缩容，解释为何将其内置于 Flink 运行时而非外置给 K8s Operator。
提案人将在下一版修订中明确层级依赖关系与 API 覆盖范围，并可能拆分 SQL/Table 相关子提案；社区将继续讨论 RpcOperator 的具体实现细节及 Checkpoint 机制的改进方案。
3 条回复 · 4 位参与者
Flink 2.3 发布准备期间发现压缩文件基准测试出现约 10% 的性能回退，经排查是由升级 lz4-java 修复 CVE 引入。社区评估了 ZSTD 或 aircompressor 等替代方案，认为无法有效解决性能问题。最终决定接受该回退，不将其作为发布的阻碍项。
@Hao Li: 确认性能回退由 lz4-java 升级修复 CVE 引起，询问是否应将其作为 Flink 2.3 发布的阻碍项。
@Piotr Nowojski: 分析认为 AI 提出的替代方案（如切换到 ZSTD 或 aircompressor）无法解决性能问题，建议暂时接受回退。
@Zakelly Lan: 同意接受该性能回退。
社区达成共识，接受因安全修复引入的性能回退，Flink 2.3 发布将继续推进，不因此受阻。
2 条回复 · 2 位参与者
讨论主要围绕 FLIP-572（引入 Flink-Kafka 事务管理工具）是否应纳入 Flink 生态系统展开。Ryan 最初质疑其必要性及维护成本，但 Aleksandr 解释了其在处理 Flink 作业停止后数据丢失问题上的独特价值及与 Flink 状态模型的紧密关联。目前讨论已消除主要疑虑，作者准备发起投票。
@Ryan van Huuksloot: 质疑该工具是否属于 Flink 生态，认为这可能是 Kafka 的 API 局限，担心增加社区维护负担。
@Aleksandr Savonin: 指出该工具解决了 Flink 作业停止后 Kafka 未提交事务数据丢失的问题，且未来与 State Processor API 的集成使其必须属于 Flink。
@Ryan van Huuksloot: 认可了关于 Savepoint 操作的解释，但询问为何第一版未包含 State Processor API 集成及依赖打包方式。
初步达成共识认为该工具对处理 Savepoint 相关事务有价值，下一步将针对实现细节（如依赖管理）进行澄清并启动投票流程。
2 条回复 · 3 位参与者
Flink 2.3 发布目前因部分跨团队测试任务缺乏负责人而受阻，涉及多个关键 FLIP 的测试验证与执行。David Anderson 指出压缩性能回归不会阻塞发布，Azure 运行问题正在调查中。随后 Xiqian YU 主动认领了 FLIP-555 的测试任务。
@David Anderson: 发布被跨团队测试阻塞，需为 FLIP-558/565 编写测试说明，并对 FLIP-555/549/487/560 进行测试。
@David Anderson: 压缩性能回归不阻塞发布，Azure 夜间运行问题由 Qingsheng Ren 跟进。
@Xiqian YU: 认领了 FLIP-555 (Native S3 File System) 的跨团队测试任务。
发布进度仍受限于测试资源，下一步需继续推进剩余 FLIP 的测试认领及 Azure 问题排查。
1 条回复 · 2 位参与者
Daniel Rossos 发起 FLIP-XXX 讨论，旨在解决 Table Planner 中因不同 FilterPushDownSpec 导致同一表重复扫描的问题，以优化昂贵数据源的读取效率。目前已有公开草案和内部原型，核心议题在于优化的配置作用域应设定为作业级还是更细粒度。
@Daniel Rossos: 指出当前机制导致昂贵数据源（如 BigQuery、JDBC）重复扫描，询问优化配置应采用作业级标志还是细粒度作用域。
@Hongshun Wang: 建议采用细粒度作用域（每表或每扫描），并提议新增 SupportReuseFilter 接口来标识 Source 是否支持此能力。
尚未达成最终决议，但倾向于探索细粒度作用域方案及相应的接口定义，后续将分享原型代码以供参考。
1 条回复 · 2 位参与者
讨论主要针对 FLIP-562（Kafka Connector 主题完整性检查）的更新版本，社区成员在肯定新方向的同时提出了多个技术细节疑问。核心议题集中在状态迁移策略、Topic Pattern 的检查逻辑是否应排除，以及完整性检查与分区发现机制的依赖关系上。
@Aleksandr Savonin: 询问从无 Topic ID 的旧检查点恢复时的状态迁移方案，并质疑对模式订阅的排除逻辑，认为即使是模式匹配，已知主题被删除重建也应受到校验。
@Aleksandr Savonin: 指出有界源因默认禁用分区发现，可能导致长时间运行的任务无法检测到中途的主题重建，建议允许在此场景下进行周期性检查。
@Hongshun Wang: 建议 Topic Pattern 应保持与普通订阅一致的检查行为，且完整性检查不应强依赖于分区发现配置（即使用户设置间隔为 -1，重启时仍应检查）。
目前尚无明确结论，讨论处于社区提出反馈与澄清问题的阶段，需作者进一步回应关于状态迁移、检查逻辑适用范围及配置依赖等问题。
1 条回复 · 2 位参与者
社区讨论了 Flink Kubernetes Operator 1.15.0 的发布计划。Gyula Fóra 提议在 5 月初发布以包含积累的重要修复，并自愿担任发布经理。针对是否等待 Flink 2.3 以确保兼容性的讨论，最终决定按原计划推进，目前已准备好首个候选发布版本。
@Gyula Fóra: 提议 5 月初发布以包含重要修复；认为不应为等待 Flink 2.3 而推迟发布，可通过手动测试验证兼容性。
@Ryan van Huuksloot: 支持发布，但建议考虑推迟两周以确保与即将发布的 Flink 2.3 兼容。
决定按原计划推进发布，首个候选发布版本（RC）已准备就绪，无需等待 Flink 2.3 正式发布。
1 条回复 · 1 位参与者
Sergey Nuyanzin 在推进 Flink 1.20.4 版本发布时，因 Docker ID 缺乏 apache/flink 仓库权限而请求协助发布镜像。他已提交 INFRA 工单处理权限问题，并在后续邮件中表示问题已成功解决。
@Sergey Nuyanzin: 发布 1.20.4 版本需要推送 Docker 镜像，但当前账号无 apache/flink 访问权限。
@Sergey Nuyanzin: 已创建 INFRA 工单申请权限，并请求有权限者临时协助。
@Sergey Nuyanzin: 最终成功解决了权限或发布问题。
问题已解决，发布流程障碍已消除。
1 条回复 · 2 位参与者
Samrat Deb 发起 FLIP-576 讨论，旨在解决 Flink 原生 S3 文件系统插件缺乏可观测性的问题，以改善生产环境下的故障排查效率。Roman Khachatryan 对提案表示支持，并就指标设计和技术实现提出了具体建议。讨论目前处于收集反馈和优化提案细节的阶段。
@Samrat Deb: 当前 S3 文件系统层缺乏对限流、重试、慢操作及分段上传泄漏等故障信号的可见性，导致排查困难。
@Roman Khachatryan: 建议增加文件大小指标和 bulkCopyHelper 指标，并使用标签（label）区分文件系统类型而非硬编码在指标名中。
@Roman Khachatryan: 支持默认启用该功能，同意不与检查点关联，并认为推荐方案不会增加每条记录路径的开销。
社区对提案价值达成初步共识，倾向于默认启用该功能，后续将根据反馈进一步完善指标定义和实现细节。
1 条回复 · 2 位参与者
Rich Bowen 邀请 Flink 社区参加将于 2026 年 10 月在 Glasgow 举办的 Community Over Code 黑客马拉松，旨在为贡献者提供协作空间。Ramin Gharib 已回复确认参与，并自愿担任联络人协助协调 Flink 社区相关事宜。
@Rich Bowen: 邀请 Flink 社区参与黑客马拉松，要求项目方提供联络人、准备任务列表（如 Bug 修复、文档编写）并进行宣传。
@Ramin Gharib: 确认愿意参加活动，并主动承担协调工作，已加入 Slack 频道以便后续跟进。
Flink 社区已确认参与意向，下一步将由 Ramin Gharib 加入 Slack 频道跟进具体协调工作，并需准备相关任务列表。