关于反压的问题

[nobleyd]

假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。

A是Kafka数据源，数据qps很平滑。
B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。

总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）

对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
C task busy，进而导致B被反压，即B的backpress值很高。

此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。

想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[东东]

flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。

在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：

>假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
>
>A是Kafka数据源，数据qps很平滑。
>B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
>C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
>
>总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
>
>对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
>C task busy，进而导致B被反压，即B的backpress值很高。
>
>此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
> 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
>但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
>为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
>
>想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
>还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[nobleyd]

flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive
buffer满，然后A被反压。
如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。

东东 <[hidden email]> 于2021年6月15日周二 下午7:07写道：

>
> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。
>
> 在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：
> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
> >
> >A是Kafka数据源，数据qps很平滑。
> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
> >
> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
> >
> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
> >C task busy，进而导致B被反压，即B的backpress值很高。
> >
> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
> >
> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[东东]

B到C如何分割成2个任务，你是打算把B里面每个Window的数据都Sink出来，然后在另外一个任务里读进来再用C处理么?


这样做的意义何在呢？仅仅从监控层面看不见反压而已(反压实际上转移到连接B和C的存储上来了)，整体的系统开销是上升的，对吞吐和延迟恐怕并没有正面的影响。


对性能影响大的肯定是瓶颈部分，不提高C的处理能力，优化其他部分没有多大意义。


如果只是希望反压的影响更平滑，可以尝试增大buffer，整体开销恐怕还是比增加一个任务要小。


在 2021-06-15 20:03:32，"yidan zhao" <[hidden email]> 写道：

>flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive
>buffer满，然后A被反压。
>如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。
>
>东东 <[hidden email]> 于2021年6月15日周二 下午7:07写道：
>>
>> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
>> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。
>>
>> 在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：
>> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
>> >
>> >A是Kafka数据源，数据qps很平滑。
>> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
>> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
>> >
>> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
>> >
>> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
>> >C task busy，进而导致B被反压，即B的backpress值很高。
>> >
>> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
>> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
>> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
>> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
>> >
>> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
>> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[nobleyd]

我不计划做分开的尝试，目前只是分析。
但我还是认为，按照flink单个sub-task只是单线程模型的话，如果这个线程正在请求输出buffer，结果请求不到，挂起等待输出buffer，即被反压。这种情况下肯定是不会处理输入的。
但实际上对于window这类算子来说，处理输入并不会导致马上更多输出，而只是更新window算子的状态而已（比如pv累加），这么考虑的话，我更希望B被反压时候，仍然继续处理A的输出，而不是不处理进而导致A被反压。

东东 <[hidden email]> 于2021年6月16日周三 上午10:59写道：

>
>
>
> B到C如何分割成2个任务，你是打算把B里面每个Window的数据都Sink出来，然后在另外一个任务里读进来再用C处理么?
>
>
> 这样做的意义何在呢？仅仅从监控层面看不见反压而已(反压实际上转移到连接B和C的存储上来了)，整体的系统开销是上升的，对吞吐和延迟恐怕并没有正面的影响。
>
>
> 对性能影响大的肯定是瓶颈部分，不提高C的处理能力，优化其他部分没有多大意义。
>
>
> 如果只是希望反压的影响更平滑，可以尝试增大buffer，整体开销恐怕还是比增加一个任务要小。
>
>
> 在 2021-06-15 20:03:32，"yidan zhao" <[hidden email]> 写道：
> >flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive
> >buffer满，然后A被反压。
> >如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。
> >
> >东东 <[hidden email]> 于2021年6月15日周二 下午7:07写道：
> >>
> >> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
> >> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。
> >>
> >> 在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：
> >> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
> >> >
> >> >A是Kafka数据源，数据qps很平滑。
> >> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
> >> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
> >> >
> >> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
> >> >
> >> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
> >> >C task busy，进而导致B被反压，即B的backpress值很高。
> >> >
> >> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
> >> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
> >> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
> >> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
> >> >
> >> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
> >> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[东东]

这中间有buffer的存在啊，并不是只要下游处理慢，buffer就一定慢，要看你究竟有多慢，还有上游究竟有多快。



目前flink是通允许你控制buffer的大小，来调整这个容忍程度的，但这个容忍肯定是有限度。


另外，你似乎在意的是数据buffer在哪里，buffer在window里和buffer在上游，从全局看，肯定是有持久化能力的上游更靠谱。如果buffer在window算子里，那么：
1、你的checkpoint会很慢，因为aligned checkpoint会等对齐之后才能完成。
2、如果启用unaligned checkpoint的话，checkpoint会变大，且如果没有反压上游，让上游减速的机制的话，这个增大会无法控制。


目前的机制提供了一种有兜底的灵活调整能力，其实是简单合理的设计。



在 2021-06-16 11:04:53，"yidan zhao" <[hidden email]> 写道：

