HDFS 读写架构&YARN

一、HDFS存储副本机制

1、在 HDFS 中，每个数据块都会被分成若干个数据块副本。默认情况下每个数据块会被复制三次到HDFS 集群中的三个不同的 DataNode 上 。

2、HDFS 会将数据块的多个副本分别存储在不同的 DataNode 上，以提高数据的可靠性和容错性。如果某个 DataNode 发生故障，数据块的其他副本仍然可以被访问。

3、HDFS 会尽量将数据块的多个副本存储在不同的机架（rack）上，以避免机架故障导致数据不可用的情况。HDFS 会将数据块的多个副本存储在不同的机架的从节点上，第一个副本在客户端所处的节点上。如果客户端在集群外，随机选一个,第二个副本在另一个机架的随机一个节点，第三个副本在第二个副本所在机架的随机节点。

4、各个从节点通过机架交换机进行数据传输，各个机架通过集群内交换机进行数据传输，各个集群通过集群间交换机进行数据传输

二、HDFS 机架感知

1、机架数据传输距离计算：

1）相同的datanode，距离为 0，比如H1到H1 distance(/D1/R1/H1,/D1/R1/H1)=0
2）同一机架下的不同datanode，距离为 2，比如H1到H2 distance(/D1/R1/H1,/D1/R1/H2)=2
3）同一集群不同机架下的datanode，距离为 4，比如H1到H4 distance(/D1/R1/H1,/D1/R1/H4)=4
4）不同集群下的datanode，距离为 6，比如H1到H7 distance(/D1/R1/H1,/D2/R3/H7)=6

2、为什么三分之一的副本在一个节点上，三分之二的副本在另一个机架不同节点上

1）hdfs 三个副本的这种存放策略减少了机架间的数据传输，提高了写操作的效率。
2）机架的错误远远比节点的错误少，所以这种策略不会影响到数据的可靠性和可用性。
3）与此同时，因为数据块只存放在两个不同的机架上，所以此策略减少了读取数据时需要的网络传输总带宽。
4）在这种策略下，副本并不是均匀的分布在不同的机架上：三分之一的副本在一个节点上，三分之二的副本在一个机架上，其它副本均匀分布在剩下的机架中，这种策略在不损害数据可靠性和读取性能的情况下改进了写的性能。

三、HDFS 写（Write）流程

（1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在，客户端是否有写权限。
（2）NameNode返回是否可以上传。
（3）客户端请求第一个 Block上传到哪几个DataNode服务器上(数据的切分在客户端完成)。
（4）NameNode返回3个DataNode节点，分别为dn1、dn2、dn3(返回dn数据存储列表)。
（5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。(Pipline管道传输)
（6）dn1、dn2、dn3逐级应答客户端。
（7）客户端开始往dn1上传第一个Block（先从磁盘读取数据放到一个本地内存缓存），以Packet为单位，dn1收到一个Packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答(ACK校验)。
（8）当一个Block传输完成之后，客户端再次请求NameNode上传第二个Block的服务器。（重复执行3-7步）。

四、HDFS 读（Read）流程

（1）客户端向 NameNode 发送读取请求，请求包括要读取的文件名和文件块的起始位置。
（2）NameNode 根据请求的文件名，查询文件所对应的块列表，并返回给客户端块列表以及每个块所在的 DataNode 列表。
（3）客户端根据返回的块列表和 DataNode 列表，选择一个 DataNode 开始读取数据。如果选择的 DataNode 不可用，则会选择另外一个 DataNode。
（4）客户端向选择的 DataNode 发送读取请求，请求包括要读取的块的起始位置和长度。
（5）DataNode 接收到读取请求后，从本地磁盘读取数据块，并将数据块返回给客户端

五、Hadoop处理框架演变

1、MRv1架构

在 Hadoop 1.0 中 MapReduce 框架（MRv1，第一代 MapReduce 框架），和 HDFS 一样，MapReduce 也是采用 Master/Slave 的架构，其架构如下图所示：

包含四个组成部分，分别为 Client，JobTracker，TaskTracker，Task。

