Spark性能调优实战
吴磊
FreeWheel机器学习团队负责人
新⼈⾸单¥59.9
1423 人已学习
课程目录
已更新 27 讲 / 共 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 性能调优篇 (7讲)
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策略?
Spark性能调优实战
15
15
1.0x
00:00/00:00
登录|注册

26 | Join Hints指南:不同场景下,如何选择Join策略?

吴磊 2021-05-12
你好,我是吴磊。
在数据分析领域,数据关联可以说是最常见的计算场景了。因为使用的频率很高,所以 Spark 为我们准备了非常丰富的关联形式,包括 Inner Join、Left Join、Right Join、Anti Join、Semi Join 等等。
搞懂不同关联形式的区别与作用,可以让我们快速地实现业务逻辑。不过,这只是基础,要想提高数据关联场景下 Spark 应用的执行性能,更为关键的是我们要能够深入理解 Join 的实现原理。
所以今天这一讲,我们先来说说,单机环境中 Join 都有哪几种实现方式,它们的优劣势分别是什么。理解了这些实现方式,我们再结合它们一起探讨,分布式计算环境中 Spark 都支持哪些 Join 策略。对于不同的 Join 策略,Spark 是怎么做取舍的。

Join 的实现方式详解

到目前为止,数据关联总共有 3 种 Join 实现方式。按照出现的时间顺序,分别是嵌套循环连接(NLJ,Nested Loop Join )、排序归并连接(SMJ,Shuffle Sort Merge Join)和哈希连接(HJ,Hash Join)。接下来,我们就借助一个数据关联的场景,来分别说一说这 3 种 Join 实现方式的工作原理。
假设,现在有事实表 orders 和维度表 users。其中,users 表存储用户属性信息,orders 记录着用户的每一笔交易。两张表的 Schema 如下:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Spark性能调优实战》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥59.9
立即订阅
登录 后留言

精选留言(5)

  • kingcall
    回答:
    问题1:个人觉得SMJ 就是用在两张大表上的关联才有意思啊,也就是事实表 Join 事实表,但是这里要求是等值关联,如果是不等值关联就只能CPJ
    问题2:可以分情况讨论一下,但是肯定是可以实现的
        1. != 这样的关联,Sort Merge Join 和 Hash Join 都是不划算的,但是是可以实现的。
        2. 大于等于、小于等于 、大于 、小于 Sort Merge Join 还是有可取之处的,但是还是考虑到了排序的成本,但是这个地方有一个问题那就是我们的shuffle输出的数据的本身就是有序的啊,所以我觉得 Sort Merge Join 是可以的,Hash Join 就算了,其实可以看出来hash 只适合等值,这是取决于hash 本身的特点的。

    作者回复: 到位~

    1. Shuffle Sort Merge Join,对于“大表Join大表”来说,是最稳定的实现方式,不过关于“大表Join大表”,咱们还是有一些调优手段的,这块可以关注28、29讲哈~

    2. 确实,排序和构建hash table本身成了开销,在不等值的情况下,已经没有任何意义。

    2021-05-12
    2
  • 斯盖丸
    老师一般SQL的教程里都是join的优化方法之一是小表join大表,但我看Spark里你都是大表join小表,在大数据里谁join谁要紧吗,感觉好像无所谓?
    2021-05-13
  • Fendora范东_
    问题回答
    1.等值条件时,内外表任意大小都可以用SMJ,只不过当内表比较小或者内表平均分片小于阈值时,有性能更好的BHJ与SHJ可以选择。特别是大表join大表时,不满足使用其他两个的条件,SMJ就是最优解。

    大表join大表,我理解目前最好的方式就是Shuffle sort merge join

    2.不等值条件可以强行用SMJ,那他的时间复杂度又变成了O(M*N),两表前期排序也没有太大意义。

    作者回复: 分析的很到位~

    1. Shuffle sort merge join 在Shuffle Joins里面确实是最稳定的实现方式了。不过对于“大表Join大表”来说,其实咱们还是有一些优化手段的,这块可以关注下28、29讲哈~

    2. 没错,就是这么回事~

    2021-05-12
  • zxk
    1. 可以对 Sort Merge Join 做一个变种,例如一个表排序,一个表不排序,不排序的表作为驱动表,排序的表可以通过二分查找等方式快速定位驱动表的 Join Key。
    2. 也可以强行实现,但 Sort Merge Join 方面的排序就会变得毫无意义,同时 Sort Merge Join、Hash Join 的时间复杂度也并未降低,反而带来了额外的排序开销与内存开销。

    作者回复: 满分💯

    第一题答得尤其好,这道题的初衷就是鼓励大家发散思维,大开脑洞,去思考更多的实现方式~ 你说的实现方式,我觉得蛮有意思,算法复杂度介于NLJ和SMJ之间,也就是O(M*logN),前置开销是一次排序,这种实现其实还是能适配一些场景的~ 666~

    第二题分析的很到位,强行用SMJ的时候,排序就成了“戴斗笠打雨伞”,多此一举。(其实我特别想说,脱了裤子放屁,不过不太文雅,哈哈)

    2021-05-12
  • Bennan
    1.两张事实表最好的等值连接方式就是smj,可以让map端输出的时候先进行排序,reduce拉取数据的时候就可以对两个表的多个数据流进行join操作
    2可以强行使用smj和hj,但是这样并没有意义,因为最后join还是m*n的复杂度(当时如果是大于或者小于的连接方式,在进行连接的可以优化一下),而smj会带来额外的排序开销,hj要求内存能够放得下并且需要构建hash表

    作者回复: 没错,大表Join大表最稳定的方式,确实就是Shuffle
     Sort Merge Join。同时如果Map阶段计算按照(partitionId,join key)排好序的话,后续Reduce阶段可以直接做SMJ的计算,相当于前置条件已经满足。

    第二题说的没错,排序、构建哈希表本身成了开销、多此一举~

    2021-05-12
收起评论
5
返回
顶部