Hadoop基础学习

声明：本文章为个人学习笔记，根据B站课程笔记整理而来。

Hadoop介绍

狭义上Hadoop指的是Apache软件基金会的一款开源软件。
用java语言实现，开源。
Hadoop核心组件：
Hadoop HDFS（分布式文件存储系统）：解决海量数据存储。
Hadoop YARN（集群资源管理和任务调度框架）：解决资源任务调度。
Hadoop MapReduce（分布式计算框架）：解决海量数据计算。

广义上讲Hadoop指的是Hadoop大数据生态圈。

Hadoop现状

HDFS作为分布式文件存储系统，处在生态圈的底层与核心地位；

YARN作为分布式通用的集群资源管理系统和任务调度平台，支持各种计算引擎（如：spark）运算，保证了Hadoop地位；

MapReduce作为大数据生态圈第一代分布式计算引擎，由于自身设计的模型所产生的弊端，导致企业一线几乎不在直接使用MapReduce进行编程处理，但很多软件的底层已然在使用MapReduce引擎来处理数据。

Hadoop的优点：三高一低

高扩展性：
在集群之间分配任务数据，可方便的扩展节点。

高效率：
在MapReduce思想下，Hadoop是并行工作，以加快任务处理速度。

高可靠性：
底层维护多个数据副本，即使Hadoop某个计算元素或存储出现故障，也不会导致数据丢失。同时能够自动将失败的任务重新分配。

低成本：
Hadoop能部署在比较廉价的机器组成的集群上来处理大数据。

Hadoop的版本发展

Hadoop1.x
HDFS（数据存储）
MapReduce（计算+资源调度）
Common（辅助工具）

Hadoop2.x
HDFS（数据存储）
MapReduce（计算）
YARN（资源调度）

Hadoop3.x
在Hadoop2.x的基础上进行性能优化。

Hadoop集群整体概述

Hadoop集群包括两个集群：HDFS集群、YARN集群
两个集群逻辑上分离，通常物理上在一起
逻辑上分离：两个集群互相之间没有依赖、互不影响
物理上在一起：某些角色进行部署在同一台物理服务器上
两个集群都是标准的主从架构集群（Master、Slaver）

HDFS集群

主角色：NameNode
从角色：DataNode
辅助主角色：SecondaryNameNode

YARN集群

主角色：ResourceManger
从角色：NodeManger

Hadoop集群的开启

启停HDFS集群：
start-dfs.sh
stop-dfs.sh

启停YARN集群：
start-yarn.sh
stop-yarn.sh

启停Hadoop集群：
start-all.sh
stop-all.sh

进程状态、日志查看
启动完毕之后可以使用jps命令查看进程是否启动成功。

Hadoop启动日志路径：/export/server/hadoop-3.3.0/logs/

HDFS集群地址：namenode_host:9870
namenode_host：namenode所在主机名

YARN集群：resourcemanger_host：8088
resourcemanger_host:resourcemanger所在主机名

HDFS分布式文件系统介绍

文件系统定义
文件系统是一种存储和组织数据的方法，实现了数据的存储、分级组织、访问和获取等操作，使得用户对文件访问和查找变得容易。
文件系统使用树形目录的抽象逻辑概念代替了硬盘等物理设备使用数据块的概念，用户不比关心数据底层存在硬盘哪里，只需记住所在目录和文件名即可。
文件系统通常使用硬盘或光盘等存储设备，并维护文件在设备中的物理位置。
数据、元数据
数据：
指存储的内容本身，比如文件、视频、图片等，这些数据底层最终是存储在磁盘等存储介质上的，一般用户无需关心。只需要基于目录树进行增删改查即可，实际针对数据操作有文件系统组成。

元数据：metadata
记录数据的数据、描述数据的数据。
文件系统元数据一般指文件大小、最后修改时间、底层存储位置、属性、所属用户等信息。

HDFS简介

HDFS（Hadoop Distributed File System）：Hadoop分布式文件系统
是Apache Hadoop核心组件之一，作为大数据生态圈最底层的分布式存储服务而存在。大数据首要解决的问题就是海量数据的存储问题。HDFS能够很好的胜任该任务。

• HDFS主要是解决大数据如何存储的问题。分布式意味着HDFS是横跨多台计算机上的存储系统；
• HDFS是一种能够在普通硬件上运行的分布式文件系统，他是高容错的，适用于具有大数据集的应用程序，他非常适合存储大型数据；
• HDFS使用多台计算机存储文件，并且提供统一的访问接口，像是访问一个普通文件系统一样使用分布式文件系统
  下图为客户端访问文件的大致流程图：
  

HDFS核心属性及功能

分布式存储系统核心属性：

主从架构

• HDFS集群是标准的master/slave主从架构集群；
• 一般一个HDFS集群是一个NameNode和一定数目的DataNode组成；
• NameNode是HDFS主节点，DataNode是HDFS从节点，两种角色各司其职，共同协作完成分布式的文件存储任务；
• 官方架构图是一主五从模式，其中五个从角色谓语两个机架（Rack）上的不同服务器上。
  

