大数据常见面试题(二)

面试题

1. Zookeeper是如何保证事务的顺序一致性的？
   zookeeper 采用了递增的事务Id来标识，所有的proposal都在被提出的时候加上了zxid，zxid实际上是一个64位的数字，高32位是epoch用来标识 leader是否发生改变，如果有新的 leader 产生出来，epoch 会自增，低32 位用来递增计数。当新产生 proposal 的时候，会依据数据库的两阶段过程，首先会向其他的 server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行
2. Zookeeper对节点的watch监听通知是永久的吗？
   不是。官方声明：一个 Watch 事件是一个一次性的触发器，当被设置了 Watch 的数据发生了改变的时候，则服务器将这个改变发送给设置了 Watch 的客户端，以便通知它们。
   为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，这太消耗性能了。
   一般是客户端执行 getData(“/节点 A”,true)，如果节点 A 发生了变更或删除，客户端会得到它的 watch 事件，但是在之后节点 A 又发生了变更，而客户端又没有设置 watch 事件，就不再给客户端发送。
   在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。
3. 海量日志数据提取出某日访问百度次数最多的IP，怎么做?
   首先是这一天，并且是访问百度的日志中的IP取出来，逐个写入到一个大文件中。注意到IP是32位，最多有2^32个IP。同样可以采用映射的方法，比如模1000，把整个大文件映射为1000个小文件，再找出每个小文件，再找出每个小文件中出现的频率最大的IP（可以采用hash map进行频率统计，然后再找出频率最大的几个）及相应的频率。然后再在这1000个最大的IP中，找出那个频率最大的IP，即为所求。
   
4. Hadoop的机架感知策略？？
   1)所谓的机架指的并不是物理机架而是逻辑机架
   2)在逻辑机架中，将主机名或者IP和机架进行了映射，也因此可以将一个或者多个节点映射到同一个逻辑机架上
   3)在实际过程中，往往会将一个或者几个物理机架上的节点都映射到一个逻辑机架上
5. Hive表关联查询，如何解决数据倾斜的问题？
   1）倾斜原因：
   map 输出数据按 key Hash 的分配到 reduce 中，由于 key 分布不均匀、业务数据本身的特点、建表时考虑不周等原因造成的 reduce 上的数据量差异过大。
   （1）key 分布不均匀;
   （2）业务数据本身的特性;
   （3）建表时考虑不周;
   （4）某些 SQL 语句本身就有数据倾斜;
   如何避免：对于 key 为空产生的数据倾斜，可以对其赋予一个随机值。
   2）解决方案
   （1）参数调节：
   hive.map.aggr = true
   hive.groupby.skewindata=true
   有数据倾斜的时候进行负载均衡，当选项设定位 true,生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的Reduce中，从而达到负载均衡的目的；第二个MR Job再根据预处理的数据结果按照Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个Reduce 中），最后完成最终的聚合操作。
   （2）SQL 语句调节：
   ① 选用 join key 分布最均匀的表作为驱动表。做好列裁剪和 filter 操作，以达到两表做 join的时候，数据量相对变小的效果。
   ② 大小表 Join：
   使用 map join 让小的维度表（1000 条以下的记录条数）先进内存（小表在左，大表在右）。在 map 端完成 reduce.
   ③ 大表 Join 大表：
   把空值的 key 变成一个字符串加上随机数，把倾斜的数据分到不同的reduce 上，由于 null值关联不上，处理后并不影响最终结果。
   ④ count distinct 大量相同特殊值:
   count distinct 时，将值为空的情况单独处理，如果是计算 count distinct，可以不用处理，直接过滤，在最后结果中加 1。如果还有其他计算，需要进行 group by，可以先将值为空的记录单独处理，再和其他计算结果进行 union
