使用spark-shell/spark-submit脚本提交作业到yarn时: 2exector :花了一分钟时间 200executor :会花费更多更多的时间在向yarn申请资源
缺点一:耗费太多的时间用于申请资源上,尤其针对那些小任务(可能任务本身20秒完成)缺点二:若因为数据倾斜导致部分task一值无法结束,那么即使那些完成任务的task的资源也不会释放缺点三:默认的Sparl sql join以及aggregation的ShufflePatition数默认是200,若数据有时多有时少,那么定死的参数肯定不合适缺点四:要处理的数据都有波峰波谷,如何保证波峰资源不吃紧波谷资源不浪费。**思考:**我们是否将所有的作业共享Spark session以及SparkContext来解决上述的问题? 答案是可以的,社区提供了:JobServer(third-party package) 、Livy(使用不是很理想)这两种服务,当然有技术积累的公司是通过自研方式解决共享Spark session的问题。
官方对SparkSQl自身解析以及优化有详细的介绍,PDF文档链接:
链接:https://pan.baidu.com/s/1533-bBabkLvvbgcf0Vp8QA 提取码:78ig使用RDD进行数据分析,不同的编程语言会导致计算的性能不一样,而Spark SQL进行数据分析时它不在乎编程语言以及实用的时SQL还是DataFrame还是Dataset ,性能都是一致的。
性能对比图: 如下Spark SQL的执行计划解析流程,几乎所有的SQL框架解析流程图都是如此