>我不计划做分开的尝试，目前只是分析。
>但我还是认为，按照flink单个sub-task只是单线程模型的话，如果这个线程正在请求输出buffer，结果请求不到，挂起等待输出buffer，即被反压。这种情况下肯定是不会处理输入的。
>但实际上对于window这类算子来说，处理输入并不会导致马上更多输出，而只是更新window算子的状态而已（比如pv累加），这么考虑的话，我更希望B被反压时候，仍然继续处理A的输出，而不是不处理进而导致A被反压。
>
>东东 <[hidden email]> 于2021年6月16日周三 上午10:59写道：
>>
>>
>>
>> B到C如何分割成2个任务，你是打算把B里面每个Window的数据都Sink出来，然后在另外一个任务里读进来再用C处理么?
>>
>>
>> 这样做的意义何在呢？仅仅从监控层面看不见反压而已(反压实际上转移到连接B和C的存储上来了)，整体的系统开销是上升的，对吞吐和延迟恐怕并没有正面的影响。
>>
>>
>> 对性能影响大的肯定是瓶颈部分，不提高C的处理能力，优化其他部分没有多大意义。
>>
>>
>> 如果只是希望反压的影响更平滑，可以尝试增大buffer，整体开销恐怕还是比增加一个任务要小。
>>
>>
>> 在 2021-06-15 20:03:32，"yidan zhao" <[hidden email]> 写道：
>> >flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive
>> >buffer满，然后A被反压。
>> >如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。
>> >
>> >东东 <[hidden email]> 于2021年6月15日周二 下午7:07写道：
>> >>
>> >> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
>> >> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。
>> >>
>> >> 在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：
>> >> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
>> >> >
>> >> >A是Kafka数据源，数据qps很平滑。
>> >> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
>> >> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
>> >> >
>> >> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
>> >> >
>> >> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
>> >> >C task busy，进而导致B被反压，即B的backpress值很高。
>> >> >
>> >> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
>> >> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
>> >> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
>> >> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
>> >> >
>> >> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
>> >> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[nobleyd]

不是呀，对于window来说，我每个key假设统计的是pv，pv=1和pv=2的存储空间是一样的，如果上游不发数据过来，这个pv就停滞在某个值不变了，发数据过来也不会导致window的数据空间变大，只是状态值变。
我考虑的是window这个sub-taskd单线程模型问题。不是buffer的问题，对于非window类算子这个问题不存在，但是window的触发是基于时间的。这意味着更多的上游数据的到位，加重的主要是cpu压力，而不是内存等状态存储压力。

东东 <[hidden email]> 于2021年6月16日周三 上午11:36写道：

>
>
>
> 这中间有buffer的存在啊，并不是只要下游处理慢，buffer就一定慢，要看你究竟有多慢，还有上游究竟有多快。
>
>
>
> 目前flink是通允许你控制buffer的大小，来调整这个容忍程度的，但这个容忍肯定是有限度。
>
>
> 另外，你似乎在意的是数据buffer在哪里，buffer在window里和buffer在上游，从全局看，肯定是有持久化能力的上游更靠谱。如果buffer在window算子里，那么：
> 1、你的checkpoint会很慢，因为aligned checkpoint会等对齐之后才能完成。
> 2、如果启用unaligned checkpoint的话，checkpoint会变大，且如果没有反压上游，让上游减速的机制的话，这个增大会无法控制。
>
>
> 目前的机制提供了一种有兜底的灵活调整能力，其实是简单合理的设计。
>
>
>
> 在 2021-06-16 11:04:53，"yidan zhao" <[hidden email]> 写道：
> >我不计划做分开的尝试，目前只是分析。
> >但我还是认为，按照flink单个sub-task只是单线程模型的话，如果这个线程正在请求输出buffer，结果请求不到，挂起等待输出buffer，即被反压。这种情况下肯定是不会处理输入的。
> >但实际上对于window这类算子来说，处理输入并不会导致马上更多输出，而只是更新window算子的状态而已（比如pv累加），这么考虑的话，我更希望B被反压时候，仍然继续处理A的输出，而不是不处理进而导致A被反压。
> >
> >东东 <[hidden email]> 于2021年6月16日周三 上午10:59写道：
> >>
> >>
> >>
> >> B到C如何分割成2个任务，你是打算把B里面每个Window的数据都Sink出来，然后在另外一个任务里读进来再用C处理么?
> >>
> >>
> >> 这样做的意义何在呢？仅仅从监控层面看不见反压而已(反压实际上转移到连接B和C的存储上来了)，整体的系统开销是上升的，对吞吐和延迟恐怕并没有正面的影响。
> >>
> >>
> >> 对性能影响大的肯定是瓶颈部分，不提高C的处理能力，优化其他部分没有多大意义。
> >>
> >>
> >> 如果只是希望反压的影响更平滑，可以尝试增大buffer，整体开销恐怕还是比增加一个任务要小。
> >>
> >>
> >> 在 2021-06-15 20:03:32，"yidan zhao" <[hidden email]> 写道：
> >> >flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive
> >> >buffer满，然后A被反压。
> >> >如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。
> >> >
> >> >东东 <[hidden email]> 于2021年6月15日周二 下午7:07写道：
> >> >>
> >> >> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
> >> >> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。
> >> >>
> >> >> 在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：
> >> >> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
> >> >> >
> >> >> >A是Kafka数据源，数据qps很平滑。
> >> >> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
> >> >> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
> >> >> >
> >> >> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
> >> >> >
> >> >> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
> >> >> >C task busy，进而导致B被反压，即B的backpress值很高。
> >> >> >
> >> >> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
> >> >> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
> >> >> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
> >> >> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
> >> >> >
> >> >> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
> >> >> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[东东]

