作者回复: 到位~
1. Shuffle Sort Merge Join,对于“大表Join大表”来说,是最稳定的实现方式,不过关于“大表Join大表”,咱们还是有一些调优手段的,这块可以关注28、29讲哈~
2. 确实,排序和构建hash table本身成了开销,在不等值的情况下,已经没有任何意义。
作者回复: 分析的很到位~
1. Shuffle sort merge join 在Shuffle Joins里面确实是最稳定的实现方式了。不过对于“大表Join大表”来说,其实咱们还是有一些优化手段的,这块可以关注下28、29讲哈~
2. 没错,就是这么回事~
作者回复: 满分💯
第一题答得尤其好,这道题的初衷就是鼓励大家发散思维,大开脑洞,去思考更多的实现方式~ 你说的实现方式,我觉得蛮有意思,算法复杂度介于NLJ和SMJ之间,也就是O(M*logN),前置开销是一次排序,这种实现其实还是能适配一些场景的~ 666~
第二题分析的很到位,强行用SMJ的时候,排序就成了“戴斗笠打雨伞”,多此一举。(其实我特别想说,脱了裤子放屁,不过不太文雅,哈哈)
作者回复: 没错,大表Join大表最稳定的方式,确实就是Shuffle
Sort Merge Join。同时如果Map阶段计算按照(partitionId,join key)排好序的话,后续Reduce阶段可以直接做SMJ的计算,相当于前置条件已经满足。
第二题说的没错,排序、构建哈希表本身成了开销、多此一举~