Spark面试题（四）

1. shuffle产生海量的小文件在磁盘上，此时会产生大量耗时的、低效的IO操作；
2. 容易导致内存不够用，由于内存需要保存海量的文件操作句柄和临时缓存信息，如果数据处理规模比较大的话，容易出现OOM；
3. 容易出现数据倾斜，导致OOM。

1. conslidate为了解决Hash Shuffle同时打开过多文件导致Writer handler内存使用过大以及产生过多文件导致大量的随机读写带来的低效磁盘IO；
2. conslidate根据CPU的个数来决定每个task shuffle map端产生多少个文件，假设原来有10个task，100个reduce，每个CPU有10个CPU，那么 使用hash shuffle会产生10100=1000个文件，conslidate产生10 10=100个文件

1. 参数用于设置每个stage的默认task数量。这个参数极为重要，如果不设置可能会直接影响你的Spark作业性能；
2. 很多人都不会设置这个参数，会使得集群非常低效，你的CPU，内存再多，如果task始终为1，那也是浪费， spark官网建议task个数为CPU的核数*executor的个数的2~3倍。

1. spark.shuffle.memoryFraction是shuffle调优中 重要参数，shuffle从上一个task拉去数据过来，要在Executor进行聚合操作， 聚合操作时使用Executor内存的比例由该参数决定，默认是20%如果聚合时数据超过了该大小，那么就会spill到磁盘，极大降低性能；
2. 如果Spark作业中的RDD持久化操作较少，shuffle操作较多时，建议降低持久化操作的内存占比，提高shuffle操作的内存占比比例， 避免shuffle过程中数据过多时内存不够用，必须溢写到磁盘上，降低了性能。此外，如果发现作业由于频繁的gc导致运行缓慢，意味着task执行用户代码的内存不够用， 那么同样建议调低这个参数的值。

1. 特点：
   1. standalone是master/slave架构，集群由Master与Worker节点组成，程序通过与Master节点交互申请资源，Worker节点启动Executor运行；
   2. standalone调度模式使用FIFO调度方式；
   3. 无依赖任何其他资源管理系统，Master负责管理集群资源。
2. 优点：
   1. 部署简单；
   2. 不依赖其他资源管理系统。
3. 缺点：
   1. 默认每个应用程序会独占所有可用节点的资源，当然可以通过spark.cores.max来决定一个应用可以申请的CPU cores个数；
   2. 可能有单点故障，需要自己配置master HA。

1. 适合长作业，不适合短作业；
2. 适合CPU繁忙型作业（计算时间长，相当于长作业），不利于IO繁忙型作业（计算时间短，相当于短作业）。

1. 计算能力保证。支持多个队列，某个作业可被提交到某一个队列中。每个队列会配置一定比例的计算资源，且所有提交到队列中的作业 共享该队列中的资源；
2. 灵活性。空闲资源会被分配给那些未达到资源使用上限的队列，当某个未达到资源的队列需要资源时，一旦出现空闲资源资源，便会分配给他们；
3. 支持优先级。队列支持作业优先级调度（默认是FIFO）；
4. 多重租赁。综合考虑多种约束防止单个作业、用户或者队列独占队列或者集群中的资源；
5. 基于资源的调度。 支持资源密集型作业，允许作业使用的资源量高于默认值，进而可容纳不同资源需求的作业。不过，当前仅支持内存资源的调度。

1. 数据压缩，大片连续区域进行数据存储并且存储区域中数据重复性高的状况下，可以使用适当的压缩算法。数组，对象序列化后都可以使用压缩，数更紧凑， 减少空间开销。常见的压缩方式有snappy，LZO，gz等
2. Hadoop生产环境常用的是snappy压缩方式（使用压缩，实际上是CPU换IO吞吐量和磁盘空间，所以如果CPU利用率不高，不忙的情况下， 可以大大提升集群处理效率）。snappy压缩比一般20%~30%之间，并且压缩和解压缩效率也非常高（参考数据如下）：
   1. GZIP的压缩率最高，但是其实CPU密集型的，对CPU的消耗比其他算法要多，压缩和解压速度也慢；
   2. LZO的压缩率居中，比GZIP要低一些，但是压缩和解压速度明显要比GZIP快很多，其中解压速度快的更多；
   3. Zippy/Snappy的压缩率最低，而压缩和解压速度要稍微比LZO要快一些。

val conf = new SparkConf()
val sc = new SparkContext(conf)
val line = sc.textFile("xxxx.txt") line.flatMap(*.split(" ")).map((* ,1)).reduceByKey(*+* ). collect().foreach(println) sc.stop()

1. mr2只有2个阶段，数据需要大量访问磁盘，数据来源相对单一 ,spark RDD ,可以无数个阶段进行迭代计算，数据来源非常丰富，数据落地介质也 非常丰富spark计算基于内存；
2. MapReduce2需要频繁操作磁盘IO，需要大家明确的是如果是SparkRDD的话，你要知道每一种数据来源对应的是什么，RDD从数据源加载数据， 将数据放到不同的partition针对这些partition中的数据进行迭代式计算计算完成之后，落地到不同的介质当中。

1. 基于内存计算，减少低效的磁盘交互；
2. 高效的调度算法，基于DAG；
3. 容错机制Lingage，主要是DAG和Lianage，即使spark不使用内存技术，也大大快于mapreduce。

1. 一个分区列表，每个分区里是RDD的部分数据（或称数据块）。
2. 一个依赖列表，存储依赖的其他RDD。
3. 一个名为compute的计算函数，用于计算RDD各分区的值。
4. 分区器（可选），用于键/值类型的RDD，比如某个RDD是按散列来分区。
5. 计算各分区时优先的位置列表（可选），比如从HDFS上的文件生成RDD时，RDD分区的位置优先选择数据所在的节点，这样可以避免数据移动带来的开销。

1. 分布式系统：HDFS，hbase
2. 分布式计算引擎：Spark，MapReduce
3. 周边工具：如zookeeper，pig，hive，oozie，sqoop，ranger，kafka等