如果B处理完的数据结构很小，比如你就是一个简单的count，那么buffer里就可以放很多个window，如果这样buffer都满了，说明上下游处理能力不匹配非常严重啊，也许下游永远也别想跟上了，这个时候，你是希望上游慢一点，还是上游保持现在的速度，一直到把内存撑爆(也就是不可控)，还是咋的？






在 2021-06-16 11:41:08，"yidan zhao" <[hidden email]> 写道：

>不是呀，对于window来说，我每个key假设统计的是pv，pv=1和pv=2的存储空间是一样的，如果上游不发数据过来，这个pv就停滞在某个值不变了，发数据过来也不会导致window的数据空间变大，只是状态值变。
>我考虑的是window这个sub-taskd单线程模型问题。不是buffer的问题，对于非window类算子这个问题不存在，但是window的触发是基于时间的。这意味着更多的上游数据的到位，加重的主要是cpu压力，而不是内存等状态存储压力。
>
>东东 <[hidden email]> 于2021年6月16日周三 上午11:36写道：
>>
>>
>>
>> 这中间有buffer的存在啊，并不是只要下游处理慢，buffer就一定慢，要看你究竟有多慢，还有上游究竟有多快。
>>
>>
>>
>> 目前flink是通允许你控制buffer的大小，来调整这个容忍程度的，但这个容忍肯定是有限度。
>>
>>
>> 另外，你似乎在意的是数据buffer在哪里，buffer在window里和buffer在上游，从全局看，肯定是有持久化能力的上游更靠谱。如果buffer在window算子里，那么：
>> 1、你的checkpoint会很慢，因为aligned checkpoint会等对齐之后才能完成。
>> 2、如果启用unaligned checkpoint的话，checkpoint会变大，且如果没有反压上游，让上游减速的机制的话，这个增大会无法控制。
>>
>>
>> 目前的机制提供了一种有兜底的灵活调整能力，其实是简单合理的设计。
>>
>>
>>
>> 在 2021-06-16 11:04:53，"yidan zhao" <[hidden email]> 写道：
>> >我不计划做分开的尝试，目前只是分析。
>> >但我还是认为，按照flink单个sub-task只是单线程模型的话，如果这个线程正在请求输出buffer，结果请求不到，挂起等待输出buffer，即被反压。这种情况下肯定是不会处理输入的。
>> >但实际上对于window这类算子来说，处理输入并不会导致马上更多输出，而只是更新window算子的状态而已（比如pv累加），这么考虑的话，我更希望B被反压时候，仍然继续处理A的输出，而不是不处理进而导致A被反压。
>> >
>> >东东 <[hidden email]> 于2021年6月16日周三 上午10:59写道：
>> >>
>> >>
>> >>
>> >> B到C如何分割成2个任务，你是打算把B里面每个Window的数据都Sink出来，然后在另外一个任务里读进来再用C处理么?
>> >>
>> >>
>> >> 这样做的意义何在呢？仅仅从监控层面看不见反压而已(反压实际上转移到连接B和C的存储上来了)，整体的系统开销是上升的，对吞吐和延迟恐怕并没有正面的影响。
>> >>
>> >>
>> >> 对性能影响大的肯定是瓶颈部分，不提高C的处理能力，优化其他部分没有多大意义。
>> >>
>> >>
>> >> 如果只是希望反压的影响更平滑，可以尝试增大buffer，整体开销恐怕还是比增加一个任务要小。
>> >>
>> >>
>> >> 在 2021-06-15 20:03:32，"yidan zhao" <[hidden email]> 写道：
>> >> >flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive
>> >> >buffer满，然后A被反压。
>> >> >如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。
>> >> >
>> >> >东东 <[hidden email]> 于2021年6月15日周二 下午7:07写道：
>> >> >>
>> >> >> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
>> >> >> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。
>> >> >>
>> >> >> 在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：
>> >> >> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
>> >> >> >
>> >> >> >A是Kafka数据源，数据qps很平滑。
>> >> >> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
>> >> >> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
>> >> >> >
>> >> >> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
>> >> >> >
>> >> >> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
>> >> >> >C task busy，进而导致B被反压，即B的backpress值很高。
>> >> >> >
>> >> >> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
>> >> >> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
>> >> >> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
>> >> >> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
>> >> >> >
>> >> >> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
>> >> >> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[nobleyd]

下游并不是“很慢”，只是由于下游是接受B输出的，而B的输出是集中窗口出发的，0-5分数据都是在6min触发输出到C。假设C需要1min的时间处理完这波数据。那么6-7min的时间段内，B都处于反压状态，进而A也反压，等到7min后，B才开始继续处理A输出的6-10min的数据，这样就浪费了至少1min的时间呀。B其实从6min就可以继续处理上游数据。

