性能调优

一、spark那些算子操作涉及到了shuffle？
1、repartition类的操作：比如repartition、repartitionAndSortWithinPartitions、coalesce等
2、byKey类的操作：比如reduceByKey、groupByKey、sortByKey等
3、join类的操作：比如join、cogroup等

重分区: 一般会shuffle，因为需要在整个集群中，对之前所有的分区的数据进行随机，均匀的打乱，然后把数据放入下游新的指定数量的分区内
byKey类的操作：因为你要对一个key，进行聚合操作，那么肯定要保证集群中，所有节点上的，相同的key，一定是到同一个节点上进行处理
join类的操作：两个rdd进行join，就必须将相同join
key的数据，shuffle到同一个节点上，然后进行相同key的两个rdd数据的笛卡尔乘积
二、spark性能优化主要有哪些手段
避免创建重复RDD，尽可能使用同一个RDD对多次使用的RDD进行持久化操作。
使用map-side预聚合的shuffle操作，尽量避免使用shuffle类的算子，使用reducebykey
代替groupbykey，使用高性能算子广播变量，用kryo优化序列性能，优化数据结构。
三、Hadoop和Spark的shuffle过程，你怎么避免一些问题
1）从 high-level 的角度来看，两者并没有大的差别。 都是将 mapper（Spark 里是 ShuffleMapTask）的输出进行 partition，不同的 partition 送到不同的 reducer（Spark 里 reducer 可能是下一个 stage 里的 ShuffleMapTask，也可能是 ResultTask）。Reducer 以内存作缓冲区，边 shuffle 边 aggregate 数据，等到数据 aggregate 好以后进行 reduce() （Spark 里可能是后续的一系列操作）。
2）从 low-level 的角度来看，两者差别不小。 Hadoop MapReduce 是 sort-based，进入 combine() 和 reduce() 的 records 必须先 sort。这样的好处在于 combine/reduce() 可以处理大规模的数据，因为其输入数据可以通过外排得到（mapper 对每段数据先做排序，reducer 的 shuffle 对排好序的每段数据做归并）。目前的 Spark 默认选择的是 hash-based，通常使用 HashMap 来对 shuffle 来的数据进行 aggregate，不会对数据进行提前排序。如果用户需要经过排序的数据，那么需要自己调用类似 sortByKey() 的操作；如果你是Spark 1.1的用户，可以将spark.shuffle.manager设置为sort，则会对数据进行排序。在Spark 1.2中，sort将作为默认的Shuffle实现。
3）从实现角度来看，两者也有不少差别。 Hadoop MapReduce 将处理流程划分出明显的几个阶段：map(), spill, merge, shuffle, sort, reduce() 等。每个阶段各司其职，可以按照过程式的编程思想来逐一实现每个阶段的功能。在 Spark 中，没有这样功能明确的阶段，只有不同的 stage 和一系列的 transformation()，所以 spill, merge, aggregate 等操作需要蕴含在 transformation() 中。
如果我们将 map 端划分数据、持久化数据的过程称为 shuffle write，而将 reducer 读入数据、aggregate 数据的过程称为 shuffle read。那么在 Spark 中，问题就变为怎么在 job 的逻辑或者物理执行图中加入 shuffle write 和 shuffle read 的处理逻辑？以及两个处理逻辑应该怎么高效实现？
Shuffle write由于不要求数据有序，shuffle write 的任务很简单：将数据 partition 好，并持久化。之所以要持久化，一方面是要减少内存存储空间压力，另一方面也是为了 fault-tolerance。
四、6.Hadoop的TextInputFormat作用是什么，如何自定义实现
InputFormat用于描述输入数据的格式。
TextInputFormat重写了其父类的isSplitable和RecordReader方法。
采用的编码机Charsets.UTF_8
五、有哪些数据倾斜，怎么解决
Hadoop中的数据倾斜
Hadoop中直接贴近用户使用使用的时Mapreduce程序和Hive程序，虽说Hive最后也是用MR来执行（至少目前Hive内存计算并不普及），但是毕竟写的内容逻辑区别很大，一个是程序，一个是Sql，因此这里稍作区分。
Hadoop中的数据倾斜主要表现在、ruduce阶段卡在99.99%，一直99.99%不能结束。
这里如果详细的看日志或者和监控界面的话会发现：
有一个多几个reduce卡住
各种container报错OOM
读写的数据量极大，至少远远超过其它正常的reduce
伴随着数据倾斜，会出现任务被kill等各种诡异的表现。
经验：Hive的数据倾斜，一般都发生在Sql中Group和On上，而且和数据逻辑绑定比较深。
Spark中的数据倾斜
Spark中的数据倾斜也很常见，这里包括Spark Streaming和Spark Sql，表现主要有下面几种：

Executor lost，OOM，Shuffle过程出错
Driver OOM
单个Executor执行时间特别久，整体任务卡在某个阶段不能结
正常运行的任务突然失败
补充一下，在Spark streaming程序中，数据倾斜更容易出现，特别是在程序中包含一些类似sql的join、group这种操作的时候。 因为Spark Streaming程序在运行的时候，我们一般不会分配特别多的内存，因此一旦在这个过程中出现一些数据倾斜，就十分容易造成OOM

Hadoop平台的优化方法：
mapjoin方式
count distinct的操作，先转成group，再count
万能膏药：hive.groupby.skewindata=true
left semi jioin的使用
设置map端输出、中间结果压缩。（不完全是解决数据倾斜的问题，
是减少了IO读写和网络传输，能提高很多效率）
Spark平台的优化方法
mapjoin方式
设置rdd压缩
合理设置driver的内存
Spark Sql中的优化和Hive类似，可以参考Hive