💬 讨论 (10)
16 条回复 · 8 位参与者
讨论主要围绕 FLIP-579 提出的 LATERAL SNAPSHOT Join 展开，旨在通过两阶段设计解决处理时间 temporal join 的初始化问题。参与者深入探讨了翻转点精确性、宕机恢复后的数据一致性以及 LOAD 阶段的状态缓冲风险等挑战。最终 Fabian 采纳了增加监控指标的建议，社区对整体方案达成共识，准备启动投票流程。
@Fabian Hueske: 解释了设计原理，指出缓冲未匹配记录会增加复杂性，且 InputSelectable 在流式处理中存在限制，同意添加算子指标以提升可观测性。
@Jark Wu & Leonard Xu: 关注翻转点的非精确性及 LOAD 阶段的状态膨胀风险，建议利用 isBacklog 或背压机制优化，但认可当前方案作为 v1 版本的可行性。
@Xingcan Cui: 指出长时间宕机恢复后，数据回放可能因丢失时间顺序而关联到错误的维度快照，建议引入事件时间模式过渡。
社区基本认可当前提案，Fabian 同意增加算子指标以解决可观测性问题，复杂的优化（如 InputSelectable 或精确翻转点）留待后续版本，计划在完善指标后启动投票。
10 条回复 · 7 位参与者
本次讨论围绕 FLIP-582 提案展开，旨在引入 RpcOperator Service 以解耦 AI 推理等无状态重负载与数据平面，实现独立扩缩容和资源隔离。社区普遍认可该方向，并深入探讨了自动扩缩容策略、故障恢复语义（如重算成本与请求取消）、GPU 资源管理及 API 设计细节。
@Guowei Ma: 建议自动扩缩容应作为一等公民，API 设计不应锁定固定并行度，并询问了多作业引用时的服务生命周期问题。
@Hongshun Wang: 关注无状态设计带来的故障重算成本，建议在数据平面故障时主动取消进行中的 RPC 请求以节省昂贵资源。
@Yi Zhang: 回应称首版将优先支持固定并行度，后续再扩展自动扩缩容；针对大消息问题，建议调整配置或使用数据引用，未来可替换传输层。
作者确认将在提案中补充异步调用示例和大消息处理说明；自动扩缩容和 GPU 一等资源支持将延后至后续 FLIP 处理；针对故障恢复时的请求取消机制达成了初步共识，后续将完善相关设计细节。
6 条回复 · 4 位参与者
本次讨论针对 FLIP-XXX 提议，即引入基于 RocksDB 合并算子的 ReducingMergeState 和 AggregatingMergeState 以优化写入性能。讨论重点集中在读后写场景的潜在开销、实际用例动机、API 兼容性及状态迁移路径。提案者澄清了新状态适用于高写入吞吐场景，并计划完善相关文档。
@Roman Khachatryan: 担忧读后写场景下的额外 IO 开销，建议评估 MapState 作为排序用例的替代方案，并询问远程压缩的兼容性。
@Soumitra Kumar: 确认新状态变量适用于写多读少场景，用户需根据运行时特性自行选择，并将补充用例与 TTL 细节。
@Yuan Mei: 强调需要具体的 SQL/DataStream 用例来支撑动机，并关注公共接口变更及端到端的落地方式。
提案者将在 FLIP 中补充具体的用例说明和 TTL 细节；新状态将作为独立选项供用户选择，而非透明替换现有实现。
3 条回复 · 2 位参与者
讨论主要围绕 FLIP-580 展开，旨在为 AsyncTableFunction 增加用户自定义超时处理逻辑的支持。参与者讨论了是否支持 correlate query 路径以及超时处理必须同步完成的限制原因。最终作者确认将更新 FLIP 以覆盖遗漏的代码路径，并计划于 6 月 4 日开启投票。
@Alan Sheinberg: 指出 FLIP 遗漏了 correlate query 代码路径，并认为要求超时处理逻辑同步完成是合理的限制。
@Kui Yuan: 确认将更新 FLIP 以支持 correlate query，并解释了同步合约能避免框架在重试协调和检查点对齐上的复杂性。
@Lincoln Lee: 对提案表示支持，建议在文档中明确“非阻塞”的具体规则并提供示例，暂不涉及 AsyncScalarFunction。
讨论已达成共识，作者将更新文档以覆盖 correlate query 路径并明确非阻塞规则，计划于 6 月 4 日开启投票。
3 条回复 · 2 位参与者
FLIP-578 提议支持将现有的常规表（CatalogTable）就地转换为物化表，以解决当前转换过程繁琐且破坏引用的问题。讨论明确了转换需停止作业并处理偏移量，但这属于一次性操作，且反向转换不在范围内。目前社区已无异议，作者已发起投票流程。
@Ramin Gharib: 提议通过 `CREATE OR ALTER` 语法实现表类型的原地转换，保留身份和存储，并指出反向转换（MT 转 Table）不在范围内。
@Kui Yuan: 确认转换现有表需停止流作业并处理起始偏移量，但这属于一次性操作，支持该提案以平滑迁移。
@Ramin Gharib: 确认转换是一次性操作，优势在于转换后 Schema 和查询可通过标准物化表路径统一演进。
社区对提案达成共识，作者已开启 [VOTE] 投票线程。
3 条回复 · 4 位参与者
Sergey Nuyanzin 提议将 flink-ci-docker 迁移至 Apache 组织下，以解决当前仓库权限受限导致的维护瓶颈。该迁移将参考 flink-shaded/connectors 的模式，旨在解除 JDK 25 升级等工作的阻碍。多位社区成员对该提议表示支持，认为有助于提升 CI 基础设施的可维护性。
@Sergey Nuyanzin: 当前仓库权限集中在少数人手中阻碍更新，提议迁移至 Apache 以方便提交者维护并支持 JDK 25。
@Chanhae Oh: 迁移对 CI 基础设施的可维护性有益，能更方便地协调未来的 JDK 升级和环境变更。
@Yuepeng Pan: 支持该提议（+1）。
社区已达成共识，同意将 flink-ci-docker 迁移至 Apache 组织下。
3 条回复 · 3 位参与者
本讨论主要关于 FLIP-583 提案，旨在为 Source 上下文（SourceReaderContext 和 SplitEnumeratorContext）暴露 JobInfo，以解决当前获取作业元数据方式脆弱且不可用的问题。参与者对提案方向达成共识，并就 API 稳定性论证和实际应用场景进行了交流。提案发起人已根据反馈更新了文档并创建了后续跟进任务。
@Aleksandr Savonin: 提议在 Source 端添加 getJobInfo() 方法以对齐 SinkV2 功能，满足连接器对认证和追踪等元数据的需求；已根据反馈更新了 FLIP 动机部分，并创建了后续 JIRA (FLINK-39827) 以推动 API 落地。
@Rui Fan: 支持提案方向，但指出关于 RichSourceReaderContext 稳定性的论据需调整（应关注其仅存在于 reader 端等实际差距），并询问了现有连接器的变通情况及后续采用计划。
@Yuepeng Pan: 认为该提案合情合理，表示支持 (+1)。
初步结论是提案方向正确，已达成共识推进。下一步行动包括根据建议完善 FLIP 文档中的动机描述，以及通过 JIRA FLINK-39827 在各连接器中采纳新接口。
2 条回复 · 3 位参与者
讨论主要围绕 FLIP-576 中 S3 文件系统插件的指标默认配置策略及 API 设计优化展开。针对默认启用大量指标可能带来的基数问题，社区采纳了 opt-in 机制和白名单配置方案。目前提案已达成共识并进入投票阶段。
@Aleksandr Iushmanov: 担心默认启用约 50 个时间序列会导致基数爆炸和数据量激增，建议采用 opt-in 模式。
@Samrat Deb: 采纳建议，计划通过配置 s3.metrics.allowlist 和 s3.metrics.detailed.enabled 让用户自主控制指标范围。
@Gabor Somogyi: 建议引入独立的 MetricsAware 接口来设置 MetricGroup，以保持 FileSystemFactory 契约的整洁性。
提案已获得各方认可，Samrat Deb 已发起投票线程。
1 条回复 · 2 位参与者
讨论主要围绕 FLIP-577（AI-Native Flink 总括提案）展开，旨在确立多模态数据处理的总体方向和工作负载类别。社区确认该提案主要起方向性指导作用，具体设计细节将在后续子 FLIP 中独立评审。作者 Guowei Ma 表示将基于当前讨论推进投票流程。
@Guowei Ma: 确认总括提案旨在对齐社区方向，具体设计需单独评估；同意在子 FLIP 中继续关注功能矩阵问题。
@Martijn Visser: 认为提案解决了之前的担忧，支持其作为方向性声明；强调子 FLIP 需独立审查，并继续关注功能矩阵覆盖。
@Yuan Mei: 支持该提案，认为多模态处理意义重大；指出架构改进（如 RPC operator）对 Flink 能力扩展具有基础性作用。
Guowei Ma 将基于现有讨论推进投票流程。
1 条回复 · 2 位参与者
熊饶饶发起了关于 FLIP-XXX（基于 Pipeline Region 的独立检查点）的讨论，旨在解决高并行度作业中因单个 Task 失败导致全局 Checkpoint 中止的问题。提案建议允许部分 Region 失败，通过组合失败 Region 的历史状态与正常 Region 的当前状态来生成逻辑完整的 Checkpoint。目前讨论主要围绕接口语义、状态一致性理论依据及生态组件的兼容性展开。
@zihao chen: 担心直接复用 CheckpointListener 可能导致开发者误解，建议扩展接口以携带区域级信息；询问特定 Task 长时间未确认检查点时的状态引用逻辑。
@熊饶饶: 指出当前机制导致资源浪费（尤其是 GPU 场景），提出“区域检查点”概念，通过新增 checkpointCoordinatorForRegionFallback 接口保证状态一致性。
@Gen Luo: 认为需进一步阐述合并不同 Checkpoint 状态为何能保持逻辑一致性的理论基础；强调需评估 Flink CDC、Paimon 等生态组件中 OperatorCoordinator 的适配情况。
该方向被认为很有前景，但提案者需进一步澄清 CheckpointListener 的语义处理、状态合并的理论依据，并调研相关生态组件的支持情况。