分布式存储

分布式存储解决了什么问题？
数据量大，单机存储遇到瓶颈
与单机存储的对比：
单机纵向扩展：磁盘不够家磁盘，有上限瓶颈限制
多级横向扩展：机器不够加机器，理论上可以无限扩展

元数据记录

解决了什么问题？
文件分布在不同机器上不利于寻找
解决方式：
元数据记录下文件及其存储位置信息，能快速定位文件位置

在HDFS中，NameNode管理的元数据具有两种类型：

• 文件自身属性信息，如：文件名称、权限、大小、数据块大小等
• 文件块位置映射信息：记录文件块和DataNode之间的映射信息，即那个块位于哪个节点上。
  
  

分块存储

解决了什么问题？
文件过大导致单机存不下，上传下载效率低
解决方式：
文件分块存储在不同机器上，针对块并行操作提高效率

• HDFS中的文件在物理上是分块存储的（block），在Hadoop1.x中默认大小是64M，Hadoop2.x以后默认大小128M，不足128M本身就是一块。
• 块的大小可以通过配置参数来规定，参数位于hdfs-default.xml中：dfs.blicksize；
• 文件的各个block的具体存储有DataNode节点承担；
• 每个block都可以在多个DataNode上存储。

副本机制

解决了什么问题？
硬件故障导致的数据丢失问题
解决方式：
不同机器设置备份，冗余存储，保障数据安全

• 文件的所欲block都会有副本。副本系数可以在文件创建的时候指定，也可以在之后通过命令改变；
• 副本有参数dfs.replication控制，默认值为3，也就是额外复制2份，连同本身总共3份副本；
• Hadoop的默认布局策略是运行客户端的节点上方第一个副本。第二个副本放在第一个不同机架上的节点上。第三个副本与第二个副本放在同一机架的随机节点上。一旦选定副本的放置位置，就根据网络拓扑创建一个管线。
  

HDFS副本存放与策略小结：
副本的存放是HDFS可靠性和性能的关键。HDFS采用一种为机架感知（rack-aware）的策略来改进数据的可靠性可用性和网络带宽的利用率。

一方面，通过一个机架感知的过程，NameNode可以确定每个DataNode所属的机架ID。目前HDFS采用的策略就是将副本存放在不同机架上。这样可以有效防止当整个机架失效时数据的丢失，并且允许读数据的时候充分利用多个机架的带宽。

这种策略设置可以将副本均匀的分布在集群中，有利于在组建失效情况下的负载均衡。

但是，因为这种策略的一个写操作需要传输到多个机架，就增加了操作的成本。
大多数情况下副本系数是3，HDFS的存放策略是一个副本存放在本地机架；另一个副本存放在不同机架的一节点上，最后一个副本存放在与第二个副本相同机架的不同节点上。

同时因为数据块只放在两个不同的机架上，所以此策略减少了读取数据时需要的网络带宽。
这一策略在不损害数据可靠性和读取性的情况下改进了写的性能。
另一方面，在读取数据时，为了减少整体的带宽消耗和降低整体的带宽延时，HDFS会尽量让程序读取离客户端最近的副本。
如果在读取程序的同一机架上有一个副本，那么就读取该副本。
如果一个HDFS集群跨越了多个数据中心，那么客户端也将首先读取本地数据中心的副本。

namespace名称空间

• HDFS支持传统的层次型文件组织结构。用户可以创建目录，然后将文件保存在这些目录里。文件系统命名空间的层次结构和大多数现有的文件系统类似：可以创建、删除、命名文件；
• NameNode负责维护文件系统的namespace名称空间，任何对文件系统名称空间或属性的修改都将被NameNode记录下来；
• HDFS会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件。

HDFS的设计目标

• 硬件故障（Hardware Failure）是经常发生的，HDFS集群中每个节点都有可能发生故障。因此故障检测和自动恢复是HDFS的架构目标之一；
• HDFS上的应用主要是以流式读取数据（Streaming Data Access）。HDFS被设计成用于批处理，而不是用户交互式的。相较于数据访问的反应时间，更注重数据访问的高吞吐量；
• 典型的HDFS文件大小是GB到TB的级别。所以HDFS被调整成支持大文件（Large Data Sets）；
• 大部分HDFS应用对于文件要求的是一次写入多次读取模型。一个文件一旦创建、写入、关闭之后就不需要修改了。这简化了数据一致性问题，是高吞吐的数据访问成为可能；
• 移动计算的代价比移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效；
• HDFS被设计为可以从一个平台轻松一致到另一个平台。这有助于HDFS广泛用作大量应用程序的首选平台。

HDFS的应用场景：
根据上述HDFS的设计目标和简介，可以得出结论
HDFS的应用场景有：

• 适用于存储操作大文件；
• 数据流式访问；
• 一次写入多次读取；
• 低成本部署，廉价PC；
• 高容错

