Spark（二）

1. Worker Node是Spark的工作节点
2. Executor是执行进程，在进程中处理Task任务
3. Task，对应的是RDD中的一个分区数据
4. Cluster Manager集群管理器
5. Driver Program用户编写的Spark驱动程序
6. 每个Driver中，都有一个sc对象

SparkContex的职责

1. 负责和CM交互，申请资源
2. 负责当前Driver的任务的调度，分配，监控以及任务的失败恢复

Cluster Manager的职责

1. 负责整个集群的资源管理

• 类比Yarn来记忆

1. ResourceManager用于资源管理
2. 每个MRJob会创建一个ApplicationMaster，负责当前Job的任务管理。

Spark的使用模式

常见的

• Local本地单机模式
• Standlone Spark集群模式，此模式下，Spark集群的资源管理由Master来负责
• On Yarn此模式下，Spark集群的资源管理是由yarn来管理。（只是更改资源管理器，Spark的任务调度依然是SparkContext）

TaskScheduler

和CM交互，为任务的执行申请资源（cpu核数+内存）

Backend模块

将Task在指定的Executor进程中启动Task

扩展

Netty高性能网络通信框架，支持序列化，支持RPC
HTTP主外：外部客户端访问本部集群用HTTP
RPC主内：集群内部通信使用RPC

Spark集群架构细化

worker和CM交互

当Spark集群启动时，每台Worker都会向CM注册，注册的同时将自身可用的资源情况汇报给CM(比如可用的最大内存，以及可用的最大核数)
CM收到这些信息之后汇总，然后将这些资源信息显示到Web控制台身上。
此外，CM和Worker会建立RPC心跳机制。

sc和CM交互

为任务的启动及执行申请资源。
CM接到资源申请之后，会在指定的worker上启动Executor进程。然后通知给sc，便于sc后续在指定的Executor上执行Task

sc和指定的Executor交互

用于完成Task启动，分配以及监控和失身恢复。包括最终的结果返回。

Task和Task之间的数据通信

比如shuffle过程。

shuffle

洗牌，即按照某种分组条件，将其有某种共同特征的数据分发到正确的分区（服务器）。这个过程就是洗牌过程。

但是shuffle过程底层是比较复杂的，需要考虑如下因素：

• 大量的数据分散到多台服务器，并且产生的中间数据量巨大。如果光靠内存来存储肯定不够的。所以势必会发生多 次的磁盘溢写。
• 产生shuffle时，就意味着，发生大量的网络数据传输。所以需要考虑如何节省带宽，比如可以采用压缩机制。
  集群的性能瓶颈：1磁盘（容量，转速），2CPU（核数），3内存（大小，一般是64GB以上），4宽带(一般是千兆，最好是万兆)最容易出现瓶颈的就是带宽
• 当shuffle时，数据通过网络通信，数据需要序列化，所有序列化性能的高低也很关键。
• Spark的Shuffle之所以产生中间的临时文件，目的之一是防止当shuffle的RDD子分区数据丢失时，导致整个计算链的重新计算。
• 补充：一个分区对应一个Task，Task分两种。1MapTask,2ResultTask
• 综上，针对这么多的细节和难题，Spark底层为我们提供了shuffle管理器，屏蔽掉这些细节。

Spark的Shuffle Manager

spark提供了两种Shuffle管理器

• Hash Based Shuffle Manager
• Sort Based Shuffle Manager
  

Hash Based Shuffle管理器

• 产生的临时文件总数=MapTask*ResultTask数
• 每个ResultTask在进行ShuffleRead时，只去获取属于自己的分区数据。
• 最大特点是Shuffle过程中，没有任何的排序操作。从而进一步提高了Shuffle过程中数据处理效率。后来Hadoop3.0也针对排序问题进行了优化。
• 补充：这种Hash Shuffle管理器的问题在于，可能会产生很多的临时文件，当临时文件数过多，造成的问题：1同时打开多个临时文件耗费内存，2这么多文件就意味着会产生大量磁盘随机I/O，造成性能下降。
• 所以目前spark底层默认的Shuffle管理器已经不是Hash Shuffle
• 产生的临时文件数不是很多的时候（<200个）时，可以使用0

Sort Based Shuffle管理器

• Shuffle管理器，优化了之前的Hash Shuffle的临时文件数过多的缺点，每个MapTask就只会生成一个临时文件。下流的ResultTask通过临时文件的索引去获取属于自己的分区数据。
• 通过这种设计，极大的减少了Shuffle临时文件数的产生。
• Sort Shuffle管理器是目前（spark1.2之后）Spark默认的Shuffle管理器
• 补充：Sort Shuffle管理器，在Shuffle过程中有排序过程，只是针对分区索引排序，不对分区数据排序。

如果面试问到SparkShuffle
先说Shuffle定义->Spark的Hash Shuffle管理器->sort Shuffle过滤器

RDD缓存机制

默认情况下，RDD只使用一次，用完即扔，这种机制并不会影响程序的正常执行。但是如果整个计算链很长，则计算代价很大。
所以Spark提供了RDD的缓存机制，即用户可以显式的将指定的RDD持久化到缓存里。避免重新计算。

对RDD进行缓存的方法

• cache 只有一种缓存级别（MEMORY_ONLY）
• persist 可以指定其他级别

案例

有topk.txt文档

hello world bye world
hello hadoop bye hadoop
hello world java web
hadoop scala java hive
hadoop hive redis hbase
hello hbase java redis

package com.yasuofenglei.persist

import org.apache.spark._
import org.apache.spark.storage.StorageLevel

object Driver {
  def main(args: Array[String]): Unit = {
    val conf = new SparkConf().setMaster("local").setAppName("persist")
    val sc=new SparkContext(conf)
    
    val data=sc.textFile("d://data/topk.txt",2)
    //一般上将数据源RDD持久化到缓存里.避免数据恢复时发生磁盘I/O
    data.cache()
    
    val r1=data.flatMap{line => line.split(" ")}
    val r2=r1.map{ word=> (word,1)}
    //建议在整个计算链中的中间位置的RDD做持久化
    //此外，如果整个计算链很长，比如30个RDD，可以每5个或10个做一下持久化。
    //持久化的目的是为了避免重新计算，从而提高执行效率
    r2.persist(StorageLevel.MEMORY_AND_DISK)
    val r3=r2.reduceByKey{_+_}
    
    r3.foreach{println}
    //当整个job执行完毕之后，一定要记得释放掉缓存
    data.unpersist()
    r2.unpersist()
  }
}

常见的缓存级别

• MEMORY_ONLY（默认的缓存级别）
• MEMORY_ONLY_SER
• MEMORY_AND_DISK
• MEMORY_AND_DIST_SER
• DIST_ONLY