各大数据组件数据倾斜的原因和解决办法

1 背景

在处理大规模数据时，数据倾斜是一个常见的问题。数据倾斜指的是在分布式环境中处理数据时，某些节点上的任务会比其他节点更加繁重，这可能导致性能下降、资源浪费等问题。数据倾斜可能会出现在不同层次的数据处理过程中，例如 map 阶段、reduce 阶段、join 操作等。

数据倾斜的背景可以从以下几个方面来解释：

• 数据量分布不均
  在分布式环境中，数据量分布不均可能导致数据倾斜。通常情况下，每个节点应该处理相同数量的数据，但如果某个节点上的数据量过大或过小，则可能导致该节点上的任务更加繁重或者空闲。

• 数据键分布不均
  如果一些数据键的出现频率非常高，那么与这些键相关的任务会比其他任务更加繁重，从而导致数据倾斜。例如，在 WordCount 任务中，某些单词可能会出现数百万次，而其他单词则只出现几次。如果不将数据键合理分配到不同的节点上，就可能会导致数据倾斜的问题。

• 处理逻辑复杂
  如果数据的处理逻辑非常复杂，例如使用多个 join 操作或使用自定义函数等，那么可能会导致数据倾斜。这是因为复杂的处理过程会导致某些节点上的任务更加繁重，从而影响整个任务的性能。

• 网络带宽和计算资源不均
  在分布式环境中，如果不同节点之间的网络带宽和计算资源不均衡，可能会导致数据倾斜。例如，如果某个节点的网络带宽非常低或者计算资源非常有限，则该节点上的任务可能无法及时完成，从而影响整个任务的性能。

总之，数据倾斜是一个常见问题，可能出现在大规模数据处理的不同阶段。了解数据倾斜的背景，可以帮助我们更好地避免和解决数据倾斜的问题，提高分布式处理任务的性能和可靠性。

2 Hive

• 数据分桶
  使用数据分桶可以将数据均匀地分布到不同的桶中，从而避免数据倾斜。在创建表时，您可以使用 CLUSTERED BY 子句指定分桶列，并使用 NUM_BUCKETS 子句指定桶的数量。例如：

CREATE TABLE mytable (
  id INT,
  name STRING,
  value DOUBLE
)
CLUSTERED BY (id) INTO 10 BUCKETS;

这将把 mytable 表按照 id 列的值分成 10 个桶。在查询时，您可以使用桶列分发器来确保 Hive 将查询分发到所有桶中。例如：

SET hive.optimize.bucketmapjoin = true;
SET hive.optimize.bucketmapjoin.sortedmerge = true;

SELECT /*+ MAPJOIN(t1) */ *
FROM mytable t1 JOIN mytable t2 ON t1.id = t2.id;

• 数据采样
  使用数据采样可以帮助您了解数据的分布情况，从而发现数据倾斜问题。在 Hive 中，您可以使用 TABLESAMPLE 子句对数据进行采样。例如：

SELECT *
FROM mytable TABLESAMPLE(10 PERCENT);

这将随机选择 mytable 表中的 10% 的数据进行查询。通过观察采样结果，您可以了解数据的分布情况，并确定哪些列或键可能会导致数据倾斜。

• 动态分区
  对于使用静态分区的表，如果某些分区中的数据量非常大，则可能会导致数据倾斜。在这种情况下，您可以考虑使用动态分区。动态分区将在运行时根据查询结果自动创建分区，并将数据均匀地分布到不同的分区中。例如：

SET hive.exec.dynamic.partition.mode = nonstrict;

INSERT INTO newtable PARTITION(year, month)
SELECT * FROM oldtable;

这将从 oldtable 表中读取数据，并将其插入到新表 newtable 中的不同分区中，每个分区由 year 和 month 列确定。

• 压缩
  在 Hive 中，压缩可以帮助减小数据倾斜问题。通过压缩数据，可以减少磁盘 I/O 和网络传输量，提高查询性能和执行时间。在创建表时，您可以使用 COMPRESSION 子句指定压缩算法。例如：

