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，会这么不均衡的嘛？*来自志愿者整理的flink邮件归档
写回答
-
感觉好像有道理哈哈。
分析下：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的不均衡就不会导致这个问题了可能。*来自志愿者整理的flink邮件归档
2021-12-07 11:26:07赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
