Hadhoop生态（Hadoop）_hadoop生态
Hadhoop生态（Hadoop）
- 一、Hadoop环境搭建与简介
-
- 1． Hadoop介绍
- 2． Hadoop特性优点
- 3． 集群简介
- 4． Hadoop安装包目录结构
- 5． Hadoop安装部署
- 6． Hadoop集群启动、处体验
-
- 6.1. 启动方式
- 6.1.1. 单节点逐个启动
- 6.1.2. 脚本一键启动
- 6.2. 集群web-ui
- 6.3. Hadoop初体验
-
- 6.3.1. HDFS 使用
- 6.3.2． 运行mapreduce程序
- 6.4. Hadoop辅助功能 MapReduce jobHistory
- 6.5. HDFS 的垃圾桶机制
-
- 6.5.1． 垃圾桶机制解析
- 6.5.2．垃圾桶机制配置
- 6.5.3．垃圾桶机制验证
- 二、Hadoop HDFS
-
- 1. HDFS基本概念
-
- 1.1. HDFS 介绍
- 1.2. HDFS 设计目标
- 2. HDFS重要特性
-
- 分布式存储的优点
- 元数据记录的功能
- 分块存储的好处
- 副本机制的好处
- 2.1. master/slave 架构
- 2.2. 分块存储
- 2.3. 名字空间（NameSpace）
- 2.4. Namenode 元数据管理
- 2.5. Datanode 数据存储
- 2.6. 副本机制
- 2.7. 一次写入，多次读出
- 3. HDFS 基本操作
-
- 3.1 Shell 命令行客户端
- 3.2. Shell 命令选项
- 3.3. Shell 常用命令介绍
- 3. HDFS基本原理
-
- 3.1. NameNode概述
- 3.2. DataNode概述
- 3.3. HDFS的工作机制
-
- 3.3.1. HDFS 写数据流程
- 3.3.2. HDFS 读数据流程
- 4. HDFS 安全模式
-
- 4.1. 安全模式概述
- 4.2. 安全模式配置
- 4.3. 安全模式命令
- 5. HDFS 元数据管理机制
-
- 5.1. 元数据管理概述
- 5.2. 元数据目录相关文件
- 5.3. 内容查看
- 6. SecondaryNameNode
-
- 6.1. CheckPoint 机制
- 6.1. CheckPoint 触发条件
- 7. 不同集群之间的数据复制
- 8. Archive 档案
-
- 8.1. 如何创建Archive
- 8.2. 如何查看Archive
- 三、Hadoop MapReduce
-
- 1. MapReduce 简介
-
- 1.1. 理解MapReduce思想
- 1.2. Hadoop MapReduce 设计构思
- 2. 官方MapReduce示例
-
- 2.1. 示例1：评估圆周率π（PI）
- 2.2. 示例2：单词词频统计WordCount
- 3. MapReduce Python 接口接入
- 4. MapReduce基本原理
-
- 4.1. Map阶段执行流程
- 4.2. Reduce阶段执行流程
- 4.3. Shuffle 机制
- Hadoop Yarn
-
- 1. Yarn 简介
- 2. Yarn三大组件介绍
-
- 2.1. ResourceManager
- 2.2. NodeManager
- 2.3. ApplicationMaster
- 3. Yarn运行流程
- 4. Yarn 调度器Scheduler
-
- 4.1. FIFO Scheduler
- 4.2. Capacity Scheduler(默认的调度)
- 4.3. Fair Scheduler
- Hadoop High Availability（HA）
-
- 1. Namenode HA
- 2. Yarn HA
一、Hadoop环境搭建与简介
1． Hadoop介绍
Hadoop 是 Apache 旗下的一个用 java 语言实现开源软件框架，是一个开发和运行处理大规模数据的软件平台。允许使用简单的编程模型在大量计算机集群上对大型数据集进行分布式处理。
狭义上说，Hadoop指Apache这款开源框架，它的核心组件有：
- HDFS（分布式文件系统）：解决海量数据存储
- YARN（作业调度和集群资源管理的框架）：解决资源任务调度
- MAPREDUCE（分布式运算编程框架）：解决海量数据计算
广义上来说，Hadoop通常是指一个更广泛的概念——Hadoop生态圈。
2． Hadoop特性优点
扩容能力（Scalable）：Hadoop是在可用的计算机集群间分配数据并完成计算任务的，这些集群可用方便的扩展到数以千计的节点中。
成本低（Economical）：Hadoop 通过普通廉价的机器组成服务器集群来分发以及处理数据，以至于成本很低。
高效率（Efficient）：通过并发数据，Hadoop可以在节点之间动态并行的移动数据，使得速度非常快。
可靠性（Rellable）：能自动维护数据的多份复制，并且在任务失败后能自动地重新部署（redeploy）计算任务。所以Hadoop的按位存储和处理数据的能力值得人们信赖。
3． 集群简介
HADOOP 集群具体来说包含两个集群：HDFS集群和YARN集群，两者逻辑上分离，但物理上常在一起。
HDFS 集群负责海量数据的存储，集群中的角色主要有：
NameNode、DataNode、SecondaryNameNode
YARN 集群负责海量数据运算时的资源调度，集群中的角色主要有：
ResourceManager、NodeManager
整个Hadoop集群就是：
datanode跟nodemanager是好基友
那mapreduce 是什么呢？它其实是一个分布式运算编程框架，是应用程序开发包，由用户按照编程规范进行程序开发，后打包运行在HDFS集群上，并且受到YARN集群的资源调度管理。（根本就没有mapreduce集群的说法，本质是代码）
Hadoop 部署方式分三种，Standalone mode（独立模式）、Pseudo-Distributed mode（伪分布式模式）、Cluster mode（群集模式），其中前两种都是在单机部署。
独立模式又称为单机模式，仅1个机器运行1个java进程，主要用于调试。
伪分布模式也是在1个机器上运行HDFS的NameNode和DataNode、YARN的 ResourceManger 和 NodeManager，但分别启动单独的java进程，主要用于调试。
集群模式主要用于生产环境部署。会使用N台主机组成一个Hadoop集群。这种部署模式下，主节点和从节点会分开部署在不同的机器上。
补充：高可用集群HA ，在分布式模式下给主角色设置备份角色，实现了容错的功能，解决了单点故障，保证集群持续可用性。
4． Hadoop安装包目录结构
https://archive.apache.org/dist/
Hadoop 官方一般都给出了对应版本安装包，一般情况下是不需要自己进行编译的，但是由于官方编译好的hadoop的安装包没有提供带C程序访问的接口，所以在使用本地库（本地库可以用来做压缩，以及支持C程序等等）的时候就会出问题，因此生产环境中，一般会重新编译。
解压hadoop-3.3.0-Centos7-64-with-snappy.tar.gz，目录结构如下：
bin：Hadoop 最基本的管理脚本和使用脚本的目录，这些脚本是 sbin 目录下管理脚本的基础实现，用户可以直接使用这些脚本管理和使用Hadoop。
etc：Hadoop 配置文件所在的目录，包括core-site,xml、hdfs-site.xml、mapred-site.xml 等从 Hadoop1.0 继承而来的配置文件和 yarn-site.xml 等Hadoop2.0 新增的配置文件。
include：对外提供的编程库头文件（具体动态库和静态库在lib目录中），这些头文件均是用C++定义的，通常用于C++程序访问HDFS或者编写MapReduce程序。
lib：该目录包含了Hadoop对外提供的编程动态库和静态库，与include目录中的头文件结合使用。
libexec：各个服务对用的shell 配置文件所在的目录，可用于配置日志输出、启动参数（比如JVM参数）等基本信息。
sbin：Hadoop 管理脚本所在的目录，主要包含HDFS 和YARN 中各类服务的启动/关闭脚本。
share：Hadoop 各个模块编译后的jar包所在的目录，官方自带示例。
5． Hadoop安装部署
基础环境准备：
…
6． Hadoop集群启动、处体验
6.1. 启动方式
要启动Hadoop集群，需要启动HDFS和YARN两个集群。
注意：首次启动HDFS时，必须对其进行格式化(初始化)操作。本质上是一些清理和准备工作，因为此时的HDFS在物理上还是不存在的。
hadoop namenode -format6.1.1. 单节点逐个启动
在主节点上使用以下命令启动HDFS NameNode：
$HADOOP_HOME/bin/hdfs --daemon start namenode
在每个从节点上使用以下命令启动HDFS DataNode：
$HADOOP_HOME/bin/hdfs --daemon start datanode
在node2上使用以下命令启动HDFS SecondaryNameNode：
$HADOOP_HOME/bin/hdfs --daemon start secondarynamenode
在主节点上使用以下命令启动YARN ResourceManager：
$HADOOP_HOME/bin/yarn --daemon start resourcemanager
在每个从节点上使用以下命令启动YARN nodemanager：
$HADOOP_HOME/bin/yarn --daemon start nodemanager
如果想要停止某个节点上某个角色，只需要把命令中的start改为stop即可。
优点：精准的控制每个角色每个进程的启停，避免群起群停（时间成本）。
6.1.2. 脚本一键启动
前提：设置好ssh免密登录。
如果配置了etc/hadoop/workers 和 ssh 免密登录，则可以使用程序脚本启动所有Hadoop两个集群的相关进程，在主节点所设定的机器上执行。
hdfs：$HADOOP_PREFIX/sbin/start-dfs.sh
yarn: $HADOOP_PREFIX/sbin/start-yarn.sh
停止集群：stop-dfs.sh、stop-yarn.sh
或者更暴力：start/stop-all.sh
6.2. 集群web-ui
一旦Hadoop 集群启动并运行，可以通过web-ui进行集群查看，如下所述：
NameNode http://nn_host:port/ 默认 9870.
ResourceManager http://rm_host:port/ 默认 8088.
6.3. Hadoop初体验
6.3.1. HDFS 使用
从Linux 本地上传一个文本文件到hdfs的/test/input目录下
hadoop fs -mkdir -p /wordcount/input hadoop fs -put /root/somewords.txt /test/input 
6.3.2． 运行mapreduce程序
在Hadoop安装包的share/hadoop/mapreduce下有官方自带的mapreduce程序。我们可以使用如下的命令进行运行测试。
计算圆周率:
hadoop jar hadoop-mapreduce-examples-3.3.0.jar pi 20 50 关于圆周率的估算，感兴趣的可以查询资料Monte Carlo方法来计算Pi值。
6.4. Hadoop辅助功能 MapReduce jobHistory
JobHistory 用来记录已经finished的mapreduce运行日志，日志信息存放于HDFS目录中，默认情况下没有开启此功能，需要在mapred-site.xml中配置并手动启动。
6.5. HDFS 的垃圾桶机制
6.5.1． 垃圾桶机制解析
每一个文件系统都会有垃圾桶机制，便于将删除的数据回收到垃圾桶里面去，避免某些误操作删除一些重要文件。回收到垃圾桶里里面的资料数据，都可以进行恢复。
6.5.2．垃圾桶机制配置
HDFS 的垃圾回收的默认配置属性为 0，也就是说，如果你不小心误删除了某样东西，那么这个操作是不可恢复的。
6.5.3．垃圾桶机制验证
如果启用垃圾箱配置，dfs命令删除的文件不会立即从HDFS中删除。相反，HDFS 将其移动到垃圾目录（每个用户在/user//.Trash下都有自己的垃圾目录）。只要文件保留在垃圾箱中，文件可以快速恢复。
[root@node1 hadoop]# hadoop fs -rm /zmx/1.txt2025-04-04 13:27:38,060 INFO fs.TrashPolicyDefault: Moved: \'hdfs://node1:8020/zmx/1.txt\' to trash at: hdfs://node1:8020/user/root/.Trash/Current/zmx/1.txt使用 skipTrash 选项删除文件，该选项不会将文件发送到垃圾箱。它将从HDFS 中完全删除。
二、Hadoop HDFS
1. HDFS基本概念
1.1. HDFS 介绍
HDFS 是Hadoop Distribute File System 的简称，意为：Hadoop 分布式文件系统。是Hadoop核心组件之一，作为最底层的分布式存储服务而存在。
分布式文件系统解决的问题就是大数据存储。它们是横跨在多台计算机上的存储系统。分布式文件系统在大数据时代有着广泛的应用前景，它们为存储和处理超大规模数据提供所需的扩展能力。
1.2. HDFS 设计目标
- 硬件故障是常态， HDFS将有成百上千的服务器组成，每一个组成部分都有可能出现故障。因此故障的检测和自动快速恢复是HDFS的核心架构目标。
- HDFS 上的应用与一般的应用不同，它们主要是以流式读取数据。HDFS 被设计成适合批量处理，而不是用户交互式的。相较于数据访问的反应时间，更注重数据访问的高吞吐量。
- 典型的HDFS文件大小是GB到TB的级别。所以，HDFS被调整成支持大文件。它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件。
- 大部分HDFS 应用对文件要求的是
write-one-read-many访问模型。一个文件一旦创建、写入、关闭之后就不需要修改了。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。 - 移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好。
- 在异构的硬件和软件平台上的可移植性。这将推动需要大数据集的应用更广泛地采用HDFS作为平台。
2. HDFS重要特性
首先，它是一个文件系统，用于存储文件，通过统一的命名空间目录树来定位文件；
其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。
一个成熟的分布式文件系统的属性功能：
- 分布式多台机器存储
- 记录元数据
- 分块存储
- 副本机制（备份）
分布式存储的优点
- 问题：数据量大，单机存储遇到瓶颈
- 解决：
- 单机纵向扩展：加磁盘，有上限
- 多机横向扩展：加机器，理论上无上限
元数据记录的功能
- 问题：文件分布在不同机器上不利于寻找
- 解决：元数据记录下文件及其存储位置信息，快速定位文件位置
分块存储的好处
- 问题：文件过大导致单机存不下、上传下载效率低
- 解决：文件分块存储在不同机器，针对块并行操作提高效率
副本机制的好处
- 问题： 硬件故障难免避免，数据容易丢失
- 解决：不同机器设置备份，冗余存储，保障数据安全
2.1. master/slave 架构
HDFS 采用master/slave 架构。一般一个HDFS集群是有一个Namenode和一定数目的Datanode组成。
Namenode 是 HDFS 集群主节点，Datanode 是HDFS 集群从节点，两种角色各司其职，共同协调完成分布式的文件存储服务。
2.2. 分块存储
HDFS 中的文件在物理上是分块存储（block）的，块的大小可以通过配置参数来规定，默认大小在hadoop2.x版本中是128M。
2.3. 名字空间（NameSpace）
HDFS 支持传统的层次型文件组织结构。用户或者应用程序可以创建目录，然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似：用户可以创建、删除、移动或重命名文件。
Namenode 负责维护文件系统的名字空间，任何对文件系统名字空间或属性的修改都将被Namenode记录下来。
HDFS 会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件，
形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。
2.4. Namenode 元数据管理
我们把目录结构及文件分块位置信息叫做元数据。Namenode 负责维护整个hdfs 文件系统的目录树结构，以及每一个文件所对应的block块信息（block的id，及所在的datanode服务器）。
2.5. Datanode 数据存储
文件的各个block的具体存储管理由datanode节点承担。每一个block都可以在多个datanode上。Datanode需要定时向Namenode汇报自己持有的block信息。
2.6. 副本机制
为了容错，文件的所有block都会有副本。每个文件的block大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定，也可以在之后改变。
副本数量也可以通过参数设置dfs.replication，默认是3。
2.7. 一次写入，多次读出
HDFS 是设计成适应一次写入，多次读出的场景，且不支持文件的修改。
正因为如此，HDFS 适合用来做大数据分析的底层存储服务，并不适合用来做.网盘等应用，因为，修改不方便，延迟大，网络开销大，成本太高。
3. HDFS 基本操作
3.1 Shell 命令行客户端
Hadoop 提供了文件系统的shell命令行客户端，使用方法如下：
hadoop fs 文件系统shell包括与Hadoop分布式文件系统（HDFS）以及Hadoop支持的其他文件系统（如本地FS，HFTP FS，S3 FS等）直接交互的各种类似shell的命令。所有FS shell命令都将路径URI作为参数。
URI 格式为scheme://authority/path。对于 HDFS，该scheme 是hdfs，对于本地FS，该scheme是file。scheme和authority是可选的。如果未指定，则使用配置中指定的默认方案，默认是本地文件。
-
对于HDFS,命令示例如下：
hadoop fs -ls hdfs://namenode:host/parent/childhadoop fs -ls /parent/child -
对于本地文件系统，命令示例如下：
hadoop fs -ls file:///root/
如果使用的文件系统是HDFS，则使用hdfs dfs也是可以的，此时
hadoop fs = hdfs dfs 3.2. Shell 命令选项
3.3. Shell 常用命令介绍
-ls使用方法：hadoop fs -ls [-h] [-R] (args)
功能：显示文件、目录信息。
示例：hadoop fs -ls /user/hadoop/file1
-mkdir 使用方法：hadoop fs -mkdir [-p] (paths)
功能：在hdfs上创建目录，-p表示会创建路径中的各级父目录。
示例：hadoop fs -mkdir –p /user/hadoop/dir1
-put 使用方法：hadoop fs -put [-f] [-p] [ -|(localsrc1) … ]. (dst)
功能：将单个src或多个srcs从本地文件系统复制到目标文件系统。 -p：保留访问和修改时间，所有权和权限。 -f：覆盖目的地（如果已经存在）
示例：hadoop fs -put -f localfile1 localfile2 /user/hadoop/hadoopdir
-get 使用方法：hadoop fs -get [-ignorecrc] [-crc] [-p] [-f] (src)(localdst)
-ignorecrc：跳过对下载文件的CRC检查。
-crc：为下载的文件写CRC校验和。
功能：将文件复制到本地文件系统。
示例：hadoop fs -get hdfs://host:port/user/hadoop/file localfile
-appendToFile 使用方法：hadoop fs -appendToFile (localsrc) … (dst)
功能：追加一个文件到已经存在的文件末尾
示例：hadoop fs -appendToFile localfile /hadoop/hadoopfile
-cat使用方法：hadoop fs -cat [-ignoreCrc] URI [URI …]
功能：显示文件内容到stdout
示例：hadoop fs -cat /hadoop/hadoopfile
-tail 使用方法：hadoop fs -tail [-f] URI
功能：将文件的最后一千字节内容显示到stdout。 -f 选项将在文件增长时输出附加数据。
示例：hadoop fs -tail /hadoop/hadoopfile
-chgrp 功能：改变文件的权限。使用-R将使改变在目录结构下递归进行。
示例：hadoop fs -chmod 666 /hadoop/hadoopfile
-chown功能：改变文件的拥有者。使用-R将使改变在目录结构下递归进行。
示例：hadoop fs -chown someuser:somegrp /hadoop/hadoopfile
-cp功能：从hdfs的一个路径拷贝hdfs的另一个路径
示例： hadoop fs -cp /aaa/jdk.tar.gz /bbb/jdk.tar.gz.2
-mv 功能：在hdfs目录中移动文件
示例： hadoop fs -mv /aaa/jdk.tar.gz /
-getmerge 功能：合并下载多个文件
示例：比如hdfs的目录 /aaa/下有多个文件:log.1, log.2,log.3,… hadoop fs -getmerge /aaa/log.* ./log.sum
-rm功能：删除指定的文件。只删除非空目录和文件。-r 递归删除。
示例：hadoop fs -rm -r /aaa/bbb/
-df 功能：统计文件系统的可用空间信息
示例：hadoop fs -df -h /
-du 功能：显示目录中所有文件大小，当只指定一个文件时，显示此文件的大小。
示例：hadoop fs -du /user/hadoop/dir1
-setrep 功能：改变一个文件的副本系数。-R 选项用于递归改变目录下所有文件的副本
系数。
示例：hadoop fs -setrep -w 3 -R /user/hadoop/dir1
3. HDFS基本原理
3.1. NameNode概述
- NameNode 是HDFS 的核心。
- NameNode 也称为Master。
- NameNode 仅存储 HDFS 的元数据：文件系统中所有文件的目录树，并跟踪整个集群中的文件。
- NameNode 不存储实际数据或数据集。数据本身实际存储在DataNodes中。
- NameNode 知道 HDFS 中任何给定文件的块列表及其位置。使用此信息NameNode 知道如何从块中构建文件。
- NameNode 并不持久化存储每个文件中各个块所在的DataNode的位置信息，这些信息会在系统启动时从数据节点重建。
- NameNode 对于HDFS至关重要，当NameNode关闭时，HDFS / Hadoop集群无法访问。
- NameNode 是Hadoop 集群中的单点故障。
- NameNode 所在机器通常会配置有大量内存（RAM）。
3.2. DataNode概述
- DataNode 负责将实际数据存储在HDFS中。
- DataNode 也称为Slave。
- NameNode 和DataNode 会保持不断通信。
- DataNode 启动时，它将自己发布到NameNode并汇报自己负责持有的块列表。
- 当某个DataNode 关闭时，它不会影响数据或群集的可用性。NameNode将安排由其他DataNode管理的块进行副本复制。
- DataNode 所在机器通常配置有大量的硬盘空间。因为实际数据存储在DataNode 中。
- DataNode 会定期（dfs.heartbeat.interval 配置项配置，默认是 3 秒）向NameNode 发送心跳，如果 NameNode 长时间没有接受到 DataNode 发送的心跳， NameNode就会认为该DataNode失效。
- block 汇报时间间隔取参数 dfs.blockreport.intervalMsec,参数未配置的话默认为6小时.
3.3. HDFS的工作机制
NameNode 负责管理整个文件系统元数据；DataNode 负责管理具体文件数据块存储；Secondary NameNode 协助NameNode 进行元数据的备份。
HDFS 的内部工作机制对客户端保持透明，客户端请求访问HDFS都是通过向NameNode 申请来进行。
3.3.1. HDFS 写数据流程
详细步骤解析：
- client 发起文件上传请求，通过RPC与NameNode 建立通讯，Nam
- 、eNode检查目标文件是否已存在，父目录是否存在，返回是否可以上传；
- client 请求第一个 block该传输到哪些DataNode服务器上；
- NameNode 根据配置文件中指定的备份数量及副本放置策略进行文件分配，返回可用的DataNode的地址，如：A，B，C；
注：默认存储策略由BlockPlacementPolicyDefault 类支持。也就是日常生活中提到最经典的3副本策略。
1st replica 如果写请求方所在机器是其中一个datanode,则直接存放在本地,否则随机在集群中选择一个datanode.
2nd replica 第二个副本存放于不同第一个副本的所在的机架.
3rd replica 第三个副本存放于第二个副本所在的机架,但是属于不同的节点
- client 请求 3 台DataNode 中的一台A上传数据（本质上是一个RPC调用，建立pipeline）， A收到请求会继续调用B，然后B调用C，将整个pipeline 建立完成，后逐级返回client；
- client 开始往A上传第一个block（先从磁盘读取数据放到一个本地内 存缓存），以packet为单位（默认64K），A收到一个packet就会传给B，B 传给C；A每传一个packet会放入一个应答队列等待应答。
- 数据被分割成一个个 packet 数据包在 pipeline 上依次传输，在pipeline 反方向上，逐个发送 ack（命令正确应答），最终由 pipeline中第一个DataNode节点A将pipeline ack发送给client;
- 当一个 block 传输完成之后，client 再次请求 NameNode 上传第二个block 到服务器。
3.3.2. HDFS 读数据流程
详细步骤解析：
- Client向NameNode发起RPC请求，来确定请求文件block所在的位置； NameNode 都会返回含有该block副本的DataNode地址；
- NameNode会视情况返回文件的部分或者全部block列表，对于每个block，
- 这些返回的DN地址，会按照集群拓扑结构得出DataNode与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离Client近的排靠前；心跳机制中超时汇报的DN状态为STALE，这样的排靠后；
- Client 选取排序靠前的 DataNode 来读取 block，如果客户端本身就是DataNode,那么将从本地直接获取数据；
- 底层上本质是建立 FSDataInputStream ， 重 复 的 调 用 父 类
DataInputStream 的 read 方法，直到这个块上的数据读取完毕；一旦到达块的末尾，DFSInputStream 关闭连接并继续定位下一个块的下一个 DataNode； - 当读完列表的 block 后，若文件读取还没有结束，客户端会继续向NameNode 获取下一批的block列表；一旦客户端完成读取，它就会调用 close() 方法。
- 读取完一个block都会进行checksum验证，如果读取DataNode时出现错误，客户端会通知 NameNode，然后再从下一个拥有该 block 副本的DataNode 继续读。
- NameNode 只是返回Client请求包含块的DataNode地址，并不是返回请求块的数据；
- 最终读取来所有的block会合并成一个完整的最终文件。
4. HDFS 安全模式
安全模式的注意事项：
- 刚启动完集群之后，要等安全模式结束才可以正常使用文件系统
- 后续如果某些软件依赖HDFS工作，必须先启动HDFS且等安全模式结束才可以使用你的软件
4.1. 安全模式概述
安全模式是HDFS所处的一种特殊状态，在这种状态下，文件系统只接受读数据请求，而不接受删除、修改等变更请求，是一种保护机制，用于保证集群中的数据块的安全性。
在NameNode主节点启动时，HDFS首先进入安全模式，集群会开始检查数据块的完整性。DataNode 在启动的时候会向 namenode 汇报可用的 block 信息，当整个系统达到安全标准
时，HDFS自动离开安全模式。
假设我们设置的副本数（即参数dfs.replication）是 5，那么在Datanode上就应该有5 个副本存在，假设只存在3个副本，那么比例就是3/5=0.6。在配置文件hdfs-default.xml中定义了一个最小的副本的副本率（即参数dfs.namenode.safemode.threshold-pct）0.999。 我们的副本率0.6 明显小于 0.99，因此系统会自动的复制副本到其他的 DataNode,使得副本率不小于0.999.如果系统中有8个副本，超过我们设定的5个副本，那么系统也会
删除多余的3个副本。
如果HDFS处于安全模式下，不允许HDFS客户端进行任何修改文件的操作,包括上传文件，删除文件，重命名，创建文件夹,修改副本数等操作。
4.2. 安全模式配置
与安全模式相关主要配置在hdfs-site.xml文件中，主要有下面几个属性:
dfs.namenode.replication.min: 每个数据块最小副本数量，默认为1. 在上传文件时，达到最小副本数，就认为上传是成功的。
dfs.namenode.safemode.threshold-pct: 达到最小副本数的数据块的百分比。默认为0.999f。当小于这个比例，那就将系统切换成安全模式，对数据块进行复制；当大于该比例时，就离开安全模式，说明系统有足够的数据块副本数，可以对外提供服务。小于等于0意味不进入安全模式，大于1意味一直处于安全模式。
dfs.namenode.safemode.min.datanodes: 离开安全模式的最小可用 datanode 数量要求，默认为0.也就是即使所有datanode都不可用，仍然可以离开安全模式。
dfs.namenode.safemode.extension: 当集群可用 block 比例，可用 datanode 都达到要求之后，如果在 extension 配置的时间段之后依然能满足要求，此时集群才离开安全模式。单位为毫秒，默认为30000.也就是当满足条件并且能够维持30秒之后，离开安全模式。 这个配置主要是对集群稳定程度做进一步的确认。避免达到要求后马上又不符合安全标准。
总结一下，要离开安全模式，需要满足以下条件：
- 达到副本数量要求的block比例满足要求；
- 可用的datanode节点数满足配置的数量要求；
- 1、2 两个条件满足后维持的时间达到配置的要求
4.3. 安全模式命令
手动进入安全模式
hdfs dfsadmin -safemode enter手动进入安全模式对于集群维护或者升级的时候非常有用，因为这时候HDFS上的数据是只读的。手动退出安全模式可以用下面命令：
hdfs dfsadmin -safemode leave5. HDFS 元数据管理机制
5.1. 元数据管理概述
HDFS 元数据，按类型分，主要包括以下几个部分：
- 文件、目录自身的属性信息，例如文件名，目录名，修改信息等。
- 文件记录的信息的存储相关的信息，例如存储块信息，分块情况，副本个数等。
- 记录HDFS的Datanode的信息，用于DataNode的管理。
按形式分为内存元数据和元数据文件两种，分别存在内存和磁盘上。
HDFS 磁盘上元数据文件分为两类，用于持久化存储：
fsimage 镜像文件：是元数据的一个持久化的检查点，包含Hadoop文件系统中的所有目录和文件元数据信息，但不包含文件块位置的信息。文件块位置信息只存储在内存中，是在 datanode 加入集群的时候，namenode询问datanode得到的，并且间断的更新。
Edits 编辑日志：存放的是Hadoop文件系统的所有更改操作（文件创建，删除或修改）的日志，文件系统客户端执行的更改操作首先会被记录到edits文件中。
fsimage 和 edits 文件都是经过序列化的，在 NameNode 启动的时候，它会将 fsimage文件中的内容加载到内存中，之后再执行edits文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作，也是最完整的元数据。
当客户端对HDFS中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存元数据中。因为fsimage文件一般都很大（GB级别的很常见），如果所有的更新操作都往fsimage文件中添加，这样会导致系统运行的十分缓慢。
HDFS 这种设计实现着手于：
一是内存中数据更新、查询快，极大缩短了操作响应时间；
二是内存中元数据丢失风险颇高（断电等），因此辅佐元数据镜像文件（fsimage）+编辑日志文件（edits）的备份机制进行确保元数据的安全。
NameNode 维护整个文件系统元数据。因此，元数据的准确管理，影响着HDFS提供文件
存储服务的能力。
5.2. 元数据目录相关文件
cd /export/data/hadoop-3.3.0/dfs/name/current
seen_txid：非常重要，是存放 transactionId 的文件，format 之后是0，它代表的是namenode里面的edits_*文件的尾数，namenode重启的时候，会按照seen_txid 的数字，循序从头跑edits_0000001~到 seen_txid 的数字。所以当你的hdfs发生异常重启的时候，一定要比对seen_txid内的数字是不是你edits最后的尾数。
5.3. 内容查看
fsimage、edits 两个文件中的内容(二进制)使用普通文本编辑器是无法直接查看的，幸运的是hadoop为此准备了专门的工具用于查看文件的内容，这些工具分别为oev 和oiv，可以使用hdfs调用执行。
hdfs oev -i edits_0000000000000000383-0000000000000000394 -o edits.xml-i ：目标文件
-o ：输出文件
# 下载到本地查看sz edits.xml
6. SecondaryNameNode
6.1. CheckPoint 机制
每达到触发条件，会由secondary namenode 将 namenode 上积累的所有 edits 和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint），如下图所示：
Checkpoint 详细步骤：
- NameNode 管理着元数据信息，其中有两类持久化元数据文件：edits 操作日志文件和fsimage 元数据镜像文件。新的操作日志不会立即与 fsimage 进行合并，也不会刷到NameNode 的内存中，而是会先写到 edits 中(因为合并需要消耗大量的资源)，操作成功之后更新至内存。
- 有dfs.namenode.checkpoint.period 和 dfs.namenode.checkpoint.txns 两个配置，只要达到这两个条件任何一个，secondarynamenode就会执行checkpoint的操作。
- 当触发checkpoint操作时，NameNode会生成一个新的edits即上图中的edits.new文件，同时SecondaryNameNode 会将edits文件和fsimage复制到本地（HTTP GET方式）。
- secondarynamenode 将下载下来的fsimage载入到内存，然后一条一条地执行edits文件中的各项更新操作，使得内存中的fsimage保存最新，这个过程就是edits和fsimage文件合并，生成一个新的fsimage文件即上图中的Fsimage.ckpt文件。
- secondarynamenode 将新生成的Fsimage.ckpt文件复制到NameNode节点。
- 在NameNode 节点的edits.new 文件和 Fsimage.ckpt 文件会替换掉原来的 edits 文件和fsimage 文件，至此刚好是一个轮回，即在NameNode中又是edits和fsimage文件。
- 等待下一次checkpoint触发SecondaryNameNode进行工作，一直这样循环操作。
6.1. CheckPoint 触发条件
Checkpoint 操作受两个参数控制，可以通过core-site.xml进行配置：
dfs.namenode.checkpoint.period 3600 两次连续的checkpoint之间的时间间隔。默认1小时 dfs.namenode.checkpoint.txns 1000000 尚未达到检查点周期。默认设置为100万。 最大的没有执行checkpoint事务的数量，满足将强制执行紧急checkpoint，即使从上面的描述我们可以看出，SecondaryNamenode 根本就不是 Namenode 的一个热备，
其只是将fsimage和edits合并。其拥有的fsimage不是最新的，因为在他从NameNode下载fsimage 和edits文件时候，新的更新操作已经写到edit.new文件中去了。而这些更新在SecondaryNamenode 是没有同步到的！当然，如果NameNode中的fsimage真的出问题了，还是可以用SecondaryNamenode 中的fsimage 替换一下NameNode上的fsimage，虽然已经不是最新的fsimage，但是我们可以将损失减小到最少！
7. 不同集群之间的数据复制
cp：同机器
scp：用集群
distcp：远程拷贝
hadoop distcp hdfs://node1:8020/1.txt hdfs://node5:8020/2.txt8. Archive 档案
HDFS 并不擅长存储小文件，因为每个文件最少一个block，每个block的元数据都会在NameNode占用内存，如果存在大量的小文件，它们会吃掉NameNode 节点的大量内存。
Hadoop Archives 可以有效的处理以上问题，它可以把多个文件归档成为一个文件，归档成一个文件后还可以透明的访问每一个文件。
8.1. 如何创建Archive
hadoop archive -archiveName name -p * 其中-archiveName 是指要创建的存档的名称。比如test.har，archive的名字的扩展名应该是*.har。 -p参数指定文件存档文件（src）的相对路径。
举个例子：-p /foo/bar a/b/c e/f/g
这里的/foo/bar是a/b/c与e/f/g的父路径，
所以完整路径为/foo/bar/a/b/c与/foo/bar/e/f/g
例如：如果你只想存档一个目录/input下的所有文件:
hadoop archive -archiveName test.har -p /input /outputdir 这样就会在/outputdir目录下创建一个名为test.har的存档文件。
8.2. 如何查看Archive
首先我们来看下创建好的har文件。使用如下的命令：
hadoop fs -ls /outputdir/test.har
这里可以看到har文件包括：两个索引文件，多个part文件（本例只有一个）以及一个标识成功与否的文件。part文件是多个原文件的集合，根据index 文件去找到原文件。
例如上述的三个小文件1.txt 2.txt 3.txt内容分别为1，2，3。进行
archive 操作之后，三个小文件就归档到test.har里的part-0一个文件里。
archive 作为文件系统层暴露给外界。所以所有的 fs shell 命令都能在archive 上运行，但是要使用不同的URI。
三、Hadoop MapReduce
1. MapReduce 简介
1.1. 理解MapReduce思想
MapReduce 的思想核心是“分而治之”
所谓“分而治之”就是把一个复杂的问题按一定的==“分解”方法分为规模较小的若干部分==，然后逐个解决，分别找出各部分的解，再把把各部分的解组成整个问题的解。
概况起来，MapReduce所包含的思想分为两步：
Map 负责“分”，即把复杂的任务分解为若干个“简单的任务”来并行处理。可以进行拆分的前提是这些小任务可以并行计算，彼此间几乎没有依赖关系。
Reduce 负责“合”，即对map阶段的结果进行全局汇总。
这两个阶段合起来正是MapReduce思想的体现。
1.2. Hadoop MapReduce 设计构思
MapReduce 是一个分布式运算程序的编程框架，核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序，并发运行在Hadoop 集群上。
MapReduce 中定义了如下的Map和Reduce两个抽象的编程接口，由用户去编程实现:
map: (k1; v1) → [(k2; v2)]
reduce: (k2; [v2]) → [(k3; v3)]
Map 和Reduce为程序员提供了一个清晰的操作接口抽象描述。通过以上两个编程接口，大家可以看出MapReduce处理的数据类型是键值对。
2. 官方MapReduce示例
在Hadoop 的安装包中，官方提供了MapReduce 程序的示例 examples，以便快速上手体验MapReduce。
该示例是使用java语言编写的，被打包成为了一个jar文件。
cd /export/server/hadoop-3.3.0/share/hadoop/mapreduce
运行该jar包程序，可以传入不同的参数实现不同的处理功能。
hadoop-mapreduce-examples-3.3.0.jar
2.1. 示例1：评估圆周率π（PI）
Monte Carlo 方法到基本思想：
当所求解问题是某种随机事件出现的概率，或者是某个随机变量的期望值时，通过某种“实验”的方法，以这种事件出现的频率估计这一随机事件的概率，或者得到这个随机变量的某些数字特征，并将其作为问题的解。
下面来运行MapReduce程序评估一下圆周率的值，执行中可以去YARN页面(http://node1:8088)上观察程序的执行的情况。
hadoop jar hadoop-mapreduce-examples-3.3.0.jar pi 10 50第一个参数pi：表示MapReduce程序执行圆周率计算；
第二个参数：用于指定map阶段运行的任务次数，并发度，这是是10；
第三个参数：用于指定每个map任务取样的个数，这里是50。
2.2. 示例2：单词词频统计WordCount
WordCount 算是大数据统计分析领域的经典需求了，相当于编程语言的HelloWorld。其背后的应用场景十分丰富，比如统计页面点击数，搜索词排行榜等跟count相关的需求。
其最基本的应用雏形就是统计文本数据中，相同单词出现的总次数。用SQL 的角度来理解的话，相当于根据单词进行group by分组，相同的单词分为一组，然后每个组内进行count聚合统计。
对于MapReduce乃至于大数据计算引擎来说，业务需求本身是简单的，重点是当数据量大了之后，如何使用分而治之的思想来处理海量数据进行单词统计。
hadoop jar hadoop-mapreduce-examples-3.3.0.jar wordcount /input /output第一个参数：wordcount表示执行单词统计
第二个参数：指定输入文件的路径
第三个参数：指定输出结果的路径（该路径不能已存在）
3. MapReduce Python 接口接入
虽然Hadoop是用Java编写的一个框架, 但是并不意味着他只能使用Java语言来操作, 在Hadoop-0.14.1 版本后, Hadoop支持了Python和C++语言, 在Hadoop 的文档中也表示可以使用Python进行开发。
在Python 中的sys包中存在, stdin 和stdout,输入输出流, 我们可以利用这个方式来进行MapReduce的编写。
map阶段：
import sysfor line in sys.stdin: # 捕获输入流 line = line.strip() # 根据分隔符切割单词 words = line.split() # 遍历单词列表 每个标记1 for word in words: print(\"%s\\t%s\" % (word, 1))reduce阶段
import sys # 保存单词次数的字典 key:单词 value：总次数 word_dict = {} for line in sys.stdin: line = line.strip() word, count = line.split(\'\\t\') # count类型转换 try: count = int(count) except ValueError: continue # 如果单词位于字典中 +1，如果不存在 保存并设初始值1 if word in word_dict: word_dict[word] += 1 else: word_dict.setdefault(word, 1) # 结果遍历输出 for k, v in word_dict.items(): print(\'%s\\t%s\' % (k, v)) 4. MapReduce基本原理
4.1. Map阶段执行流程
影响maptask个数的因素有：
- 文件的个数
- 文件的大小
- split size=block size 切片的大小受数据块大小控制
- 第一阶段是把输入目录下文件按照一定的标准逐个进行逻辑切片，形成切片规划。默认情况下，Split size = Block size。每一个切片由一个MapTask 处理。（getSplits）
- 第二阶段是对切片中的数据按照一定的规则解析成对。默认规节)，value是本行的文本内容。（TextInputFormat）。
- 第三阶段是调用Mapper类中的map方法。上阶段中每解析出来的一个，调用一次map方法。每次调用map方法会输出零个或多个键值对。
- 第四阶段是按照一定的规则对第三阶段输出的键值对进行分区。默认是只有一个区。分区的数量就是Reducer任务运行的数量。默认只有一个Reducer 任务。
- 第五阶段是对每个分区中的键值对进行排序。首先，按照键进行排序，对于键相同的键值对，按照值进行排序。比如三个键值对、、，键和值分别是整数。那么排序后的结果是、、。如果有第六阶段，那么进入第六阶段；如果没有，直接输出到文件中。
- 第六阶段是对数据进行局部聚合处理，也就是combiner处理。键相等的键值对会调用一次reduce方法。经过这一阶段，数据量会减少。本阶段默认是没有的。
4.2. Reduce阶段执行流程
- 第一阶段是Reducer任务会主动从Mapper任务复制其输出的键值对。Mapper 任务可能会有很多，因此Reducer会复制多个Mapper的输出。
- 第二阶段是把复制到Reducer本地数据，全部进行合并，即把分散的数据合并成一个大的数据。再对合并后的数据排序。
- 第三阶段是对排序后的键值对调用reduce方法。键相等的键值对调用一次值对写入到HDFS文件中。
4.3. Shuffle 机制
map 阶段处理的数据如何传递给reduce阶段，是MapReduce框架中最关键的一个流程，这个流程就叫shuffle。
shuffle: 洗牌、发牌——（核心机制：数据分区，排序，合并）。
shuffle 是 Mapreduce 的核心，它分布在Mapreduce的map阶段和reduce阶段。一般把从Map产生输出开始到Reduce取得数据作为输入之前的过程称作shuffle。
Hadoop Yarn
1. Yarn 简介
Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
可以把yarn理解为相当于一个分布式的操作系统平台，而mapreduce等运算程序则相当于运行于操作系统之上的应用程序，Yarn为这些程序提供运算所需的资源（内存、cpu）。
YARN 是一个资源管理、任务调度的框架，主要包含三大模块：ResourceManager（RM）、NodeManager（NM）、 ApplicationMaster（AM）。
- ResourceManager 负责所有资源的监控、分配和管理；
- ApplicationMaster 负责每一个具体应用程序的调度和协调；
- NodeManager 负责每一个节点的维护。
对于所有的applications，RM拥有绝对的控制权和对资源的分配权。而每个AM则会和RM 协商资源，同时和NodeManager通信来执行和监控task。
- yarn并不清楚用户提交的程序的运行机制
- yarn中的主管角色叫ResourceManager
- yarn只提供运算资源的调度（用户程序向yarn申请资源，yarn就负责分配资源）
- yarn中具体提供运算资源的角色叫NodeManager
- yarn与运行的用户程序完全解耦，意味着yarn上可以运行各种类型的分布式运算程序，比如mapreduce、storm，spark，tez ……
- spark、storm 等运算框架都可以整合在 yarn 上运行，只要他们各自的框架中有符合yarn 规范的资源请求机制即可
- yarn 成为一个通用的资源调度平台.企业中以前存在的各种运算集群都可以整合在一个物理集群上，提高资源利用率，方便数据共享
2. Yarn三大组件介绍
2.1. ResourceManager
- ResourceManager 负责整个集群的资源管理和分配，是一个全局的资源管理系统。
- NodeManager 以心跳的方式向ResourceManager汇报资源使用情况（目前主要是CPU和内存的使用情况）。RM只接受NM的资源回报信息，对于具体的资源处理则交给NM自己处理。
2.2. NodeManager
- NodeManager 是每个节点上的资源和任务管理器，它是管理这台机器的代理，负责该节点程序的运行，以及该节点资源的管理和监控。YARN 集群每个节点都运行一个NodeManager。
- NodeManager 定时向 ResourceManager 汇报本节点资源（CPU、内存）的使用情况和Container 的运行状态。当 ResourceManager 宕机时 NodeManager 自动连接 RM 备用节点。
- NodeManager 接收并处理来自 ApplicationMaster 的 Container 启动、停止等各种请求。
2.3. ApplicationMaster
- 用户提交的每个应用程序均包含一个 ApplicationMaster，它可以运行在ResourceManager 以外的机器上。
- 负责与RM调度器协商以获取资源（用Container表示）。
- 将得到的任务进一步分配给内部的任务(资源的二次分配)。
- 与NM通信以启动/停止任务。
- 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
- 当前YARN自带了两个ApplicationMaster 实现，一个是用于演示 AM 编写方法的实例程序DistributedShell，它可以申请一定数目的 Container 以并行运行一个 Shell 命令或者Shell脚本；另一个是运行MapReduce应用程序的AM—MRAppMaster。
注：RM 只负责监控AM，并在AM运行失败时候启动它。RM不负责AM内部任务的容错，任务的容错由AM完成。
3. Yarn运行流程
- client 向RM 提交应用程序，其中包括启动该应用的ApplicationMaster的必须信息，例如ApplicationMaster 程序、启动ApplicationMaster的命令、用户程序等。
- ResourceManager 启动一个container用于运行ApplicationMaster。
- 启动中的ApplicationMaster向ResourceManager 注册自己，启动成功后与RM保持心跳。
- ApplicationMaster 向 ResourceManager 发送请求，申请相应数目的container。
- ResourceManager 返回 ApplicationMaster 的申请的 containers 信息。申请成功的container，由 ApplicationMaster 进行初始化。container 的启动信息初始化后，AM与对应的NodeManager 通信，要求NM启动container。AM 与NM保持心跳，从而对NM上运行的任务进行监控和管理。
- container运行期间，ApplicationMaster对container 进行监控。container通过RPC协议向对应的AM汇报自己的进度和状态等信息。
- 应用运行期间，client直接与AM通信获取应用的状态、进度更新等信息。
- 应用运行结束后，ApplicationMaster向ResourceManager注销自己，并允许属于它的container 被收回。
4. Yarn 调度器Scheduler
理想情况下，我们应用对Yarn资源的请求应该立刻得到满足，但现实情况资源往往是有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能的到相应的资源。在Yarn中，负责给应用分配资源的就是Scheduler。其实调度本身就是一个难题，很难找到一个完美的策略可以解决所有的应用场景。为此，Yarn 提供了多种调度器和可配置的策略供我们选择。
在 Yarn 中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，Fair Scheduler。
4.1. FIFO Scheduler
FIFO Scheduler 把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
FIFO Scheduler 是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。
4.2. Capacity Scheduler(默认的调度)
Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。
Capacity Scheduler 被设计为允许应用程序在一个可预见的和简单的方式共享集群资源，即\"作业队列\"。Capacity Scheduler 是根据租户的需要和要求把现有的资源分配给运行的应用程序。Capacity Scheduler 同时允许应用程序访问还没有被使用的资源，以确保队列之间共享其它队列被允许的使用资源。管理员可以控制每个队列的容量，Capacity Scheduler 负责把作业提交到队列中。
4.3. Fair Scheduler
在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job 动态的调整系统资源。如下图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair 调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
需要注意的是，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。
Hadoop High Availability（HA）
HA(High Available), 高可用，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，分为活动节点（Active）及备用节点（Standby）。通常把正在执行业务的称为活动节点，而作为活动节点的一个备份的则称为备用节点。
当活动节点出现问题，导致正在运行的业务（任务）不能正常运行时，备用节点此时就会侦测到，并立即接续活动节点来执行业务。从而实现业务的不中断或短暂中断。
在HA具体实现方法不同情况下，HA框架的流程是一致的, 不一致的就是如何存储、管理、同步edits编辑日志文件。
在Active NN 和 Standby NN 之间要有个共享的存储日志的地方，Active NN把edit Log写到这个共享的存储日志的地方，Standby NN去读取日志然后执行， 这样Active和Standby NN 内存中的HDFS元数据保持着同步。一旦发生主从切换Standby NN 可以尽快接管Active NN的工作。
1. Namenode HA
QJM/Qurom Journal Manager，这是一个基于Paxos算法（分布式一致性算法）实现的HDFS HA方案，它给出了一种较好的解决思路和方案,QJM主要优势如下：
- 不需要配置额外的高共享存储，降低了复杂度和维护成本。
- 消除spof(单点故障)。
- 系统鲁棒性(Robust)的程度可配置、可扩展。
2. Yarn HA
Yarn 作为资源管理系统，是上层计算框架（如MapReduce,Spark）的基础。在 Hadoop 2.4.0 版本之前，Yarn存在单点故障（即ResourceManager存在单点故障），一旦发生故障，恢复时间较长，且会导致正在运行的Application丢失，影响范围较大。从Hadoop 2.4.0版本开始，Yarn实现了ResourceManager HA，在发生故障时自动failover，大大提高了服务的可靠性。
ResourceManager（简写为 RM）作为 Yarn 系统中的主控节点，负责整个系统的资源管理和调度，内部维护了各个应用程序的ApplictionMaster信息、NodeManager（简写为NM）信息、资源使用等。由于资源使用情况和NodeManager信息都可以通过NodeManager的心跳机制重新构建出来，因此只需要对ApplicationMaster相关的信息进行持久化存储即可。
在一个典型的HA集群中，两台独立的机器被配置成ResourceManger。在任意时间，有且只允许一个活动的ResourceManger,另外一个备用。切换分为两种方式：
- 手动切换：在自动恢复不可用时，管理员可用手动切换状态，或是从Active到Standby,或是从Standby到Active。
- 自动切换：基于Zookeeper，但是区别于HDFS的HA，2个节点间无需配置额外的ZFKC守护进程来同步数据。
