啥是数据倾斜？就是数据歪啦！

我们在《业务开发中你用到了哪些算法？》中，一起畅聊了 hash 算法在实际研发中的应用，并且提出了“数据倾斜是怎么回事？”的疑问；由于按照一猿小讲的风格，绝不能让大家止于应用，于是在《业务开发中你用到了哪些算法（续）？》中，一起把主题又升华了一下。

虽然在以往的文章提出了“数据倾斜是怎么回事呢？”的疑问，却迟迟未给大家分享答案。

面试官：啥是数据倾斜？ 懵B 哥：数据倾斜就是数据歪啦！ 面试官：然后呢？ 懵B 哥：没有然后啦！ 气氛相当之凝重，尬聊......

为了避免以上尬聊，那么不妨一起尝试把这个事聊透亮，万一你在面试的时候有幸被问到呢？

话不多说，请坐稳扶好，本期不烧脑的分享正式开始。

01. “二八”法则

(图片来源于网络)

从朋友圈里拽了一张图，刚好吻合咱们今天分享的主题。如上图总结，20% 的人掌握世上 80% 的财富，而 80% 的人掌握世上 20% 的财富，言外之意财富在世上的分配是不平衡的，其实生搬硬套再讲的高大尚一点就是存在数据倾斜。

(图片来源于网络)

02. 数据倾斜

“二八”法则已经阐明了生活中的数据倾斜，那在计算机的世界里是否会存在数据倾斜呢？答案是肯定的。

想想线上的那些事儿。

1. 线上服务器，始终有几台超负荷工作。想想上篇分享为什么建议后端研发人员维护 Session，而不是 Nginx 配置 ip_hash 的策略来解决 Session 共享的问题。 2. 分布式缓存环境下，由于数据分散度不够，导致大量的数据集中到了一台或者几台服务节点上。 3. MapReduce 场景下，Mapper 执行完后，默认会根据 (key.hashCode() & Integer.MAX_VALUE) % numReduceTasks 进行分区，如果 key 的 hash 值重复了，即会存在大量 key，始终让一个 Reducer 去处理的情形。

想想身边的那些事儿。

在社交媒体网站上，一些名人用户有数百万粉丝，当其发布一些热点事件时可能会一起异常访问风暴。例如，某某官宣结婚，某浪微博服务器又宕机了的消息，瞬间会出现在你的视野之中。

其实还有很多这样的场景，但是都说明了一个问题“一台机器超负荷，一台机器零负荷；一部分数据多，一部分数据少”。其实生活中也会经常听到有人抱怨道“忙的忙死，闲的闲死”，不过话又说回来，如果工作中你比较忙，那么恭喜你，从以上的种种场景分析足矣说明你非常重要，哈哈，扯远啦。

用一句话尝试说清楚数据倾斜，其实是由于数据的 key 的分摊严重不均，导致的一部分分摊的数据很多，一部分数据分摊的很少的尴尬局面。

面对这种尴尬的局面，该如何解决呢？

03. 辨证施药

看到“二八”法则，我们知道财富在世上的分配是不平衡的，但是你有没有办法去扭转它呢？如果你真有方式可以扭转，那大家一定要抱紧你大腿，往往扭转不太现实，但是大家能做的就是努力挤进那 20% 的塔尖（远方的希望还是有的，万一实现了呢），言外之意扭转数据倾斜的方式，需要改变方式。

最近在看一本书《数据密集型应用系统设计》，书中提到，大多数的系统今天仍然无法自动消除高度倾斜的负载，而只能通过应用层来减轻倾斜的程度。

例如，在面对某某官宣的热点问题，热点关键字可能是名人的用户 ID 或者正在评论的事件 ID，一个简单的技术就是在关键字的开头或者结尾处添加一个随机数，因为一个两位数的十进制随机数，就可以将关键字的写操作，分布到 100 个不同的关键字上，从而分配到不同的分区上。但是随之而来的问题是，之后的任何读取都需要做些额外的工作，必须从100 个关键字中读取数据然后进行合并。

例如，在面对 MapReduce 默认分区HashPartitioner，若在实际应用中表现不太良好时，那不妨看看数据，然后根据业务自定义 Partitioner 的实现。

说白了，数据倾斜没有一劳永逸的方式可以解决，需要辩证施药，在不同的场景下，应对的方案也不尽相同。

最后，以《数据密集型应用系统设计》书中的一段话结束本次的分享。也许将来某一天，系统会自动检测负载倾斜情况，然后自动处理这些倾斜的负载。但是截至目前，仍然需要开发者自己结合实际应用来综合权衡。