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