26 | Join Hints指南：不同场景下，如何选择Join策略？

精选留言(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

  

  