💬 讨论 (10)
8 条回复 · 4 位参与者
讨论围绕 FLIP-570 运行时数据采样功能的性能影响、内存模型及生产环境可靠性展开。Jiangang Liu 详细阐述了多层内存限制、toString() 风险的防御性设计以及热路径开销的实测数据，回应了社区关于稳定性的疑虑。讨论已结束，若无新问题将于两日后开启投票流程。
@Look_Y_Y: 关注生产环境依赖 toString() 的可靠性风险，如未重写该方法导致的无意义输出、异常、死锁或阻塞 mailbox 线程。
@xingsuo-zbz: 质疑热路径中 Volatile 读在极端吞吐量场景下是否会成为性能瓶颈。
@Jiangang Liu: 解释了三层防御机制（智能检测、时间预算、异常隔离）确保业务逻辑不受影响，且实测显示 Volatile 读开销极低，内存占用通过 JVM Heap 及多层限流机制控制在安全范围内。
所有技术疑虑均已得到详细解答，Yuepeng Pan 表示无其他问题，Jiangang Liu 宣布将于两日后发起投票。
6 条回复 · 5 位参与者
本次讨论围绕 FLIP-571 展开，提议通过 REST API 动态更新 Checkpoint 配置（如间隔和超时）以解决生产环境中的级联故障问题。讨论重点涉及配置一致性校验、线程安全、存储架构设计以及运维风险，提议者针对各方疑虑进行了详细的技术辩护。
@Roman Khachatryan: 关注可观测性问题（Web UI 不同步）、部分更新缺乏整体校验逻辑以及 API 路径设计。
@熊饶饶: 担心将字段改为 volatile 无法保证多字段更新的原子性，可能导致配置不一致。
@Jiangang Liu: 回应称更新操作在 JobMaster 主线程的同步块中原子执行，存储方案复用了现有成熟模式，且相比重启作业具有更低的运维成本。
提议者对线程安全和存储架构等核心质疑给出了合理解释，后续需进一步完善可观测性（如 GET 接口）及配置校验逻辑的设计细节。
5 条回复 · 6 位参与者
Sergey Nuyanzin 提议发布 Flink 1.20、2.0、2.1 和 2.2 的补丁版本，理由是各版本已累积约 50 个提交，建议在 2.3 主版本发布前完成。该提议得到了多位社区成员的迅速支持，大家认为已有重要修复需交付给用户。
@Sergey Nuyanzin: 提议发布 1.20、2.0、2.1、2.2 的补丁版本（各约 50 个提交），并自荐担任发布经理。
@Gustavo de Morais: 支持发布，认为目前已有相关的修复需要提供给用户。
@Rui Fan / Leonard Xu: 明确支持发布计划并同意由 Sergey 担任发布经理。
社区一致通过发布提议，Sergey Nuyanzin 将作为发布经理推进后续工作。
4 条回复 · 3 位参与者
Jim Hughes 发起 FLIP-574 讨论，旨在解决元数据列谓词在现有路径下因序列化索引失效而无法下推的问题。该提案建议通过 SupportsReadingMetadata 新增默认方法建立独立的元数据过滤器下推路径，并已提交 PR。讨论获得了积极反馈，主要针对 CTAS 场景进行了澄清。
@Jim Hughes: 指出当前元数据谓词下推会导致编译计划恢复失败，提议新增 MetadataFilterPushDownSpec 和专用接口路径来解决此问题。
@Timo Walther: 支持该提案，认为接口设计整洁，并解释 CTAS 最终转换为 CREATE TABLE 和 INSERT INTO，不影响元数据过滤下推。
@Sergey Nuyanzin: 支持提案，但建议增加针对 CREATE TABLE AS (CTAS) 场景的测试，以防列重排引发问题。
若没有其他反馈，作者将于次日或周四发起投票；关于 PushFilterInCalcIntoTableSourceRule 的细节讨论将移至 PR 中进行。
2 条回复 · 3 位参与者
讨论指出 Hive 3.1 connector 在 Java 11+ 环境下因 Hive 自身的类加载器转换 Bug 导致功能失效，阻碍了 Flink 2.0 的兼容性。鉴于 Hive 3.1 已停止维护且 Flink 2.x connector 尚未发布，社区正在权衡是否应通过技术手段绕过该问题或直接放弃对 Hive 3.1 的支持。
@Lalwani, Jayesh: Hive 3.1 在 Java 11+ 上因 ClassLoader 转换错误导致 25 个测试失败，询问是否应通过封装线程上下文类加载器来绕过此问题。
@Martijn Visser: 由于缺乏对新 Java 版本的官方支持，对此类兼容性问题的修复持保留态度。
@Ferenc Csaky: 既然 Flink 2.x 的 Hive connector 尚未发布，不算破坏性变更，建议直接放弃已 EOL 的 Hive 3 并转向 Hive 4。
初步结论倾向于在 Flink 2.x 版本中不再支持 Hive 3.1，建议用户升级至 Hive 4.0。
1 条回复 · 1 位参与者
讨论主要围绕 FLIP-572 提案展开，旨在解决 Flink 作业意外终止且不再重启时 Kafka 残留事务的处理问题。作者阐述了为何现有的作业内恢复机制和 Kafka 超时机制无法满足数据一致性或低延迟要求，并论证了独立工具在最小化依赖方面的优势。
@Aleksandr Savonin: 现有的 `POOLING` 策略和恢复路径仅在作业重启时生效，该工具专门针对作业不再运行且无 Flink 代码执行的场景。
@Aleksandr Savonin: 依赖 Kafka 超时机制存在风险：若 Flink 在 checkpoint 后崩溃，超时中止会导致数据丢失；长事务超时则会阻塞下游消费者（LSO）。
@Aleksandr Savonin: 相比 Flink CALL procedures，独立工具仅需 Java 环境即可运行，避免了在 Kafka 机器上安装 Flink 依赖的麻烦。
讨论澄清了提案的适用场景（作业不重启）及设计考量，确认了独立工具在处理残留事务和减少环境依赖方面的必要性。
1 条回复 · 1 位参与者
Shekhar Rajak 提议在 Flink Kafka connector 中新增 KafkaShareGroupSource，以支持 Kafka 4.0 的 Share Groups (KIP-932) 功能。该方案利用竞争消费者模型实现类似队列的语义，通过显式确认和锁更新机制保证“至少一次”处理，且无需 Flink 端维护记录状态。设计完全向后兼容，仅新增一个用户配置开关。
@Shekhar Rajak: 提议新增 KafkaShareGroupSource 以支持 Kafka 4.0 Share Groups，实现无需 Flink 端状态的队列式竞争消费。
@Shekhar Rajak: 核心机制包括显式确认、锁更新以及 Checkpoint 期间的暂停/恢复流程，确保至少一次语义。
@Shekhar Rajak: 征求关于 Broker 端获取锁超时与 Flink Checkpointing 交互机制的反馈。
提案已发布，目前处于征求反馈阶段，特别关注锁超时与 Checkpoint 的交互问题。
1 条回复 · 2 位参与者
Dennis-Mircea Ciupitu 发起了关于 FLIP-XXX 的讨论，旨在扩展 Flink Autoscaler 的 Executor Plugin SPI。他提交了设计文档及包含参考实现的草稿 PR，以便社区进行具体审阅。
@Dennis-Mircea Ciupitu: 提议扩展 Executor Plugin SPI，并提供了参考实现以使提案更具体、易于审查。
@Gyula: 审阅后支持该提案（+1），认为基于过往经验该方案看起来不错。
提案已获得初步支持，下一步将继续收集社区反馈并完善实现。
1 条回复 · 1 位参与者
Dennis-Mircea Ciupitu 发起了关于“FLIP-XXX: Flink Autoscaler 可组合并行度对齐模式”的讨论。他提供了设计文档及包含参考实现的草稿 PR，旨在使提案更加具体并便于社区审查。
@Dennis-Mircea Ciupitu: 提议为 Flink Autoscaler 引入可组合的并行度对齐模式。
@Dennis-Mircea Ciupitu: 已提交草稿 PR (#1088) 作为参考实现，辅助提案理解。
@Dennis-Mircea Ciupitu: 积极寻求社区的反馈和建议。
目前处于提案发起阶段，暂无明确结论，下一步等待社区对设计文档和代码实现的反馈。
0 条回复 · 1 位参与者
Piotr Rudnicki 提交了针对 FLINK-35321 的修复补丁，解决了 CheckpointCommittableManagerImpl 在每次提交操作时重复注册 pendingCommittables 指标的问题。该修复虽已在一个多月前获得 Rion Williams 的批准，但仍需具有写入权限的人员进行最终审批，以便赶在 2.3 版本发布前合并。
@Piotr Rudnicki: 已准备好修复代码，此前已获批准，急需具有写入权限的人员审批以赶上 2.3 版本发布。
@Rion Williams: 已于一个多月前批准了该修复方案。
修复代码已就绪，等待具有写入权限的 Committer 进行最终审批和合并。