如果uid=0的组合数规模大点，能够更加均衡的分到10个并发算子。那么相当于10个并发算子能公平的分到流量低（uid!=0）的组合，以及流量高（uid=0）的组合。所以本身就不会不均衡了。
此处应该是因为*sid+subid+browser*的组合数正好也不够大导致的。
感觉有道理不。
赵一旦 <
[hidden email]> 于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的不均衡就不会导致这个问题了可能。
>
>
>
> 范瑞 <
[hidden email]> 于2020年11月5日周四 下午8:29写道：
>
>> Hello
>>
>>
>> 是不是因为 uid = 0 的数据较多导致的倾斜呢？
>>
>>
>> Best Wishes
>> fanrui
>>
>>
>>
>>
>> ------------------ 原始邮件 ------------------
>> 发件人:
>> "user-zh"
>> <
>>
[hidden email]>;
>> 发送时间: 2020年11月5日(星期四) 晚上8:13
>> 收件人: "user-zh"<
[hidden email]>;
>>
>> 主题: 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，会这么不均衡的嘛？
>
>
Locked