东东 <[hidden email]> 于2021年6月16日周三 下午12:32写道：

>
>
>
>
> 如果B处理完的数据结构很小，比如你就是一个简单的count，那么buffer里就可以放很多个window，如果这样buffer都满了，说明上下游处理能力不匹配非常严重啊，也许下游永远也别想跟上了，这个时候，你是希望上游慢一点，还是上游保持现在的速度，一直到把内存撑爆(也就是不可控)，还是咋的？
>
>
>
>
>
>
> 在 2021-06-16 11:41:08，"yidan zhao" <[hidden email]> 写道：
> >不是呀，对于window来说，我每个key假设统计的是pv，pv=1和pv=2的存储空间是一样的，如果上游不发数据过来，这个pv就停滞在某个值不变了，发数据过来也不会导致window的数据空间变大，只是状态值变。
> >我考虑的是window这个sub-taskd单线程模型问题。不是buffer的问题，对于非window类算子这个问题不存在，但是window的触发是基于时间的。这意味着更多的上游数据的到位，加重的主要是cpu压力，而不是内存等状态存储压力。
> >
> >东东 <[hidden email]> 于2021年6月16日周三 上午11:36写道：
> >>
> >>
> >>
> >> 这中间有buffer的存在啊，并不是只要下游处理慢，buffer就一定慢，要看你究竟有多慢，还有上游究竟有多快。
> >>
> >>
> >>
> >> 目前flink是通允许你控制buffer的大小，来调整这个容忍程度的，但这个容忍肯定是有限度。
> >>
> >>
> >> 另外，你似乎在意的是数据buffer在哪里，buffer在window里和buffer在上游，从全局看，肯定是有持久化能力的上游更靠谱。如果buffer在window算子里，那么：
> >> 1、你的checkpoint会很慢，因为aligned checkpoint会等对齐之后才能完成。
> >> 2、如果启用unaligned checkpoint的话，checkpoint会变大，且如果没有反压上游，让上游减速的机制的话，这个增大会无法控制。
> >>
> >>
> >> 目前的机制提供了一种有兜底的灵活调整能力，其实是简单合理的设计。
> >>
> >>
> >>
> >> 在 2021-06-16 11:04:53，"yidan zhao" <[hidden email]> 写道：
> >> >我不计划做分开的尝试，目前只是分析。
> >> >但我还是认为，按照flink单个sub-task只是单线程模型的话，如果这个线程正在请求输出buffer，结果请求不到，挂起等待输出buffer，即被反压。这种情况下肯定是不会处理输入的。
> >> >但实际上对于window这类算子来说，处理输入并不会导致马上更多输出，而只是更新window算子的状态而已（比如pv累加），这么考虑的话，我更希望B被反压时候，仍然继续处理A的输出，而不是不处理进而导致A被反压。
> >> >
> >> >东东 <[hidden email]> 于2021年6月16日周三 上午10:59写道：
> >> >>
> >> >>
> >> >>
> >> >> B到C如何分割成2个任务，你是打算把B里面每个Window的数据都Sink出来，然后在另外一个任务里读进来再用C处理么?
> >> >>
> >> >>
> >> >> 这样做的意义何在呢？仅仅从监控层面看不见反压而已(反压实际上转移到连接B和C的存储上来了)，整体的系统开销是上升的，对吞吐和延迟恐怕并没有正面的影响。
> >> >>
> >> >>
> >> >> 对性能影响大的肯定是瓶颈部分，不提高C的处理能力，优化其他部分没有多大意义。
> >> >>
> >> >>
> >> >> 如果只是希望反压的影响更平滑，可以尝试增大buffer，整体开销恐怕还是比增加一个任务要小。
> >> >>
> >> >>
> >> >> 在 2021-06-15 20:03:32，"yidan zhao" <[hidden email]> 写道：
> >> >> >flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive
> >> >> >buffer满，然后A被反压。
> >> >> >如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。
> >> >> >
> >> >> >东东 <[hidden email]> 于2021年6月15日周二 下午7:07写道：
> >> >> >>
> >> >> >> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
> >> >> >> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。
> >> >> >>
> >> >> >> 在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：
> >> >> >> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
> >> >> >> >
> >> >> >> >A是Kafka数据源，数据qps很平滑。
> >> >> >> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
> >> >> >> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
> >> >> >> >
> >> >> >> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
> >> >> >> >
> >> >> >> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
> >> >> >> >C task busy，进而导致B被反压，即B的backpress值很高。
> >> >> >> >
> >> >> >> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
> >> >> >> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
> >> >> >> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
> >> >> >> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
> >> >> >> >
> >> >> >> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
> >> >> >> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[东东]

就你这个例子，只要buffer足够大，B在6min产生的数据都能放进buffer里，B就感受不到反压的影响，可以继续处理上游的数据啊，只要下一个窗口触发之前，C能处理完buffer中的数据，那么B全程都不会被限制。buffer在send和receive两端都是有的，B只关心自己的send buffer还能不能写进去。


