关于Spark调优的一些粗略总结

Spark海量数据调优实战 ===》

TB级别数据调优实战

感谢原作者：aijiudu

PS：以下是一些基础调优：只代表本萌新的个人见解

1、广播变量：driver端将数据量过大的外部变量拷贝到各个节点上，task共享节点上executor的数据，而不需要去单独拷贝一份，节省IO内存

2、持久化RDD：将公用的RDD缓存到内存，以后直接去持久化的RDD的数据，不需要从头计算
cache：内部缓存默认为一个内存
persist：有默认值，但是可以自定义内部缓存级别
持久化的内存不够时，可以配合序列化，但是使用时需要反序列化
chekpoint：检查点，设置于shuffle之后，存储在hdfs上（默认3份），切断依赖关系，比cache更加安全

3、资源分配：一般公司分配多少资源就使用多少资源
增加executor：executor少，task就少，并行度低
增加每个executor的cpu core：task个数取决于cpu core个数
增加每个executor的内存：
可以缓存更多的数据，减少IO
shuffle时，reduce端需要内存存放拉取的数据进行聚合，内存不够写入磁盘
task会创建很多对象，频繁的gc

4、序列化：spark的kyro序列化后内存比java序列化更小
外部变量过大、结合持久化RDD、shuffle

5、fastutil：
内部封装重写集合类库，提供特殊的集合对象，更小内存占用，更快存取速度
用于过大的外部变量、或者task运行时创建的过大的集合对象，shuffle

6、jvm：
减少cache分配的内存空间、默认为60%，有时cache用不到这么多内存，可以修改占比，而且实在不行可以使用persist设置为内存+磁盘
增加堆外内存，创建对象过大，默认为300m，一般调节到1G以上，避免OOM
调整executor等待时长，频繁gc会导致spark停止运行等待gc结束，时间过长，多次拉取数据失败，spark会崩溃，可以增加等待时长，默认为60s

7、算子：
filter结合coalesce，先过滤再压缩，优化数据分布不均匀的情况，使数据更加紧凑，不产生shuffle
repartition底层是coalesce，用于增加分区，产生shuffle
mappartition，一次处理一个分区的数据，在估算不会发生OOM时使用，可以减少IO
foreachpartition每个分区只会调用一次function，创建一个数据库连接，而不是每条数据

10、并行度：executor的task数量
理想情况一对一，但是task执行速度有快慢，导致先结束的等待，cpu core空闲，所以一般设置为cpu core的2-3倍
hdfs上去读数据，可以增加block
repartition
shuffle时指定partition数量
join时增加父RDD的partition个数

11、(Task原理)本地化级别：
PROCESS_LOCAL:进程本地化、代码和数据在同一个executor中
NODE_LOCAL：节点本地化、代码和数据在同一个节点中
RACK_LOCAL：机架本地化、数据和Task在不同的节点，数据需要通过网络传输
NO_PREF：数据从哪里获取都一样
ANY：数据和Task不在同一机架中，性能最差

12、数据倾斜：shuflle时，某个key的value过大，导致task执行过慢或者OOM
1、聚合源数据：一般数据源来自hive表中，拼接字符串减少key对应的数据条数，也可以分析数据的粒度，把较大key的数据通过粒度划分的更细一些
2、过滤导致倾斜的key：如果业务允许，只有个别key过大，ETL时可以直接过滤掉
3、提高reduce并行度：在发生倾斜的shuffle设置reduce task参数增加，这样每个task执行的数据就会分配的少一些
4、随机key双重聚合：将key变为不同的key进行局部聚合，然后去掉前缀再进行全局聚合
5、reduce join换为map join：将所有相同的key的value汇聚到一个task中，再join,两个RDDjoin，确保内存足够的情况下广播小的RDD
6、sample分散：个别key的value过大，可以跟其他的key进行join，把数据分散到其他的task上运行
7、随机数、扩容表进行join：一个RDD进行flatmap，每条数据映射为多条数据，并附加10以内的随机数，另一个RDD做map，每条数据也附加10以内的随机数，两个RDD进行join，只能减轻，无法解决