admin 管理员组

文章数量: 887007

啥是数据倾斜?就是数据歪啦!

【这是一猿小讲的第 75 篇原创分享】

我们在《业务开发中你用到了哪些算法?》中,一起畅聊了 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 的实现。

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

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

好了,今天不烧脑的分享,到这就结束啦,希望你们能够喜欢

推荐阅读:

业务开发中你用到了哪些算法?

业务开发中你用到了哪些算法(续)?

本文标签: 啥是数据倾斜就是数据歪啦!