Hadoop1.0架构回顾
Hadoop是Apache的一个开源分布式计算平台，以分布式文件系统HDFS，和MapReduce为核心的Hadoop为用户提供了系统底层细节透明的分布式基础架构。HDFS的高容错性、高伸缩性等优点形成分布式系统；MapReduce分布式编程模型让我们开发并行应用程序。
Hadoop为包含多个子项目的集合，其核心内容是MapReduce和HDFS。主要是通过HDFS来实现对分布式存储的底层支持，并且它会通过MapReduce来实现对分布式并行任务处理。
MapReduce是一种编程模型，用于大规模数据集的并行运算。它的主要思想是从函数式编程中借来的，它使得我们在不了解分布式并行 编程的情况下也能方便地将程序运行在分布式系统上。MapReduce在执行时先指定一个Map函数，把输入键值对映射成一组新的键值对，经过一定的处理后交给Reduce，它对相同的Key下的所有Value进行处理后再输出键值对作为最终的结果。
HDFS，是一个分布式文件系统，具有高容错性特点，故障的检测和自动快速恢复是HDFS的一个核心目标；它使应用程序流式的数据访问数据集；大部分的HDSF程序操作文件时需要一次写入，多次读取，一个文件一旦经过创建、写入、关闭后就不需要修改了，从面简化了数据一致性问题和高吞吐量的数据访问问题。
HDFS采用了主从（Master/Slave）结构模型，一个HDFS集群是由一个NameNode和若干个DataNode组成。其中NameNode作为主服务器，管理文件系统的命名空间和客户端对文件的访问操作（注意存在单点问题）；集群中的DataNode管理存储的数据。HDFS文件被分成若干个数据块，这些数据块存放在一组DataNode上，NameNode执行文件系统的命名空间操作，如打开、关闭、重命名文件或目录等，也负责数据块到具体DataNode的映射，统一调度进行数据块的创建、删除和复制工作等（即单点，工作压力还很大哈）。一个典型的部署是集群中的一台机器运行一个NameNode实现，其他机器分别运行一个DataNode实例。
MapReduce以一种高容错的方式并行处理大量的数据集，实现Hadoop的并行任务处理功能。由一个单独运行在主节点上的JobTracker和运行在每个集群从节点上的TaskTracker共同组成的。主节点负责调度构成一个作业的所有任务，这些任务分布在不同的从节点上。主节点监控它们的执行情况，并且重新执行之前失败的任务；从节点仅负责接收主节点指派的任务。当一个Job被提交时，JobTracker接收到提交作业和配置信息后，就会将配置信息等分发给从节点，同时调度任务并监控TaskTracker的执行。
总结
- 数据分布存储：HDFS由一个NameNode和N个DataNode组成，但HDFS底层把文件切成Block，然后这些Block分散在存储于不同的DataNode上，每个Block还可以复制数份数据存储于不同的DataNode上，达到容灾的目的。NameNode是整个HDFS的核心，它通过维护一些数据结构来记录每一个文件被切割了多少个Block、这些Block可以从哪些DataNode中获取，及各个DataNode的状态等重要信息。
- 分布式并行计算：Hadoop中有一个作为主控的JobTracker，用于调度和管理TaskTracker，JobTracker可以运行于集群中的任意一台计算机上，TaskTracker则负责执行任务，它运行于DataNode上，DataNode既是数据存储节点，也是计算节点。JobTracker将map任务和reduce任务分发给空闲的TaskTracker，并负责监控任务的运行情况。如某一TaskTracker出了故障，JobTracker会将其负责的任务转交给另一个空闲的TaskTracker重新运行。
- 本地计算：数据存储在哪一个计算机上，就在那台计算机上进行这部分数据的计算，这样可以减少数据在网络上的传输。移动计算比移动数据更经济。
- 任务粒度：把原始大数据集切割成小数据时，通常让小数据集小于或等于HDFS中一个Block的大小，这样能够保证一个小数据集是位于一台计算机上，便于本地计算。有M个小数据集待处理，就启动M个map任务，这里的M个map任务分布于N台计算机上，reduce任务的数量R则可由用户指定。
- 数据分割（Partition）：把map任务输出的中间结果按key的范围划分成R份，划分时通常使用hash函数，这样可以保证某一范围内的Key一定是由一个reduce任务来处理，可以简化Reduce的过程。
- 数据合并（Combine）：在数据分割前，还可以先对中间结果进行数据合并，将中间结果中有相同key的键值对合并成一对。Combine的过程与Reduce的过程类似，很多情况下直接使用Reduce函数，Combine作为Map任务的一部分，在执行完Map函数后立刻执行。Combine能够减少中间结果的键值对的数据，从而降低网络流量。
- Reduce：Map任务的中间结果在完成Combine和Partition后，以文件形式存在本地磁盘上。中间结果文件的位置会通知主控JobTracker，JobTracker再通知Reduce任务到哪一个DataNode上取中间结果。所有的map任务生产的中间结果均按Key用同一个Hash函数划分成R份，R个Reduce任务各自负责一段key区间。每个Reduce需要向许多个Map任务节点取得落在其负责的key区间内的中间结果，然后执行reduce函数，开成一个最终的结果文件。
- 任务管道：有R个reduce任务，就会有R个最终结果，很多情况下R个最终结果并不需要合并成一个最终结果，因为这R个结果又可以作为另一个计算任务的输入，开始另一个并行计算任务，这也就形成了任务管道。
存在的问题
- HDFS存在的问题
- NameNode单点故障，难以应用于在线场景
- NameNode压力过大，且内存受限，影响系统扩展性。
- MapReduce存在的问题
- JobTracker单点故障
- JobTracker访问压力大，影响系统扩展性
- 难以支持除MapReduce之外的框架，如Spark、Storm等
Yarn资源管理
Apache Hadoop Yarn（Yet Another Resource Negotiator，另一种资源协调者）是一种新的Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
基本思想
Yarn的基本思想是将JobTracker的两个主要功能（资源管理和作业调度/监控）分离，主要方法是创建一个全局的ResourceManager（RM）和若干个针对应用程序的ApplicationMaster（AM）。这里的应用程序是指传统的MapReduce作业或作业的DAG（有向无环图）。
ResourceManager
Yarn分层结构的本质是ResourceManager。这个实体控制整个集群并管理应用程序基础计算资源的分配。ResourceManager将各个资源部分（计算、内存、带宽等）精心安排给基础 NodeManager（Yarn 的每节点代理）。ResourceManager还与ApplicationMaster一起分配资源，与 NodeManager一起启动和监视它们的基础应用程序。在此上下文中，ApplicationMaster承担了以前的TaskTracker的一些角色，ResourceManager承担了JobTracker的角色。
ApplicationMaster
ApplicationMaster管理一个在Yarn内运行的应用程序的每个实例。ApplicationMaster负责协调来自ResourceManager的资源，并通过 NodeManager监视容器的执行和资源使用（CPU、内存等的资源分配）。从 Yarn角度讲，ApplicationMaster是用户代码，因此存在潜在的安全问题。Yarn假设ApplicationMaster存在错误或者甚至是恶意的，因此将它们当作无特权的代码对待。
NodeManager
NodeManager管理一个Yarn集群中的每个节点。NodeManager提供针对集群中每个节点的服务，从监督对一个容器的终生管理到监视资源和跟踪节点健康。MRv1通过插槽管理Map和Reduce任务的执行，而NodeManager 管理抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。Yarn继续使用HDFS层。它的主要NameNode用于元数据服务，而 DataNode用于分散在一个集群中的复制存储服务。
工作流程
要使用一个Yarn集群，首先需要来自包含一个应用程序的客户的请求。ResourceManager协商一个容器的必要资源，启动一个 ApplicationMaster来表示已提交的应用程序。通过使用一个资源请求协议，ApplicationMaster协商每个节点上供应用程序使用的资源容器。执行应用程序时，ApplicationMaster监视容器直到完成。当应用程序完成时，ApplicationMaster从ResourceManager注销其容器，执行周期就完成了。
MRv1与MRv2从架构上的区别
多种计算框架可以运行在一个集群中
- 良好的扩展性、高可用
- 对多种类型应用进行统一管理和调度
- 自带了多种用户调度器，适合共享集群环境
- 提高了资源利用率、降低运维成本和数据共享成本
总结
RM
RM处理客户端请求，接收JobSubmitter提交的作业，按照作业的上下文 (Context) 信息，以及从 NodeManager(NM)收集来的状态信息，启动调度过程，分配一个Container作为Application Master
RM拥有为系统中所有应用资源分配的决定权，是中心服务，做的事情就是调度、启动每一个Job所属的Application、另外监控Application的存在情况
与运行在每个节点上的NM进程交互，通过心跳通信，达到监控NM的目的
NM
是slave进程，类似TaskTracker的角色，是每个机器框架代理
处理来自RM的任务请求
接收并处理来自ApplicationMaster的Container启动、停止等各种请求
负责启动应用程序的Container(执行应用程序的容器)，并监控他们的资源使 用情况(CPU、内存、磁盘和网络)，并报告给RM
总的来说，在单节点上进行资源管理和任务管理
AM
应用程序的Master，每一个应用对应一个AM，在用户提交一个应用程序时，一 个AM的轻量型进程实例会启动，AM协调应用程序内的所有任务的执行
负责一个Job生命周期内的所有工作，类似旧的JobTracker
每一个Job都有一个AM，运行在RM以外的机器上下文
与NM协同工作与Scheduler协商合适的Container进行Container的监控
是一个普通Container的身份运行
Container
是任务运行环境的抽象封装
Container只是使用NM上指定资源的权利
AM必须向NM提供更多的信息来启动Container
描述任务的运行资源(节点、内存、cpu)、启动命令和运行环境
Yarn框架对于旧的MapReduce框架的优势
减小了JobTracker(也就是现在的 RM)的资源消耗，并且让监测每一个Job子任务(tasks)状态的程序分布式化了，更安全、更优美
AM是一个可变更的部分，用户可以对不同的编程模型写自己的AM，让更多类 型的编程模型能够跑在 Hadoop集群中
对于资源的表示以内存为单位，比之前以剩余 slot 数目更合理
老的框架中，JobTracker一个很大的负担就是监控job下的tasks的运行状况 现在，这个部分就扔给ApplicationMaster做了
资源表示成内存量，那就没有了之前的 map slot/reduce slot 分开造成集群资 源闲置的尴尬情况
Yarn框架的运行过程
Client请求Resource Manager运行一个 Application Master实例(step 1);
Resource Manager选择一个Node Manager，启 动一个Container并运行Application Master实例( step 2a、step 2b);
Application Master根据实际需要向Resource Manager请求更多的Container资源(step 3);
Application Master通过获取到的Container资源执 行分布式计算(step 4a、step 4b)
Yarn的容错能力
RM挂掉:单点故障，新版本可以基于Zookeeper实现HA高可用集群，可通过 配置进行设置准备RM，主提供服务，备同步主的信息，一旦主挂掉，备立即做 切换接替进行服务
NM挂掉:不止一个，当一个挂了，会通过心跳方式通知RM，RM将情况通知对应AM，AM作进一步处理
AM挂掉:若挂掉，RM负责重启，其实RM上有一个RMApplicationMaster，是AM的AM，上面保存已经完成的task，若重启AM，无需重新运行已经完成的task
