Re: keyBy的数据均衡性

Thu, 05 Nov 2020 05:08:38 -0800 

感觉好像有道理哈哈。

分析下：*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的不均衡就不会导致这个问题了可能。



范瑞 <[email protected]> 于2020年11月5日周四 下午8:29写道：

> Hello
>
>
> 是不是因为 uid = 0 的数据较多导致的倾斜呢？
>
>
> Best&nbsp;Wishes
> fanrui
>
>
>
>
> ------------------&nbsp;原始邮件&nbsp;------------------
> 发件人:
>                                                   "user-zh"
>                                                                     <
> [email protected]&gt;;
> 发送时间:&nbsp;2020年11月5日(星期四) 晚上8:13
> 收件人:&nbsp;"user-zh"<[email protected]&gt;;
>
> 主题:&nbsp;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，会这么不均衡的嘛？

回复