💬 讨论 (10)
4 条回复 · 3 位参与者
讨论主要围绕 FLIP-XXX（基于 Pipeline Region 的独立检查点）展开，重点探讨了扩缩容时的状态引用机制、Finished Operators 的数据一致性风险及与 FLIP-306 的兼容性。目前作者已针对数据丢失风险提出解决方案，并计划补充正式文档，但关于扩缩容时状态重分配的具体实现细节仍存在争议。
@Roman Khachatryan: 指出缺失正式 FLIP 页面；质疑扩缩容时 `refCheckpointId` 的处理逻辑，担心混合新旧状态会导致问题；担忧 Finished Operators 在最后检查点失败时可能导致数据丢失。
@熊饶饶: 针对数据丢失风险，提出在 Source 耗尽时强制执行全局检查点；主张保留 TM-level 文件合并，并调整通知机制以兼容 Regional Checkpoint；解释扩缩容时 `refCheckpointId` 仅作为元数据保留。
@Zakelly Lan: 支持 FLIP 方向，但反对 region-level merging，建议保留 TM-level merging 并通过保持旧文件存活来兼容。
已确认需创建正式 FLIP 页面，并针对 Finished Operators 达成“强制全局检查点”的解决方案。针对 FLIP-306 兼容性，决定保留 TM-level merging 并调整通知机制。但在扩缩容时的状态重分配逻辑上，Roman 提出了新的质疑，尚未达成最终一致意见，需进一步讨论。
4 条回复 · 4 位参与者
Samrat Deb 和 Poorvank Bhatia 提议为 Flink 构建独立于 Hadoop 的原生 Google Cloud Storage (GCS) 文件系统实现，旨在减少依赖复杂度并提升性能。该提议获得了社区支持，Aleksandr Iushmanov 认为这与其跨云支持 FLIP 相辅相成，Ryan van Huuksloot 则表示愿意参与测试。Poorvank 进一步分析了现有代码，指出可复用已独立于 Hadoop 的 RecoverableWriter 部分，从而简化原生实现的工作范围。
@Samrat Deb: 提议创建原生 GCS 文件系统以消除 Hadoop 依赖，解决升级受限和依赖堆栈过大的问题。
@Aleksandr Iushmanov: 支持该提议，指出 Hadoop 连接器存在 CVE 管理复杂、依赖升级困难等痛点，并提到正在进行的跨云支持 FLIP。
@Poorvank Bhatia: 分析了现有代码结构，建议复用已独立的 RecoverableWriter 组件，并参考 FLIP-555 (S3) 作为实现模型。
社区对提议反响积极，下一步将准备正式的 FLIP，并与跨云支持相关的“Umbrella”FLIP 进行协调，后续将推出 alpha 版本供用户测试。
3 条回复 · 2 位参与者
讨论主要围绕 FLIP-591 在 PyFlink 中引入 Python DataFrame API 的设计方案展开。参与者针对多模态数据处理、批处理内存控制、GPU 资源配置以及 API 设计风格（如与 Table API 的关系及 Pandas 兼容性）提出了具体建议。作者已根据反馈更新了提案，明确了类类型支持和 API 命名规范。
@Yong Fang: 指出仅按行数控制 batch_size 在处理多模态数据时可能导致 OOM，建议支持基于内存预算的切分，并询问了多模态读写 API 及 GPU 资源配置方案。
@Zander Matheson: 探讨了该提案与 FLIP-541 的关系，建议 API 设计应考虑与 Pandas/Polars 等主流框架的一致性，例如 dropna 与 drop_null 的命名选择。
@Dian Fu: 解释了独立推出 DataFrame API 而非演进 Table API 的原因，确认将支持类类型的处理器，但多模态专用 API 和基于内存的批处理将留待后续 FLIP 解决。
初步结论是维持 DataFrame API 与 Table API 分离的设计思路，采纳了关于类类型处理器、列访问方式及 drop_null 命名的建议；关于多模态数据支持和基于内存的批处理策略，计划在未来通过独立的 FLIP 进行扩展。
3 条回复 · 3 位参与者
社区正在规划下一批 Flink JDBC Connector 的发布，讨论确认了版本管理策略并最终确定了具体的 Jira 版本标签。主要计划发布针对 Flink 1.20.x、2.1.x 和 2.2.x 的 JDBC 连接器版本，并一致同意放弃对 Flink 2.0 的支持。
@Chanhae Oh: 发起了创建 Jira 版本标签的请求，并更正了 Flink 1.20.x 对应的主版本号应为 jdbc-3.4.0。
@Yuepeng Pan: 澄清了最终标签列表，指出 jdbc-3.4.0 已存在，建议将 jdbc-6.0.0 纳入当前发布周期，并确认了有足够的志愿者支持。
@Jark Wu: 支持发布计划和顺序版本管理方案，并同意放弃对 Flink 2.0 的支持。
社区已就版本发布计划达成共识，下一步行动是请求 PMC 成员或 Jira 管理员协助创建 jdbc-3.5.0、jdbc-5.0.0、jdbc-6.0.0 等版本标签。
2 条回复 · 3 位参与者
讨论主要围绕 Flink S3 文件系统实现的未来演进方向，核心议题是如何从现有的三个实现过渡到统一的 native-s3-fs。社区一致认为 native-s3-fs 是长期正确方向，因为它解决了此前需要混用多个连接器的痛点，但在弃用旧实现前，需确保新连接器在生产环境达到足够的稳定性与成熟度。
@Samrat Deb: 发起讨论，指出目前存在三种 S3 实现，询问社区是计划长期维护多个实现还是进行整合。
@Gabor Somogyi: 强调开发资源有限，目标是提供单一解决方案，建议先让新连接器在大型生产环境中稳定运行，再逐步淘汰旧连接器。
@Aleksandr Iushmanov: 建议在更广泛的云存储“伞形 FLIP”框架下讨论旧版弃用问题，目前正在推进该 FLIP 的制定。
初步结论是确立 native-s3-fs 为长期统一方案，但不会立即弃用旧实现。下一步行动包括制定涵盖主要云服务商的伞形 FLIP，并优先推动 native 连接器在生产环境中的稳定性验证与用户迁移。
2 条回复 · 3 位参与者
讨论主要围绕 FLIP-588 提案，旨在支持 per-job 级别的委托令牌，以解决同一集群不同作业需以不同身份认证的问题。参与者就 Provider 生命周期、令牌重新获取的 API 设计以及线程安全等细节进行了深入探讨，并进一步提出了任务端连接器如何匹配正确凭证的挑战。
@Gabor Somogyi: 支持 per-job 模型，但关注并发环境下的线程安全（如竞态条件、死锁），建议引入专用 API 处理令牌重新获取，并询问任务端连接器如何根据 JobID 选择正确凭证。
@Alan Sheinberg: 澄清 Provider 生命周期保持不变，stop 函数仅用于清理；提议引入 DelegationTokenManagerCallback 接口，让 Provider 主动触发令牌更新，替代依赖 registerJob 返回值的方案。
初步认可 per-job 模型及回调接口的设计思路，下一步需解决任务端连接器如何根据 JobID 选择正确凭证的具体实现，并提供参考连接器案例。
2 条回复 · 2 位参与者
讨论主要针对 Flink SQL 引入原生 GEOGRAPHY 类型的提案，作者澄清了该类型旨在支持互操作性而非替代专业地理空间库。针对社区提出的为何不使用 Calcite 现有 GEOMETRY 类型或先贡献给 Calcite 的疑问，作者解释了两者在语义上的本质区别及独立推进的必要性。目前提案明确了类型定义的差异化及后续的实施路径。
@Sergey Nuyanzin: 质疑为何不使用 Calcite 现有的 GEOMETRY 类型，或考虑先向 Calcite 添加 GEOGRAPHY 类型。
@David Chaava: 指出 GEOMETRY（平面）与 GEOGRAPHY（球面/测地）在语义和计算模型上存在本质区别，若混用会导致函数重载和语义歧义。
@David Chaava: 建议先在 Flink 中作为原生逻辑类型实现，以便独立于 Calcite 的发布流程快速推进，未来再考虑贡献给 Calcite。
初步结论是维持提案方向，即在 Flink 中引入原生 GEOGRAPHY 类型，并参考 BITMAP 类型的模式通过 Calcite 集成层桥接，未来再考虑向上游 Calcite 贡献。
1 条回复 · 1 位参与者
Flink 2.3.0 发布经理 Yuepeng Pan 因首次发布核心产品，请求 PMC 授予其 PyPI 账号权限以上传 Python artifacts。随后他确认在社区成员的帮助下，上传工作已完成，后续发布步骤正由 David Anderson 处理。
@Yuepeng Pan: 请求 PMC 将其账号（panyuepeng）添加到 pyflink 维护者列表，以便发布 Flink 2.3.0 Python artifacts。
@Yuepeng Pan: 确认 Python artifacts 已成功上传，并感谢 Dian Fu 和 David Anderson 的协助。
权限问题已解决，Python artifacts 已上传完毕，David Anderson 正在推进后续发布流程。
1 条回复 · 1 位参与者
snuyanzin 向 flink-ci-docker 仓库提交了一个 PR，旨在添加 .gitignore 文件。该 PR 随后被提交者合并，属于一项简单的维护性修复。
@snuyanzin: 开启了 PR #2 以添加 .gitignore 文件。
@snuyanzin: 合并了该 PR。
PR #2 已成功合并，任务完成。
0 条回复 · 1 位参与者
讨论主要针对 FLIP-582 提案中 RpcOperator Service 的适用范围和使用限制。Yi Zhang 回应了 Gyula Fóra 关于明确功能边界的建议，在文档中新增了“限制与使用指南”章节，清晰界定了该功能不支持状态管理及精确一次语义等特性，以防用户误用。
@Gyula Fóra: 建议明确列出 RpcOperator 不适用的场景及缺失的功能（如状态管理），防止用户将其视为解决现有问题的“银弹”，并要求澄清处理语义。
@Yi Zhang: 确认已添加限制说明（无状态、无时态操作、无精确一次语义），明确了不同模式下的处理保证，并指出该功能仅适用于解耦昂贵的无状态计算。
提案已更新，增加了明确的限制说明和使用指南，界定了功能边界。