解决问题的思路：重视原理

这是一篇参杂了技术和思考的文章。

几乎每天都会被源码社群的同学问各种sql的优化问题（有在群里问的，有私聊的），有的同学描述问题比较清晰，再加上需要优化的sql的业务逻辑不是特别复杂，所以，我能很快定位问题，并协助解决；但有的同学就没那么幸运，业务逻辑复杂，也没办法描述的更细致，真正的优化可能还需要去深入了解业务逻辑，所以，最终还是得靠自己去解决问题。

所以，这篇想说一下，我解决问题时，是怎么从原理层面想到该用什么方法去解决的。看看能不能给大家提供一些思路，毕竟工作中遇到难题时，还是靠自己最有普。

spark中最容易出现慢，OOM的地方，就是shuffle，而sql中出现shuffle最常见的操作就是join、聚合、窗口。

这三块，只要深刻理解了它们的运行原理，内存使用原理，解决问题时就会得心应手，至少能判断清楚，什么样的问题，能用什么样的方法来解决。

就拿群里的问题举个例子吧，

问题是关联时，出现了OOM，再加上下面描述的数据量，我这边猜测大概率走的是SortMergeJoin，真正用的啥还需要这个同学去看执行计划。

最后，我判断引起OOM的最大原因是数据倾斜，应该先处理数据倾斜。

我说说我为啥会这样判断（当然了，也有可能是我判断不对，但是没办法现场调试，真实的原因，无从得知）：

为啥数据倾斜会导致OOM?

得理解SortMergeJoin 关联时的特点：

读右侧的表的数据时，读到一行，会先放在一个叫bufferedMatches的结构里，bufferedMatches是啥呢？

bufferedMatches是一个ExternalAppendOnlyUnsafeRowArray 这样的结构，类似array，但这个array有溢写的功能。

也就是说，当右侧表的关联键有重复时，这些重复的数据都会先放在ExternalAppendOnlyUnsafeRowArray这样一个结构里，然后，左侧表再和这个ExternalAppendOnlyUnsafeRowArray来关联，代码类似下图：

说类似，主要是这个是拿join的逻辑，不是left join的，因为我觉得join的逻辑在截图时更清晰一些

，join,left join ,right join 的原理大差不差。

你想啊，

如果没有重复键，或者重复键比较少的情况下，这个大的array是不是放在内存里的条数就少；

如果重复键比较多，就像聊天里说的750w+，那这750w+的数据，都是要在ExternalAppendOnlyUnsafeRowArray这个结构里，这个大字段array也会被关联750w+次 。

虽然哈，这个结构有溢写磁盘的功能，但溢写着溢写着JVM就疯掉了，总有对内存使用评估不到位的情况，那可不，就OOM了嘛。

所以，应该把精力放在先处理数据倾斜。

数据倾斜处理了，即使这个array 有3000字符，那对内存的使用也是可量化，可评估的。

之前有处理过有10w+ size大的array，这里不是按字符算的，如果按字符算，可就更大了，给的内存是一个core 8个G，因为当时还有其他大字段：