不适合以下场景：

• 操作小文件
• 数据交互式访问
• 频繁任意修改
• 低延迟处理

HDFS shell操作

介绍

• 命令行界面（command-line interface，缩写CLI），是指通过键盘输入指令，计算机接收到指令后，执行命令的交互方式；
• Hadoop提供了文件系统的shell命令行客户端：hadoop fs
  

常用命令操作

1、创建文件夹：
hadoop fs -mkdir [-p] …
path为待创建的目录
-p会沿着路径创建父目录

2、查看指定目录下内容：
hadoop fs -ls [-h] [-R] [ …]
path 指定目录路径
-h人性化显示文件size
-R递归查看执行目录及其子目录

3、上传文件到HDFS执行目录下：
hadoop fs -put [-f] [-p] …
-f覆盖目标文件（已存在时）
-p保留访问和修改时间，所有权和权限
localsrc本地文件系统（客户端所在机器）
dst目标文件系统（HDFS）

4、查看HDFS文件内容：
hadoop fs -cat …
读取指定文件全部内容，显示输出在控制台上。
注意：对于大文件内容读取要慎重

5、下载HDFS文件：
hadop fs -get [-f] [-p] …
下载文件到本地文件系统指定目录，localdst必须是目录
-f覆盖目标文件（已存在时）
-p保留访问和修改时间，所有权和权限

6、拷贝HDFS文件：
hadoop fs -cp [-f]…
-f覆盖目标文件（已存在时）

7、追加数据到HDFS文件中：
hadoop fs -appendToFile …
将所有给定本地文件的内容追加到给定dst文件
dst如果文件不存在，将创建该文件
如果localsrc为-，则输入为从标准输入中读取

8、HDFS数据移动操作：
hadoop fs -mv …
移动文件到指定文件夹下
可以使用该命令移动数据，重命名文件的名称

HDFS工作流程与机制

HDFS集群角色与职责

主角色：NameNode

• NameNode是Hadoop分布式文件系统的核心，架构中的主角色；
• NameNode维护和管理文件系统元数据，包括名称空间（namespace）、目录树结构、文件和快的信息位置、访问权限等信息；
• NameNode知道HDFS中任何给定文件的块列表及其位置。使用此信息NameNode知道如何从块中构建文件。
• NameNode不持久化存储每个文件中各个块所在的datanode的位置信息，这些信息会在系统启动时从DataNode重建。
  这里涉及到HDFS的“安全模式”：
  NameNode启动后会进入一个成为安全模式的特殊状态。处于安全模式的NameNode是不会进行数据块复制的。NameNode从所有的DataNode上接收心跳信号和块状态报告。
  块状态报告包括了某个DataNode所有的数据块列表。每个数据块都有一个指定的最小副本数。
  当NameNode检测确定某个数据块的副本数目达到最小值时，那么该数据块就会被任务时副本安全的；
  在一定百分比的数据块被NameNode检测确定安全之后，NameNode将退出安全模式状态。接下来他会确定还有那些数据块的副本没有达到指定数目，并将这些数据块复制到其他DataNode上。
• NameNode是访问HDFS的唯一入口
• NameNode内部通过内存和磁盘文件两种方式管理元数据；
• 其中磁盘上的元数据包括fsimage内存元数据镜像文件和edits log（journal）编辑日志。
• NameNode是Hadoop集群中的单点故障，如果NameNode发生故障，那么对整个集群的影响是非常大的，会导致无法正常读取数据。
• NameNode所在机器通常会配置有大量内存（RAM）

从角色：DataNode

• DataNode是Hadoop HDFS中的从角色，负责具体的数据块存储；
• DataNode的数量决定了HDFS集群的整体数据存储能力。通过NameNode配合维护着数据块。
• DataNode启动时，会将自己注册到NameNode并汇报自己负责持有的块列表；
• DataNode所在机器通常配置有大量磁盘空间，因为要存放实际数据。
  
  主角色辅助角色：secondarynamenode
  Secondary NameNode充当NameNode的辅助节点，但不能替代NameNode

HDFS写数据流程（上传文件）

写数据大致流程图：

核心概念：Pipline管道

• Pipline，译为管道。这是HDFS再上传文件写数据过程中采用的一种数据传输方式；
• 客户端将数据块写入第一个数据节点，第一个数据节点保存数据之后再将块复制到第二个数据节点，后者保存后将其复制到第三个数据节点
• 为什么datanode之间采用pipline线性传输，而不是一次给三个datanode拓扑式传输呢？
• 因为数据以管道的方式，顺序沿着一个方向传输，能够重分利用每个机器的带宽，避免网络瓶颈和高延迟的连接，最小化推送所有数据的延时；
• 在线性推送模式下，每台机器所有的出口宽带都以最快的速度传输数据，而不是再多个接受者之前分配宽带。
  下图为数据通过管道的传输方式：
  
  核心概念：ACK应答相应