6. Hive自定义UDF函数的流程？
   1）写一个类继承（org.apache.hadoop.hive.ql.）UDF 类；
   2）覆盖方法 evaluate()；
   3）打 JAR 包；
   4）通过 hive 命令将 JAR 添加到 Hive 的类路径：hive> add jar /home/ubuntu/ToDate.jar;
   5）注册函数： hive> create temporary function xxx as ‘XXX’;
   6）使用函数；
7. Map-reduce程序运行的时候会有什么比较常见的问题？
   比如说作业中大部分都完成了，但是总有几个 reduce 一直在运行
   这是因为这几个 reduce 中的处理的数据要远远大于其他的 reduce，可能是因为对键值对任务划分的不均匀造成的数据倾斜
   解决的方法可以在分区的时候重新定义分区规则对于 value 数据很多的 key 可以进行拆分、均匀打散等处理，或者是在 map 端的 combiner 中进行数据预处理的操作
8. Hadoop和spark的都是并行计算，那么他们有什么相同和区别？
   两者都是用 mr 模型来进行并行计算，hadoop 的一个作业称为 job，job 里面分为 map 、task 和 reduce task，每个 task 都是在自己的进程中运行的，当 task 结束时，进程也会结束。
   spark 用户提交的任务成为 application，一个 application 对应一个 sparkcontext，app 中存在多个 job，每触发一次 action 操作就会产生一个 job。
   这些 job 可以并行或串行执行，每个 job 中有多个 stage，stage 是 shuffle 过程中DAGSchaduler 通过 RDD 之间的依赖关系划分 job 而来的，每个 stage 里面有多个 task，组成 taskset 有 TaskSchaduler 分发到各个 executor 中执行，executor 的生命周期是和app 一样的，即使没有 job 运行也是存在的，所以 task 可以快速启动读取内存进行计算。
   hadoop 的 job 只有 map 和 reduce 操作，表达能力比较欠缺而且在 mr 过程中会重复的读写 hdfs，造成大量的 io 操作，多个 job 需要自己管理关系。spark 的迭代计算都是在内存中进行的，API 中提供了大量的 RDD 操作如 join，groupby等，而且通过 DAG 图可以实现良好的容错。
9. Hive 如何优化？
   1）join 优化，尽量将小表放在 join 的左边，如果一个表很小可以采用 mapjoin。
   2）排序优化，order by 一个 reduce 效率低，distirbute by +sort by 也可以实现全局排序。
   3）使用分区，查询时可减少数据的检索，从而节省时间。
10. Flume 的事务机制？
    Flume 的事务机制（类似数据库的事务机制）：
    Flume 使用两个独立的事务分别负责从 Soucrce 到 Channel（put），以及从 Channel到 Sink 的事件传递（take）。
    比如 spooling directory source 为文件的每一行创建一个事件，一旦事务中所有的事件全部传递到 Channel 且提交成功，那么 Soucrce 就将该文件标记为完成。
    同理，事务以类似的方式处理从 Channel 到 Sink 的传递过程，如果因为某种原因使得事件无法记录，那么事务将会回滚。且所有的事件都会保持到 Channel 中，等待重新传递。
11. HBase 宕机如何处理？
    宕机分为 HMaster 宕机 和 HRegisoner 宕机 .
    如果是 HRegisoner 宕机，HMaster 会将其所管理的 region 重新分布到其他活动的RegionServer 上，由于数据和日志都持久在 HDFS 中，该操作不会导致数据丢失,所以数据的一致性和安全性是有保障的。
    如果是 HMaster 宕机， HMaster 没有单点问题， HBase 中可以启动多个 HMaster，通过 Zookeeper 的 Master Election 机制保证总有一个 Master 运行。即 ZooKeeper会保证总会有一个 HMaster 在对外提供服务
