💬 讨论 (10)
3 条回复 · 4 位参与者
讨论主要围绕 Flink JDBC Connector 的版本控制策略和支持政策展开，重点讨论了版本命名规范及是否放弃 Flink 2.0 支持。经过讨论，社区倾向于继续沿用现有顺序版本号，并参考 Kafka 连接器做法，计划发布 v5.0（针对 Flink 2.1）和 v3.4（针对 Flink 1.20）。
@Chanhae Oh: 建议下次发布继续沿用现有顺序版本号以减少干扰，未来再统一命名规范；认为应放弃 Flink 2.0 支持，专注于 Flink 1.20 (LTS) 和 2.x 版本。
@Rui Fan: 建议版本控制策略参考 Kafka 或其他连接器的做法。
@Yuepeng Pan: 总结讨论结果，计划发布 v5.0（适配 Flink 2.1）和 v3.4（适配 Flink 1.20），并欢迎新贡献者加入发布周期。
初步确定发布 v5.0 和 v3.4 两个版本，放弃对 Flink 2.0 的支持，下次发布暂不改变版本命名策略，后续将推进发布流程。
3 条回复 · 2 位参与者
讨论围绕 FLIP-XXX 提案展开，旨在支持基于 Java 关联合并运算符的 ReducingMergeState 和 AggregatingMergeState。作者已根据反馈更新了关于状态 TTL 的文档，但在作者认为无遗留问题准备结项时，审阅者指出仍有问题未获解答。
@Soumitra Kumar: 用户从 ReducingState 迁移需谨慎，因 RocksDB 运行时特性不同，不建议自动迁移，且需编写调优文档。
@Soumitra Kumar: 已在提案文档中新增了关于 ReducingMergeState 和 AggregatingMergeState 状态 TTL 的章节。
@Roman Khachatryan: 指出作者尚未回答之前提出的问题，要求进行澄清或确认 FLIP 的必要性。
目前处于澄清阶段，作者认为已解决所有问题，但审阅者 Roman 提出异议，下一步需确认作者之前的回复是否已有效传达并解决审阅者的疑问。
2 条回复 · 2 位参与者
讨论主要围绕 RpcOperator 的定位、性能表现及 API 设计展开。Yi Zhang 阐明了 RpcOperator 旨在补充而非替代 StreamOperator，适用于计算密集型且无需状态的场景，并提出了共享服务的 API 方案。Gyula Fóra 则强调需明确界定其适用边界和局限性（如不支持状态），以防用户误用。
@Yi Zhang: RpcOperator 定位为 StreamOperator 的补充，专用于计算密集、初始化昂贵且无需状态的场景（如模型推理），目前不支持有状态计算。
@Yi Zhang: 初步性能测试显示，在小对象和长耗时处理场景下开销极低；建议新增 startSharedRpcOperatorService API 以支持跨作业共享服务，并暂缓引入自动伸缩相关参数。
@Gyula Fóra: 社区需提供明确的使用指导，不仅要说何时用，更要明确何时“不该用”，并清晰指出其缺失的功能（如状态支持）和语义保证。
初步确定将引入 Shared RPC Service API，并明确了当前版本不包含自动伸缩逻辑；下一步需完善文档，明确 RpcOperator 的局限性及语义保证。
2 条回复 · 3 位参与者
Dian Fu 发起 FLIP-591 讨论，提议在 PyFlink 中引入 Python DataFrame API，旨在为 Python 用户提供更自然的接口，同时保留 Flink 的执行语义。讨论主要围绕 API 的易用性设计展开，参与者建议增强与主流 Python 库的一致性并优化语法糖。
@Dian Fu: 提议构建 `pyflink.dataframe` 模块，专注于提供 Python 友好的 API、支持 Arrow 格式及优化 AI/ML 工作负载的执行配置。
@Cole Bailey: 建议在聚合操作中支持 kwargs 别名，并增加属性样式（如 `df.age`）的列引用方式以提升代码可读性。
@Zander Matheson: 建议加强与 Pandas/Polars 等 API 的一致性（如使用 `dropna` 而非 `drop_null`），并询问了关于索引和原地操作的支持情况。
目前处于收集反馈阶段，作者尚未对具体建议进行回复，后续将根据社区意见进一步完善 API 设计细节。
1 条回复 · 2 位参与者
讨论主要针对 Flink SQL 引入 GEOGRAPHY 类型的提案进行了细节审查，涉及功能边界、生态集成及 SQL 语义。作者 dylanhz 提出了关于计算函数维护成本、Sedona 适配及显示逻辑的疑虑，David Chaava 据此更新了提案，明确了 Flink 侧重于原生类型与互操作性而非全功能计算，并补充了 WKB 交互路径与 WKT 显示规范。
@dylanhz: 质疑 Flink 是否应维护大量特定领域的地理计算函数，建议此类功能应由 Sedona 等专业项目维护，同时关注类型的显示方式和 SQL 语义定义。
@David Chaava: 明确 FLIP 核心范围仅限于原生类型支持、序列化及与 Iceberg/Parquet 等格式的互操作性，V1 版本仅包含必要的构造和转换函数。
@David Chaava: 确定了与 Sedona 的互操作通过 ISO WKB 进行，且 SQL Client 等显示层将渲染为 WKT 格式，但这不意味着支持隐式转换为 STRING。
提案作者已根据反馈更新文档，明确了类型范围、SQL 语义及与 Sedona 的交互方式，解决了主要疑虑。
1 条回复 · 2 位参与者
该讨论围绕 FLIP-589 展开，提议引入 FILE 逻辑类型以优化多模态数据处理中的字节内容引用机制。发起人 dylanhz 阐述了该类型相比传统 URI 的优势，而 Yanquan Lv 在表示支持的同时，针对元数据语义和内容变更处理提出了具体改进建议。
@dylanhz: 提议引入 FILE 类型作为字节内容的逻辑引用，不存储实际字节，旨在为多模态处理提供比 STRING URI 更清晰的契约。
@Yanquan Lv: 指出 modification_time 在跨系统间存在语义不一致问题（代表上传时间而非内容创建时间），建议明确其局限性。
@Yanquan Lv: 针对 FILE 类型仅作为引用而非快照的特性，建议明确内容变更时的读取行为并提供配置选项（如失败或返回 null）。
目前处于讨论初期，已收到初步支持与改进建议，等待发起人对元数据语义及内容变更处理方案的进一步回应。
1 条回复 · 1 位参与者
讨论主要针对 FLIP-XXX（基于 Pipeline Region 的独立检查点）提案，旨在解决高并行度流作业中单点故障导致全局检查点失败的问题。作者详细澄清了当前设计仅限于尴尬并行区域，并解释了故障处理、元数据布局及 JM 恢复机制等技术细节。目前所有评审意见已处理完毕，若无异议将于下周一启动投票。
@熊饶饶: 当前设计范围仅限于尴尬并行区域（如典型 ETL 场景），各并行度间无连接边，暂不涉及 Keyed State 或增量 State。
@熊饶饶: 设计了双层故障处理机制：连续区域失败次数超阈值后强制全局检查点，若该全局检查点仍失败则仅中止检查点而非导致作业失败，防止级联故障。
@熊饶饶: 通过在元数据中增加 refCheckpointId 追踪历史状态引用，确保 JM 恢复时只需读取单一元数据文件即可保证状态一致性。
作者已回应所有评审意见，若无进一步异议，将于 6 月 22 日启动 [VOTE] 投票线程。
1 条回复 · 1 位参与者
本次讨论涉及一个旨在为 Flink CI Docker 镜像添加 Java 25 支持的拉取请求（PR #1）。提交者 snuyanzin 开启了该请求并随后完成了合并，期间无额外评论或讨论。
@snuyanzin: 开启了 PR #1，提议将 Java 25 添加到 Docker 镜像中。
@snuyanzin: 合并了该 PR，完成了代码变更。
PR #1 已成功合并，Java 25 已正式添加到 Flink CI Docker 镜像中。
0 条回复 · 1 位参与者
讨论主要关注 ASF 共享 GitHub Runner 资源紧张的问题及 Flink 社区的优化进展。目前 Flink 项目的资源消耗排名已退出前十，社区成员针对长期未维护的 flink-ml 仓库提出了降低构建频率的具体建议。
@Sergey Nuyanzin: 发现 Flink nightly 构建和 flink-ml 测试消耗资源较多，建议将长期未更新的 flink-ml 的 nightly 构建改为每月一次。
@Robert Metzger: 同意大幅降低 flink-ml 相关构建的频率以节省资源。
@Bob Thomson: 肯定了 Flink 社区的优化进展（排名下降），并提供了 GitHub Actions 优化最佳实践指南和交流渠道。
社区已达成共识将降低 flink-ml 的构建频率，后续可参考 ASF 提供的最佳实践指南进一步优化工作流。
0 条回复 · 1 位参与者
Geng Biao 和 Dylanhz 发起 FLIP-590 讨论，提议为 AI 导向的 Flink 管道引入 Vector、Tensor 和 Image 三种多模态数据类型。该提案旨在解决当前使用通用类型表示多模态数据时丢失语义的问题，通过定义新的逻辑类型和 ElementDType 枚举，为 SQL、UDF 和连接器提供稳定的契约。提案明确其范围仅限于类型语义与接口定义，不涉及具体的计算框架实现。
@Geng Biao: 现有表示方式（如 VARBINARY、ROW）丢失了元素类型、张量形状等关键语义，导致不同 API 和连接器间难以共享稳定契约。
@Geng Biao: 提议引入 TENSOR、VECTOR 和 IMAGE 三种逻辑数据类型，并配合 ElementDType 枚举支持 uint8、float32 等多种数据精度。
@Geng Biao: 提案范围严格限定于类型语义、运行时表示及序列化等边界，不旨在将 Flink 转变为张量计算或图像处理框架。
目前处于向社区征集反馈阶段，尚无最终定论。