Spark性能优化指南-高级篇(spark shuffle) 非常好的讲解

前言 继基础篇讲解了每个Spark开发人员都必须熟知的开发调优与资源调优之后,本文作为<Spark性能优化指南>的高级篇,将深入分析数据倾斜调优与shuffle调优,以解决更加棘手的性能问题. 数据倾斜调优 调优概述 有的时候,我们可能会遇到大数据计算中一个最棘手的问题——数据倾斜,此时Spark作业的性能会比期望差很多.数据倾斜调优,就是使用各种技术方案解决不同类型的数据倾斜问题,以保证Spark作业的性能. 数据倾斜发生时的现象 绝大多数task执行得都非常快,但个别task执行极慢.比如

开发调优 调优概述 Spark性能优化的第一步,就是要在开发Spark作业的过程中注意和应用一些性能优化的基本原则.开发调优,就是要让大家了解以下一些Spark基本开发原则,包括:RDD lineage设计.算子的合理使用.特殊操作的优化等.在开发过程中,时时刻刻都应该注意以上原则,并将这些原则根据具体的业务以及实际的应用场景,灵活地运用到自己的Spark作业中. 原则一:避免创建重复的RDD 通常来说,我们在开发一个Spark作业时,首先是基于某个数据源(比如Hive表或HDFS文件)创建一个

本文旨在解析 spark on Yarn 的内存管理,使得 spark 调优思路更加清晰 内存相关参数 spark 是基于内存的计算,spark 调优大部分是针对内存的,了解 spark 内存参数有也助于我们理解 spark 内存管理 spark.driver.memory:默认 512M spark.executor.memory:默认 512M spark.yarn.am.memory:默认 512M spark.yarn.driver.memoryOverhead:driver memor

Spark调优,性能优化 1.使用reduceByKey/aggregateByKey替代groupByKey 2.使用mapPartitions替代普通map 3.使用foreachPartitions替代foreach 4.使用filter之后进行coalesce操作 5.使用repartitionAndSortWithinPartitions替代repartition与sort类操作 6.使用broadcast使各task共享同一Executor的集合替代算子函数中各task传送一份集合

Spark版本:1.1.0 本文系以开源中国社区的译文为基础,结合官方文档翻译修订而来,转载请注明以下链接: http://www.cnblogs.com/zhangningbo/p/4117981.html http://www.oschina.net/translate/spark-tuning 目录 数据序列化 内存优化 确定内存消耗 优化数据结构 序列化RDD存储 优化内存回收 其他考虑因素 并行度 Reduce任务的内存用量 广播”大变量“ 总结 因为大多数Spark程序都具有“内存计

[场景] Spark提交作业job的时候要指定该job可以使用的CPU.内存等资源参数,生产环境中,任务资源分配不足会导致该job执行中断.失败等问题,所以对Spark的job资源参数分配调优非常重要. spark提交作业,yarn-cluster模式示例: ./bin/spark-submit\ --class com.ww.rdd.wordcount \ --master yarn \ --deploy-mode cluster \  --executor-memory 4G \ --num

[使用场景] 两个RDD进行join的时候,如果数据量都比较大,那么此时可以sample看下两个RDD中的key分布情况.如果出现数据倾斜,是因为其中某一个RDD中的少数几个key的数据量过大,而另一个RDD中的所有key都分布比较均匀,此时可以考虑采用本解决方案. [解决方案] 对有数据倾斜那个RDD,使用sample算子采样出一份样本,统计下每个key的数量,看看导致数据倾斜数据量最大的是哪几个key. 然后将这几个key对应的数据从原来的RDD中拆分出来,形成一个单独的RDD,并给每个ke

[使用场景] 对RDD使用join类操作,或者是在Spark SQL中使用join语句时,而且join操作中的一个RDD或表的数据量比较小(例如几百MB或者1~2GB),比较适用此方案. [解决方案] 小表join大表转为小表broadcast+map大表实现.具体为: 普通的join是会shuffle的,而一旦shuffle,就相当于会将相同key的数据拉取到一个shuffle read task中再进行join,此时就是reduce join,此时如果发生数据倾斜,影响处理性能,而此时恰好一

[数据倾斜及调优概述] 大数据分布式计算中一个常见的棘手问题——数据倾斜: 在进行shuffle的时候,必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理,比如按照key进行聚合或join等操作.此时如果某个key对应的数据量特别大的话,就会发生数据倾斜.比如大部分key对应10条数据,但是个别key却对应了百万条数据,那么大部分task可能就只会分配到10条数据,然后1秒钟就运行完了:但是个别task可能分配到了百万数据,要运行一两个小时.木桶原理,整个作业的运行进度是由运行

[业务场景] 在Spark的统计开发过程中,肯定会遇到类似小维表join大业务表的场景,或者需要在算子函数中使用外部变量的场景(尤其是大变量,比如100M以上的大集合),那么此时应该使用Spark的广播(Broadcast)功能来提升性能. [原理说明] 在算子函数中使用到外部变量或两表join时,默认情况下,Spark会将该变量或小维表复制多个副本,通过网络传输到task中,此时每个task都有一个变量副本.如果变量本身比较大的话(比如100M,甚至1G),那么大量的变量副本在网络中传输的性能

