Spark性能调优实战
吴磊
FreeWheel机器学习团队负责人
新⼈⾸单¥59.9
1450 人已学习
课程目录
已更新 30 讲 / 共 32 讲
0/4登录后,你可以任选4讲全文学习。
课前必学 (3讲)
开篇词 | Spark性能调优,你该掌握这些“套路”
免费
01 | 性能调优的必要性:Spark本身就很快,为啥还需要我调优?
02 | 性能调优的本质:调优的手段五花八门,该从哪里入手?
原理篇 (5讲)
03 | RDD:为什么你必须要理解弹性分布式数据集?
04 | DAG与流水线:到底啥叫“内存计算”?
05 | 调度系统:“数据不动代码动”到底是什么意思?
06 | 存储系统:空间换时间,还是时间换空间?
07 | 内存管理基础:Spark如何高效利用有限的内存空间?
通用性能调优篇 (12讲)
08 | 应用开发三原则:如何拓展自己的开发边界?
09 | 调优一筹莫展,配置项速查手册让你事半功倍!(上)
10 |调优一筹莫展,配置项速查手册让你事半功倍!(下)
11 | Shuffle的工作原理:为什么说Shuffle是一时无两的性能杀手?
12 | 广播变量(一):克制Shuffle,如何一招制胜!
13 | 广播变量(二):有哪些途径让Spark SQL选择Broadcast Joins?
14 | CPU视角:如何高效地利用CPU?
15 | 内存视角(一):如何最大化内存的使用效率?
16 | 内存视角(二):如何有效避免Cache滥用?
17 | 内存视角(三):OOM都是谁的锅?怎么破?
18 | 磁盘视角:如果内存无限大,磁盘还有用武之地吗?
19 | 网络视角:如何有效降低网络开销?
Spark SQL 性能调优篇 (10讲)
20 | RDD和DataFrame:既生瑜、何生亮
21 | Catalyst逻辑计划:你的SQL语句是怎么被优化的?(上)
22 | Catalyst物理计划:你的SQL语句是怎么被优化的(下)?
23 | 钨丝计划:Tungsten给开发者带来了哪些福报?
24 | Spark 3.0(一):AQE的3个特性怎么才能用好?
25 | Spark 3.0(二):DPP特性该怎么用?
26 | Join Hints指南:不同场景下,如何选择Join策略?
27 | 大表Join小表:广播变量容不下小表怎么办?
28 | 大表Join大表(一):什么是“分而治之”的调优思路?
29 | 大表Join大表(二):什么是负隅顽抗的调优思路?
Spark性能调优实战
15
15
1.0x
00:00/00:00
登录|注册

27 | 大表Join小表:广播变量容不下小表怎么办?

吴磊 2021-05-14
你好,我是吴磊。
在数据分析领域,大表 Join 小表的场景非常普遍。不过,大小是个相对的概念,通常来说,大表与小表尺寸相差 3 倍以上,我们就将其归类为“大表 Join 小表”的计算场景。因此,大表 Join 小表,仅仅意味着参与关联的两张表尺寸悬殊。
对于大表 Join 小表这种场景,我们应该优先考虑 BHJ,它是 Spark 支持的 5 种 Join 策略中执行效率最高的。BHJ 处理大表 Join 小表时的前提条件是,广播变量能够容纳小表的全量数据。但是,如果小表的数据量超过广播阈值,我们又该怎么办呢?
今天这一讲,我们就结合 3 个真实的业务案例,来聊一聊这种情况的解决办法。虽然这 3 个案例不可能覆盖“大表 Join 小表”场景中的所有情况,但是,分析并汇总案例的应对策略和解决办法,有利于我们在调优的过程中开阔思路、发散思维,从而避免陷入“面对问题无所适从”的窘境。

案例 1:Join Key 远大于 Payload

在第一个案例中,大表 100GB、小表 10GB,它们全都远超广播变量阈值(默认 10MB)。因为小表的尺寸已经超过 8GB,在大于 8GB 的数据集上创建广播变量,Spark 会直接抛出异常,中断任务执行,所以 Spark 是没有办法应用 BHJ 机制的。那我们该怎么办呢?先别急,我们来看看这个案例的业务需求。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Spark性能调优实战》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥59.9
立即订阅
登录 后留言

精选留言(4)

  • 老师,这些都是基于spark3.0的新特性,那对于3.0之前的版本又该怎么解决呢,毕竟3.0版本是新出的,对于大多数公司不一定使用了该版本

    作者回复: 咱们举了3个案例,其中第二个案例需要用到3.0的AQE,具体来说是Join策略调整;第三个案例是用join hints把Shuffle SMJ转化为Shuffle HJ。这两个case利用的新特性,确实是3.0才支持。

    不过第一个,也就是Join Keys比Payload大很多,这个技巧并不需要3.0哈~

    2021-05-19
  • zxk
    老师我想请问下,在第二个案例中,如果我将 join 条件写成 on orders.userId = users.id and users.type = ‘Head User’ ,是否能实现维度表提前过滤并达到 Broadcast 的要求?
    2021-05-16
  • aof
    1. 可以使用BitMap
    2. 一种方法可以使用老师之前讲过的先对DataFrame进行cache,然后读取 Spark SQL 执行计划的统计数据。另一种也可以对过滤后的维表进行cache,然后执行Spark任务,,最后在Spark的Web UI上查看缓存的表大小
    3. 找出倾斜数据对应的key,对key加盐打散,使维表的每个数据分片都能放进内存,从而利用SHJ。
    2021-05-16
  • Fendora范东_
    问题回答
    1.给join keys每个字段维护一个字典,每个字段值在字典内对应一个唯一的整数。拿到每个字段指定的种整数,然后组装起来,作为新的join key。
     2.把维度表查询sql单独拿出来,缓存其df,查看其屋里计划,可以知道它结果集大小。
    3.参考AQE的自动倾斜处理特性,把数据倾斜的分区拆分开,然后再进行SHJ
    2021-05-15
收起评论
4
返回
顶部