囧芝麻的博客

Spark2.x是钨丝计划的升级。一：Spark性能优化核心基石1， Spark是采用Master-Slaves的模式进行资源管理和任务执行的管理：a) 资源管理：Master-Workers，在一台机器上可以有多个Workers；b) 任务执行：Driver-Executors，当在一台机器上分配多个Workers的时候那么默认情况下每个Worker都会为当前运行的应用程序分配一个Executor

一：Tungsten中到底什么是Page？ 1.在Spark其实不存在Page这个类的。Page是一种数据结构(类似于Stack，List等)，从OS层面上讲，Page代表了一个内存块，在Page里面可以存放数据，在OS中会存放很多不同的Page，当要获得数据的时候首先要定位具体是哪个Page中的数据，找到该Page之后从Page中根据特定的规则(例如说数据的offset和length)取出数据

一：使用Tungsten功能 1， 如果想让您的程序使用Tungsten的功能，可以配置： Spark.Shuffle.Manager = tungsten-sort Tungsten中文blogTungsten英文blogSpark在钨丝计划下要管理两种类型的内存存储方式：堆内和堆外。为了管理他们，所以搞了一个Page。 堆外：指针直接指向数据本身。 堆内：指针首先指向Object

一：“钨丝计划”产生的本质原因1，Spark作为一个一体化多元化的（大）数据处理通用平台，性能一直是其根本性的追求之一，Spark基于内存迭代（部分基于磁盘迭代）的模型极大的满足了人们对分布式系统处理性能的渴望，但是有Spark事采用Scala+Java语言编写的所以运行在JVM平台，当然JVM是一个绝对伟大的平台，因为JVM让整个离散的主机融为一体（网络即OS），但是JVM的死穴GC反过来限制了S

一：Shuffle性能调优1，问题：Shuffle output file lost？真正的原因是GC导致的！！！如果GC尤其是Full GC产生通常会导致线程停止工作，这个时候下一个Stage的Task在默认情况下就会尝试重试来获取数据，一般重试3次每次重试的时间为5s，也就是说默认情况下15s内如果还是无法抓到数据的话，就会出现Shuffle output file lost等情况，进而会导致T

一：性能优化之数据本地性1，数据本地性对分布式系统的性能而言是一件最为重要的事情（之一），程序运行本身包含代码和数据两部分，单机版本一般情况下很少数据本地性的问题（因为数据在本地），但是对于单机版本的程序由于数据本地性有PROCESS_LOCAL和NODE_LOCAL之分，所以我们还是尽量的让数据处于PROCESS_LOCAL；Spark作为分布式系统更加注意数据本地性，在Spark中数据本地性分为

一：Spark性能调优之序列化1，之所以进行序列化，最重要的原因是内存空间有限（减少GC的压力，最大化的避免Full GC的产生，因为一旦产生Full GC则整个Task处于停止状态！！！）、减少磁盘IO的压力、减少网络IO的压力；2，什么时候会必要的产生序列化或反序列化呢？发生磁盘IO和网络通讯的时候会序列化和反序列化，更为重要的考虑序列化和反序列化的时候有另外两种情况：A)Persist（Che

一：Spark程序数据结构的优化 1，Java的对象：对象头是16个字节（例如指向对象的指针等元数据信息），如果对象只有一个int的property，则此时会占据20字节，也就是说对象的元数据占用了大部分的空间，所有在封装数据的时候尽量不要使用对象！例如说使用JSON格式来封装数据； 2，Java中的基本的数据类型会自动的封箱操作，例如int会自动变成Integer，这会额外增加对象头的空间占用

一：Task性能优化1，慢任务（数据倾斜或机器故障）的性能优化:可以考虑减少每个partition处理的数据量，同时建议开启Spark.speculation；2，尽量减少Shuffle，例如我们要减少groupByKey的操作，因为groupByKey会要求通过网络拷贝（Shuffle）所有的数据，有限考虑使用reduceByKey，因为会首先reduce locally；再例如在进行join操作

一：Memory Manager在Spark 1.6 版本中，memoryManager 的选择是由spark.memory.useLegacyMode=false决定的。如果采用1.6之前的模型，这会使用StaticMemoryManager来管理，否则使用新的UnifiedMemoryManager，我们先看看1.6之前，对于一个Executor,内存都有哪些部分构成：1，ExecutionMe