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大表（二）：什么是负隅顽抗的调优思路？
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
请订阅文章所属专栏，新⼈⾸单¥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
aof1. 可以使用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的自动倾斜处理特性，把数据倾斜的分区拆分开，然后再进行SHJ2021-05-15
收起评论