• ACK（Acknowledge character）即是确认字符，在数据通信中，接收方发给发送方的一种传输类控制字符。表示发来的数据已确认接收无误。
• 在HDFS pipline管道传输数据的过程中，传输的反方向会进行ACK校验，确保数据传输安全。
  一下为ACK应答示意图：

核心概念：默认3副本存储策略
默认副本策略是BlockPlacementPolicyDefault指定

• 第一块副本：优先客户端本地，否则随机
• 第二块副本：同第一块副本相同机架的不同机器上
• 第三块副本：通第一块副本不同机架的机器上

整完了几个概念，加下来整体描述一下HDFS写数据的流程：
先把流程图贴出来，看图描述

1. HDFS客户端创建对象实例DistributedFileSystem，该对象中封装了与HDFS文件系统操作的相关方法；
2. 调用DistributedFileSystem对象的create方法，通过RPC请求NameNode创建文件。NameNode执行各种检查判断：目标文件是否存在、父目录是否存在、客户端是否具有创建该文件的权限。检查通过，NameNode就会为本次请求记录下一条记录，返回FSDataOutputStream输出流对象给客户端用于写数据，否则文件创建失败并行客户端抛出一个IOException异常。
3. 客户端通过FSDataOutputStream输出流开始写入数据，该对象负责处理namenode和datanode之间的通信；
4. 客户端写入数据时，FSDataOutputStream将数据分成一个个数据包**（packet默认64k），并写入北部队列，称为“数据队列（data queue）”。内部组件DataStreamer处理数据队列，他负责请求NameNode挑选出适合存储数据副本的一组DataNode地址，默认是3副本存储。
   DataStreamer将数据包流式传输到pipeline**的第一个DataNode，该DataNode存储数据包并将它发送到pipeline的第二个DataNode。同样第二个datanode存储该数据并且发送给第三个DataNode上；
5. 输出的反方向上，会通过ACK机制校验数据包传输是否成功，通过DFSOutputStream维护的“确认队列（ACK queue）实现”。收到管道管道中所有datanode确认信息后，该数据包才会从确认队列删除；
6. 客户端完成数据写入后，在FSDataOutputStream输出流上调用close方法关闭；
7. DistributedFileSystem联系NameNode告知其文件写入成功，等待NameNode确认。
   因为NameNode已经知道文件是有哪些块组成（DataStream请求分配数据块），因此仅需要等待最小复制块即可返回成功。
   最小复制是由参数dfs.namenode.replication.min指定，默认为1。
   扩展：如果任何datnode在写入数据期间发生故障会怎样？
   如果发生故障，则执行一下操作（对写入数据的客户端是透明的）：首先关闭pipline，确认把对垒中的所有数据包都添加回数据队列的最前端，以确保故障节点下游的datanode不会漏掉任何一个数据包。为存储在另一正常datanode的当前数据块指定一个新的标识，并将该标识传递给anmenode，以便故障datanode在恢复后可以删除存储的部分数据块。从管线中删除故障datanode，基于两个正常datanode构建一条新管线。余下的数据块写入管线中正常的datanode。namenode注意到块副本量不足时，会在另一个节点上创建一个新的副本。后续的数据块正常接受处理。

HDFS读数据完整流程（下载文件）

读数据完成流程：

1. HDFS客户端创建对象实例DistributedFileSystem，调用对象的open方法来打开希望读取的文件；
2. DistributedFileSystem使用RPC调用namenode来确定文件中前几个块位置（分批次读取）信息。
   对于每个块，namenode返回具有该块所有副本的datanode位置地址列表，并且改地址列表是排序好的，与客户端的网络拓扑举例的排序靠前。
3. DistributedFileSystem将FSDataInputStream输入流返回到客户端以供其读取数据；
4. 客户端在FSDataInputStream输入流上调用read方法。然后已存储DataNode地址的inputStream连接到文件中第一个块的最近DataNode。数据从DataNode流回客户端，结果客户端可以再流上重复调用read；
5. 当该块结束时，FSDataInputStream将关闭与DataNode的连接，然后寻找下一个block块的最佳datanode位置。这些操作对用户来说是透明的。所以用户感觉起来是一直在读取一个连续的流；
6. 一旦客户单完成读取，就对FSDataInputDtream调用close方法。

扩展：如果DFSInoutStream在于datanode通信时遇到错误，会尝试从这个块的另外一个最近datanode读取数据。它也会记住那个故障datanode，以保证以后不会重复读取该节点上后续的块。FSDataInputStream也会通过校验和确认从datanode发来的数据是否完整。如果发现有损坏的块，FSDataInputStream会视图从其他datanode读取其副本，也会将被损坏的块通知给namenode。
这个设计的好处是，客户端可以直接连接到datanode检索数据，且namenode告知客户端每个块所在的最佳datanode。由于数据流分散在集群中的所有datanode，所以这种设计能使HDFS扩展到大量的并发客户端。同时，namenode只需要相应块位置的请求，无需响应数据请求。

