关于spark Executor OOM的问题引发的联想

      最近被问到executor OOM如何处理的问题，一开始想可以调整spark.executor.cores的大小，因为每个executor中多个task是共享同一个heap的大小的，spark中资源的分配是以executor为单位分配的。

另外在看join和cogroup的区别的时候，发现join是在cogroup基础上封装的，但是join有可能会有笛卡尔积的情况。具体原因，这里不展开。

看源码一个比较新的发现是cache和persist的区别，cache是在persist的基础上封装的，persist根据传入的storageLevel来决定是将数据存入硬盘还是内存，cache就是把这个参数设为内存，这在一定程度上保证了读取数据的速度，当时也会造成OOM。所以如果是比较大块的数据需要做cache，又不想放在内存中的话，可以考虑persist的方法存入硬盘而不是用cache。

这就是目前想到的可能会OOM的问题。当然这都是在executor上的，如果是在driver上的，目前来看task数量过多的话，各种监控的event-loop有可能会导致OOM，在目前的spark版本上只能通过spark.driver.memory调大或者减少shuffle和减少task数量来解决。

还有就是在join之前，通过reparitionBy来使得同一个key在同一个partition上可以减少很多shuffle，这个又是一个新的文章了。

水平有限，仅供参考。如有遗漏，欢迎补充