前言
一转眼已经是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真能好好睡觉么？
标签：读取,Spark3,Cache,内存,2022,抓狂 来源： https://blog.csdn.net/zhuxuemin1991/article/details/122398539
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。