Hadoop MaReduce介绍

MapReduce设计思想

MapReduce核心思想是“先分再合，分而治之”
分而治之就是把一个复杂的问题，按照一定的分解方法分为等价的规模较小的若干部分，然后逐个解决，分别找出各部分的结果，然后把各部分的结果组整个问题的最终结果。

MapReduce有两个核心方法：Map、Reduce
Map表示第一阶段，负责拆分：即把负责的任务分解成若干个简单的子任务来并行处理。可以进行拆分的前提是这些小任务可以并行计算，彼此没有任何依赖关系。
Reduce表示第二阶段，负责合并：即对map阶段的结果进行全局汇总
这两个阶段合起来就是MapReduce思想的体现。

MR的抽象编程模型
MapReduce通过Map和Reduce两个函数提供了高层的秉性编程抽象模型。
map：对一组数据元素进行某种重复式处理；
reduce：对map的中间结果进行进一步结果整理。

MapReduce中定义了Map和Reduce两个抽象的编程接口，有用户去编程实现：
map：（k1；v1）->（k2,；v2）
reduce：（k2；[v2]）->（k3；v3）
MapReduce处理的数据类型是**<key,value>键值对**。

阶段组成

• 一个MapReduce编程模型中只能有一个Map阶段和一个Reduce阶段，或者只有Map阶段；
• 不能有多个map阶段、多个reduce阶段的情景出现；
• 如果用户的业务逻辑非常复杂，就只能由多个MapReduce程序串行运行

统一架构、隐层底层细节

• MapReduce设计并提供了统一的计算框架，为程序员隐藏了绝大多数系统层面的处理细节；
• MapReduce亮点在于通过抽象模型和计算框架把需要做什么和具体怎么做分开了，为程序员提供一个抽象和高层的编程接口和框架；
• 程序员仅需要关心其应用层的具体计算问题，仅需要编写少量的处理应用本身计算问题的业务程序代码；
• 置于底层实现，则是交给计算框架去处理：从分布代码执行，到集群的自动调度使用。

分布式计算概念

• 分布式计算是一种计算方法，和集中计算式是相对的。
• 分布式计算将该应用分解成许多小部分，分配给多台计算机进行处理。这样可以节约整体计算时间，大大提高计算效率。

MapReduce介绍

• Hadoop MapReduce是一个分布式计算框架，用于轻松编写分布式应用程序，这些应用程序以可靠、容错的方式并行处理大型硬件集群上的大量数据。
• MapReduce是一种面向海量数据处理的一种指导思想，也是一种用于对大规模进行分布式计算的编程模型。

MapReduce特点

• 易于编程
  MapReduce框架提供了用于二次开发的借口；简单的实现一些接口，就可以完成一个分布式程序。计算任务交给计算框架去处理，将分布式程序部署到hadoop集群上运行，集群节点可扩展到成百上千个等。

• 良好的扩展性
  基于Mapreduce的分布式计算的特点可以随节点数目增长保持近似与线性的增长，能很容易进行节点扩充。

• 高容错
  Hadoop集群是分布式搭建和部署的，任何单一节点宕机了，他可以把上面的计算任务转移到另一个节点上运行，不影响整个作业任务的完成，过程完全由Hadoop内部完成。

• 适合海量数据的离线处理
  可以处理GB、TB和PB级别的数据量。

MapReduce的局限性

• 实时计算性能差
  MapReduce主要用于离线作业，无法做到秒级别或者毫秒级别的数据相应。

• 不能进行流式计算
  流式计算特点是数据时源源不断的计算，并且数据时动态的；而Mapreduce
  作为一个离线计算框架，主要是针对静态数据集的，数据是不能动态变化的。

MapReduce实例进程

一个完整的MapReduce程序分布式运行时有三类：

1. MRAppMaster：负责整个MR程序的过程调度及状态协调；
2. MapTask：负责map阶段的整个数据处理流程；
3. ReduceTask：负责reduce阶段的整个数据处理流程。

MapReduce执行流程

词频统计（WordCount）示例

WordCount编程实现思路

• map阶段的核心：把输入的数据经过切割，全部标记为1，因此输出就是 <单词，1>；

• shuffle阶段核心：经过MR程序内部自带默认的排序分组等功能，把key相同的单词会作为一组数据构成新的kv键值对；

• reduce阶段核心：处理shuffle完的一组数据，改组数据就是该单词所有的键值对。对所有的1进行累计求和，就是单词总次数。
  
  Map阶段执行流程：
  MapReduce整体执行流程图：
  

• 第一阶段：把输入目录下文件按照一定的标准逐个进行逻辑切片，形成切片规划。默认split size = Block size（128M），么个切片由一个MapTask处理；

• 第二阶段：对切片的数据按照一定的规则读取解析返回<K,V>键值对。默认是按行读取数据。key是每一行的起始偏移量，value是本行的本文内容。

