https://img-beg-sg-1252771144.cos.ap-singapore.myqcloud.com/20221020144100.png 看这个图，窗口结束的时候，会产生反压，导致前边的 busy 直接是0，不干活了
https://img-beg-sg-1252771144.cos.ap-singapore.myqcloud.com/20221020152835.png 这个是前边在正常消费处理的时候 macia kk <pre...@gmail.com> 于2022年10月20日周四 14:24写道： > Hi yidan > > 我的的意思是，假设上游 1-10 分钟在处理数据，然后第11分钟就把大批量数据发给 sink，然后上游继续进行 10-20的处理，但是这时候 > sink 由于数据量大产生了阻塞，造成反压反馈给上游，上游就变慢了。但实际上如果没有反压机制。10-20 的时候，sink > 其实可以慢慢写完的。唯一的区别是他发送了一个反压信号，导致上游处理变慢。不知道理解的对不对。 > > > 为了要10分钟发送，是因为上游太多数据， 所以我先提前用窗口个聚合一下，目前一秒将近有 800MB 的流量 > > > > Shammon FY <zjur...@gmail.com> 于2022年10月20日周四 11:48写道： > >> 如果必须要10分钟，但是key比较分散，感觉这种情况可以增加资源加大一下并发试试，减少每个task发出的数据量 >> >> On Thu, Oct 20, 2022 at 9:49 AM yidan zhao <hinobl...@gmail.com> wrote: >> >> > 这个描述前后矛盾，写出速度跟不上导致反压，那控制写出速度不是问题更大。不过你不需要考虑这些，因为你控制不了写出速度，只能控制写出时机。 >> > >> > 写出时机是由window的结束时间和watermark决定的，所以如果真要解决，需要控制分窗不要固定整点10分钟。 >> > >> > macia kk <pre...@gmail.com> 于2022年10月20日周四 00:57写道： >> > > >> > > 聚合10分钟再输出，到10分钟的时候由于积攒了很多数据，写出速度跟不上，导致反压，然后上游消费就处理变慢了。 >> > > >> > > 如果控制一下写出的速度，让他慢慢写会不会好一些 >> > >> >