12. Spark master使用zookeeper进行HA的，有哪些元数据保存在Zookeeper？
    spark 通过这个参数 spark.deploy.zookeeper.dir 指定 master 元数据在 zookeeper中保存的位置，包括 Worker，Driver 和 Application 以及 Executors。standby 节点要从 zk 中，获得元数据信息，恢复集群运行状态，才能对外继续提供服务，作业提交资源申请等，在恢复前是不能接受请求的。另外，Master 切换需要注意 2 点：
    1）在 Master 切换的过程中，所有的已经在运行的程序皆正常运行！因为 Spark Application 在运行前就已经通过 Cluster Manager 获得了计算资源，所以在运行时 Job本身的调度和处理和 Master 是没有任何关系的！
    2） 在 Master 的切换过程中唯一的影响是不能提交新的 Job：一方面不能够提交新的应用程序给集群，因为只有 Active Master 才能接受新的程序的提交请求；另外一方面，已经运行的程序中也不能够因为 Action 操作触发新的 Job 的提交请求；
13. Spark on Mesos中，什么是的粗粒度分配，什么是细粒度分配，各自的优点和缺点是什么？
    1）粗粒度：启动时就分配好资源， 程序启动，后续具体使用就使用分配好的资源，不需要再分配资源；好处：作业特别多时，资源复用率高，适合粗粒度；缺点：容易资源浪费，假如一个 job 有 1000 个 task，完成了 999 个，还有一个没完成，那么使用粗粒度，999 个资源就会闲置在那里，资源浪费。
    2）细粒度分配：用资源的时候分配，用完了就立即回收资源，启动会麻烦一点，启动一次分配一次，会比较麻烦。
14. driver的功能是什么？
    1）一个 Spark 作业运行时包括一个 Driver 进程，也是作业的主进程，具有 main 函数，并且有 SparkContext 的实例，是程序的人口点；
    2）功能：负责向集群申请资源，向master 注册信息，负责了作业的调度，负责作业的解析、生成 Stage 并调度 Task 到Executor 上。包括DAGScheduler，TaskScheduler。
15. Spark的有几种部署模式，每种模式特点？
    1）本地模式
    Spark 不一定非要跑在 hadoop 集群，可以在本地，起多个线程的方式来指定。将 Spark应用以多线程的方式直接运行在本地，一般都是为了方便调试，本地模式分三类
    · local：只启动一个 executor
    · local[k]:启动 k 个 executor
    · local[*]：启动跟 cpu 数目相同的 executor
    2)standalone 模式
    分布式部署集群， 自带完整的服务，资源管理和任务监控是 Spark 自己监控，这个模式也是其他模式的基础，
    3)Spark on yarn 模式
    分布式部署集群，资源和任务监控交给 yarn 管理，但是目前仅支持粗粒度资源分配方式，包含 cluster 和 client 运行模式，cluster 适合生产，driver 运行在集群子节点，具有容错功能，client 适合调试，dirver 运行在客户端
    4）Spark On Mesos 模式。官方推荐这种模式（当然，原因之一是血缘关系）。正是由于Spark 开发之初就考虑到支持 Mesos，因此，目前而言，Spark 运行在 Mesos 上会比运行在 YARN 上更加灵活，更加自然。用户可选择两种调度模式之一运行自己的应用程序：

1. 粗粒度模式（Coarse-grained Mode）：每个应用程序的运行环境由一个 Dirver 和若干个 Executor 组成，其中，每个 Executor 占用若干资源，内部可运行多个 Task（对应多少个“slot”）。应用程序的各个任务正式运行之前，需要将运行环境中的资源全部申请好，且运行过程中要一直占用这些资源，即使不用，最后程序运行结束后，回收这些资源。
2. 细粒度模式（Fine-grained Mode）：鉴于粗粒度模式会造成大量资源浪费，Spark On Mesos 还提供了另外一种调度模式：细粒度模式，这种模式类似于现在的云计算，思想是按需分配。