• 第三阶段：调用Mapper类中的map方法处理数据。每读取解析出来的一个<k,v>键值对，调用一次map方法；

• 第四阶段：按照一定的规则对Map输出的键值对进行分区partition。默认不分区，因为只有一个reducetask。分区的数量就是reducetask运行的数量；

• 第五阶段：Map输出数据写入内存缓冲区，达到比例溢出到磁盘上。溢出spill的时候根据key进行排序sort。默认根据key字典序排序；

• 第六阶段：对所有溢出文件进行最终merge合并，成为一个文件。
  
  Reduce阶段执行过程

• 第一阶段：ReduceTask主动从MapTask复制拉取属于需要自己处理的数据；

• 第二阶段：把拉取来的数据，全部进行合并merge，即把分散的数据合并成一个大的数据。再对合并后的数据排序；

• 第三阶段：对排序后的键值对调用redue方法。键相等的键值对调用一次reduce方法。最后把这些输出的键值对写入到HDFS文件中。
  
  shuffle阶段
  shuffle概念：

• shuffle翻译洗牌、混洗；

• 而在MR中，shuffle操作指的是将map端的无规则输出按指定规则清洗成具有一定规则的数据，以便reduce端接收处理；

• 一般把从map产生输出开始到reduce取得数据作为输入之前的过程成为shuffle。
  
  Map端shuflle

• Collect阶段：将MapTask的结果收集输出到默认100M的环形缓冲区，保存之前会对key进行分区的计算，默认Hash分区；

• Spill阶段：当内存中的数量达到一定的阈值时（80%），就会将数据溢出（spill）本地磁盘，在将数据写入磁盘之前需要对数据进行一次排序的操作，如果配置了combiner，还会将有相同分区号和key的数据进行排序（写入磁盘之前）。运行conbiner函数是的map输出结果更加紧凑，因此减少减少写到磁盘的数据和传递给reduce的数据。
  在溢出写到磁盘过程中，map会输出继续写到缓冲区，但如果此期间缓冲区被填满，map会被阻塞知道写磁盘过程完成。

• Merge阶段：每次内存缓冲区达到溢出阈值，就会新建一个溢出文件（spill file），把所有溢出的临时文件进行一次合并操作，合并成一个一分区且已排序的输出文件，以确保一个MapTask最终只产生一个中间数据文件。

扩展：在将压缩map输出写到磁盘的过程中对它进行压缩往往是个很好的注意，因为这样会写磁盘的速度更快，节约磁盘空间，并且减少传给reduce的数据量。在默认情况下，输出是不压缩的，但只要将mapreduce.map.output.compress设置为true就可开启此功能。

Reduce端shuffle

• copy阶段：ReduceTask启动Tetcher进程到已经完成MapTask的节点上复制一份属于自己的数据；
  如果map输出相当小，会被复制到reduce任务JVM的内存，否则，map输出被复制到磁盘。一旦内存缓冲区达到阈值大小（有mapreduce.reduce.shuffle.merge.percent决定）或达到map输出阈值（有mapreduce.reduce.merge.inmem.threshold控制），则合并后溢出写到磁盘中。
  扩展：reduce如何知道从哪台机器取得map输出呢？
  map任务完成后，他们会使用心跳机制通知它们的applicationmaster。因此对于指定作业，applicationmaster知道map输出和主机位置的映射关系。reduce中的一个线程定期询问master以便获取map输出主机的位置，知道获取所有输出位置。
  由于第一个reduce可能会失败，因此主机并没有在第一个reduce检测到map输出时就立即从磁盘上删除它们。相反，主机等待机会，知道applicationmaster告知它删除map输出，这就是作业完成后执行的。

• Merge、Sort阶段：在ReduceTask远程复制数据同时，在后台开启两个线程对内存到本地的数据文件进行合并操作，这个阶段将合并map输出，维持其顺序排序。并是循环进行的。比如：如果与50个map输出，而合并因子是10（10为默认设置，有mapreduce.task.io.sort.factor属性设置，与map的合并类似），合并将进行5趟。每趟将10个文件合并成一个文件，因此最后有5个中间文件。
  
  shuffle机制弊端

• shuffle过程中频繁涉及到数据在内存、磁盘之间的往复

shuffle配置调优：
总的原则是给shuffle过程尽量多提供内存空间。然而有一个平衡问题，也就是要确保map函数和reduce函数能够得到足够的内存来运行。
在map端：
在map端可以通过避免多次溢出写磁盘来获得最佳性能；一次是最佳的情况。如果能估算map输出大小，就可以合理的设置mapreduce.task.io.sort.*属性来尽可能减少溢出写的次数。
在reduce端：
在reduce端，中间数据全部驻留在内存时，就能获得最佳性能。在默认情况下这是不能发生的，因为所有内存一般都预留给reduce函数。但如果reduce函数的内存需求不大，把mapreduce.reduce.merge.inmem.threshold设置为0，把mapreduce.reduce.input.buffer.percent设置为1.0（或者更低）就可以提升性能。

