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