16. Spark技术栈有哪些组件，每个组件都有什么功能，适合什么应用场景？
    1）Spark core：是其它组件的基础，spark 的内核，主要包含：有向循环图、RDD、Lingage、Cache、broadcast 等，并封装了底层通讯框架，是 Spark 的基础。
    2）SparkStreaming 是一个对实时数据流进行高通量、容错处理的流式处理系统，可以对多种数据源（如 Kdfka、Flume、Twitter、Zero 和 TCP 套接字）进行类似 Map、Reduce 和 Join 等复杂操作，将流式计算分解成一系列短小的批处理作业。
    3）Spark sql：Shark 是 SparkSQL 的前身，Spark SQL 的一个重要特点是其能够统一处理关系表和 RDD，使得开发人员可以轻松地使用 SQL 命令进行外部查询，同时进行更复杂的数据分析
    4）BlinkDB ：是一个用于在海量数据上运行交互式 SQL 查询的大规模并行查询引擎，它允许用户通过权衡数据精度来提升查询响应时间，其数据的精度被控制在允许的误差范围内。
    5）MLBase 是 Spark 生态圈的一部分专注于机器学习，让机器学习的门槛更低，让一些可能并不了解机器学习的用户也能方便地使用 MLbase。MLBase 分为四部分：MLlib、MLI、ML Optimizer 和 MLRuntime。
    6）GraphX 是 Spark 中用于图和图并行计算
17. Spark中Work的主要工作是什么？
    主要功能：管理当前节点内存，CPU 的使用状况，接收 master 分配过来的资源指令，通过 ExecutorRunner 启动程序分配任务，worker 就类似于包工头，管理分配新进程，做计算的服务，相当于 process 服务。
    需要注意的是：1）worker 会不会汇报当前信息给 master，worker 心跳给 master 主要只有 workid，它不会发送资源信息以心跳的方式给 mater，master 分配的时候就知道 work，只有出现故障的时候才会发送资源。
    2）worker 不会运行代码，具体运行的是 Executor 是可以运行具体 appliaction 写的业务逻辑代码，操作代码的节点，它不会运行程序的代码的。
18. Spark为什么比mapreduce快？
    1）基于内存计算，减少低效的磁盘交互；
    2）高效的调度算法，基于 DAG；
    3）容错机制 Linage，精华部分就是 DAG 和 Lingae
19. 简单说一下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。
20. Mapreduce和Spark的都是并行计算，那么他们有什么相同和区别？
    两者都是用 mr 模型来进行并行计算:
    1)hadoop 的一个作业称为 job，job 里面分为 map task 和 reduce task，每个 task 都是在自己的进程中运行的，当 task 结束时，进程也会结束。
    2)spark 用户提交的任务成为 application，一个 application 对应一个 sparkcontext，app 中存在多个 job，每触发一次 action 操作就会产生一个 job。这些 job 可以并行或串行执行，每个 job 中有多个 stage，stage 是 shuffle 过程中 DAGSchaduler 通过 RDD 之间的依赖关系划分 job 而来的，每个 stage 里面有多个 task，组成 taskset 有TaskSchaduler 分发到各个 executor 中执行，executor 的生命周期是和 app 一样的，即使没有 job 运行也是存在的，所以 task 可以快速启动读取内存进行计算。
    3)hadoop 的 job 只有 map 和 reduce 操作，表达能力比较欠缺而且在 mr 过程中会重复的读写 hdfs，造成大量的 io 操作，多个 job 需要自己管理关系。
    spark 的迭代计算都是在内存中进行的，API 中提供了大量的 RDD 操作如 join，groupby等，而且通过 DAG 图可以实现良好的容错
21. Spark的优化怎么做？
    Spark 调优比较复杂，但是大体可以分为三个方面来进行
    1）平台层面的调优：防止不必要的 jar 包分发，提高数据的本地性，选择高效的存储格式如 parquet
    2）应用程序层面的调优：过滤操作符的优化降低过多小任务，降低单条记录的资源开销，处理数据倾斜，复用 RDD 进行缓存，作业并行化执行等等
    3）JVM 层面的调优：设置合适的资源量，设置合理的 JVM，启用高效的序列化方法如 kyro，增大 off head 内存等等
