Spark数据倾斜解决方案三：随机key双重聚合（包含完整案例代码）

已于 2023-07-11 09:22:25 修改
阅读量1.3k 收藏 1
点赞数 1
CC 4.0 BY-SA版权
分类专栏： Spark最佳实战与性能优化 文章标签： spark 大数据 数据倾斜 随机key 双重聚合
于 2023-06-09 14:37:44 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/Android_xue/article/details/131126122
本文介绍了Spark的随机key双重聚合方法来解决数据倾斜问题，详细阐述了其实现思路、适用场景和案例代码。通过在Key值前添加随机数进行局部聚合，再去除前缀进行全局聚合，有效缓解数据倾斜，提升作业性能。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

在这里插入图片描述

什么是随机key双重聚合

随机Key双重聚合是指Spark分布式计算对RDD调用reduceByKey等聚合类Shuffle算子进行计算，使用对Key值随机数前缀的处理技巧，对Key值进行二次聚合。

  • 第一次聚合（局部聚合）：对每个Key值加上一个随机数，执行第一次reduceByKey聚合操作。
  • 第二次聚合（双重聚合）：去掉Key值的前缀随机数，执行第二次reduceByKey聚合，最终得到全局聚合的结果。

适用场景

对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合。

案例：电商广告点击系统中，如果根据用户点击的省份进行汇聚，原来的Key值是省份，如果某些省份的Value值特别多，发生了数据倾斜，可以将每个Key拆分成多个Key，加上随机数前缀将Key

