Spark Sql 调优

思路:SparkSql转化为MR任务,充分利用硬件资源

利用好分布式系统的并行计算

1.提交查询任务的并行度

  • 集群的处理能力

SPARK_WORKER_INSTANCES参数、SPARK_WORKER_CORES参数决定

  • total_executor_cores集群的有效处理能力

SparkSql的查询并行度主要和集群的core数量有关,合理配置每个节点的core可以提高集群的并行度,提高查询效率。

  • Spark任务默认为200个task

task过多,会产生很多的任务启动开销,task多少,每个task处理的时间过长,容易straggle.

2.高效的数据格式

一方面是为了加快数据的读入速度,另一方面可以减少内存的消耗

  • 数据本地性

合理设置数据副本、合理设置数据缓存级别:PROCESS_LOCAL>NODE_LOCAL>ANY

  • 合适的数据类型

使用合适的数据类型可以节省有限的内存资源,能定义为tinyint,就不定义成int。tinyint占1个字节,int占4个字节。

  • sql书写优化

在写sql时尽量写出要查询的列名。

根据自己的业务需求,测试并选择合适的数据存储格式及压缩算法,将有利于SparkSql的查询效率

3.内存的使用

参数设置:

SPARK_WORKER_MEMORY 调节worker节点的内存,SPARK_WORKER_INSTANCES

spark.storage.memoryFraction   Spark应用程序所申请的内存资源可用于cache的比例。

spark.shuffle.memoryFraction Spark应用程序锁申请的内存资源可用于cache的比例

注意点:

     对于频繁使用的表或者查询才进行缓存,对于只使用一次的表才不需要缓存。

     对join操作优先缓存较小的表。

     要多注意对stage的监控,多思考如何才能使用更多的task使用PROCESS_LOCAL;

     要多注意storage的监控,思考如何才能Fractioin cached的比例更多

  • 其他

         想要获取更好的表达式查询速度,可以将spark.sql.codegen设置为true,spark.sql.codegen 默认值为false,当它设置为true时,Spark SQL会把每条查询的语句在运行时编译为java的二进制代码。这有什么作用呢?它可以提高大型查询的性能,但是如果进行小规模的查询的时候反而会变慢,就是说直接用查询反而比将它编译成为java的二进制代码快。所以在优化这个选项的时候要视情况而定。

         对于大数据集的计算结果,不要使用collect(),collect()就是将结果返回给Driver,很容易撑爆Driver的内存。一般将这种结果直接存储到分布式文件系统中了。

         对于数据倾斜,采用加入中间步骤,如聚合后cache,具体情况具体分析;

         适当地使用序列化方案以及压缩方案;

         善于利用集群监控系统,将集群的运行状况维持在一个合理、稳定的状态;

         善于解决重点矛盾,多观察stage中的task,查看最耗时的task,查找原因并改善。

4.主要的参数调优

并行度:spark.sql.shuffle.partitions,一个partitions相当于一个task。这是配置当shuffle数据去join或者聚合的时候的partitions的数量。200一般情况下在生产上是不够的,需要做相应的调整。

spark.sql.inMemoryColumnStorage.compressed 默认值为false 它的作用是自动对内存中的列式存储进行压缩

spark.sql.inMemoryColumnStorage.batchSize 默认值为1000 这个参数代表的是列式缓存时的每个批处理的大小。如果将这个值调大可能会导致内存不够的异常,所以在设置这个的参数的时候得注意你的内存大小。

spark.sql.parquet.compressed.codec 默认值为snappy 这个参数代表使用哪种压缩编码器。可选的选项包括uncompressed/snappy/gzip/lzo

uncompressed这个顾名思义就是不用压缩的意思

5.推测执行

推测执行(Speculative Execution)是指在分布式集群环境下,因为程序BUG,负载不均衡或者资源分布不均等原因,造成同一个job的多个task运行速度不一致,有的task运行速度明显慢于其他task(比如:一个job的某个task进度只有10%,而其他所有task已经运行完毕),则这些task拖慢了作业的整体执行进度,为了避免这种情况发生,Hadoop会为该task启动备份任务,让该speculative task与原始task同时处理一份数据,哪个先运行完,则将谁的结果作为最终结果。

推测执行优化机制采用了典型的以空间换时间的优化策略,它同时启动多个相同task(备份任务)处理相同的数据块,哪个完成的早,则采用哪个task的结果,这样可防止拖后腿Task任务出现,进而提高作业计算速度,但是,这样却会占用更多的资源,在集群资源紧缺的情况下,设计合理的推测执行机制可在多用少量资源情况下,减少大作业的计算时间。

检查逻辑代码中注释很明白,当成功的Task数超过总Task数的75%(可通过参数spark.speculation.quantile设置)时,再统计所有成功的Tasks的运行时间,得到一个中位数,用这个中位数乘以1.5(可通过参数spark.speculation.multiplier控制)得到运行时间门限,如果在运行的Tasks的运行时间超过这个门限,则对它启用推测。简单来说就是对那些拖慢整体进度的Tasks启用推测,以加速整个Stage的运行。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值