前言

一转眼已经是2022年1月9日了，跨年的节点会发生很多系统性的大事，对于普通人来讲就是跨过一个新的公元年2021->2022,对于生产系统来说，尤其是离线系统，需要发生年结，虽然期望平稳度过，但是实际情况总归没那么太平，所以每次到了这种节点，我们都是第一个flag，新的一年，好好睡觉!!

2022我就想好好睡觉

Spark1.X

Spark1.x的时代，大部分工作上解决内存计算模式下动不动就OOM那种让人抓狂的事情，需要半夜爬起来加内存

Spark2.x

Spark2.x版本，尤其是SparkSQL的引入，扩大了使用场景，自动化的执行计划经常是不对的，需要半夜爬起来手工改执行计划

Spark3.x

到了Spark3.x时代,就在当下,只能一些展望吧，小博客可以带来一些改善睡眠带有一些舒适度（吐槽+抓狂+有点小改善）的内容^^

Spark Cache中 Ugly的执行计划带来的抓狂问题(重点批判)

”Cache Table可以把数据放在内存，这段数据在未来使用的时候可以复用，减少IO“，这个是最初吸引很多同学去使用Cache表的骚操作，这个带来一系列抓狂问题：

1、乱用Cache

大部分同学就是直接使用sql，不是很懂得去控制Cache的大小，大量疯狂的大表也往内存里面怼，实际也装不下，反而导致数据溢出到磁盘上面了

2、想当然地以为快而已

我们看到那种问题SQL，下游其实没有所谓的复用，就是存粹的，读取一次Cache一次，然后下游的作业再从内存表中读取一次

3、凌晨资源情况不一样

凌晨起夜的时候，因为平台的资源会整体拉到一个高度，所以到了凌晨的时候没有那么多内存来霍霍，最后白天可以正常执行的就不能执行了

4、没关注真正慢的原因

磁盘读取一次其实也没那么慢，很多任务慢在Shuffle上，cache一次只能是添堵

5、调试带来的困难

一方面，我们作为平台同学来说，是去看人家的任务，逻辑也没那么熟悉，另一方面，Spark2.X的UI 不显示哪个表被读取了

InMemoryTableScan压根看不出啥东西，处理问题起来很痛苦

一些改进的措施

Cache别乱用

我们在很多情况下发现，大部分任务慢发生在Shuffle阶段，当然在Spark3.x中对Shuffe本身也做了很多优化，需要找准瓶颈

平台侧的解读取IO思路

实际发现我们真要做分布式Cache，是直接把数据底层Cache起来，上层并不感知，目前效果比较好的做法是走的Alluxio，我们会把表的localtion改掉，而且也是平台视角去观测读取的热点数据

重复读落地表来得更有效

实际的重复读读，其实是在夸任务的情况读取比较多，而且是发生在跨集群带来的打满带宽问题，集群内部的IO读取很少打爆的，平台的优化策略是在不同的cluster上作replication操作

Spark3.x带来优化Cache Table展示

后记

所以说2022真能好好睡觉么？