sparksql如何调优
这篇文章将为大家详细讲解有关sparksql如何调优，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
1，jvm调优
这个是扯不断，理还乱。建议能加内存就加内存，没事调啥JVM，你都不了解JVM和你的任务数据。
spark调优系列之内存和GC调优
2，内存调优
缓存表
spark2.+采用：
spark.catalog.cacheTable("tableName")缓存表，spark.catalog.uncacheTable("tableName")解除缓存。
spark 1.+采用：
采用 sqlContext.cacheTable("tableName")缓存，sqlContext.uncacheTable("tableName") 解除缓存
Sparksql仅仅会缓存必要的列，并且自动调整压缩算法来减少内存和GC压力。
属性 | 默认值 | 介绍 |
spark.sql.inMemoryColumnarStorage.compressed | true | 假如设置为true，SparkSql会根据统计信息自动的为每个列选择压缩方式进行压缩。 |
spark.sql.inMemoryColumnarStorage.batchSize | 10000 | 控制列缓存的批量大小。批次大有助于改善内存使用和压缩，但是缓存数据会有OOM的风险 |
3，广播
大小表进行join时，广播小表到所有的Worker节点，来提升性能是一个不错的选择。Spark提供了两个参数可以调整，不同版本会有些许不一样，本文以Spark2.2.1为例讲解。
属性 | 默认值 | 描述 |
spark.sql.broadcastTimeout | 300 | 广播等待超时时间，单位秒 |
spark.sql.autoBroadcastJoinThreshold | 10485760 (10 MB) | 最大广播表的大小。设置为-1可以禁止该功能。当前统计信息仅支持Hive Metastore表 |
广播的变量的使用其实，有时候没啥用处。在任务超多，夸stage使用数据的时候才能凸显其真正作用。任务一趟跑完了，其实广播不广播无所谓了。。。
4，分区数据的调控
分区设置spark.sql.shuffle.partitions，默认是200.
对于有些公司来说，估计在用的时候会有Spark sql处理的数据比较少，然后资源也比较少，这时候这个shuffle分区数200就太大了，应该适当调小，来提升性能。
也有一些公司，估计在处理离线数据，数据量特别大，而且资源足，这时候shuffle分区数200，明显不够了，要适当调大。
适当，就完全靠经验。
5，文件与分区
这个总共有两个参数可以调整：
一个是在读取文件的时候一个分区接受多少数据；
另一个是文件打开的开销，通俗理解就是小文件合并的阈值。
文件打开是有开销的，开销的衡量，Spark 采用了一个比较好的方式就是打开文件的开销用，相同时间能扫描的数据的字节数来衡量。
参数介绍如下：
属性名称 | 默认值 | 介绍 |
spark.sql.files.maxPartitionBytes | 134217728 (128 MB) | 打包传入一个分区的最大字节，在读取文件的时候。 |
spark.sql.files.openCostInBytes | 4194304 (4 MB) | 用相同时间内可以扫描的数据的大小来衡量打开一个文件的开销。当将多个文件写入同一个分区的时候该参数有用。该值设置大一点有好处，有小文件的分区会比大文件分区处理速度更快（优先调度）。 |
spark.sql.files.maxPartitionBytes该值的调整要结合你想要的并发度及内存的大小来进行。
spark.sql.files.openCostInBytes说直白一些这个参数就是合并小文件的阈值，小于这个阈值的文件将会合并。
6，文件格式
建议parquet或者orc。Parquet已经可以达到很大的性能了。
关于“sparksql如何调优”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
免责声明：
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
