本文共 18676 字，大约阅读时间需要 62 分钟。
文章目录
一、什么是数据倾斜
简单的讲，数据倾斜就是我们在计算数据的时候，数据的分散度不够，导致大量的数据集中到了一台或者几台机器上计算，造成数据热点问题（数据倾斜的另一种说法），这些数据的计算速度远远低于平均计算速度，导致整个计算过程过慢（木桶效应）。
现象：
- 大部分的task都非常快速的处理完成，只有极少数的task处理的非常慢，这种状况很可能就是数据倾斜了。对于Spark可以在WEB-UI的job=>stage=>task里看，你可以把task处理的数据量排序一下。
- 上面场景下虽说极少数task处理的比较慢，但是最终还是能够处理完OK的。但大部分场景下：Spark/Hive作业运行的好好的，突然发生OOM，作业很大可能就挂了。比如发现某一天 Spark 作业在运行的时候突然 OOM 了，追查之后发现，是 Hive 表中的某一个 key 在那天数据异常，导致数据量暴增。对于这种场景比较low的方式是手工的去干预；比较高级的方式是遇到数据倾斜的场景应该要具备自适应的能力。
- 用Hive算数据的时候reduce阶段卡在99.99%
- 用SparkStreaming做实时算法时候，一直会有executor出现OOM的错误，但是其余的executor内存使用率却很低。
二、结合Shuffle
Shuffle是一个能产生奇迹的地方，不管是在Spark还是Hadoop中，它们的作用都是至关重要的。那么在Shuffle如何产生了数据倾斜？
1.结合mapreduce的shshuffle来说：
结合MapReduce执行过程，在shuffle的时候，必须将各个节点相同的key拉取到某一个节点进行task的处理，比如：join、group by。如果某个key对应的数据量非常大，那么必然这个key对应的数据进行处理的时候就会产生数据倾斜。
Shuffle过程是MapReduce的核心，也被称为奇迹发生的地方。要想理解MapReduce， Shuffle是必须要了解的。上面这张是官方对Shuffle过程的描述。 2.结合spark的shshuffle来说：
窄依赖（narrow dependency）：一个父RDD的partition至多被子RDD的某个partition使用一次。换句话说，一个父RDD的分区对应于一个子RDD的分区，或者多个父RDD的分区对应于一个子RDD的分区。所以窄依赖又可以分为两种情况：
- 1个子RDD的分区对应于1个父RDD的分区，比如map，filter，union等算子
- 1个子RDD的分区对应于N个父RDD的分区，比如co-partioned join
宽依赖（wide dependency，也称为shuffle dependency）：一个父RDD的partition会被子RDD的partition使用多次，有shuffle。遇到shuffle，原来的stage就会被拆分。宽依赖有分为两种情况：
- 1个父RDD对应非全部多个子RDD分区，比如groupByKey，reduceByKey，sortByKey
- 1个父RDD对应所有子RDD分区，比如未经协同划分的join
Spark中RDD的高效与DAG（有向无环图）有着莫大的关系，在DAG调度中我们需要对计算过程划分stage，而划分依据就是RDD之间的依赖关系。针对不同的转换函数，RDD之间的依赖关系分为宽依赖和窄依赖。宽依赖和窄依赖的区别是RDD之间是否存在shuffle操作，宽依赖将其数据进行打散分开，走shuffle机制与mapreduce相同，他主要将一些数据进行洗牌和重新分组发牌。宽依赖、窄依赖的概念不仅用在调度，对容错也有用，如果一个节点损坏，运算是窄依赖，只要把丢失的父节点分区重新计算即可。而宽依赖的话，就需要使用checkpoint来检查和重新计算。 我们结合一下WordCount操作理解一下：
下面的代码需要能默写出来：val lines = sc.textFile("")val words = lines.flatMap(_.split(" "))val pairs = words.map((_.1))val result = pairs.reduceByKey(_+_) 
（1）Spark任务调度：
（2）Spark Shuffle：
Apache Spark 的 Shuffle 过程与 Apache Hadoop 的 Shuffle 过程有着诸多类似，一些概念可直接套用，例如，Shuffle 过程中，提供数据的一端，被称作 Map 端，Map 端每个生成数据的任务称为 Mapper，对应的，接收数据的一端，被称作 Reduce 端，Reduce 端每个拉取数据的任务称为 Reducer，Shuffle 过程本质上都是将 Map 端获得的数据使用分区器进行划分，并将数据发送给对应的 Reducer 的过程。
参考官网：
Spark Shuffle发展史： 在Spark的版本的发展，ShuffleManager在不断迭代，变得越来越先进。 在Spark 1.2以前，默认的shuffle计算引擎是HashShuffleManager。而HashShuffleManager有着一个非常严重的弊端，就是会产生大量的中间磁盘文件，进而由大量的磁盘IO操作影响了性能。因此在Spark 1.2以后的版本中，默认的ShuffleManager改成了SortShuffleManager。SortShuffleManager相较于HashShuffleManager来说，有了一定的改进。主要就在于，每个Task在进行shuffle操作时，虽然也会产生较多的临时磁盘文件，但是最后会将所有的临时文件合并(merge)成一个磁盘文件，因此每个Task就只有一个磁盘文件。在下一个stage的shuffle read task拉取自己的数据时，只要根据索引读取每个磁盘文件中的部分数据即可。
三、产生数据倾斜的场景和思路分析
1.Spark中：
在 Spark 中，同一个 Stage 的不同 Partition 可以并行处理，而具有依赖关系的不同 Stage 之间是串行处理的。假设某个 Spark Job 分为 Stage 0和 Stage 1两个 Stage，且 Stage 1依赖于 Stage 0，那 Stage 0完全处理结束之前不会处理Stage 1。而 Stage 0可能包含 N 个 Task，这 N 个 Task 可以并行进行。如果其中 N-1个 Task 都在10秒内完成，而另外一个 Task 却耗时1分钟，那该 Stage 的总时间至少为1分钟。换句话说，一个 Stage 所耗费的时间，主要由最慢的那个 Task 决定。由于同一个 Stage 内的所有 Task 执行相同的计算，在排除不同计算节点计算能力差异的前提下，不同 Task 之间耗时的差异主要由该 Task 所处理的数据量决定。
简单可概括为：Spark 数据倾斜的几种场景以及对应的解决方案，包括避免数据源倾斜，调整并行度，使用自定义 Partitioner，使用 Map 侧 Join 代替 Reduce 侧 Join（内存表合并），给倾斜 Key 加上随机前缀等。
（1）调整并行度分散同一个 Task 的不同 Key：
Spark在做Shuffle时，默认使用HashPartitioner（非Hash Shuffle）对数据进行分区。如果并行度设置的不合适，可能造成大量不相同的Key对应的数据被分配到了同一个Task上，造成该Task所处理的数据远大于其它Task，从而造成数据倾斜。
如果调整Shuffle时的并行度，使得原本被分配到同一Task的不同Key发配到不同Task上处理，则可降低原Task所需处理的数据量，从而缓解数据倾斜问题造成的短板效应。
案例：现有一张测试表，名为student_external，内有10.5亿条数据，每条数据有一个唯一的id值。现从中取出id取值为9亿到10.5亿的共1.5亿条数据，并通过一些处理，使得id为9亿到9.4亿间的所有数据对12取模后余数为8（即在Shuffle并行度为12时该数据集全部被HashPartition分配到第8个Task），其它数据集对其id除以100取整，从而使得id大于9.4亿的数据在Shuffle时可被均匀分配到所有Task中，而id小于9.4亿的数据全部分配到同一个Task中。处理过程如下：
INSERT OVERWRITE TABLE testSELECT CASE WHEN id < 940000000 THEN (9500000 + (CAST (RAND() * 8 AS INTEGER)) * 12 ) ELSE CAST(id/100 AS INTEGER) END, nameFROM student_externalWHERE id BETWEEN 900000000 AND 1050000000;
通过上述处理，一份可能造成后续数据倾斜的测试数据即以准备好。接下来，使用Spark读取该测试数据，并通过groupByKey(12)对id分组处理，且Shuffle并行度为12。代码如下
public class SparkDataSkew { public static void main(String[] args) { SparkSession sparkSession = SparkSession.builder() .appName("SparkDataSkewTunning") .config("hive.metastore.uris", "thrift://hadoop1:9083") .enableHiveSupport() .getOrCreate(); Dataset dataframe = sparkSession.sql( "select * from test"); dataframe.toJavaRDD() .mapToPair((Row row) -> new Tuple2 (row.getInt(0),row.getString(1))) .groupByKey(12) .mapToPair((Tuple2 > tuple) -> { int id = tuple._1(); AtomicInteger atomicInteger = new AtomicInteger(0); tuple._2().forEach((String name) -> atomicInteger.incrementAndGet()); return new Tuple2 (id, atomicInteger.get()); }).count(); sparkSession.stop(); sparkSession.close(); } }
通过上述处理，一份可能造成后续数据倾斜的测试数据即以准备好。接下来，使用Spark读取该测试数据，并通过groupByKey(12)对id分组处理，且Shuffle并行度为12。代码如下
public class SparkDataSkew { public static void main(String[] args) { SparkSession sparkSession = SparkSession.builder() .appName("SparkDataSkewTunning") .config("hive.metastore.uris", "thrift://hadoop1:9083") .enableHiveSupport() .getOrCreate(); Dataset dataframe = sparkSession.sql( "select * from test"); dataframe.toJavaRDD() .mapToPair((Row row) -> new Tuple2 (row.getInt(0),row.getString(1))) .groupByKey(12) .mapToPair((Tuple2 > tuple) -> { int id = tuple._1(); AtomicInteger atomicInteger = new AtomicInteger(0); tuple._2().forEach((String name) -> atomicInteger.incrementAndGet()); return new Tuple2 (id, atomicInteger.get()); }).count(); sparkSession.stop(); sparkSession.close(); } }
本次实验所使用集群节点数为4，每个节点可被Yarn使用的CPU核数为16，内存为16GB。使用如下方式提交上述应用，将启动4个Executor，每个Executor可使用核数为12（该配置并非生产环境下的最优配置，仅用于本文实验），可用内存为12GB。
spark-submit --queue ambari --num-executors 4 --executor-cores 12 --executor-memory 12g --class com.jasongj.spark.driver.SparkDataSkew --master yarn --deploy-mode client SparkExample-with-dependencies-1.0.jar
GroupBy Stage的Task状态如下图所示，Task 8处理的记录数为4500万，远大于（9倍于）其它11个Task处理的500万记录。而Task 8所耗费的时间为38秒，远高于其它11个Task的平均时间（16秒）。整个Stage的时间也为38秒，该时间主要由最慢的Task 8决定。
在这种情况下，可以通过调整Shuffle并行度，使得原来被分配到同一个Task（即该例中的Task 8）的不同Key分配到不同Task，从而降低Task 8所需处理的数据量，缓解数据倾斜。通过groupByKey(48)将Shuffle并行度调整为48，重新提交到Spark。新的Job的GroupBy Stage所有Task状态如下图所示： 
从上图可知，记录数最多的Task 20处理的记录数约为1125万，相比于并行度为12时Task 8的4500万，降低了75%左右，而其耗时从原来Task 8的38秒降到了24秒。 在这种场景下，调整并行度，并不意味着一定要增加并行度，也可能是减小并行度。如果通过groupByKey(11)将Shuffle并行度调整为11，重新提交到Spark。新Job的GroupBy Stage的所有Task状态如下图所示：
从上图可见，处理记录数最多的Task 6所处理的记录数约为1045万，耗时为23秒。处理记录数最少的Task 1处理的记录数约为545万，耗时12秒。 适用场景：大量不同的Key被分配到了相同的Task造成该Task数据量过大。
解决方案：调整并行度。一般是增大并行度，但有时如本例减小并行度也可达到效果。 优势：实现简单，可在需要Shuffle的操作算子上直接设置并行度或者使用spark.default.parallelism设置。如果是Spark SQL，还可通过SET spark.sql.shuffle.partitions=[num_tasks]设置并行度。可用最小的代价解决问题。一般如果出现数据倾斜，都可以通过这种方法先试验几次，如果问题未解决，再尝试其它方法。 劣势：适用场景少，只能将分配到同一Task的不同Key分散开，但对于同一Key倾斜严重的情况该方法并不适用。并且该方法一般只能缓解数据倾斜，没有彻底消除问题。从实践经验来看，其效果一般。 （2）自定义Partitioner：
原理：使用自定义的Partitioner（默认为HashPartitioner），将原本被分配到同一个Task的不同Key分配到不同Task。
案例：以上述数据集为例，继续将并发度设置为12，但是在groupByKey算子上，使用自定义的Partitioner（实现如下）
.groupByKey(new Partitioner() { @Override public int numPartitions() { return 12; } @Override public int getPartition(Object key) { int id = Integer.parseInt(key.toString()); if(id >= 9500000 && id <= 9500084 && ((id - 9500000) % 12) == 0) { return (id - 9500000) / 12; } else { return id % 12; } }}) 由下图可见，使用自定义Partition后，耗时最长的Task 6处理约1000万条数据，用时15秒。并且各Task所处理的数据集大小相当。
适用场景：大量不同的Key被分配到了相同的Task造成该Task数据量过大。 解决方案：使用自定义的Partitioner实现类代替默认的HashPartitioner，尽量将所有不同的Key均匀分配到不同的Task中。 优势：不影响原有的并行度设计。如果改变并行度，后续Stage的并行度也会默认改变，可能会影响后续Stage。 劣势：适用场景有限，只能将不同Key分散开，对于同一Key对应数据集非常大的场景不适用。效果与调整并行度类似，只能缓解数据倾斜而不能完全消除数据倾斜。而且需要根据数据特点自定义专用的Partitioner，不够灵活。 （3）将Reduce side Join转变为Map side Join：
原理：通过Spark的Broadcast机制，将Reduce侧Join转化为Map侧Join，避免Shuffle从而完全消除Shuffle带来的数据倾斜。
案例：通过如下SQL创建一张具有倾斜Key且总记录数为1.5亿的大表test。
INSERT OVERWRITE TABLE testSELECT CAST(CASE WHEN id < 980000000 THEN (95000000 + (CAST (RAND() * 4 AS INT) + 1) * 48 ) ELSE CAST(id/10 AS INT) END AS STRING), nameFROM student_externalWHERE id BETWEEN 900000000 AND 1050000000;
使用如下SQL创建一张数据分布均匀且总记录数为50万的小表test_new。
INSERT OVERWRITE TABLE test_newSELECT CAST(CAST(id/10 AS INT) AS STRING), nameFROM student_delta_externalWHERE id BETWEEN 950000000 AND 950500000;
直接通过Spark Thrift Server提交如下SQL将表test与表test_new进行Join并将Join结果存于表test_join中。
INSERT OVERWRITE TABLE test_joinSELECT test_new.id, test_new.nameFROM testJOIN test_newON test.id = test_new.id;
该SQL对应的DAG如下图所示。从该图可见，该执行过程总共分为三个Stage，前两个用于从Hive中读取数据，同时二者进行Shuffle，通过最后一个Stage进行Join并将结果写入表test_join中。
从下图可见，Join Stage各Task处理的数据倾斜严重，处理数据量最大的Task耗时7.1分钟，远高于其它无数据倾斜的Task约2秒的耗时。 
接下来，尝试通过Broadcast实现Map侧Join。实现Map侧Join的方法，并非直接通过CACHE TABLE test_new将小表test_new进行cache。现通过如下SQL进行Join。 CACHE TABLE test_new;INSERT OVERWRITE TABLE test_joinSELECT test_new.id, test_new.nameFROM testJOIN test_newON test.id = test_new.id;
通过如下DAG图可见，该操作仍分为三个Stage，且仍然有Shuffle存在，唯一不同的是，小表的读取不再直接扫描Hive表，而是扫描内存中缓存的表。
并且数据倾斜仍然存在。如下图所示，最慢的Task耗时为7.1分钟，远高于其它Task的约2秒。 
正确的使用Broadcast实现Map侧Join的方式是，通过SET spark.sql.autoBroadcastJoinThreshold=104857600;将Broadcast的阈值设置得足够大。 再次通过如下SQL进行Join：
SET spark.sql.autoBroadcastJoinThreshold=104857600;INSERT OVERWRITE TABLE test_joinSELECT test_new.id, test_new.nameFROM testJOIN test_newON test.id = test_new.id;
通过如下DAG图可见，该方案只包含一个Stage：
并且从下图可见，各Task耗时相当，无明显数据倾斜现象。并且总耗时为1.5分钟，远低于Reduce侧Join的7.3分钟。 
适用场景：参与Join的一边数据集足够小，可被加载进Driver并通过Broadcast方法广播到各个Executor中。 解决方案：在Java/Scala代码中将小数据集数据拉取到Driver，然后通过Broadcast方案将小数据集的数据广播到各Executor。或者在使用SQL前，将Broadcast的阈值调整得足够大，从而使用Broadcast生效。进而将Reduce侧Join替换为Map侧Join。 优势：避免了Shuffle，彻底消除了数据倾斜产生的条件，可极大提升性能。 劣势：要求参与Join的一侧数据集足够小，并且主要适用于Join的场景，不适合聚合的场景，适用条件有限。 （4）为skew的key增加随机前/后缀：
原理：为数据量特别大的Key增加随机前/后缀，使得原来Key相同的数据变为Key不相同的数据，从而使倾斜的数据集分散到不同的Task中，彻底解决数据倾斜问题。Join另一则的数据中，与倾斜Key对应的部分数据，与随机前缀集作笛卡尔乘积，从而保证无论数据倾斜侧倾斜Key如何加前缀，都能与之正常Join。
案例：通过如下SQL，将id为9亿到9.08亿共800万条数据的id转为9500048或者9500096，其它数据的id除以100取整。从而该数据集中，id为9500048和9500096的数据各400万，其它id对应的数据记录数均为100条。这些数据存于名为test的表中。对于另外一张小表test_new，取出50万条数据，并将id（递增且唯一）除以100取整，使得所有id都对应100条数据。
INSERT OVERWRITE TABLE testSELECT CAST(CASE WHEN id < 908000000 THEN (9500000 + (CAST (RAND() * 2 AS INT) + 1) * 48 ) ELSE CAST(id/100 AS INT) END AS STRING), nameFROM student_externalWHERE id BETWEEN 900000000 AND 1050000000;INSERT OVERWRITE TABLE test_newSELECT CAST(CAST(id/100 AS INT) AS STRING), nameFROM student_delta_externalWHERE id BETWEEN 950000000 AND 950500000;
通过如下代码，读取test表对应的文件夹内的数据并转换为JavaPairRDD存于leftRDD中，同样读取test表对应的数据存于rightRDD中。通过RDD的join算子对leftRDD与rightRDD进行Join，并指定并行度为48。
public class SparkDataSkew{ public static void main(String[] args) { SparkConf sparkConf = new SparkConf(); sparkConf.setAppName("DemoSparkDataFrameWithSkewedBigTableDirect"); sparkConf.set("spark.default.parallelism", String.valueOf(parallelism)); JavaSparkContext javaSparkContext = new JavaSparkContext(sparkConf); JavaPairRDD leftRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test/") .mapToPair((String row) -> { String[] str = row.split(","); return new Tuple2 (str[0], str[1]); }); JavaPairRDD rightRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test_new/") .mapToPair((String row) -> { String[] str = row.split(","); return new Tuple2 (str[0], str[1]); }); leftRDD.join(rightRDD, parallelism) .mapToPair((Tuple2 > tuple) -> new Tuple2 (tuple._1(), tuple._2()._2())) .foreachPartition((Iterator > iterator) -> { AtomicInteger atomicInteger = new AtomicInteger(); iterator.forEachRemaining((Tuple2 tuple) -> atomicInteger.incrementAndGet()); }); javaSparkContext.stop(); javaSparkContext.close(); }} 从下图可看出，整个Join耗时1分54秒，其中Join Stage耗时1.7分钟。
通过分析Join Stage的所有Task可知，在其它Task所处理记录数为192.71万的同时Task 32的处理的记录数为992.72万，故它耗时为1.7分钟，远高于其它Task的约10秒。这与上文准备数据集时，将id为9500048为9500096对应的数据量设置非常大，其它id对应的数据集非常均匀相符合。 
现通过如下操作，实现倾斜Key的分散处理： - 将leftRDD中倾斜的key（即9500048与9500096）对应的数据单独过滤出来，且加上1到24的随机前缀，并将前缀与原数据用逗号分隔（以方便之后去掉前缀）形成单独的leftSkewRDD
- 将rightRDD中倾斜key对应的数据抽取出来，并通过flatMap操作将该数据集中每条数据均转换为24条数据（每条分别加上1到24的随机前缀），形成单独的rightSkewRDD
- 将leftSkewRDD与rightSkewRDD进行Join，并将并行度设置为48，且在Join过程中将随机前缀去掉，得到倾斜数据集的Join结果skewedJoinRDD
- 将leftRDD中不包含倾斜Key的数据抽取出来作为单独的leftUnSkewRDD
- 对leftUnSkewRDD与原始的rightRDD进行Join，并行度也设置为48，得到Join结果unskewedJoinRDD
- 通过union算子将skewedJoinRDD与unskewedJoinRDD进行合并，从而得到完整的Join结果集
具体实现代码如下：
public class SparkDataSkew{ public static void main(String[] args) { int parallelism = 48; SparkConf sparkConf = new SparkConf(); sparkConf.setAppName("SolveDataSkewWithRandomPrefix"); sparkConf.set("spark.default.parallelism", parallelism + ""); JavaSparkContext javaSparkContext = new JavaSparkContext(sparkConf); JavaPairRDD leftRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test/") .mapToPair((String row) -> { String[] str = row.split(","); return new Tuple2 (str[0], str[1]); }); JavaPairRDD rightRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test_new/") .mapToPair((String row) -> { String[] str = row.split(","); return new Tuple2 (str[0], str[1]); }); String[] skewedKeyArray = new String[]{ "9500048", "9500096"}; Set skewedKeySet = new HashSet (); List addList = new ArrayList (); for(int i = 1; i <=24; i++) { addList.add(i + ""); } for(String key : skewedKeyArray) { skewedKeySet.add(key); } Broadcast > skewedKeys = javaSparkContext.broadcast(skewedKeySet); Broadcast > addListKeys = javaSparkContext.broadcast(addList); JavaPairRDD leftSkewRDD = leftRDD .filter((Tuple2 tuple) -> skewedKeys.value().contains(tuple._1())) .mapToPair((Tuple2 tuple) -> new Tuple2 ((new Random().nextInt(24) + 1) + "," + tuple._1(), tuple._2())); JavaPairRDD rightSkewRDD = rightRDD.filter((Tuple2 tuple) -> skewedKeys.value().contains(tuple._1())) .flatMapToPair((Tuple2 tuple) -> addListKeys.value().stream() .map((String i) -> new Tuple2 ( i + "," + tuple._1(), tuple._2())) .collect(Collectors.toList()) .iterator() ); JavaPairRDD skewedJoinRDD = leftSkewRDD .join(rightSkewRDD, parallelism) .mapToPair((Tuple2 > tuple) -> new Tuple2 (tuple._1().split(",")[1], tuple._2()._2())); JavaPairRDD leftUnSkewRDD = leftRDD.filter((Tuple2 tuple) -> !skewedKeys.value().contains(tuple._1())); JavaPairRDD unskewedJoinRDD = leftUnSkewRDD.join(rightRDD, parallelism).mapToPair((Tuple2 > tuple) -> new Tuple2 (tuple._1(), tuple._2()._2())); skewedJoinRDD.union(unskewedJoinRDD).foreachPartition((Iterator > iterator) -> { AtomicInteger atomicInteger = new AtomicInteger(); iterator.forEachRemaining((Tuple2 tuple) -> atomicInteger.incrementAndGet()); }); javaSparkContext.stop(); javaSparkContext.close(); }}
从下图可看出，整个Join耗时58秒，其中Join Stage耗时33秒。
通过分析Join Stage的所有Task可知： - 由于Join分倾斜数据集Join和非倾斜数据集Join，而各Join的并行度均为48，故总的并行度为96
- 由于提交任务时，设置的Executor个数为4，每个Executor的core数为12，故可用Core数为48，所以前48个Task同时启动（其Launch时间相同），后48个Task的启动时间各不相同（等待前面的Task结束才开始）
- 由于倾斜Key被加上随机前缀，原本相同的Key变为不同的Key，被分散到不同的Task处理，故在所有Task中，未发现所处理数据集明显高于其它Task的情况
适用场景：两张表都比较大，无法使用Map则Join。其中一个RDD有少数几个Key的数据量过大，另外一个RDD的Key分布较为均匀。
解决方案：将有数据倾斜的RDD中倾斜Key对应的数据集单独抽取出来加上随机前缀，另外一个RDD每条数据分别与随机前缀结合形成新的RDD（相当于将其数据增到到原来的N倍，N即为随机前缀的总个数），然后将二者Join并去掉前缀。然后将不包含倾斜Key的剩余数据进行Join。最后将两次Join的结果集通过union合并，即可得到全部Join结果。 优势：相对于Map则Join，更能适应大数据集的Join。如果资源充足，倾斜部分数据集与非倾斜部分数据集可并行进行，效率提升明显。且只针对倾斜部分的数据做数据扩展，增加的资源消耗有限。 劣势：如果倾斜Key非常多，则另一侧数据膨胀非常大，此方案不适用。而且此时对倾斜Key与非倾斜Key分开处理，需要扫描数据集两遍，增加了开销。（5）大表随机添加N种随机前缀，小表扩大N倍
原理：如果出现数据倾斜的Key比较多，上一种方法将这些大量的倾斜Key分拆出来，意义不大。此时更适合直接对存在数据倾斜的数据集全部加上随机前缀，然后对另外一个不存在严重数据倾斜的数据集整体与随机前缀集作笛卡尔乘积（即将数据量扩大N倍）。
案例：这里给出示例代码，读者可参考上文中分拆出少数倾斜Key添加随机前缀的方法，自行测试。
public class SparkDataSkew { public static void main(String[] args) { SparkConf sparkConf = new SparkConf(); sparkConf.setAppName("ResolveDataSkewWithNAndRandom"); sparkConf.set("spark.default.parallelism", parallelism + ""); JavaSparkContext javaSparkContext = new JavaSparkContext(sparkConf); JavaPairRDD leftRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test/") .mapToPair((String row) -> { String[] str = row.split(","); return new Tuple2 (str[0], str[1]); }); JavaPairRDD rightRDD = javaSparkContext.textFile("hdfs://hadoop1:8020/apps/hive/warehouse/default/test_new/") .mapToPair((String row) -> { String[] str = row.split(","); return new Tuple2 (str[0], str[1]); }); List addList = new ArrayList (); for(int i = 1; i <=48; i++) { addList.add(i + ""); } Broadcast > addListKeys = javaSparkContext.broadcast(addList); JavaPairRDD leftRandomRDD = leftRDD.mapToPair((Tuple2 tuple) -> new Tuple2 (new Random().nextInt(48) + "," + tuple._1(), tuple._2())); JavaPairRDD rightNewRDD = rightRDD .flatMapToPair((Tuple2 tuple) -> addListKeys.value().stream() .map((String i) -> new Tuple2 ( i + "," + tuple._1(), tuple._2())) .collect(Collectors.toList()) .iterator() ); JavaPairRDD joinRDD = leftRandomRDD .join(rightNewRDD, parallelism) .mapToPair((Tuple2 > tuple) -> new Tuple2 (tuple._1().split(",")[1], tuple._2()._2())); joinRDD.foreachPartition((Iterator > iterator) -> { AtomicInteger atomicInteger = new AtomicInteger(); iterator.forEachRemaining((Tuple2 tuple) -> atomicInteger.incrementAndGet()); }); javaSparkContext.stop(); javaSparkContext.close(); }}
适用场景：一个数据集存在的倾斜Key比较多，另外一个数据集数据分布比较均匀。
优势：对大部分场景都适用，效果不错。 劣势：需要将一个数据集整体扩大N倍，会增加资源消耗。总结：对于数据倾斜，并无一个统一的一劳永逸的方法。更多的时候，是结合数据特点（数据集大小，倾斜Key的多少等）综合使用上文所述的多种方法。
参考：
1.Hive中：
group by、join、count(distinct)可参考：
转载地址：https://blog.csdn.net/m0_37739193/article/details/117429459 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！
发表评论
最新留言
关于作者