1）Client： 客户端，每一个 Job 都会在用户端通过 Client 类，将应用程序以及参数配置 Configuration 打包成 Jar 文件存储在 HDFS，并把路径提交到 JobTracker 的 master 服务，然后由 master 创建每一个 Task（即 MapTask 和 ReduceTask），将它们分发到各个 TaskTracker 服务中去执行。
2）JobTracker： 管理主节点，JobTracker 负责资源监控和作业调度。JobTracker 监控所有的 TaskTracker 与 job 的健康状况，一旦发现失败，就将相应的任务转移到其它节点；同时 JobTracker 会跟踪任务的执行进度，资源使用量等信息，并将这些信息告诉任务调度器，而调度器会在资源出现空闲时，选择合适的任务使用这些资源。在 Hadoop 中，任务调度器是一个可插拔的模块，用于可以根据自己的需要设计相应的调度器。
3）TaskTracker： 执行从节点，TaskTracker 会周期性地通过 HeartBeat 将本节点上资源的使用情况和任务的运行进度汇报给 JobTracker，同时执行 JobTracker 发送过来的命令 并执行相应的操作（如启动新任务，杀死任务等）。TaskTracker 使用 “slot” 等量划分本节点上的资源量。“slot” 代表计算资源（cpu，内存等） 。一个 Task 获取到一个 slot 之后才有机会运行，而 Hadoop 调度器的作用就是将各个 TaskTracker 上的空闲 slot 分配给 Task 使用。slot 分为 MapSlot 和 ReduceSlot 两种，分别提供 MapTask 和 ReduceTask 使用。TaskTracker 通过 slot 数目（可配置参数）限定 Task 的并发度。
4）Task： 计算任务，Task 分为 MapTask 和 ReduceTask 两种，均由 TaskTracker 启动。HDFS 以固定大小的 block 为基本单位存储数据，而对于 MapReduce 而言，其处理单位是 split。split 是一个逻辑概念，它只包含一些元数据信息，比如数据起始位置、数据长度、数据所在节点等。它的划分方法完全由用户自己决定。但需要注意的是，split 的多少决定了 MapTask 的数目，因为每一个 split 只会交给一个 MapTask 处理。

2、MRv1缺陷

在 Hadoop 1.0 中， JobTracker 由资源管理（由 TaskScheduler 模块实现）和作业控制（由 JobTracker 中多个模块共同实现）两部分组成，Hadoop 对 JobTracker 赋予的功能过多而造成负载过重。Hadoop YARN 是在 MRv1 基础上演化而来的，它克服了 MRv1 中的各种局限性，概括为以下几个方面：

1）扩展性差： 在 MRv1 中， JobTracker 同时兼备了资源管理和作业控制两个功能，这成为系统的一个最大瓶颈，严重制约了 Hadoop 集群扩展性。
2）可靠性差： MRv1 采用了 master/slave 结构，其中， master 存在单点故障问题，一旦它出现故障将导致整个集群不可用。
3）资源利用率低： MRv1 采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空闲资源。此外， Hadoop 将槽位分为 Map Slot 和 Reduce Slot 两种，且不允许它们之间共享，常常会导致一种槽位资源紧张而另外一种闲置（比如一个作业刚刚提交时，只会运行 Map Task，此时 Reduce Slot 闲置）。
4）无法支持多种计算框架： 随着互联网高速发展， MapReduce 这种基于磁盘的离线计算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、流式计算框架和迭代式计算框架等，而 MRv1 不能支持多种计算框架并存。

3、YARN架构

为了克服以上几个缺点， Apache 开始尝试对 Hadoop 进行升级改造，进而诞生了更加先进的下一代 MapReduce 计算框架 MRv2。正是由于MRv2将资源管理功能抽象成了一个独立的通用系统YARN，直接导致下一代MapReduce的核心从单一的计算框架MapReduce转移为通用的资源管理系统YARN。

YARN 实际上是一个弹性计算平台，它的目标已经不再局限于支持 MapReduce 一种计算框架，而是朝着对多种框架进行统一管理的方向发展。

