You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-zh@flink.apache.org by 范瑞 <83...@qq.com> on 2020/11/05 12:29:13 UTC
回复：keyBy的数据均衡性
Hello
是不是因为 uid = 0 的数据较多导致的倾斜呢？
Best Wishes
fanrui
------------------ 原始邮件 ------------------
发件人: "user-zh" <hinobleyd@gmail.com>;
发送时间: 2020年11月5日(星期四) 晚上8:13
收件人: "user-zh"<user-zh@flink.apache.org>;
主题: keyBy的数据均衡性
我这边遇到一个情况比较奇怪。
（1）一整天数据的统计信息如下：
sid+subid+browser+ip: 13068577
sid+subid+browser+uid: 2962237
如上，sid和subid是渠道和子渠道，browser是浏览器，ip和uid都是一个相对变化较大的维度。
*数字是distinct count信息。*
（2）任务逻辑
流A，分别基于sid+subid+browser+ip和sid+subid+browser+uid组合维护做统计。window算子并发都是10。结果是sid+subid+browser+ip的window算子收到数据基本均衡（1.09G～1.48G），此处是指运行一段时间后。但sid+subid+browser+uid算子收到数据却很不均衡（230MB～6.84G）。
我的疑问是，虽然keyBy不能完全均衡，这很好理解。但是差距也太奇葩了。230MB和6.84G。
而且从统计信息看uid的确没有ip区分度大。但 sid+subid+browser+uid 的组合数达到 296w，并发才10，会这么不均衡的嘛？
Re: keyBy的数据均衡性
Posted by 赵一旦 <hi...@gmail.com>.
如果uid=0的组合数规模大点，能够更加均衡的分到10个并发算子。那么相当于10个并发算子能公平的分到流量低（uid!=0）的组合，以及流量高（uid=0）的组合。所以本身就不会不均衡了。
此处应该是因为*sid+subid+browser*的组合数正好也不够大导致的。
感觉有道理不。
赵一旦 <hi...@gmail.com> 于2020年11月5日周四 下午9:08写道：
> 感觉好像有道理哈哈。
>
> 分析下：*sid+subid+browser+uid* 一共大约300w假设，*sid+subid+browser *则假设是300个。
> 那么uid=0的存在300种组合，即 *300w种组合 *中有 *300种组合（uid=0） *是相对大概率出现的。
>
> 那么这300种大概率出现的组合如果碰巧分布不够均衡，就会导致window算子部分不均衡。
>
> 之前我考虑了uid的问题，但想的是hash是一堆字段一起哈希，uid自身不均衡不会导致问题。但基于如上分析，貌似是有问题的。因为uid=0的组合数的
> *规模太小（300）*，如果这个规模稍微大点的话，uid的不均衡就不会导致这个问题了可能。
>
>
>
> 范瑞 <83...@qq.com> 于2020年11月5日周四 下午8:29写道：
>
>> Hello
>>
>>
>> 是不是因为 uid = 0 的数据较多导致的倾斜呢？
>>
>>
>> Best Wishes
>> fanrui
>>
>>
>>
>>
>> ------------------ 原始邮件 ------------------
>> 发件人:
>> "user-zh"
>> <
>> hinobleyd@gmail.com>;
>> 发送时间: 2020年11月5日(星期四) 晚上8:13
>> 收件人: "user-zh"<user-zh@flink.apache.org>;
>>
>> 主题: keyBy的数据均衡性
>>
>>
>>
>> 我这边遇到一个情况比较奇怪。
>> （1）一整天数据的统计信息如下：
>> sid+subid+browser+ip: 13068577
>> sid+subid+browser+uid: 2962237
>> 如上，sid和subid是渠道和子渠道，browser是浏览器，ip和uid都是一个相对变化较大的维度。
>> *数字是distinct count信息。*
>> （2）任务逻辑
>>
>> 流A，分别基于sid+subid+browser+ip和sid+subid+browser+uid组合维护做统计。window算子并发都是10。结果是sid+subid+browser+ip的window算子收到数据基本均衡（1.09G～1.48G），此处是指运行一段时间后。但sid+subid+browser+uid算子收到数据却很不均衡（230MB～6.84G）。
>>
>> 我的疑问是，虽然keyBy不能完全均衡，这很好理解。但是差距也太奇葩了。230MB和6.84G。
>> 而且从统计信息看uid的确没有ip区分度大。但 sid+subid+browser+uid 的组合数达到 296w，并发才10，会这么不均衡的嘛？
>
>
Re: keyBy的数据均衡性
Posted by 赵一旦 <hi...@gmail.com>.
感觉好像有道理哈哈。
分析下：*sid+subid+browser+uid* 一共大约300w假设，*sid+subid+browser *则假设是300个。
那么uid=0的存在300种组合，即 *300w种组合 *中有 *300种组合（uid=0） *是相对大概率出现的。
那么这300种大概率出现的组合如果碰巧分布不够均衡，就会导致window算子部分不均衡。
之前我考虑了uid的问题，但想的是hash是一堆字段一起哈希，uid自身不均衡不会导致问题。但基于如上分析，貌似是有问题的。因为uid=0的组合数的
*规模太小（300）*，如果这个规模稍微大点的话，uid的不均衡就不会导致这个问题了可能。
范瑞 <83...@qq.com> 于2020年11月5日周四 下午8:29写道：
> Hello
>
>
> 是不是因为 uid = 0 的数据较多导致的倾斜呢？
>
>
> Best Wishes
> fanrui
>
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人:
> "user-zh"
> <
> hinobleyd@gmail.com>;
> 发送时间: 2020年11月5日(星期四) 晚上8:13
> 收件人: "user-zh"<user-zh@flink.apache.org>;
>
> 主题: keyBy的数据均衡性
>
>
>
> 我这边遇到一个情况比较奇怪。
> （1）一整天数据的统计信息如下：
> sid+subid+browser+ip: 13068577
> sid+subid+browser+uid: 2962237
> 如上，sid和subid是渠道和子渠道，browser是浏览器，ip和uid都是一个相对变化较大的维度。
> *数字是distinct count信息。*
> （2）任务逻辑
>
> 流A，分别基于sid+subid+browser+ip和sid+subid+browser+uid组合维护做统计。window算子并发都是10。结果是sid+subid+browser+ip的window算子收到数据基本均衡（1.09G～1.48G），此处是指运行一段时间后。但sid+subid+browser+uid算子收到数据却很不均衡（230MB～6.84G）。
>
> 我的疑问是，虽然keyBy不能完全均衡，这很好理解。但是差距也太奇葩了。230MB和6.84G。
> 而且从统计信息看uid的确没有ip区分度大。但 sid+subid+browser+uid 的组合数达到 296w，并发才10，会这么不均衡的嘛？