22. RDD的弹性表现在哪几点？
    1）自动的进行内存和磁盘的存储切换；
    2）基于 Lingage 的高效容错；
    3）task 如果失败会自动进行特定次数的重试；
    4）stage 如果失败会自动进行特定次数的重试，而且只会计算失败的分片；
    5）checkpoint 和 persist，数据计算之后持久化缓存
    6）数据调度弹性，DAG TASK 调度和资源无关
    7）数据分片的高度弹性，a.分片很多碎片可以合并成大的，b.par
23. 常规的容错方式有哪几种类型？
    1）数据检查点,会发生拷贝，浪费资源
    2）记录数据的更新，每次更新都会记录下来，比较复杂且比较消耗性能
24. RDD有哪些缺陷？
    1）不支持细粒度的写和更新操作（如网络爬虫），spark 写数据是粗粒度的所谓粗粒度，就是批量写入数据，为了提高效率。但是读数据是细粒度的也就是说可以一条条的读
    2）不支持增量迭代计算，Flink 支持
25. Spark有哪些聚合类的算子,我们应该尽量避免什么类型的算子？
    在我们的开发过程中，能避免则尽可能避免使用 reduceByKey、join、distinct、repartition 等会进行 shuffle 的算子，尽量使用 map 类的非 shuffle 算子。这样的话，没有 shuffle 操作或者仅有较少 shuffle 操作的 Spark 作业，可以大大减少性能开销。
26. 你如何从Kafka中获取数据？
    1)基于 Receiver 的方式
    这种方式使用 Receiver 来获取数据。Receiver 是使用 Kafka 的高层次 Consumer API 来实现的。receiver 从 Kafka 中获取的数据都是存储在 Spark Executor 的内存中的，然后Spark Streaming 启动的 job 会去处理那些数据。
    2)基于 Direct 的方式
    这种新的不基于 Receiver 的直接方式，是在 Spark 1.3 中引入的，从而能够确保更加健壮的机制。替代掉使用 Receiver 来接收数据后，这种方式会周期性地查询 Kafka，来获得每个 topic+partition 的最新的 offset，从而定义每个 batch 的 offset 的范围。当处理数据的 job 启动时，就会使用 Kafka 的简单 consumer api 来获取 Kafka 指定 offset 范围的数据。
27. 对于Spark中的数据倾斜问题你有什么好的方案？
    1）前提是定位数据倾斜，是 OOM 了，还是任务执行缓慢，看日志，看 WebUI
    2）解决方法，有多个方面
    ☆避免不必要的 shuffle，如使用广播小表的方式，将 reduce-side-join 提升为 mapside-join
    ☆分拆发生数据倾斜的记录，分成几个部分进行，然后合并 join 后的结果
    ☆改变并行度，可能并行度太少了，导致个别 task 数据压力大
    ☆两阶段聚合，先局部聚合，再全局聚合
    ☆自定义 paritioner，分散 key 的分布，使其更加均匀。
28. Map与flatMap的区别？
    map：对 RDD 每个元素转换，文件中的每一行数据返回一个数组对象
    flatMap：对 RDD 每个元素转换，然后再扁平化
    将所有的对象合并为一个对象，文件中的所有行数据仅返回一个数组对象，会抛弃值为 null 的值。