了解本专栏 订阅专栏 解锁全文 超级会员免费看
Spark数据倾斜解决方案六：随机前缀和扩容Join（包含完整案例代码）
SunnyRivers
06-10 1314
该想法的原因：Shuffle的时候把Key的数据可以分到不同的Task里。但是，现在的倾斜的Key非常多，成千上万，所以如果说采样找出倾斜的Key的话，并不是一个非常好的想法。需要考虑当前程序能够使用的Core的数目，扩容的问题是来解决从程序运行不了的问题，从无法运行到能运行的结果。该方案更多的是缓解数据倾斜，而不是彻底避免数据倾斜，而且需要对整个RDD进行扩容，对内存资源要求很高。同时对另外一个正常的RDD进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一个0~n的前缀。
Spark数据倾斜解决方案五：对倾斜key采样后单独Join（包含完整案例代码）
SunnyRivers
06-10 1056
对倾斜的Keys采样进行单独的Join操作步骤有点复杂：首先对RDD1进行采样，例如RDD1进行Sample抽样（15%）可以计算出一个结果，其是一个RDD，采样之后进行Map操作，通过reduceBykey操作计数，然后对Key和Value进行置换，通过SortByKey进行排序，再进行Map置换操作，从而找出哪一个Key值倾斜比较严重，对其进行过滤，提取到RDD11中，剩下的提取到RDD12中。避免了占用过多内存。如果倾斜的Key特别多，如50多个倾斜的Key，我们可以一个一个地对Key进行过滤处理。
Spark SQL中的聚合与窗口函数
日常分享数据分析开发、编程语言内容
01-02 1367
Spark SQL中的聚合与窗口函数是强大的工具，用于分析和处理结构化数据。本文深入探讨了聚合函数、分组操作、窗口函数以及实际用例，并提供了性能优化的建议。希望本文能够帮助大家更好地理解和应用Spark SQL中的聚合与窗口函数，以解决复杂的数据分析问题。
spark 大型项目实战(五十五):数据倾斜解决方案之使用随机key实现双重聚合
u012957549的博客
08-04 3224
使用随机key实现双重聚合 1、原理 2、使用场景 （1）groupByKey （2）reduceByKey 比较适合使用这种方式；join，咱们通常不会这样来做，后面会讲三种，针对不同的join造成的数据倾斜的问题的解决方案。 第一轮聚合的时候，对key进行打散，将原先一样的key，变成不一样的key，相当于是将每个key分为多组； 先针对多个组，进行key的局部聚合；接着，再去除...
spark 数据倾斜之两阶段聚合（局部聚合+全局聚合）
鸭梨的博客
01-30 1592
两阶段聚合（局部聚合+全局聚合） 方案适用场景： 对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时，比较适用这种方案。 方案实现思路： 这个方案的核心实现思路就是进行两阶段聚合。第一次是局部聚合，先给每个key都打上一个随机数，比如10以内的随机数，此时原先一样的key就变成不一样的了，比如(hello, (hello, 1) (hello, 1) (hello, 1)，就会变成(1_hello, 1) (1_hello,
spark通过随机加前缀解决数据倾斜问题
qq_50166024的博客
11-26 929
package day03 import org.apache.spark.sql.{DataFrame, SparkSession} //解决wordcount的数据倾斜问题 object _01DataSkewDemo01 { def main(args: Array[String]): Unit = { val spark: SparkSession = SparkSession.builder().master("local[2]").appName("test").getOrCr.
Hadoop学习（十）——数据倾斜及案例汇总
livan1234的博客
06-28 3601
笔者是一个痴迷于挖掘数据中的价值的学习人，希望在平日的工作学习中，挖掘数据的价值，找寻数据的秘密，笔者认为，数据的价值不仅仅只体现在企业中，个人也可以体会到数据的魅力，用技术力量探索行为密码，让大数据助跑每一个人，欢迎直筒们关注我的公众号，大家一起讨论数据中的那些有趣的事情。 我的公众号为：livandata
Spark数据倾斜解决方案四：Mapper端Join（包含完整案例代码）
SunnyRivers
06-09 1248
为什么要在Mapper端Join 解决数据倾斜有一个技巧：把Reducer端的操作变成Mapper端的Reduce，通过这种方式不需要发生Shuffle。如果把Reducer端的操作放在Mapper端，就避免了Shuffle。避免了Shuffle，在很大程度上就化解掉了数据倾斜的问题。Spark是RDD的链式操作，DAGScheduler根据RDD的不同类型的依赖关系划分成不同的Stage，所谓不同类型的依赖关系，就是宽依赖、窄依赖。当发生宽依赖的时候，把Stage划分成更小的Stage。划分的依据就是宽依
Spark数据倾斜解决方案一：源数据预处理和过滤倾斜key
SunnyRivers
06-09 1109
为什么把源数据预处理和过滤掉倾斜的key两种处理倾斜的方式写到一起？因为这两种方式在实际的项目中场景较少而且单一，对于数据源预处理，比如原本要在spark中进行聚合或join的操作，提前到hive中去做，这种方式虽然解决了spark中数据倾斜的问题，但是hive中依然也会存在；而过滤倾斜的key的场景就更加少了。不过虽然少见，也需要有这样的解决问题思维。
hive/spark数据倾斜解决方案
运维仙人
06-21 2043
数据倾斜主要表现在，mapreduce程序执行时，reduce节点大部分执行完毕，但是有一个或者几个reduce节点运行很慢，导致整个程序的处理时间很长，这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多)，这条Key所在的reduce节点所处理的数据量比其他节点就大很多，从而导致某几个节点迟迟运行不完。
Spark SQL数据倾斜解决方案
迎接小天使
10-14 711
由于Spark都是基于RDD的特性，所以可以用纯RDD的方法，实现和Spark SQL一模一样的功能。 之前在Spark Core中的数据倾斜的七种解决方案，全部都可以直接套用在Spark SQL上。 Spark SQL的数据倾斜解决方案： 聚合源数据：Spark Core和Spark SQL没有任何区别 1、过滤导致倾斜的key：在sql中用where条件 2、提高shuffle并行度：grou...
Spark中组件Mllib的学习21之随机数-RandomRDD产生
Keep Learning
05-23 4392
更多代码请见：https://github.com/xubo245/SparkLearning Spark中组件Mllib的学习之基础概念篇 1解释 在org.apache.spark.mllib.random下RandomRDDs对象，处理生成RandomRDD，还可以生成uniformRDD、poissonRDD、exponentialRDD、gammaRDD等2.代码：/** *
spark SQL （二） 聚合
weixin_30480075的博客
12-23 195
聚合内置功能DataFrames提供共同聚合，例如count()，countDistinct()，avg()，max()，min()，等。虽然这些功能是专为DataFrames，spark SQL还拥有类型安全的版本，在其中的一些 scala和Java使用强类型数据集的工作。而且，用户可以预定义的聚合函数，也可以创建自己自定义的聚合函数。 1，...
spark数据倾斜，spark sql 优化方案
Lpf的博客
05-26 3014
1、SQL 代码层面优化 Step1、阻塞调度的长耗时 SQL 提取 Step2、划分长耗时 SQL Step3、对长耗时 SQL 逐个分析 1.1、数据倾斜优化 1.1.1、sqoop 导入数据时的倾斜： 经过分析发现，数据倾斜是因为sqoop 同步数据时，采用的是sys_time字段进行数据进行split的，客户可能在某一时间对业务数据库进行过导入，从而导致很多数据的sys_time 在同一时间。所以sqoop 导入的数据，即存在了数据倾斜 解决办法： 将sqoop split_by 的..
数据倾斜时如何应对--倾斜key单独处理/MapJoin/SkewJoin的原理及使用方法
andarly的专栏
10-08 306
Common Join 的一个主要问题是在数据整理排序的过程上耗费了大量的资源，它会启动一个Task，Mapper会去读取两张表中的数据，然后处理数据后会对对他们进行排序、合并等操作，然后相同key的所有行数据都会分发到同一个节点上。但是MapJoin只适用于大表小表Join的情况，因为MapJoin会将指定表的数据全部加载在内存，表在被加载到内存后，数据大小会急剧膨胀，因此指定的表只能是小表。当存在大量倾斜key的时候，可以通过手动拆分，将倾斜与未倾斜的部分分别做处理，再将结果合并。
Spark性能优化指南——高级篇
世界那么大，我想去看看！
09-23 379
继基础篇讲解了每个Spark开发人员都必须熟知的开发调优与资源调优之后，本文作为《Spark性能优化指南》的高级篇，将深入分析数据倾斜调优与shuffle调优，以解决更加棘手的性能问题。 调优概述 有的时候，我们可能会遇到大数据计算中一个最棘手的问题——数据倾斜，此时Spark作业的性能会比期望差很多。数据倾斜调优，就是使用各种技术方案解决不同类型的数据倾斜问题，以保证Spark作业的性能。 数据倾斜发生时的现象 绝大多数task执行得都非常快，但个别task执行极慢。比如，总共有1000个ta
数据倾斜解决方案之三：使用随机Key实现双重聚合
大模型与Agent智能体
07-13 2574
数据倾斜解决方案之三：使用随机Key实现双重聚合本节讲解使用随机Key实现双重聚合，首先讲解什么是随机Key双重聚合；接下来讲解使用随机Key实现双重聚合解决数据倾斜的适用场景、原理分析、案例实战以及使用随机Key实现双重聚合解决数据倾斜注意事项等内容。30.4.1 什么是随机Key双重聚合？随机Key双重聚合是指：Spark分布式计算对RDD调用reduceByKey各算子进行计算，使用对Key
Spark性能优化之道——解决Spark数据倾斜
学海无涯
02-09 1715
本文结合实例详细阐明了Spark数据倾斜的几种场景以及对应的解决方案，包括避免数据源倾斜，调整并行度，使用自定义Partitioner，使用Map侧Join代替Reduce侧Join，给倾斜Key加上随机前缀等。摘要本文结合实例详细阐明了Spark数据倾斜的几种场景以及对应的解决方案，包括避免数据源倾斜，调整并行度，使用自定义Partitioner，使用Map侧Join代替Reduce侧Join，...
spark 数据倾斜解决方案 使用随机key实现双重聚合
weixin_42435657的博客
04-07 417
用我们讲的这种高级的reduce join转map join的技术，不要用普通的join，去通过shuffle，第一轮聚合的时候，对key进行打散，将原先一样的key，变成不一样的key，相当于是将每个key分为多组；可以执行map操作，去将之前打上的随机数，给去掉，然后再和另外一个普通RDD join以后的结果，1、选择一个RDD，要用flatMap，进行扩容，将每条数据，映射为多条数据，每个映射出来的数据，join，咱们通常不会这样来做，后面会讲三种，针对不同的join造成的数据倾斜的问题的解决方案。
假设你做了一个基于SpringBoot+Spark的考研预测分析系统，如果问你你在过去的编程中，遇到的最困难的事是什么？你是如何解决的？
最新发布
03-29
<think>嗯，用户现在问的是，如果做了一个基于SpringBoot和Spark的考研预测分析系统，在过去的编程中遇到的最困难的事情是什么，以及如何解决的。首先，我需要先理解这个问题的意图。用户可能是在准备面试，或者想要了解在开发这类项目中可能遇到的挑战和解决方法。 接下来，我需要构造一个合理的虚构案例，因为作为AI，我没有实际的项目经验。但根据常见的开发问题，可以推测可能遇到的技术难点，比如数据量大导致处理效率低、框架集成问题、模型训练时间过长等。 然后，用户提到的是SpringBoot和Spark的结合使用。SpringBoot通常用于构建后端服务，而Spark用于大数据处理。两者结合时，可能会遇到集成上的问题，比如依赖冲突，或者如何在SpringBoot中有效地调度Spark任务。此外，数据处理的性能优化也是一个常见的难点。 还要考虑用户可能关心的点，比如如何解决技术难题，解决问题的过程，以及从中获得的经验。需要将问题具体化，比如数据预处理阶段的性能瓶颈，或者模型训练时的资源不足。 然后，需要分步骤思考如何描述这个困难，如何分析问题，以及采取了哪些措施来解决。比如，遇到Spark任务在SpringBoot中运行缓慢，可能的原因包括数据倾斜、资源配置不当、代码效率低等。解决方案可能包括优化数据分区、调整Executor内存、使用广播变量减少数据传输等。 还要确保回答结构清晰，符合之前用户要求的步骤式解答，并且符合系统级指令中的格式要求，比如使用行内数学公式和独立公式的格式。 最后，需要验证回答是否涵盖了用户的问题，是否提供了具体的例子和解决步骤，以及是否展示了技术深度和解决问题的能力。同时，要确保语言自然，避免过于机械化的表达，符合用户希望的中文回答要求。</think>--- ### **假设案例：基于SpringBoot+Spark的考研预测分析系统** **技术栈**：SpringBoot（Web服务层） + Spark（大数据处理） + Scikit-learn（预测模型） + MySQL（数据存储） --- ### **一、遇到的核心难点** **问题定位**：**数据预处理阶段Spark性能骤降** - 现象：当处理百万级考生历史数据（文本日志+结构化成绩）时，Spark任务在`DataFrame`的`join`操作后，执行时间从20分钟突然上升到2小时以上，且Executor出现频繁GC（垃圾回收） **技术矛盾点**： 1. **数据倾斜严重**：部分高校考生日志量级差达100倍（如热门院校vs冷门院校） 2. **Shuffle溢出**：`join`操作触发大量Shuffle，默认分区策略导致单个Task处理数据量超过内存限制 3. **序列化瓶颈**：自定义的UDF（用户定义函数）未优化，引发Java反射性能损耗 --- ### **二、解决路径与关键技术决策** #### **第一步：定位瓶颈源（科学分析工具）** - **Spark UI诊断**： - 发现Stage 3的`Shuffle Read Size/Records`存在严重倾斜（最大分区数据量达98GB，最小仅2GB） - 关键指标：`GC Time`占比超60%，`Shuffle Spill`次数超过200次 - **代码审查**： - 定位到`school_id`字段作为`join`键，但该字段基数低（仅200个高校），导致哈希分布不均 #### **第二步：针对性优化方案** **1. 数据倾斜缓解（双重随机盐值法）** - 对倾斜的`school_id`添加随机前缀，将大Key分散到不同分区： ```scala val saltedSchoolDF = originDF.withColumn("salted_school_id", concat($"school_id", lit("_"), (rand() * 10).cast("int")) ) ``` - 二次聚合时去除盐值前缀，确保结果正确性 **2. Shuffle参数调优** - 动态调整分区数，避免内存溢出： ```sql SET spark.sql.shuffle.partitions=2000; -- 根据数据量动态计算 SET spark.sql.adaptive.enabled=true; -- 启用自适应查询 ``` - 提升Executor堆外内存，降低GC频率： ```bash spark.executor.memoryOverhead=2g spark.memory.fraction=0.8 ``` **3. UDF函数优化（避免反射开销）** - 将Java反射式UDF改写为`Scala原生函数` + `Spark SQL表达式`： ```scala // 优化前（反射性能差） spark.udf.register("parse_log", (log:String) => LogParser.parse(log)) // 优化后（列式处理） val parsedDF = rawDF.withColumn("parsed_data", expr("split(value, '|')").getItem(2) // 直接使用Spark内置函数 ) ``` #### **第三步：验证与效果** - **性能对比**： - Shuffle数据量从**1.2TB**降至**300GB** - 任务执行时间从**2小时**缩短至**25分钟** - GC时间占比从60%降至8% - **质量验证**： - 通过抽样比对优化前后JOIN结果，确认数据一致性（准确率100%） --- ### **三、经验沉淀与复用** 1. **编码规范**： - 在Spark中优先使用内置高阶函数（如`transform`、`aggregate`），避免低效UDF - 对`join`/`groupBy`键提前做基数分析，预设分区策略 2. **参数调优模板**： ```scala // 针对Shuffle的通用配置模板 val spark = SparkSession.builder() .config("spark.sql.adaptive.coalescePartitions.enabled", "true") .config("spark.sql.adaptive.skewJoin.enabled", "true") // 自动处理倾斜 .config("spark.sql.adaptive.advisoryPartitionSizeInBytes", "128MB") .getOrCreate() ``` 3. **监控增强**： - 集成Prometheus + Grafana，实时监控Executor的CPU/内存/GC指标 - 对倾斜任务自动触发告警（如单个分区数据量超过平均值的5倍） --- ### **四、核心方法论总结** $$ 解决难题 = \frac{精准定位（工具化分析） + 分层击破（数据/代码/配置）}{盲目试错} $$ - **永远优先定位根因**：性能问题切忌直接调参，需通过Spark UI/日志明确瓶颈阶段 - **权衡优化成本**：例如数据盐值法会增加开发复杂度，需评估是否值得（如倾斜率>30%则必须处理） - **建立技术雷达**：持续关注Spark 3.0+的AQE（自适应查询优化）等新特性，减少手动调优负担
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

SunnyRivers

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值