4、YARN与MRv1区别

Hadoop2.0 即第二代 Hadoop，由分布式存储系统HDFS、并行计算框架MapReduce和分布式资源管理系统YARN三个系统组成，其中 YARN 是一个资源管理系统，负责集群资源管理和调度，MapReduce 则是运行在 YARN 上的离线处理框架，称为 MRv2（MapReduce 的第二版）。

MRv1 主要由编程模型（由新旧 API 组成）、数据处理引擎（由 MapTask 和 ReduceTask 组成）和运行时环境（由一个 JobTracker 和若干个 TaskTracker 组成）三部分组成，为了保证编程模型的向后兼容性， MRv2 重用了 MRv1 中的编程模型和数据处理引擎，但运行时环境被完全重写，具体如下：

1）编程模型与数据处理引擎： MRv2 重用了 MRv1 中的编程模型和数据处理引擎。

• 为了能够让用户应用程序平滑迁移到 Hadoop 2.0 中， MRv2 应尽可能保证编程接口的向后兼容性，但由于 MRv2 本身进行了改进和优化，它在向后兼容性方面存在少量问题。
• MapReduce 应用程序编程接口有两套，分别是新 API（mapredue）和旧 API（mapred） ， MRv2
  可做到以下兼容性 ：采用 MRv1 旧 API 编写的应用程序，可直接使用之前的 JAR 包将程序运行在 MRv2 上；但采用 MRv1 新 API 编写的应用程序则不可以，需要使用 MRv2 编程库重新编译并修改不兼容的参数和返回值。

2）运行时环境： MRv1 的运行时环境主要由两类服务组成，分别是 JobTracker 和 TaskTracker。

• JobTracker 负责资源和任务的管理与调度， TaskTracker 负责单个节点的资源管理和任务执行。 MRv1 将资源管理和应用程序管理两部分混杂在一起，使得它在扩展性、容错性和多框架支持等方面存在明显缺陷。
• MRv2 则通过将资源管理和应用程序管理两部分剥离开，分别由 YARN 和 ApplicationMaster 负责，其中， YARN 专管资源管理和调度，而 ApplicationMaster 则负责与具体应用程序相关的任务切分、任务调度和容错等。

六、YARN架构组件

1、架构图

2、YARN基本组成

ResourceManager: RM是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（ApplicationManager）。

Scheduler: 调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量.

ApplicationManager: 应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。

ApplicationMaster（AM）: 用户提交的每个应用程序均包含一个AM，主要功能包括：
1、与RM调度器协商以获取资源（用Container表示）；将得到的任务进一步分配给内部的任务；
2、与NM通信以启动/停止任务；
3、监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
4、当前YARN自带了两个AM实现，一个是用于演示AM编写方法的实例程序distributedshell，它可以请一定数目的 Container 以并行运行一个Shell命令或者Shell 脚本：
5、另一个是运行MapReduce应用程序的AM—MRAppMaster。

NodeManager（NM）: NM是每个节点上的资源和任务管理器
1、它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；
2、它接收并处理来自AM的Container启动/停止等各种请求。

Container： 是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。
YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。
需要注意的是，Container不同于MRv1中的slot，它是一个动态资源划分单位、是根据应用程序的需求动态生成的。目前，YARN暂仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制 Cgroups进行资源隔离。

七、YARN工作流程

1、步骤一：用户向YARN中提交应用程序
步骤1用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
2、步骤二：ResourceManager分配Container，NodeManager通信
步骤2：ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。
3、步骤三：ApplicationMaster向ResourceManager注册
步骤3ApplicationMaster 首先向ResourceManager注册，这样用户可以直接通过ResourceManage查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4～7。
4、步骤四：ApplicationMaster向ResourceManager申请和领取资源
步骤4：ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源
5、步骤五：ApplicationMaster与对应的NodeManager通信，要求它启动任务。
步骤5：一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。
6、步骤六：NodeManager为任务设置好运行环境
步骤6：NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
7、步骤七：各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度
步骤7：各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
8、步骤八：ApplicationMaster注销
应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。