Hadoop YARN介绍

• Apache Hadoop YARN （Yet Another Resource
  Negotiator，另一种资源协调者）是一种新的Hadoop资源管理器；

• YARN是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度；

• 它的引入为集群再利用率、资源统一管理和数据共享等方面带来了巨大好处。
  YARN相比MapReduce1的好处：
  1、可扩展性：相比MR1，YARN可以在更大的集群上运行。当节点达到4000，任务数量达到400000时，MapReduce1会遇到可扩展性瓶颈，瓶颈源自于MR1中的jobtracker必须同时管理作业和任务这样一个事实（一个人干两个人的活，任务多了难免忙不过来）。YARN利用其资源管理器和applicationmaster分离的架构优点客服了这个局限性，可以扩展面向奖金10000个节点和100000个任务。
  2、高可用性：当服务守护进行失败时，通过为另一个守护进程复制接管工作所需的状态以便其继续提供服务，从而可以提高可用性（HA、High Availability）
  3、利用率：YARN的资源是精细化管理的，这样一个应用能够按需请求资源，而不是请求一个不可分割的、低于特定的任务而言可能会太大（浪费资源）会太小（资源不够导致任务失败）的slot；
  4、多租户：YARN的最大优点在于向MapReduce以外的其他类型分布式开放了Hadoop。Mapreduce仅仅是许多YARN应用中的一个。
  

YARN的功能

• 资源管理系统：集群的硬件资源，和程序运行相关，比如内存、CPU等；
• **调度平台：**过个程序同时申请计算资源如何分配，调度的规则；
• **通用：**不仅仅支持MR程序，理论上支持各种计算程序。YARN不关心程序要做什么，只关心资源分配，有的分配，用完回收。

YARN架构、组件

官方YARN架构图：

YARN三大组件：

• ResourceManger（RM）：YARN集群中的主角色，决定系统中所有应用程序之间资源分配的最终权限。接收用户的作业提交，并通过NM分配、管理各个机器上的计算资源；
• NodeManger（NM）：YARN的从角色，一台机器上一个，负责**管理本机器上的计算资源。**根据RM命令，启动Container容器、监视容器的资源使用情况。并且向RM主角色汇报资源使用情况；
• ApplicationMaster（AM）：用户提交的每个应用程序均包含一个AM。应用程序内的老大，负责程序内部各个阶段的资源申请，监督程序的执行情况。

YARN交互流程

核心交互流程

• MR作业提交：Client->RM
• 资源申请：MRAppMaster->RM
• MR作业状态汇报：Container（Map|Reduce Task）->Container（MRAppMaster）
• 节点状态汇报NM->RM

交互整体概述
首先，客户端联系资源管理器，要求它运行一个applicationmaster进程，然后资源管理器找到一个能够在容器中启动applicationmaster的节点管理器。application一旦运行起来能做什么依赖于应用本身。有可能实在所处的容器中简单运行一个运算，并将结果返回给客户端；或是向资源管理器请求更多的容器，已用于运算一个分布式计算。
注意：
YARN本身不会为应用的各部分（客户端、master和进程）彼此间通信提供任何手段。大多数重要的YARN应用使用某种形式的远程通信机制（Hadoop的RPC层）来向客户端传递状态更新和返回结果，但是这些通信机制都是专属于各应用的。
MR提交YARN交互流程

1. 用户通过客户端向YARN中ResourceManger提交应用程序；
2. ResourceManger为该应用程序分配第一个Container（容器），并且对应的NodeManger通信，要求他在这个Container中启动这个应用程序的ApplicationMaster；
3. ApplicationMaster启动完成之后，首先先ResourceManger注册并保持通信，这样用户可以直接通过ResourceManger查看应用程序的运行状态（处理进度）；
4. AM为本次程序内部的各个Task任务向RM申请资源，并监控它的运行状态；
5. 一旦ApplicationMaster申请到了资源后，便于对应的NodeManger通信，要求它启动任务；
6. NodeManger为任务设置好运行环境后，将任务启动命令写到一个脚本中，并通过运行脚本启动任务；
7. 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可以随时通过RPC先ApplicationMaster查询应用查询的当前运行状态；
8. 应用程序运行完成后，ApplicationMaster向ResourceManger注销并关闭自己。

YARN资源调度器schedule

理解资源调度

1. 在理想情况下，应用程序提出的请求将立即得到YARN批准。但是实际中，资源是有限的，并且在繁忙的集群上，应用程序通常需要等待某些请求得到满足。YARN调度程序的工作是根据一些定义的策略为程序分配资源；
2. 在YARN中负责给应用分配资源的是schedule，他是ResourceManger的核心组件之一。schedule完全专用于调度作业，他无法跟踪应用程序的状态；

YARN中的几种调度策略