在 2021-06-16 13:32:52，"yidan zhao" <[hidden email]> 写道：

>下游并不是“很慢”，只是由于下游是接受B输出的，而B的输出是集中窗口出发的，0-5分数据都是在6min触发输出到C。假设C需要1min的时间处理完这波数据。那么6-7min的时间段内，B都处于反压状态，进而A也反压，等到7min后，B才开始继续处理A输出的6-10min的数据，这样就浪费了至少1min的时间呀。B其实从6min就可以继续处理上游数据。
>
>东东 <[hidden email]> 于2021年6月16日周三 下午12:32写道：
>>
>>
>>
>>
>> 如果B处理完的数据结构很小，比如你就是一个简单的count，那么buffer里就可以放很多个window，如果这样buffer都满了，说明上下游处理能力不匹配非常严重啊，也许下游永远也别想跟上了，这个时候，你是希望上游慢一点，还是上游保持现在的速度，一直到把内存撑爆(也就是不可控)，还是咋的？
>>
>>
>>
>>
>>
>>
>> 在 2021-06-16 11:41:08，"yidan zhao" <[hidden email]> 写道：
>> >不是呀，对于window来说，我每个key假设统计的是pv，pv=1和pv=2的存储空间是一样的，如果上游不发数据过来，这个pv就停滞在某个值不变了，发数据过来也不会导致window的数据空间变大，只是状态值变。
>> >我考虑的是window这个sub-taskd单线程模型问题。不是buffer的问题，对于非window类算子这个问题不存在，但是window的触发是基于时间的。这意味着更多的上游数据的到位，加重的主要是cpu压力，而不是内存等状态存储压力。
>> >
>> >东东 <[hidden email]> 于2021年6月16日周三 上午11:36写道：
>> >>
>> >>
>> >>
>> >> 这中间有buffer的存在啊，并不是只要下游处理慢，buffer就一定慢，要看你究竟有多慢，还有上游究竟有多快。
>> >>
>> >>
>> >>
>> >> 目前flink是通允许你控制buffer的大小，来调整这个容忍程度的，但这个容忍肯定是有限度。
>> >>
>> >>
>> >> 另外，你似乎在意的是数据buffer在哪里，buffer在window里和buffer在上游，从全局看，肯定是有持久化能力的上游更靠谱。如果buffer在window算子里，那么：
>> >> 1、你的checkpoint会很慢，因为aligned checkpoint会等对齐之后才能完成。
>> >> 2、如果启用unaligned checkpoint的话，checkpoint会变大，且如果没有反压上游，让上游减速的机制的话，这个增大会无法控制。
>> >>
>> >>
>> >> 目前的机制提供了一种有兜底的灵活调整能力，其实是简单合理的设计。
>> >>
>> >>
>> >>
>> >> 在 2021-06-16 11:04:53，"yidan zhao" <[hidden email]> 写道：
>> >> >我不计划做分开的尝试，目前只是分析。
>> >> >但我还是认为，按照flink单个sub-task只是单线程模型的话，如果这个线程正在请求输出buffer，结果请求不到，挂起等待输出buffer，即被反压。这种情况下肯定是不会处理输入的。
>> >> >但实际上对于window这类算子来说，处理输入并不会导致马上更多输出，而只是更新window算子的状态而已（比如pv累加），这么考虑的话，我更希望B被反压时候，仍然继续处理A的输出，而不是不处理进而导致A被反压。
>> >> >
>> >> >东东 <[hidden email]> 于2021年6月16日周三 上午10:59写道：
>> >> >>
>> >> >>
>> >> >>
>> >> >> B到C如何分割成2个任务，你是打算把B里面每个Window的数据都Sink出来，然后在另外一个任务里读进来再用C处理么?
>> >> >>
>> >> >>
>> >> >> 这样做的意义何在呢？仅仅从监控层面看不见反压而已(反压实际上转移到连接B和C的存储上来了)，整体的系统开销是上升的，对吞吐和延迟恐怕并没有正面的影响。
>> >> >>
>> >> >>
>> >> >> 对性能影响大的肯定是瓶颈部分，不提高C的处理能力，优化其他部分没有多大意义。
>> >> >>
>> >> >>
>> >> >> 如果只是希望反压的影响更平滑，可以尝试增大buffer，整体开销恐怕还是比增加一个任务要小。
>> >> >>
>> >> >>
>> >> >> 在 2021-06-15 20:03:32，"yidan zhao" <[hidden email]> 写道：
>> >> >> >flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive
>> >> >> >buffer满，然后A被反压。
>> >> >> >如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。
>> >> >> >
>> >> >> >东东 <[hidden email]> 于2021年6月15日周二 下午7:07写道：
>> >> >> >>
>> >> >> >> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
>> >> >> >> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。
>> >> >> >>
>> >> >> >> 在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：
>> >> >> >> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
>> >> >> >> >
>> >> >> >> >A是Kafka数据源，数据qps很平滑。
>> >> >> >> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
>> >> >> >> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
>> >> >> >> >
>> >> >> >> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
>> >> >> >> >
>> >> >> >> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
>> >> >> >> >C task busy，进而导致B被反压，即B的backpress值很高。
>> >> >> >> >
>> >> >> >> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
>> >> >> >> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
>> >> >> >> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
>> >> >> >> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
>> >> >> >> >
>> >> >> >> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
>> >> >> >> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[nobleyd]