[Java序列化与反序列化] Java序列化是指把Java对象转换为字节序列的过程:而Java反序列化是指把字节序列恢复为Java对象的过程.序列化使用场景:1.数据的持久化,通过序列化可以把数据永久地保存到硬盘上(通常存放在文件里).2.远程通信,即在网络上传送对象的字节序列. 这篇文章写的不错https://blog.csdn.net/wangloveall/article/details/7992448 [Spark序列化与反序列化场景] 在Spark中,主要有三个地方涉及序列化与反序列化

由于Spark自己的调优guidance已经覆盖了很多很有价值的点,因此这里直接翻译一份过来.也作为一个积累. Spark 调优 (Tuning Spark) 由于大多数Spark计算任务是在内存中运行计算,任何集群中的资源限制都可能成为Spark程序的瓶颈,比如:CPU.网络.带宽.内存.通常情况下,如果内存能容纳所处理数据,主要的瓶颈则仅是网络带宽.但有些时候您也需要做一些调优,比如利用RDD序列化存储来降低内存消耗.本手册将会涵盖以下两个大点:数据序列化(对优化网络传输和降低内存开销有显著

[生产实践经验] 生产实践中的切身体会是:影响Spark性能的大BOSS就是shuffle,抓住并解决shuffle这个主要原因,事半功倍. [Shuffle原理学习笔记] 1.未经优化的HashShuffleManager 注:这是spark1.2版本之前,最早使用的shuffle方法,这种shuffle方法不要使用,只是用来对比改进后的shuffle方法.  如上图,上游每个task 都输出下游task个数的结果文件,下游每个task去上游task输出的结果文件中获取对应自己的. 问题: 生

聚合操作使用reduceByKey/aggregateByKey替代groupByKey 参见我的这篇博客说明 [Spark调优]:如果实在要shuffle,使用map侧预聚合的算子 内存充足前提下使用mapPartitions替代普通map mapPartitions类的算子,一次函数调用会处理一个partition所有的数据,而不是一次函数调用处理一条,性能相对来说会高一些.但是有的时候,使用mapPartitions会出现OOM(内存溢出)问题.因为单次函数调用就要处理掉一个partiti

Spark 调优 返回原文英文原文:Tuning Spark Because of the in-memory nature of most Spark computations, Spark programs can be bottlenecked by any resource in the cluster: CPU, network bandwidth, or memory. Most often, if the data fits in memory, the bottleneck is

版权声明:本文为博主原创文章,转载请注明出处. Spark调优秘诀 1.诊断内存的消耗 在Spark应用程序中,内存都消耗在哪了? 1.每个Java对象都有一个包含该对象元数据的对象头,其大小是16个Byte.由于在写代码时候,可能会出现这种情况:对象头比对象本身占有的字节数更多,比如对象只有一个int的域.一般这样设计是不合理的,造成对象的“浪费”,在实际开发中应避免这种情况. 2.Java的String对象,会比它内部的原始数据要多出40个字节.因为它内部使用char数组来保存内部的字符序列

16年的时候花了一些时间整理了一些关于jvm的介绍文章,到现在回顾起来还是一些还没有补充全面,其中就包括如何利用工具来监控调优前后的性能变化.工具做为图形化界面来展示更能直观的发现问题,另一方面一些耗费性能的分析(dump文件分析)一般也不会在生产直接分析,往往dump下来的文件达1G左右,人工分析效率较低,因此利用工具来分析jvm相关问题,长长可以到达事半功倍的效果来. jvm监控分析工具一般分为两类,一种是jdk自带的工具,一种是第三方的分析工具.jdk自带工具一般在jdk bin目录下面,

总结一下spark的调优方案--性能调优: 一.调节并行度 1.性能上的调优主要注重一下几点: Excutor的数量 每个Excutor所分配的CPU的数量 每个Excutor所能分配的内存量 Driver端分配的内存数量 2.如何分配资源 在生产环境中,提交spark作业的时候,使用的是spark-submit shell脚本,里面调整对应的参数. ./bin/spark-submit \ --class com.spark.sparkTest.WordCount \ --num-execut

spark调优是须要依据业务须要调整的,并非说某个设置是一成不变的,就比方机器学习一样,是在不断的调试中找出当前业务下更优的调优配置.以下零碎的总结了一些我的调优笔记. spark 存储的时候存在严重的分配不均的现象,有几台机器在过渡使用, 有几台机器却非常少被使用.有几台机器缓存了几十个上百个RDD blocks  有的机器一个RDD blocks 都没有.这样存储有RDD blocks 的能够进行运算.运算的tasks 最多为该机器core数. spark.storage.memoryFra

进行GC性能调优时, 须要明白了解, 当前的GC行为对系统和用户有多大的影响. 有多种监控GC的工具和方法, 本章将逐一介绍经常使用的工具. 您应该已经阅读了前面的章节: 垃圾收集简单介绍 - GC參考手冊 Java中的垃圾收集 - GC參考手冊 GC 算法(基础篇) - GC參考手冊 GC 算法(实现篇) - GC參考手冊 GC 调优(基础篇) - GC參考手冊 JVM 在程序执行的过程中, 提供了GC行为的原生数据. 那么, 我们就能够利用这些原生数据来生成各种报告.原生数据(raw dat