1. FIFO Schedule（先进先出调度器）
2. Capacity Schedule（容量调度器），默认使用的调度器。
3. Fair Schedule（公平调度器）
   调度器的配置：yarn-site.xml中的yarn.resourcemanger.schedule.cass进行配置
   
   FIFO Schedule先进新出调度器
   1、FIFO Schedule是Hadoop1.x中jobTracker原有的调度器实现，此调度器在YARN中保留了下来；
   2、FIFO 是一个先进先出思想，即先提交的应用先运行。调度工作不考虑优先级和范围，适用于负载较低的小规模集群。当使用大型共享集群时，它的效率较低且会导致一些问题。
   3、FIFO Scheduler拥有一个控制全局的队列queue，默认queue名称为default，该调度器会获取当前集群上所有的
   资源信息作用于这个全局的queue
   优势：
   无需配置、先到先得、易于执行。
   劣势：
   任务的优先级不会变高，因此高优先级的作业需要等待，不适合共享集群。
   示意图：
   
   Capacity Schedule容量调度器
4. Capacity Scheduler容量调度是Apache Hadoop2.x默认调度策略。该策略允许多个组织共享整个集群资源，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了
5. Capacity可以理解成一个个的资源队列，这个资源队列是用户自己去分配的。队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略；
6. Capacity Scheduler调度器以队列为单位划分资源。简单通俗点来说，就是一个个队列有独立的资源，队列的结构和资源是可以进行配置的。
7. 这种策略是以整个集群的利用率为代价。这意味大作业执行的时间要长。
   对应配置文件capacity-schedule。xml
   
   
   Capacity Scheduler特性优势
8. 层次化的队列设计（Hierarchical Queues）
   层次化的管理，可以更容易、更合理分配和限制资源的使用。
9. 容量保证（Capacity Guarantees）
   每个队列上都可以设置一个资源的占比，保证每个队列都不会占用整个集群的资源。
10. 安全（Security）
    每个队列有严格的访问控制。用户只能向自己的队列里面提交任务，而且不能修改或者访问其他队列的任务。
11. 弹性分配（Elasticity）
    空闲的资源可以被分配给任何队列。当多个队列出现争用的时候，则会按照权重比例进行平衡。

Fair Schedule公平调度器

1、Fair Schedule公平调度器，提供了YARN应用程序公平地分享大型集群中资源的另一种方式。使用所有应用在平均情况下随着时间的流逝可以获得相等的资源份额；
2、设计目标是为了所有的应用分配公平的资源；
3、公平调度可以在多个队队列间工作，允许资源共享和抢占。

公平共享的理解

• 有两个用户A和B，每个用户都有自己的队列；
• A启动一个作业，由于没有B的需求，它分配了集群所有可用的资源；
• 然后B在A的作业仍在运行时启动了一个作业，经过一段时间（并非立即生效）从第二个作业的启动到获得公平共享资源之间会有时间滞后，因为他必须等待第一个作业使用的容器用完并释放出资源。，A,B各自作业都使用了一半的资源；
• 现在，如果B用户在其他作业仍在运行时开始第二个作业，它将与B的另一个作业共享其资源，因此B的每个作业将拥有资源的四分之一，而A的继续将拥有一半的资源。结果是资源在用户之间公平地共享。
  
  Fair Schedule特征优势
  1、分层队列：队列可以按层次结构排列以划分资源，并可以配置权重以按特定比例共享集群；
  2、基于用户或组的队列映射：可以根据提交任务的用户名或组来分配队列。如果任务指定了一个队列,则在该队列中提交任务；
  3、**资源抢占：**根据应用的配置，抢占和分配资源可以是友好的或是强制的。默认不启用资源抢占；
  4、保证最小配额：可以设置队列最小资源，允许将保证的最小份额分配给队列，保证用户可以启动任务。当队列不能满足最小资源时,可以从其它队列抢占。当队列资源使用不完时,可以给其它队列使用。这对于确保某些用户、组或生产应用始终获得足够的资源。
  5、**允许资源共享：**即当一个应用运行时,如果其它队列没有任务执行,则可以使用其它队列,当其它队列有应用需要资源时再将占用的队列释放出来。所有的应用都从资源队列中分配资源；
  6、默认不限制每个队列和用户可以同时运行应用的数量。可以配置来限制队列和用户并行执行的应用数量。限制并行执行应用数量不会导致任务提交失败,超出的应用会在队列中等待。
  延迟调度策略：
  扩展：所有的YARN调度器都是土以本地请求为主。在一个繁忙的集群上，如果一个应用请求某个节点，那么极有可能此时有其他容器正在该节点上运行。显而易见的处理是，放宽本地性需求，在同一机架中分配一个容器。然而，通过实践发现，此时如果等待一小段时间（几秒钟），能够戏剧性增加在青丘的节点上分配到一个容器的机会，从而提高及去哪的效率。这个特性称之为延迟调度（delay scheduling）。容量调度器和公平调度器都支持延迟调度。

以上内容只是Hadoop中一部分，此后会持续填充相关知识。
未完待续~
点个赞吧~~