yarn+MapReduce入门

hdfs 存储
yarn 资源调度分配
MapReduce 计算

yarn主要模块

1. ResourceManger(RM)
   yarn 的资源的控制框架的中心模块，负责集群中所有的资源的统一管理的分配

   调度器
   应用管理器

2. 调度器（ResourceScheduler）
   根据各个应用程序的资源需求，进行分配

3. 应用管理器（Applications Manager）
   负责监控或跟踪AM的执行状态

4. NodeManager(NM)
   是ResourceManager每台机器上的代理，负责容器的管理，并监控他们的资源使用情况（CPU，内存，磁盘，网络等等）以及向RM提供这些资源的使用汇报

5. ApplicationMaster(AM)
   yarn中每个应用都会启动一个AM，负责向RM去申请资源。请求NM启动container，并告诉container需要做什么

6. container
   这是一个虚拟的一个概念
   yarn中所有应用都是在container上运行的，包括ApplicationMaster

   1. container是yarn中资源的抽象，它封装了某个节点上一定的资源（CPU，内存，磁盘，网络等）
   2. container是由AM向RM申请，由RM中的ResourceScheduler分配给AM

   container的分类

   1. 运行AM的container

   2. 运行各类任务的container，由AM向RM申请的

MapReduce on yarn

这张图就是MapReduce on yarn

1. client 向RM提交应用程序，其中包括AM主程序，启动AM的命令，用户的程序（wordcount）
2. RM为该应用分配第一个container，并与NM通信，要求NM在这个container中启动AM
3. AM首先向RM注册，这样用户可以直接通过RM来查看程序的运行状态 可以通过9527（原8088）端口
4. AM通过RPC协议向ResourceScheduler申请资源
5. 一旦AM申领到资源，NM通信，要求NM启动任务
6. NM为任务设置好运行环境（环境变量，jar包等等）将任务的启动命令写到一个脚本中，并通过脚本触发启动任务
   wc.sh
   hadoop jar share/…
7. 各个container的task（Map Task,Reduce Task）,通RPC向AM进行进度和状态汇报，以便AM随时可以掌握任务的运行状态，失败的时候，也会重启container任务
8. 应用程序运行完成后，AM会向RM申请注销和关闭。

1-4 启动ApplicationMaster，领取资源
5-8 运行任务，直到任务完成

spark on yarn也大同小异

Scheduler

理想情况下，我们应用对yarn的资源的请求应该立刻被满足，但是实际上，资源有限。特别是很忙的集群
一般指很忙的时间段，比如1-3点 1:05运行 可能1:40才有资源才开始运行，需要等待。
yarn中负责分配资源的就是Scheduler
调度本身就是一个大难题，很难找到一个完美的解决方案，所以yarn提供了三种调度器

1. FIFO Scheduler
   FIFO = frist in frist out 队列
   这种调度器把应用按提交按顺序排成一个队列，先进先出的队列，在进行资源分配的时候先给队列中最头部的应用分配资源
   等到引用满足了，再给下一个分配，以此类推
   问题：大的应用可能会占用所有的资源，造成阻塞，不适合集群
2. Capacity Scheduler
   专门有一个队列来运行小任务，但是为小任务专门设置的队列也会占用一定的资源，导致大任务的运行时间落后于FIFO
3. Fair Scheduler
   不需要预先占用一定的资源，动态调整
   比如第一个是大任务且只有这个任务在运行，那么把所有资源都给它，然后第二个小任务提交了，Fair Scheduler就会分配一半资源给小任务，公平的共享资源，小任务跑完了，还是会把所有资源给到大任务

以上三种Scheduler如图所示

从9527(原8088)端口的RM管理界面可以看到Scheduler默认为Capcity

hadoop官网上面配置文件说明里有关于调度器的配置
yarn.resourcemanager.scheduler.class
默认为org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
可以修改为org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FariScheduler
FIFO一般不用

capacity-scheduler.xml
可以通过这个文件进行详细配置

MapReduce入门

学习还是得上官网

MapReduce java
Hive 使得SQL->java在MapReduce上跑

官网上写着"easily writing applications" 轻松编写应用程序，但是现在公司基本上不去写MapReduce
对于如何容错，如何进行RPC通信等，开发人员不用关注，关注我们业务逻辑就可以，这方面来说显得较为简单
业务逻辑 + MR框架自带的内置的组件=>分布式应用程序开发
但是呢 用MR来作开发很麻烦，相较于Spark，但是MapReduce的思想是很纯粹很经典的

MapReduce由Map和Reduce组成
Map：映射 把一个任务拆解成多个
Reduce：聚合 把拆解的任务做最后的聚合操作

对于wordcount文件来说其实是把以下内容
hadoop hdfs hdfs hive
hdfs sqoop flume java
Java Hadoop hadoop

变成了
（hadoop，1）
（hdfs，1）
（hdfs，1）
等

Reduce则是把上述内容聚合变为
（hdfs，2）
等

MapReduce-适用/不适用场景
适用：离线、批处理计算
不适用：实时计算

重跑官网例子初步了解MapReduce
关注运行中的进程
22720 DataNode
22595 NameNode
16003 Jps
3766 ResourceManager
22951 SecondaryNameNode
3895 NodeManager

MR运行中的进程
16421 YarnChild Task（包括MapTask ReduceTask）
16058 RunJar
6184 MRAppMaster

可以发现对比安装时的运行例子来说慢了不少
为什么相对安装于跑得慢呢
MapTask ReduceTask都是以进程的方式运行的
进程需要申请资源，运行，释放资源 这就是MR慢的其中一个原因