spark性能优化调优指导性文件

Posted 格格巫 MMQ!!

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了spark性能优化调优指导性文件相关的知识,希望对你有一定的参考价值。

1.让我们看一下前面的核心参数设置:

num-executors=10||20,executor-cores=1||2,executor-memory=10||20,driver-memory=20,spark.default.parallelism=64

假设我们的火花队列资源如下:

内存=1T,内核=400

这里有一些关于如何设置参数的技巧。首先,我们必须了解星火资源的配置和使用原则:

在默认的非动态资源分配场景中,spark是一个预应用的资源,在任务开始之前资源被独占,直到整个作业的所有任务都完成。例如,如果你在跳板上启动一个火花壳,并且从不退出或执行任务,它将总是占用所有应用的资源。(如果设置了num-executors,动态资源分配将无效)

注意上面这句话。spark的资源分配方法与mapreduce/hive有很大不同。如果不理解这个问题,会造成参数设置的其他问题。

例如,多少适合执行器核心?没有任务的并行性,整个队列资源将被独占消耗,其他同学的任务无法执行。例如,当num-executors=20个executors-cores=1个executors-memory=10时,上述任务将独占20个内核和200G内存3小时。

那么,根据这种情况下的任务,结合我们现有的资源,如何设置这五个核心参数呢?

  1. executor_cores*num_executors不能太小或太大!一般不超过总队列核心的25%,比如总队列核心400,最大不超过100,最小不低于40,除非日志量很小。

  2. executor_cores不应为1!否则工作过程中的线程数太少,一般2~4个为宜。

executor _ memory通常为6~10g,最大不超过20G,否则会导致GC成本高或资源严重浪费。

  1. spark_parallelism一般是executor_cores*num_executors的1~4倍,系统默认值为64。如果不设置,任务会分批串行执行,或者大量内核闲置,造成资源严重浪费。

5)驱动记忆有个同学之前设置了20G。实际上,驱动程序并不做任何计算和存储,只是发出任务与纱线浏览器和task进行交互。除非你是火花壳,一般1-2g就够了。

火花存储器管理器:

6)spark.shuffle.memoryFraction(默认为0.2),也称为ExecutionMemory。这个内存区域用于解决混洗、连接、排序和ag等问题。

gregations 过程中为了避免频繁IO需要的buffer。如果你的程序有大量这类操作可以适当调高。

7)spark.storage.memoryFraction(默认0.6),也叫 StorageMemory。这片内存区域是为了解决 block cache(就是你显示调用dd.cache, rdd.persist等方法), 还有就是broadcasts,以及task results的存储。可以通过参数,如果你大量调用了持久化操作或广播变量,那可以适当调高它。

8)OtherMemory,给系统预留的,因为程序本身运行也是需要内存的, (默认为0.2)。Other memory在1.6也做了调整,保证至少有300m可用。你也可以手动设置 spark.testing.reservedMemory . 然后把实际可用内存减去这个reservedMemory得到 usableMemory。 ExecutionMemory 和 StorageMemory 会共享usableMemory * 0.75的内存。0.75可以通过 新参数 spark.memory.fraction 设置。目前spark.memory.storageFraction 默认值是0.5,所以ExecutionMemory,StorageMemory默认情况是均分上面提到的可用内存的。

例如,如果需要加载大的字典文件,可以增大executor中 StorageMemory 的大小,这样就可以避免全局字典换入换出,减少GC,在这种情况下,我们相当于用内存资源来换取了执行效率。

通过执行日志分析性能瓶颈

最后的任务还需要一个小时,那这一个小时究竟耗在哪了?按我的经验和理解,一般单天的数据如果不是太大,不涉及复杂迭代计算,不应该超过半小时才对。

由于集群的 Spark History Server 还没安装调试好,没法通过 spark web UI 查看历史任务的可视化执行细节,所以我写了个小脚本分析了下前后具体的计算耗时信息,可以一目了然的看到是哪个 stage 的问题,有针对性的优化。

怎么进行Spark的性能调优

可以看到优化后的瓶颈主要在最后写 redis 的阶段,要把 60G 的数据,25亿条结果写入 redis,这对 redis 来说是个挑战,这个就只能从写入数据量和 kv 数据库选型两个角度来优化了。

怎么进行Spark的性能调优

其它优化角度

当然,优化和高性能是个很泛、很有挑战的话题,除了前面提到的代码、参数层面,还有怎样防止或减少数据倾斜等,这都需要针对具体的场景和日志来分析,此处也不展开。

2、spark 初学者的一些误区

对于初学者来说 spark 貌似无所不能而且高性能,甚至在某些博客、技术人眼里 spark 取代 mapreduce、hive、storm 分分钟的事情,是大数据批处理、机器学习、实时处理等领域的银弹。但事实确实如此吗?

从上面这个 case 可以看到,会用 spark、会调 API 和能用好 spark,用的恰到好处是两码事,这要求咱们不仅了解其原理,还要了解业务场景,将合适的技术方案、工具和合适的业务场景结合——这世上本就不存在什么银弹。。。

说道 spark 的性能,想要它快,就得充分利用好系统资源,尤其是内存和CPU:核心思想就是能用内存 cache 就别 spill 落磁盘,CPU 能并行就别串行,数据能 local 就别 shuffle。

以上是关于spark性能优化调优指导性文件的主要内容,如果未能解决你的问题,请参考以下文章

Spark性能优化指南——高级篇

万字宝典 |《 Spark性能优化全书》推荐收藏!

Spark性能优化指南——高级篇

Spark性能优化指南——高级篇

Spark性能优化指南——高级篇

Spark性能优化指南——高级篇