下一篇：spark优化三部曲（二）--代码优化_dkk2014的博客-CSDN博客
最近两年一直在做公司的spark项目优化，目前略有成效。总结一下经验希望能帮到你。
spark项目优化的目标很简单，在不耗费更多资源的情况下，尽可能跑得快
（目前笔者将线上一个5个小时的项目优化到3个小时，且使用的资源更少，更稳定，近一年无事故发生）
1.多个spark项目
实际工作中，你的项目可能依赖其他项目的输出（比如业务部依赖中台部，亦或者组内其他成员的问题），此时要根据关键路径分析或木桶效应来分析，找出最值得优化的部分，这个过程和技术无关，大多是依赖个人的沟通能力以及对整个业务的熟悉度。
2.单个spark项目
比起上述情况，我们更多时候是应对单个spark项目，可能是spark core，也可能是spark sql。
但无论是spark core还是spark sql，万变不离其宗，本质都是分布式运算，面对一个比较慢的spark项目，优化思路如下。
（1）观察web ui
- job 找出运行慢的job，方便定位代码块
- stages 找出运行慢的stage，方便定位代码块，观察shuffle量，可跟踪具体log，看各个阶段运行时间
- storage 缓存的大小是否在预期范围内，有时候过大的缓存也可能导致运行慢
- environment 一般不需要看，查看参数时可以看
- executor 观察是否有任务倾斜（大多数task集中在某个executor）和数据倾斜以及GC状况是否良好
- sql 查看sql的执行过程，输入输出及其大小。看是否存在优化的空间（比如hint 指定join的方式）
（2）查看代码块
通过上述步骤，大部分情况下我们可以找到是哪块代码（或者sql）运行的慢，此时我们需要进行初步排查，看代码逻辑是否合理
通常情况下，一个业务可以通过多种代码逻辑实现，当你接手别人的代码的时候，不应该是调整参数（比如盲目增大内存），而是应该要来业务文档和技术文档（没有？自己梳理吧），结合代码和文档梳理，当前代码是否为业务逻辑的最优解。