29. Spark为什么要持久化，一般什么场景下要进行persist操作？
    为什么要进行持久化？
    spark 所有复杂一点的算法都会有 persist 身影,spark 默认数据放在内存，spark 很多内容都是放在内存的，非常适合高速迭代，1000 个步骤只有第一个输入数据，中间不产生临时数据，但分布式系统风险很高，所以容易出错，就要容错，rdd 出错或者分片可以根据血统算出来，如果没有对父 rdd 进行 persist 或者cache 的化，就需要重头做。
    以下场景会使用 persist
    1）某个步骤计算非常耗时，需要进行 persist 持久化
    2）计算链条非常长，重新恢复要算很多步骤，很好使，persist
    3）checkpoint 所在的 rdd 要持久化 persist，lazy 级别，框架发现有 checnkpoint，checkpoint 时单独触发一个 job，需要重算一遍，
    checkpoint 前要持久化，写个 rdd.cache 或者 rdd.persist，将结果保存起来，再写 checkpoint 操作，这样执行起来会非常快，不需要重新计算 rdd 链条了。checkpoint 之前一定会进行persist。
    4）shuffle 之后为什么要 persist，shuffle 要进性网络传输，风险很大，数据丢失重来，恢复代价很大
    5）shuffle 之前进行 persist，框架默认将数据持久化到磁盘，这个是框架自动做的。
30. 介绍一下join操作优化经验？
    join 其实常见的就分为两类： map-side join 和 reduce-side join。当大表和小表join 时，用 map-side join 能显著提高效率。将多份数据进行关联是数据处理过程中非常普遍的用法，不过在分布式计算系统中，这个问题往往会变的非常麻烦，因为框架提供的join 操作一般会将所有数据根据 key 发送到所有的 reduce 分区中去，也就是 shuffle的过程。造成大量的网络以及磁盘 IO 消耗，运行效率极其低下，这个过程一般被称为reduce-side-join。如果其中有张表较小的话，我们则可以自己实现在 map 端实现数据关联，跳过大量数据进行 shuffle 的过程，运行时间得到大量缩短，根据不同数据可能会有几倍到数十倍的性能提升。
    备注：这个题目面试中非常非常大概率见到，务必搜索相关资料掌握，这里抛砖引玉。
31. Spark hashParitioner的弊端是什么？
    HashPartitioner 分区的原理很简单，对于给定的 key，计算其 hashCode，并除于分区的个数取余，如果余数小于 0，则用余数+分区的个数，最后返回的值就是这个 key 所属的分区 ID；弊端是数据不均匀，容易导致数据倾斜，极端情况下某几个分区会拥有 rdd的所有数据。
32. 不需要排序的hash shuffle是否一定比需要排序的sort shuffle速度快？
    不一定！！当数据规模小，Hash shuffle 快于 Sorted Shuffle 数据规模大的时候；当数据量大，sorted Shuffle 会比 Hash shuffle 快很多，因为数量大的有很多小文件，不均匀，甚至出现数据倾斜，消耗内存大，1.x 之前 spark 使用 hash，适合处理中小规模，1.x之后，增加了 Sorted shuffle，Spark 更能胜任大规模处理了。
33. Spark中的HashShufle的有哪些不足？
    1）shuffle 产生海量的小文件在磁盘上，此时会产生大量耗时的、低效的 IO 操作；
    2）.容易导致内存不够用，由于内存需要保存海量的文件操作句柄和临时缓存信息，如果数据处理规模比较大的化，容易出现 OOM；
    3）容易出现数据倾斜，导致 OOM。
34. Spark on Yarn 模式有哪些优点？
    1)与其他计算框架共享集群资源（eg.Spark 框架与 MapReduce 框架同时运行，如果不用Yarn 进行资源分配，MapReduce 分到的内存资源会很少，效率低下）；资源按需分配，进而提高集群资源利用等。
    2)相较于 Spark 自带的 Standalone 模式，Yarn 的资源分配更加细致
    3)Application 部署简化，例如 Spark，Storm 等多种框架的应用由客户端提交后，由Yarn 负责资源的管理和调度，利用 Container 作为资源隔离的单位，以它为单位去使用内存,cpu 等。
    4)Yarn 通过队列的方式，管理同时运行在 Yarn 集群中的多个服务，可根据不同类型的应用程序负载情况，调整对应的资源使用量，实现资源弹性管理。