嗯，你这个说法我同意。

东东 <[hidden email]> 于2021年6月16日周三 下午2:34写道：

>
> 就你这个例子，只要buffer足够大，B在6min产生的数据都能放进buffer里，B就感受不到反压的影响，可以继续处理上游的数据啊，只要下一个窗口触发之前，C能处理完buffer中的数据，那么B全程都不会被限制。buffer在send和receive两端都是有的，B只关心自己的send buffer还能不能写进去。
>
>
> 在 2021-06-16 13:32:52，"yidan zhao" <[hidden email]> 写道：
> >下游并不是“很慢”，只是由于下游是接受B输出的，而B的输出是集中窗口出发的，0-5分数据都是在6min触发输出到C。假设C需要1min的时间处理完这波数据。那么6-7min的时间段内，B都处于反压状态，进而A也反压，等到7min后，B才开始继续处理A输出的6-10min的数据，这样就浪费了至少1min的时间呀。B其实从6min就可以继续处理上游数据。
> >
> >东东 <[hidden email]> 于2021年6月16日周三 下午12:32写道：
> >>
> >>
> >>
> >>
> >> 如果B处理完的数据结构很小，比如你就是一个简单的count，那么buffer里就可以放很多个window，如果这样buffer都满了，说明上下游处理能力不匹配非常严重啊，也许下游永远也别想跟上了，这个时候，你是希望上游慢一点，还是上游保持现在的速度，一直到把内存撑爆(也就是不可控)，还是咋的？
> >>
> >>
> >>
> >>
> >>
> >>
> >> 在 2021-06-16 11:41:08，"yidan zhao" <[hidden email]> 写道：
> >> >不是呀，对于window来说，我每个key假设统计的是pv，pv=1和pv=2的存储空间是一样的，如果上游不发数据过来，这个pv就停滞在某个值不变了，发数据过来也不会导致window的数据空间变大，只是状态值变。
> >> >我考虑的是window这个sub-taskd单线程模型问题。不是buffer的问题，对于非window类算子这个问题不存在，但是window的触发是基于时间的。这意味着更多的上游数据的到位，加重的主要是cpu压力，而不是内存等状态存储压力。
> >> >
> >> >东东 <[hidden email]> 于2021年6月16日周三 上午11:36写道：
> >> >>
> >> >>
> >> >>
> >> >> 这中间有buffer的存在啊，并不是只要下游处理慢，buffer就一定慢，要看你究竟有多慢，还有上游究竟有多快。
> >> >>
> >> >>
> >> >>
> >> >> 目前flink是通允许你控制buffer的大小，来调整这个容忍程度的，但这个容忍肯定是有限度。
> >> >>
> >> >>
> >> >> 另外，你似乎在意的是数据buffer在哪里，buffer在window里和buffer在上游，从全局看，肯定是有持久化能力的上游更靠谱。如果buffer在window算子里，那么：
> >> >> 1、你的checkpoint会很慢，因为aligned checkpoint会等对齐之后才能完成。
> >> >> 2、如果启用unaligned checkpoint的话，checkpoint会变大，且如果没有反压上游，让上游减速的机制的话，这个增大会无法控制。
> >> >>
> >> >>
> >> >> 目前的机制提供了一种有兜底的灵活调整能力，其实是简单合理的设计。
> >> >>
> >> >>
> >> >>
> >> >> 在 2021-06-16 11:04:53，"yidan zhao" <[hidden email]> 写道：
> >> >> >我不计划做分开的尝试，目前只是分析。
> >> >> >但我还是认为，按照flink单个sub-task只是单线程模型的话，如果这个线程正在请求输出buffer，结果请求不到，挂起等待输出buffer，即被反压。这种情况下肯定是不会处理输入的。
> >> >> >但实际上对于window这类算子来说，处理输入并不会导致马上更多输出，而只是更新window算子的状态而已（比如pv累加），这么考虑的话，我更希望B被反压时候，仍然继续处理A的输出，而不是不处理进而导致A被反压。
> >> >> >
> >> >> >东东 <[hidden email]> 于2021年6月16日周三 上午10:59写道：
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> B到C如何分割成2个任务，你是打算把B里面每个Window的数据都Sink出来，然后在另外一个任务里读进来再用C处理么?
> >> >> >>
> >> >> >>
> >> >> >> 这样做的意义何在呢？仅仅从监控层面看不见反压而已(反压实际上转移到连接B和C的存储上来了)，整体的系统开销是上升的，对吞吐和延迟恐怕并没有正面的影响。
> >> >> >>
> >> >> >>
> >> >> >> 对性能影响大的肯定是瓶颈部分，不提高C的处理能力，优化其他部分没有多大意义。
> >> >> >>
> >> >> >>
> >> >> >> 如果只是希望反压的影响更平滑，可以尝试增大buffer，整体开销恐怕还是比增加一个任务要小。
> >> >> >>
> >> >> >>
> >> >> >> 在 2021-06-15 20:03:32，"yidan zhao" <[hidden email]> 写道：
> >> >> >> >flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive
> >> >> >> >buffer满，然后A被反压。
> >> >> >> >如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。
> >> >> >> >
> >> >> >> >东东 <[hidden email]> 于2021年6月15日周二 下午7:07写道：
> >> >> >> >>
> >> >> >> >> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
> >> >> >> >> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。
> >> >> >> >>
> >> >> >> >> 在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：
> >> >> >> >> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
> >> >> >> >> >
> >> >> >> >> >A是Kafka数据源，数据qps很平滑。
> >> >> >> >> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
> >> >> >> >> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
> >> >> >> >> >
> >> >> >> >> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
> >> >> >> >> >
> >> >> >> >> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
> >> >> >> >> >C task busy，进而导致B被反压，即B的backpress值很高。
> >> >> >> >> >
> >> >> >> >> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
> >> >> >> >> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
> >> >> >> >> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
> >> >> >> >> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
> >> >> >> >> >
> >> >> >> >> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
> >> >> >> >> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？

