哈希冲突 | 数据倾斜

哈希冲突解决哈希冲突的常用方法分析 - 云+社区 - 腾讯云

哈希冲突：由于哈希算法被计算的数据是无限的，而计算后的结果范围有限，因此总会存在不同的数据经过计算后得到的值相同，这就是哈希冲突。

解决哈希冲突的方法：

一般有：开放定址法、链地址法（拉链法）、再哈希法、建立公共溢出区等方法。

开放定址法：从发生冲突的那个单元起，按照一定的次序，从哈希表中找到一个空闲的单元。然后把发生冲突的元素存入到该单元的一种方法。开放定址法需要的表长度要大于等于所需要存放的元素。

链地址法（拉链法）：链接地址法的思路是将哈希值相同的元素构成一个同义词的单链表，并将单链表的头指针存放在哈希表的第i个单元中，查找、插入和删除主要在同义词链表中进行。链表法适用于经常进行插入和删除的情况。

再哈希法 就是同时构造多个不同的哈希函数： Hi = RHi(key) i= 1,2,3 … k; 当H1 = RH1(key) 发生冲突时，再用H2 = RH2(key) 进行计算，直到冲突不再产生，这种方法不易产生聚集，但是增加了计算时间。

建立公共溢出区：将哈希表分为公共表和溢出表，当溢出发生时，将所有溢出数据统一放到溢出区。

****************************************************************************************************************************************************************************************************************************

数据倾斜

数据倾斜在MapReduce计算框架中经常发生。通俗理解，该现象指的是在整个计算过程中，大量相同的key被分配到了同一个任务上，造成“一个人累死、其他人闲死”的状况，这违背了分布式计算的初衷，使得整体的执行效率十分低下。

在计算数据的时候，数据的分散度不够，导致大量的数据集中到了一台或者几台机器上计算，这些数据的计算速度远远低于平均计算速度，导致整个计算过程过慢。

数据倾斜会发生在数据开发的各个环节中，比如：

用Hive算数据的时候reduce阶段卡在99.99%
用SparkStreaming做实时算法时候，一直会有executor出现OOM的错误，但是其余的executor内存使用率却很低。
数据倾斜有一个关键因素是数据量大，可以达到千亿级。

Hadoop中的数据倾斜

Hadoop中的数据倾斜主要表现在reduce阶段卡在99.99%，一直99.99%不能结束。
这里如果详细的看日志或者和监控界面的话会发现：

有一个多几个reduce卡住
各种container报错OOM（内存溢出(Out Of Memory，简称OOM))
读写的数据量极大，至少远远超过其它正常的reduce
伴随着数据倾斜，会出现任务被kill等各种诡异的表现。

经验： Hive的数据倾斜，一般都发生在Sql中Group和On上，而且和数据逻辑绑定比较深。

Spark中的数据倾斜

Spark中的数据倾斜也很常见，这里包括Spark Streaming和Spark Sql，表现主要有下面几种：

Executor lost，OOM，Shuffle过程出错
Driver OOM
单个Executor执行时间特别久，整体任务卡在某个阶段不能结束
正常运行的任务突然失败
补充一下，在Spark streaming程序中，数据倾斜更容易出现，特别是在程序中包含一些类似sql的join、group这种操作的时候。因为Spark Streaming程序在运行的时候，我们一般不会分配特别多的内存，因此一旦在这个过程中出现一些数据倾斜，就十分容易造成OOM。

数据倾斜的原理

1、数据倾斜产生的原因
我们以Spark和Hive的使用场景为例。他们在做数据运算的时候会设计到，count distinct、group by、join等操作，这些都会触发Shuffle动作，一旦触发，所有相同key的值就会拉到一个或几个节点上，就容易发生单点问题。

2、万恶的shuffle
Shuffle是一个能产生奇迹的地方，不管是在Spark还是Hadoop中，它们的作用都是至关重要的。那么在Shuffle如何产生了数据倾斜？

大部分数据倾斜的原理就类似于下图，很明了，因为数据分布不均匀，导致大量的数据分配到了一个节点。

从业务计角度来理解数据倾斜

数据往往和业务是强相关的，业务的场景直接影响到了数据的分布。再举一个例子，比如就说订单场景吧，我们在某一天在北京和上海两个城市多了强力的推广，结果可能是这两个城市的订单量增长了10000%，其余城市的数据量不变。然后我们要统计不同城市的订单情况，这样，一做group操作，可能直接就数据倾斜了。

如何解决
解决数据倾斜有这几个思路：
1.业务逻辑，我们从业务逻辑的层面上来优化数据倾斜，比如上面的例子，我们单独对这两个城市来做count，最后和其它城市做整合。
2.程序层面，比如说在Hive中，经常遇到count（distinct）操作，这样会导致最终只有一个reduce，我们可以先group 再在外面包一层count，就可以了。
3.调参方面，Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜，合理利用它们就能解决大部分问题。

从业务和数据上解决数据倾斜

有损的方法：
找到异常数据，比如ip为0的数据，过滤掉
无损的方法：
对分布不均匀的数据，单独计算
先对key做一层hash，先将数据打散让它的并行度变大，再汇集
•数据预处理

Hadoop平台的优化方法

1.mapjoin方式
2.count distinct的操作，先转成group，再count
3.hive.groupby.skewindata=true
4.left semi jioin的使用
5.设置map端输出、中间结果压缩。（不完全是解决数据倾斜的问题，但是减少了IO读写和网络传输，能提高很多效率）

Spark平台的优化方法

1.mapjoin方式
      2.设置rdd压缩
      3.合理设置driver的内存
      4.Spark Sql中的优化和Hive类似，可以参考Hive

mapjoin:

MapJoin是Hive的一种优化操作，其适用于小表JOIN大表的场景，由于表的JOIN操作是在Map端且在内存进行的，所以其并不需要启动Reduce任务也就不需要经过shuffle阶段，从而能在一定程度上节省资源提高JOIN效率.

mapjoin 在Map阶段执行表连接，而非等到Reduce阶段才执行表连接，可以缩短大量数据传输时间，提升系统资源利用率，从而起到优化作业的作用。

Hive的MapJoin，在Join 操作在 Map 阶段完成，如果需要的数据在 Map 的过程中可以访问到则不再需要Reduce。
小表关联一个超大表时，容易发生数据倾斜，可以用MapJoin把小表全部加载到内存在map端进行join，避免reducer处理。

Spark内存超出怎么解决？ spark 内存溢出处理 - 青紫天涯 - 博客园（待读）

Spark中的OOM问题不外乎以下两种情况

map执行中内存溢出
shuffle后内存溢出

map执行中内存溢出代表了所有map类型的操作。包括：flatMap，filter，mapPatitions等。
shuffle后内存溢出的shuffle操作包括join，reduceByKey，repartition等操作。

Spark RDD Spark学习之路（三）Spark之RDD - 扎心了，老铁 - 博客园（待读）

RDD（Resilient Distributed Dataset）叫做弹性分布式数据集，是Spark中最基本的数据抽象，它代表一个不可变、可分区、里面的元素可并行计算的集合。RDD具有数据流模型的特点：自动容错、位置感知性调度和可伸缩性。RDD允许用户在执行多个查询时显式地将工作集缓存在内存中，后续的查询能够重用工作集，这极大地提升了查询速度。

SQL去重

distinct | group by | 窗口函数row_number