CREATE TABLE mytable (
  id INT,
  name STRING,
  value DOUBLE
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'
STORED AS ORC
TBLPROPERTIES ("orc.compress"="SNAPPY");

这将创建一个 ORC 格式的表，并使用 SNAPPY 压缩算法对数据进行压缩。

3 Hbase

解决方案：预分区、加盐、哈希、反转。

• 预分区:预分区的目的让表的数据可以均衡的分散在集群中，而不是默认只有一个Region分布在集群的 一个节点上。
• 加盐:这里所说的加盐不是密码学中的加盐，而是在Rowkey的前面增加随机数，具体就是给Rowkey分配 一个随机前缀，从而使得它和之前的Rowkey的开头不同。
• 哈希:哈希会使同一行永远用一个前缀加盐，也可以使负载分散到整个集群，但是读却是可以预测的，使 用确定的哈希可以让客户端重构完整的Rowkey，可以使用get操作准确获取某一个行数据。
• 反转:反转固定长度或者数字格式的Rowkey，这样可以使得Rowkey中经常改变的部分(最没有意义的部 分)放在前面，这样可以有效的随机Rowkey，但是牺牲了Rowkey的有序性。

4 Spark

• Spark中的数据倾斜问题主要指shuffle过程中出现的数据倾斜问题，是由于不同的key对应的数据量不同导致的不同task所处理的数据量不同的问题。

• 例如，reduce点一共要处理100万条数据，第一个和第二个task分别被分配到了1万条数据，计算5分钟内完成，第三个task分配到了98万数据，此时第三个task可能需要10个小时完成，这使得整个Spark作业需要10个小时才能运行完成，这就是数据倾斜所带来的后果。

• 解决方案一：使用Hive ETL预处理数据

  • 适用场景：导致数据倾斜的是Hive表。如果该Hive表中的数据本身很不均匀（比如某个key对应了100万数据，其他key才对应了10条数据），而且业务场景需要频繁使用Spark对Hive表执行某个分析操作，那么比较适合使用这种技术方案。

  • 方案实现思路：此时可以评估一下，是否可以通过Hive来进行数据预处理（即通过Hive ETL预先对数据按照key进行聚合，或者是预先和其他表进行join），然后在Spark作业中针对的数据源就不是原来的Hive表了，而是预处理后的Hive表。此时由于数据已经预先进行过聚合或join操作了，那么在Spark作业中也就不需要使用原先的shuffle类算子执行这类操作了。

  • 方案实现原理：这种方案从根源上解决了数据倾斜，因为彻底避免了在Spark中执行shuffle类算子，那么肯定就不会有数据倾斜的问题了。但是这里也要提醒一下大家，这种方式属于治标不治本。因为毕竟数据本身就存在分布不均匀的问题，所以Hive ETL中进行group by或者join等shuffle操作时，还是会出现数据倾斜，导致Hive ETL的速度很慢。我们只是把数据倾斜的发生提前到了Hive ETL中，避免Spark程序发生数据倾斜而已。

  • 方案优点：实现起来简单便捷，效果还非常好，完全规避掉了数据倾斜，Spark作业的性能会大幅度提升。

  • 方案缺点：治标不治本，Hive ETL中还是会发生数据倾斜。

  • 方案实践经验：在一些Java系统与Spark结合使用的项目中，会出现Java代码频繁调用Spark作业的场景，而且对Spark作业的执行性能要求很高，就比较适合使用这种方案。将数据倾斜提前到上游的Hive ETL，每天仅执行一次，只有那一次是比较慢的，而之后每次Java调用Spark作业时，执行速度都会很快，能够提供更好的用户体验。

  • 项目实践经验：在美团·点评的交互式用户行为分析系统中使用了这种方案，该系统主要是允许用户通过Java Web系统提交数据分析统计任务，后端通过Java提交Spark作业进行数据分析统计。要求Spark作业速度必须要快，尽量在10分钟以内，否则速度太慢，用户体验会很差。所以我们将有些Spark作业的shuffle操作提前到了Hive ETL中，从而让Spark直接使用预处理的Hive中间表，尽可能地减少Spark的shuffle操作，大幅度提升了性能，将部分作业的性能提升了6倍以上。

• 解决方案二：过滤少数导致倾斜的key

  • 适用场景：如果发现导致倾斜的key就少数几个，而且对计算本身的影响并不大的话，那么很适合使用这种方案。比如99%的key就对应10条数据，但是只有一个key对应了100万数据，从而导致了数据倾斜。

  • 方案实现思路：如果我们判断那少数几个数据量特别多的key，对作业的执行和计算结果不是特别重要的话，那么干脆就直接过滤掉那少数几个key。比如，在Spark SQL中可以使用where子句过滤掉这些key或者在Spark Core中对RDD执行filter算子过滤掉这些key。如果需要每次作业执行时，动态判定哪些key的数据量最多然后再进行过滤，那么可以使用sample算子对RDD进行采样，然后计算出每个key的数量，取数据量最多的key过滤掉即可。

  • 方案实现原理：将导致数据倾斜的key给过滤掉之后，这些key就不会参与计算了，自然不可能产生数据倾斜。

  • 方案优点：实现简单，而且效果也很好，可以完全规避掉数据倾斜。

  • 方案缺点：适用场景不多，大多数情况下，导致倾斜的key还是很多的，并不是只有少数几个。

  • 方案实践经验：在项目中我们也采用过这种方案解决数据倾斜。有一次发现某一天Spark作业在运行的时候突然OOM了，追查之后发现，是Hive表中的某一个key在那天数据异常，导致数据量暴增。因此就采取每次执行前先进行采样，计算出样本中数据量最大的几个key之后，直接在程序中将那些key给过滤掉。

• 解决方案三：提高shuffle操作的并行度

  • 方案适用场景：如果我们必须要对数据倾斜迎难而上，那么建议优先使用这种方案，因为这是处理数据倾斜最简单的一种方案。

  • 方案实现思路：在对RDD执行shuffle算子时，给shuffle算子传入一个参数，比如reduceByKey(1000)，该参数就设置了这个shuffle算子执行时shuffle read task的数量。对于Spark SQL中的shuffle类语句，比如group by、join等，需要设置一个参数，即spark.sql.shuffle.partitions，该参数代表了shuffle read task的并行度，该值默认是200，对于很多场景来说都有点过小。

  • 方案实现原理：增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个task处理比原来更少的数据。举例来说，如果原本有5个key，每个key对应10条数据，这5个key都是分配给一个task的，那么这个task就要处理50条数据。而增加了shuffle read task以后，每个task就分配到一个key，即每个task就处理10条数据，那么自然每个task的执行时间都会变短了。

  • 方案优点：实现起来比较简单，可以有效缓解和减轻数据倾斜的影响。

  • 方案缺点：只是缓解了数据倾斜而已，没有彻底根除问题，根据实践经验来看，其效果有限。

  • 方案实践经验：该方案通常无法彻底解决数据倾斜，因为如果出现一些极端情况，比如某个key对应的数据量有100万，那么无论你的task数量增加到多少，这个对应着100万数据的key肯定还是会分配到一个task中去处理，因此注定还是会发生数据倾斜的。所以这种方案只能说是在发现数据倾斜时尝试使用的第一种手段，尝试去用最简单的方法缓解数据倾斜而已，或者是和其他方案结合起来使用。

• 解决方案四：两阶段聚合（局部聚合+全局聚合）

  • 方案适用场景：对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时，比较适用这种方案。

  • 方案实现思路：这个方案的核心实现思路就是进行两阶段聚合。第一次是局部聚合，先给每个key都打上一个随机数，比如10以内的随机数，此时原先一样的key就变成不一样的了，比如(hello, 1) (hello, 1) (hello, 1) (hello, 1)，就会变成(1_hello, 1)(1_hello, 1) (2_hello, 1) (2_hello, 1)。接着对打上随机数后的数据，执行reduceByKey等聚合操作，进行局部聚合，那么局部聚合结果，就会变成了(1_hello, 2) (2_hello, 2)。然后将各个key的前缀给去掉，就会变成(hello,2)(hello,2)，再次进行全局聚合操作，就可以得到最终结果了，比如(hello, 4)。

  • 方案实现原理：将原本相同的key通过附加随机前缀的方式，变成多个不同的key，就可以让原本被一个task处理的数据分散到多个task上去做局部聚合，进而解决单个task处理数据量过多的问题。接着去除掉随机前缀，再次进行全局聚合，就可以得到最终的结果。

  • 方案优点：对于聚合类的shuffle操作导致的数据倾斜，效果是非常不错的。通常都可以解决掉数据倾斜，或者至少是大幅度缓解数据倾斜，将Spark作业的性能提升数倍以上。

  • 方案缺点：仅仅适用于聚合类的shuffle操作，适用范围相对较窄。如果是join类的shuffle操作，还得用其他的解决方案。

• 解决方案五：将reduce join转为map join

  • 方案适用场景：在对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且join操作中的一个RDD或表的数据量比较小（比如几百M或者一两G），比较适用此方案。

  • 方案实现思路：不使用join算子进行连接操作，而使用Broadcast变量与map类算子实现join操作，进而完全规避掉shuffle类的操作，彻底避免数据倾斜的发生和出现。将较小RDD中的数据直接通过collect算子拉取到Driver端的内存中来，然后对其创建一个Broadcast变量；接着对另外一个RDD执行map类算子，在算子函数内，从Broadcast变量中获取较小RDD的全量数据，与当前RDD的每一条数据按照连接key进行比对，如果连接key相同的话，那么就将两个RDD的数据用你需要的方式连接起来。

  • 方案实现原理：普通的join是会走shuffle过程的，而一旦shuffle，就相当于会将相同key的数据拉取到一个shuffle read task中再进行join，此时就是reduce join。但是如果一个RDD是比较小的，则可以采用广播小RDD全量数据+map算子来实现与join同样的效果，也就是map join，此时就不会发生shuffle操作，也就不会发生数据倾斜。。

  • 方案优点：对join操作导致的数据倾斜，效果非常好，因为根本就不会发生shuffle，也就根本不会发生数据倾斜。

  • 方案缺点：适用场景较少，因为这个方案只适用于一个大表和一个小表的情况。毕竟我们需要将小表进行广播，此时会比较消耗内存资源，driver和每个Executor内存中都会驻留一份小RDD的全量数据。如果我们广播出去的RDD数据比较大，比如10G以上，那么就可能发生内存溢出了。因此并不适合两个都是大表的情况。

• 解决方案六：采样倾斜key并分拆join操作

  • 方案适用场景：两个RDD/Hive表进行join的时候，如果数据量都比较大，无法采用“解决方案五”，那么此时可以看一下两个RDD/Hive表中的key分布情况。如果出现数据倾斜，是因为其中某一个RDD/Hive表中的少数几个key的数据量过大，而另一个RDD/Hive表中的所有key都分布比较均匀，那么采用这个解决方案是比较合适的。

  • 方案实现思路：对包含少数几个数据量过大的key的那个RDD，通过sample算子采样出一份样本来，然后统计一下每个key的数量，计算出来数据量最大的是哪几个key。然后将这几个key对应的数据从原来的RDD中拆分出来，形成一个单独的RDD，并给每个key都打上n以内的随机数作为前缀，而不会导致倾斜的大部分key形成另外一个RDD。接着将需要join的另一个RDD，也过滤出来那几个倾斜key对应的数据并形成一个单独的RDD，将每条数据膨胀成n条数据，这n条数据都按顺序附加一个0~n的前缀，不会导致倾斜的大部分key也形成另外一个RDD。再将附加了随机前缀的独立RDD与另一个膨胀n倍的独立RDD进行join，此时就可以将原先相同的key打散成n份，分散到多个task中去进行join了。而另外两个普通的RDD就照常join即可。最后将两次join的结果使用union算子合并起来即可，就是最终的join结果。

  • 方案实现原理：对于join导致的数据倾斜，如果只是某几个key导致了倾斜，可以将少数几个key分拆成独立RDD，并附加随机前缀打散成n份去进行join，此时这几个key对应的数据就不会集中在少数几个task上，而是分散到多个task进行join了。

  • 方案优点：对于join导致的数据倾斜，如果只是某几个key导致了倾斜，采用该方式可以用最有效的方式打散key进行join。而且只需要针对少数倾斜key对应的数据进行扩容n倍，不需要对全量数据进行扩容。避免了占用过多内存。

  • 方案缺点：如果导致倾斜的key特别多的话，比如成千上万个key都导致数据倾斜，那么这种方式也不适合。

• 解决方案七：使用随机前缀和扩容RDD进行join

  • 方案适用场景：如果在进行join操作时，RDD中有大量的key导致数据倾斜，那么进行分拆key也没什么意义，此时就只能使用最后一种方案来解决问题了。

  • 方案实现思路：该方案的实现思路基本和“解决方案六”类似，首先查看RDD/Hive表中的数据分布情况，找到那个造成数据倾斜的RDD/Hive表，比如有多个key都对应了超过1万条数据。然后将该RDD的每条数据都打上一个n以内的随机前缀。同时对另外一个正常的RDD进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一个0~n的前缀。最后将两个处理后的RDD进行join即可。

  • 方案实现原理：将原先一样的key通过附加随机前缀变成不一样的key，然后就可以将这些处理后的“不同key”分散到多个task中去处理，而不是让一个task处理大量的相同key。该方案与“解决方案六”的不同之处就在于，上一种方案是尽量只对少数倾斜key对应的数据进行特殊处理，由于处理过程需要扩容RDD，因此上一种方案扩容RDD后对内存的占用并不大；而这一种方案是针对有大量倾斜key的情况，没法将部分key拆分出来进行单独处理，因此只能对整个RDD进行数据扩容，对内存资源要求很高。

  • 方案优点：对join类型的数据倾斜基本都可以处理，而且效果也相对比较显著，性能提升效果非常不错。

  • 方案缺点：该方案更多的是缓解数据倾斜，而不是彻底避免数据倾斜。而且需要对整个RDD进行扩容，对内存资源要求很高。

  • 方案实践经验：曾经开发一个数据需求的时候，发现一个join导致了数据倾斜。优化之前，作业的执行时间大约是60分钟左右；使用该方案优化之后，执行时间缩短到10分钟左右，性能提升了6倍。

• 解决方案八：多种方案组合使用

  在实践中发现，很多情况下，如果只是处理较为简单的数据倾斜场景，那么使用上述方案中的某一种基本就可以解决。但是如果要处理一个较为复杂的数据倾斜场景，那么可能需要将多种方案组合起来使用。比如说，我们针对出现了多个数据倾斜环节的Spark作业，可以先运用解决方案一和二，预处理一部分数据，并过滤一部分数据来缓解；其次可以对某些shuffle操作提升并行度，优化其性能；最后还可以针对不同的聚合或join操作，选择一种方案来优化其性能。大家需要对这些方案的思路和原理都透彻理解之后，在实践中根据各种不同的情况，灵活运用多种方案，来解决自己的数据倾斜问题。

5 Flink

• 产生数据倾斜的原因主要有2个方面

  • 业务上有严重的数据热点，比如如祺出行的车辆轨迹数据中，广州天河区、深圳南山区等几个一线城市的热点区域远远超过其他区域。
  • 技术上如果大量使用了KeyBy、GroupBy等操作，且没有对分组的Key做特殊的处理，会产生数据热点问题。

• 解决问题的思路

  • 业务上要尽量避免热点 key 的设计，例如我们可以把上海、北京等热点城市与非热点城市划分成不同的区域，并进行单独处理；

  • 技术上出现热点时，要调整方案打散原来的 key，避免直接聚合；此外还可以利用Flink提供的功能来避免数据倾斜。

• Flink 任务数据倾斜场景和解决方案

  • （1）两阶段聚合解决 KeyBy 热点

    • a. 将需要分组的 key 打散，例如添加随机的后缀；
    • b. 对打散后的数据进行聚合；
    • c. 将被打散的 key 还原为原始的 key；
    • d. 二次 KeyBy 来统计最终结果并输出给下游。

  • （2）GroupBy + Aggregation 分组聚合热点问题

    • 如果是采用FlinkSQL的方式，则可以将FlinkSQL 嵌套成两层，里层通过随机打散若干份（如100）的方式降低数据热点，（这个打散的方式可以根据业务灵活指定）。

  • （3）Flink 消费 Kafka 使用并行度与Kafka分区数不一致导致的数据倾斜

    • Flink 消费 Kafka 的数据时，是推荐消费并行度为Kafka分区数的1倍或者整数倍的 ，即 Flink Consumer 的并行度 = Kafka 的分区数 * n （n = 1, 2 ,3 …）。