回复： FlinkSQL大窗口小步长的滑动窗口解决方案

[tanjialiang <ta...@126.com>]

Hi, Shammon FY.

理论上提高并行度是可以缓解，但是并行度调整太大对成本要求可能会比较高。因为写入其实不需要占用太多的资源，只是窗口触发后数据量过大（用户的基数），每条数据合并的操作成本过高（一条数据的窗口聚合成本需要合并24*60/5=288次）。


现在我只能想到以下几种解决办法
1. 将窗口步长往上调，这个问题可以从根本上解决（步长过长意味着窗口触发的时间会延后）
2. 步长可以往上调，使用early-fire机制，将未计算完成的窗口直接下发（触发的数据可能不符合近24小时的业务含义，下游系统需要支持upsert）
3. 借助外部存储，flink直接同步或者预聚合的方式写入一个OLAP系统（譬如doris/ck），读时再聚合（需要一个稳定可靠的外部存储）


你这边用flink做滑动窗口的计算会遇到这样的问题吗？是否还有其他更好解决办法？
十分期待你的反馈
best, 
tanjialiang.
---- 回复的原邮件 ----
| 发件人 | Shammon FY<zj...@gmail.com> |
| 发送日期 | 2023年5月29日 09:08 |
| 收件人 | <us...@flink.apache.org> |
| 主题 | Re: FlinkSQL大窗口小步长的滑动窗口解决方案 |
Hi,

这是窗口触发后发送的数据量过大吗？调大资源，加大窗口计算的并发度是否可以缓解这个问题？

Best,
Shammon FY

On Fri, May 26, 2023 at 2:03 PM tanjialiang <ta...@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.