在伪分布式模式下，先开启hadoop和启动历史服务：
start-all.sh
mr-jobhistory-daemon.sh start historyserver
可以查看jobHistory：
http://192.168.237.100:19888/jobhistory
一般用来处理，对集群来说执行的时间过长，或者发生执行错误的情况。考虑是否发生了类似数据倾斜，集群某个节点卡死的问题，这时候需要去查看执行情况。
yarn的前世今生：
在yarn出来之前，在hadoop1.x的版本的时候，最大的问题是资源问题。数据处理和资源调度都需要依赖mapreduce，且只能运行mapreduce程序，随着时间的发展，刚开始还比较好用，数据量变大。mapreduce同时要负责处理和管理，压力会越来越大。
压力过大会带来两个问题：
1.速度变慢
2.容易出各种bug
直到2.0版本开始增加yarn，yarn是hadoop一个重大的改革。意味着hadoop可以扩展计算框架。
好处：在mapreduce不够用的时候可以使用别的，同时可以分担mapreduce管理作用。（mapreduce不需要再执行管理的动作了，只需要执行yarn发过来的任务，jobTracker会交给resource manager去管理，而不是给mapreduce去管理）
生成的各种job实际处理计算会在mapreduce上运行。从jobscheduler才真正进入到mapreduce。
yarn的名称：
yarn就叫做把资源的管理和任务的监控和调度分离开来。只要是计算框架，将来写一个mapreduce2，mapreduce3，它同样可以兼容。不一定要使用原生的mapreduce，不需要集成在里面了。
它的引入在集群的利用率上有什么好处？
最关键的，可以把application master不一定要建在某一个datanode上面。看谁比较闲就让谁做application master。其他的人只负责建container放mapreduce计算就好了。相对来说，工作量就会减少很多。
yarn的基本架构：
yarn的核心框架是主从结构。指的是resourcemanager是主（总经理）和nodemanager（各个小部门的leader），所以，resource manager负责全局的资源管理，只要在这个集群之内，资源可以统一通过resource manager来调度分配。resource manager会发送一些任务给node manager，node manager从resource manager接收任务过来，比如说创建container，还要定时给resource manager发送心跳（我是不是还活着）和信息（当前运行速度是还可以还是巨慢无比，都要给resource manager去返回）。
yarn的核心组件主要也是resource manager和node manager。接下来yarn还有一个核心组件叫做application manager，专门来负责管理application master应用管理器。 为什么需要application manager来管理？因为同一时间可能有多个任务进来，一个任务就会生成一个application master。如果统一由yarn来管理，yarn的线程就会非常多。所以由application manager来管理，来一个job给一个application master。
在每个datanode上面，每个node manager负责管理container。
客户端（一般来说是指hdfs dfs的命令行，或者类似命令行的东西，或者hadoop jar生成的job）有一个请求进来之后，图中有两个请求，一个请求会生成一个application master，只有一个container的意思是，只在这一台节点上运行。可能请求很简单，比如就put一个小文件上去。调集资源的时间会很长。 可能只有一个节点给他报告工作，也可能有多个节点。正常来说会尽量的平均分配资源，谁比较忙就给他任务少点。
yarn的核心组件resource manager下面会有：
resource scheduler 资源调度器，负责进度调度的，相当于执行计划。根据节点的容量、队列情况、为应用程序分配资源
application manager->应用程序管理器，专门负责接收客户端发送过来的任务请求，来一个job创建一个application master来处理。
resource manager的功能：
1.处理客户端请求
2.监控nodemanager（准确来说是由nodemanager上报，根据它上报的东西，判断是否ok）
3.启动和监控applicationmaster，进行必要的重启（会在每个节点尝试重启3次）
4.整个系统的资源分配和调度
nodemanager的功能：
1.本节点上的资源管理和任务调度。
2.定时的向resourcemanager汇报本节点的资源使用情况（我忙不忙，虽然还活着但是快死了，resource manager会找别人来干活）和心跳（代表还活着）。
3.container的执行情况也是由nodemanager来处理的。
4.application master会和其他的datanode通信，一般是其他节点的优先级高，它已经有了application master就比较忙了，会优先找别的，这个application master就负责通知container，来一个MapTask，ReduceTask
application master的功能：
1.每个job对应一个application master，负责单个app的管理
2.负责数据切分，不是逻辑块，而是分片（物理切块的是存在机器上，逻辑分片默认的会判断一下最后一个块小于10%合并到倒数第二个块）
3.为应用程序向ResourceManager申请资源(Container)，原因application master 原则上还是属于resource manager的功能。只不过是把功能放在了一台datanode上面，对datanode并没有执行的权限。因为是不同的机器，需要向resource manager去申请资源并分配内部任务（MapTask和ReduceTask）
4.与NodeManager通信来启动/停止任务，Task都是运行在Container中的（除了jobTask）
5.负责任务的监控和容错，当某些Task运行出错，进行容错处理（重启，每台重试3次，错误节点就不会再重试了，最终上报，是不是权限卡死了container连接不上）
Container：
理解：是个对象，里面包含了map和reduce的任务，一个MapTask里面可能会有多个map，因为一个MapTask可能负责读一段文件，这一段可能有多行，一个map负责读一行。要执行任务就是执行对象里的方法，但不仅仅是一个对象，对象只关系到内存，它需要各种各样的资源，包括内存，CPU，磁盘（只要谈到文件，必然是落地在磁盘上的），网络（appmaster访问和container返回信息）
Resource Manager终极图：
假设有一个hdfs客户端发出一个world count的请求，客户端实现了hadoop jar，会先和namenode说，我要执行一个事情，通知一下yarn。yarn说你有啥事？cli说我要处理一个任务，申请一个jobID，yarn问一个够不够，不一定够。这时候可能分配多个作业id，返回回来的作业ID类似hdfs://…JOB130450这样的东西，会放在tmp下面，但是我们在tmp下面是看不到的，都是临时的session文件。
一个个job给回来之后，cli把jar包上传到这个路径，包括一些配置文件信息和文件路径信息，全都放上去，同时客户端会自动判断文件是不是过大，hdfs的count命令，可以计数多少行，多少字节进行分片（物理分片128M），强行切容易切到行中间，会在appmaster逻辑分片解决。给每个块定义一个标记。正常来说不需要管切割的，文件已经存在hdfs上面，就已经切割好了。除非当时是根据自己情况定的。只要把对于的块信息放在这里。
给resource manager说放好了，安排人处理一下。yarn接收到请求，resource manager开始安排。先找项目组，schedule排任务计划，看需要几步完成列好表，申请资源是要调度的。列出来一个开发java，一个测试，20个打酱油的。文档，安全各个功能的负责人。完整的执行计划放给appmanager，去招人了，招一个人叫appmaster，我到外包公司去招的，告诉nodemanager 多个一起问是否有资源，谁的资源比较丰富，能来做这个事。计划给出来了，具体执行还没有。
细化执行计划，几个人干第一件事情，第一阶段，而不是把人全部招进来。appmaster也是要有个container来确定管辖权限，文档在哪去取一下，分析需要多长时间，几个节点合作。通知其他节点，把结果返回scheduler，计划可行达成一致，application master 告诉自己及其他公司的nodemanager，会抄送到appmanager，而是由appmanager告诉每个nodemanager给了appmaster权限，container创建成功之后，文件和jar包在哪，去拿一下。map/reducetask接收共享的数据，下载下来，开始执行了。
程序运行完之后，释放资源
程序来源于生活。不要单单的从程序来看，既然是管理，就从生活的层面来看。
YARN的资源调度器：
3种
先进先出调度器：基于流和队列去做的，就是个队列，相当于排队scheduler就是这么去做的。它不是调度器，只是定义先做什么后做什么，不具备调度功能，但在1.0的时候就是用scheduler先进先出。队列的特点是，有一个人没走完队列就结束不了。是很大的瓶颈。
容量调度器：1.5之后是容量调度器，跑到各个datanode节点，创建container，根据container和在datanode占用别的比例来分配。会频繁的通信。并不合适。
公平调度器：容量调度器的优化，会提前的把容量可能的使用情况计划好了，只要保证当前活着的节点尽量公平的分配资源。
默认的资源调度器可以在yarn-default.xml文件中查看，属性如下：
yarn.resourcemanager.scheduler.class
默认调度器是公平调度器
yarn常用命令：
查看正在运行的任务
有网页了，命令用处不大，在8088上都能看得到，8088也是未来工作中比较常用的。
yarn application -list
yarn node -list
到这里，hdfs和yarn，原生的hadoop就已经结束了。