Hi, Shammon FY. 理论上提高并行度是可以缓解，但是并行度调整太大对成本要求可能会比较高。因为写入其实不需要占用太多的资源，只是窗口触发后数据量过大（用户的基数），每条数据合并的操作成本过高（一条数据的窗口聚合成本需要合并24*60/5=288次）。
现在我只能想到以下几种解决办法 1. 将窗口步长往上调，这个问题可以从根本上解决（步长过长意味着窗口触发的时间会延后） 2. 步长可以往上调，使用early-fire机制，将未计算完成的窗口直接下发（触发的数据可能不符合近24小时的业务含义，下游系统需要支持upsert） 3. 借助外部存储，flink直接同步或者预聚合的方式写入一个OLAP系统（譬如doris/ck），读时再聚合（需要一个稳定可靠的外部存储） 你这边用flink做滑动窗口的计算会遇到这样的问题吗？是否还有其他更好解决办法？ 十分期待你的反馈 best, tanjialiang. ---- 回复的原邮件 ---- | 发件人 | Shammon FY<zjur...@gmail.com> | | 发送日期 | 2023年5月29日 09:08 | | 收件人 | <user-zh@flink.apache.org> | | 主题 | Re: FlinkSQL大窗口小步长的滑动窗口解决方案 | Hi, 这是窗口触发后发送的数据量过大吗？调大资源，加大窗口计算的并发度是否可以缓解这个问题？ Best, Shammon FY On Fri, May 26, 2023 at 2:03 PM tanjialiang <tanjl_w...@126.com> wrote: Hi, all. 我在使用FlinkSQL的window tvf滑动窗口时遇到一些问题。 滑动步长为5分钟，窗口为24小时，group by user_id的滑动窗口，当任务挂掉了或者从kafka的earliest-offset消费，checkpoint很难成功。 因为从earliest开始消费，数据很快就会堆满缓冲区产生背压，这时这一批数据可能会触发N次窗口计算往下游发，每次触发的操作成本是（用户基数 * 24 * 60 / 5），checkpoint barrier可能会一直卡住。 这时候有什么办法可以破局吗？ best, tanjialiang.
