Re: flink checkpoint导致反压严重

[赵一旦 <hi...@gmail.com>]

（1）url理论上足够多，也足够随机。而并行度比如是30，url理论上是万、十万、百万、千万级别，理论上不会出现数据倾斜吧。
（2）如果的确有倾斜，那么你那个方法我看不出有啥用，我看你好像是全缓存下来？这没啥用吧。
（3）我的思路，考虑到你是要求1分钟窗口，每个url维度的，response的中位数。所以本质需要url+time维度的全部response数据排序。
         由于url数量可能比较少（比如和并行度类似），导致了数据倾斜。所以key不能仅用url，需要分步。

 分步方法：如果url的访问量总体极大，则response的值应该有很大重复，比如url1对应response=2ms的有1000个，对应3ms的有500个等这种量级。这样的话直接url+response作为key作为第一级统计也可以降低很大压力，同时加了response后应该就够分散了。第2级别拿到的是url级别的不同response+出现次数的数据。根据这些是可以计算中位数的，同时第二步压力也低，因为url1可能有1w流量，但response的不同值可能是100个。
         前提背景：每个url的流量 >> 该url的response不同值（即具有相同response+url的流量不少）。

JasonLee <17...@163.com> 于2020年8月31日周一 下午7:31写道：

> hi
>
> 我理解应该是数据倾斜的问题导致的 可以看下采用加随机数的方式key是否分布的均匀.
>
>
>
> --
> Sent from: http://apache-flink.147419.n8.nabble.com/

Re: flink checkpoint导致反压严重

[Congxian Qiu <qc...@gmail.com>]

Hi
    如果我理解没错的话，这种 单 key 热点的问题，需要算 中位数（无法像 sum/count
这样分步计算的），只能通过现在你写的这种方法，先分布聚合，然后最终再计算中位数。不过或许可以找找数学方法，看有没有近似的算法
Best,
Congxian


赵一旦 <hi...@gmail.com> 于2020年9月1日周二 上午10:15写道：

> （1）url理论上足够多，也足够随机。而并行度比如是30，url理论上是万、十万、百万、千万级别，理论上不会出现数据倾斜吧。
> （2）如果的确有倾斜，那么你那个方法我看不出有啥用，我看你好像是全缓存下来？这没啥用吧。
> （3）我的思路，考虑到你是要求1分钟窗口，每个url维度的，response的中位数。所以本质需要url+time维度的全部response数据排序。
>          由于url数量可能比较少（比如和并行度类似），导致了数据倾斜。所以key不能仅用url，需要分步。
>
>
>  分步方法：如果url的访问量总体极大，则response的值应该有很大重复，比如url1对应response=2ms的有1000个，对应3ms的有500个等这种量级。这样的话直接url+response作为key作为第一级统计也可以降低很大压力，同时加了response后应该就够分散了。第2级别拿到的是url级别的不同response+出现次数的数据。根据这些是可以计算中位数的，同时第二步压力也低，因为url1可能有1w流量，但response的不同值可能是100个。
>          前提背景：每个url的流量 >> 该url的response不同值（即具有相同response+url的流量不少）。
>
> JasonLee <17...@163.com> 于2020年8月31日周一 下午7:31写道：
>
> > hi
> >
> > 我理解应该是数据倾斜的问题导致的 可以看下采用加随机数的方式key是否分布的均匀.
> >
> >
> >
> > --
> > Sent from: http://apache-flink.147419.n8.nabble.com/
>