[nobleyd]

@东东 帮忙分析个其他异常吧。异常如下图所示，我是standalone集群，每天一会一个报错，目前阶段是这个报错。

yidan zhao <[hidden email]> 于2021年6月16日周三 下午3:32写道：

>
> 嗯，你这个说法我同意。
>
> 东东 <[hidden email]> 于2021年6月16日周三 下午2:34写道：
> >
> > 就你这个例子，只要buffer足够大，B在6min产生的数据都能放进buffer里，B就感受不到反压的影响，可以继续处理上游的数据啊，只要下一个窗口触发之前，C能处理完buffer中的数据，那么B全程都不会被限制。buffer在send和receive两端都是有的，B只关心自己的send buffer还能不能写进去。
> >
> >
> > 在 2021-06-16 13:32:52，"yidan zhao" <[hidden email]> 写道：
> > >下游并不是“很慢”，只是由于下游是接受B输出的，而B的输出是集中窗口出发的，0-5分数据都是在6min触发输出到C。假设C需要1min的时间处理完这波数据。那么6-7min的时间段内，B都处于反压状态，进而A也反压，等到7min后，B才开始继续处理A输出的6-10min的数据，这样就浪费了至少1min的时间呀。B其实从6min就可以继续处理上游数据。
> > >
> > >东东 <[hidden email]> 于2021年6月16日周三 下午12:32写道：
> > >>
> > >>
> > >>
> > >>
> > >> 如果B处理完的数据结构很小，比如你就是一个简单的count，那么buffer里就可以放很多个window，如果这样buffer都满了，说明上下游处理能力不匹配非常严重啊，也许下游永远也别想跟上了，这个时候，你是希望上游慢一点，还是上游保持现在的速度，一直到把内存撑爆(也就是不可控)，还是咋的？
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 在 2021-06-16 11:41:08，"yidan zhao" <[hidden email]> 写道：
> > >> >不是呀，对于window来说，我每个key假设统计的是pv，pv=1和pv=2的存储空间是一样的，如果上游不发数据过来，这个pv就停滞在某个值不变了，发数据过来也不会导致window的数据空间变大，只是状态值变。
> > >> >我考虑的是window这个sub-taskd单线程模型问题。不是buffer的问题，对于非window类算子这个问题不存在，但是window的触发是基于时间的。这意味着更多的上游数据的到位，加重的主要是cpu压力，而不是内存等状态存储压力。
> > >> >
> > >> >东东 <[hidden email]> 于2021年6月16日周三 上午11:36写道：
> > >> >>
> > >> >>
> > >> >>
> > >> >> 这中间有buffer的存在啊，并不是只要下游处理慢，buffer就一定慢，要看你究竟有多慢，还有上游究竟有多快。
> > >> >>
> > >> >>
> > >> >>
> > >> >> 目前flink是通允许你控制buffer的大小，来调整这个容忍程度的，但这个容忍肯定是有限度。
> > >> >>
> > >> >>
> > >> >> 另外，你似乎在意的是数据buffer在哪里，buffer在window里和buffer在上游，从全局看，肯定是有持久化能力的上游更靠谱。如果buffer在window算子里，那么：
> > >> >> 1、你的checkpoint会很慢，因为aligned checkpoint会等对齐之后才能完成。
> > >> >> 2、如果启用unaligned checkpoint的话，checkpoint会变大，且如果没有反压上游，让上游减速的机制的话，这个增大会无法控制。
> > >> >>
> > >> >>
> > >> >> 目前的机制提供了一种有兜底的灵活调整能力，其实是简单合理的设计。
> > >> >>
> > >> >>
> > >> >>
> > >> >> 在 2021-06-16 11:04:53，"yidan zhao" <[hidden email]> 写道：
> > >> >> >我不计划做分开的尝试，目前只是分析。
> > >> >> >但我还是认为，按照flink单个sub-task只是单线程模型的话，如果这个线程正在请求输出buffer，结果请求不到，挂起等待输出buffer，即被反压。这种情况下肯定是不会处理输入的。
> > >> >> >但实际上对于window这类算子来说，处理输入并不会导致马上更多输出，而只是更新window算子的状态而已（比如pv累加），这么考虑的话，我更希望B被反压时候，仍然继续处理A的输出，而不是不处理进而导致A被反压。
> > >> >> >
> > >> >> >东东 <[hidden email]> 于2021年6月16日周三 上午10:59写道：
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >> B到C如何分割成2个任务，你是打算把B里面每个Window的数据都Sink出来，然后在另外一个任务里读进来再用C处理么?
> > >> >> >>
> > >> >> >>
> > >> >> >> 这样做的意义何在呢？仅仅从监控层面看不见反压而已(反压实际上转移到连接B和C的存储上来了)，整体的系统开销是上升的，对吞吐和延迟恐怕并没有正面的影响。
> > >> >> >>
> > >> >> >>
> > >> >> >> 对性能影响大的肯定是瓶颈部分，不提高C的处理能力，优化其他部分没有多大意义。
> > >> >> >>
> > >> >> >>
> > >> >> >> 如果只是希望反压的影响更平滑，可以尝试增大buffer，整体开销恐怕还是比增加一个任务要小。
> > >> >> >>
> > >> >> >>
> > >> >> >> 在 2021-06-15 20:03:32，"yidan zhao" <[hidden email]> 写道：
> > >> >> >> >flink 的task单线程，我那个问题中，很可能当B被反压时候，线程被卡在向C发送的过程中。这样B本身就无法处理A的输入。进而导致receive
> > >> >> >> >buffer满，然后A被反压。
> > >> >> >> >如上为我的想法，这个也比较坑。如果是这样，那对于我这种类似的case，如果C属于计算复杂的task，B属于window的话。可能需要从B到C之间分割成2个任务。否则性能影响还是比较大的。
> > >> >> >> >
> > >> >> >> >东东 <[hidden email]> 于2021年6月15日周二 下午7:07写道：
> > >> >> >> >>
> > >> >> >> >> flink处理反压，我理解就是靠task之间的send/receive buffer，所以如果仅仅是下游的receive buffer满了，上游的send buffer没满，就不会影响上游，否则就会影响，且影响发生在上游输出结果的时候。
> > >> >> >> >> 所以总体来说就是看你buffer的大小，越大就约能碾平反压的影响，否则就约容易受到影响。
> > >> >> >> >>
> > >> >> >> >> 在 2021-06-15 17:39:26，"yidan zhao" <[hidden email]> 写道：
> > >> >> >> >> >假设任务逻辑为 A => B => C 这样的task序列，其中B是window类型task，使用时间滚动窗口，假设滚动窗口为5min。
> > >> >> >> >> >
> > >> >> >> >> >A是Kafka数据源，数据qps很平滑。
> > >> >> >> >> >B是window类任务，5min滚动窗口，比如0-5分的数据会在6min触发窗口输出。即B的输入是平滑的，但B的输出是集中在6min的（此处以及后续都以0-5min窗口做示例说明）。
> > >> >> >> >> >C是基于B输出的5min特征的一个计算类task，且复杂性也比较高。
> > >> >> >> >> >
> > >> >> >> >> >总结即： A --平滑输出---> B ---窗口触发集中输出--> C（计算复杂）
> > >> >> >> >> >
> > >> >> >> >> >对于0-5min数据，由于B输出集中在6min，且C本身的计算也比较复杂。因此6min时，C task的busy值很容易升高。
> > >> >> >> >> >C task busy，进而导致B被反压，即B的backpress值很高。
> > >> >> >> >> >
> > >> >> >> >> >此时我想知道的是，对于B来说，如果B在6min时候输出很快输出到了C，那么没有残留，此时B虽然被反压，但本质不应该影响B继续处理A输出的数据。
> > >> >> >> >> > 即使B在6min时的数据无法很快输出到C，即输出一部分就开始处于反压状态。
> > >> >> >> >> >但B0-5分的窗口的触发以及触发后的输出可以卡着，我想知道B的输入是否也可能卡住。
> > >> >> >> >> >为什么需要考虑这个呢，是因为我认为这种情况下，B继续处理5-10分的数据只会影响B的窗口状态，并不会导致B新增更多输出。所以我更期望此时不影响B处理A的输出，即B的反压不传播到A。
> > >> >> >> >> >
> > >> >> >> >> >想问问了解的大佬们，这种情况B的反压是否会传播到A呢？当一个task被反压到100%，是无脑传播到上游，导致上游也反压呢？
> > >> >> >> >> >还是独立的逻辑，比如B的输入buffer本身还是可以及时处理掉的，只是B无法输出而已。因此，B并不会导致A反压呢？