解析:
a) Fifo schedular 默认的调度器 先进先出
b) Capacity schedular 计算能⼒调度器 选择占⽤内存⼩ 优先级⾼的
c) Fair schedular 调肚脐 公平调度器 所有job 占⽤相同资源
YarnClient模式下，执⾏Spark SQL报这个错，Exception in thread "Thread-2" java.lang.OutOfMemoryError: PermGen space，但是在Yarn Cluster模式下正常运⾏，可能是什么原因？
解析:
1）原因查询过程中调⽤的是Hive的获取元数据信息、SQL解析，并且使⽤Cglib等进⾏序列化反序列化，中间可能产⽣较多的class⽂件，导致JVM中的持久代使⽤较多
Cluster模式的持久代默认⼤⼩是64M，Client模式的持久代默认⼤⼩是32M，⽽Driver端进⾏SQL处理时，其持久代的使⽤可能会达到90M，导致OOM溢出，任务失败。
yarn-cluster模式下出现，yarn-client模式运⾏时倒是正常的，原来在$SPARK_HOME/bin/spark-class⽂件中已经设置了持久代⼤⼩：
JAVA_OPTS="-XX:MaxPermSize=256m $OUR_JAVA_OPTS"
2）解决⽅法:在Spark的conf⽬录中的spark-defaults.conf⾥，增加对Driver的JVM配置，因为Driver才负责SQL的解析和元数据获取。配置如下：
spark.driver.extraJavaOptions -XX:PermSize=128M -XX:MaxPermSize=256M
spark.driver.extraJavaOptions这个参数是什么意思，你们⽣产环境配了多少？
解析:
传递给executors的JVM选项字符串。例如GC设置或者其它⽇志设置。注意，在这个选项中设置Spark属性或者堆⼤⼩是不合法的。Spark属性需要⽤SparkConf对象或者spark-submit脚本⽤
到的spark-defaults.conf⽂件设置。堆内存可以通过spark.executor.memory设置
导致Executor产⽣FULL gc 的原因，可能导致什么问题？
解析:
答：可能导致Executor僵死问题，海量数据的shuffle和数据倾斜等都可能导致full gc。以shuffle为例，伴随着⼤量的Shuffle写操作，JVM的新⽣代不断GC，Eden Space写满了就往Survivor
Space写，同时超过⼀定⼤⼩的数据会直接写到⽼⽣代，当新⽣代写满了之后，也会把⽼的数据搞到⽼⽣代，如果⽼⽣代空间不⾜了，就触发FULL GC，还是空间不够，那就OOM错误了，
此时线程被Blocked，导致整个Executor处理数据的进程被卡住
解析:
combine分为map端和reduce端，作⽤是把同⼀个key的键值对合并在⼀起，可以⾃定义的。combine函数把⼀个map函数产⽣的<key,value>对（多个key,value）合并成⼀个新
<key2,value2>.将新的<key2,value2>作为输⼊到reduce函数中这个value2亦可称之为values，因为有多个。这个合并的⽬的是为了减少⽹络传输。partition是分割map每个节点的结果，按照
key分别映射给不同的reduce，也是可以⾃定义的。这⾥其实可以理解归类。我们对于错综复杂的数据归类。⽐如在动物园⾥有⽜⽺鸡鸭鹅，他们都是混在⼀起的，但是到了晚上他们就各⾃
⽜回⽜棚，⽺回⽺圈，鸡回鸡窝。partition的作⽤就是把这些数据归类。只不过在写程序的时候，mapreduce使⽤哈希HashPartitioner帮我们归类了。这个我们也可以⾃定义。shuffle就是
map和reduce之间的过程，包含了两端的combine和partition。Map的结果，会通过partition分发到Reducer上，Reducer做完Reduce操作后，通OutputFormat，进⾏输出shuffle阶段的主要
函数是fetchOutputs(),这个函数的功能就是将map阶段的输出，copy到reduce 节点本地
