标签：HDFS NN 文件 root Hadoop 数据节点

Hadoop

主要包括HDFS(存储)/MapReduce(计算)/Yarn(资源调度)

特性优点以及注意事项：

Hadoop的扩容能力很强：可以通过增加计算机数量来增加节点的数量
成本低：通过部署廉价的机器组成集群
效率高：将数据部署到了多台机器上，通过并发数据，使得Hadoop在节点之间动态并行的移动数据，速度快
可靠性：各种机制保证了正常运行
通用性：精准区分了做什么和怎么做，而做什么属于业务问题，怎么做属于技术问题
简单

单机式：将所有的业务放在一台机器上进行处理，但是如果数据量较大，业务增长了，那就没有办法满足，所以产生了集群

集群：由多个计算机来完成同一件事，他们彼此之间通过计算机软件或者硬件连接在一起高度紧密的协同工作，在某种意义上可以看作是一台计算机。

分布式：由多个节点来完成同一件事，不同的节点负责不同的功能

注意事项：

YARN和HDFS在物理层面在一起（可能进程节点在同一个机架上），但是在逻辑上并没有交集（不存在有你才有我的关系）

Hadoop集群 = HDFS集群 + YARN集群，不存在MapRenduce集群

hadoop集群启动命令：

HDFS集群：

start-dfs.sh/stop-dfs.sh

YARN集群:

start-yarn.sh/stop-yarn.sh

Hadoop集群：

start-all.sh/stop-all.sh

hadoop命令：

Hadoop可以操作多种文件系统，例如本地文件系统(file:///)、分布式文件系统（hdfs://nn:8020）、以及谷歌文件系统，具体的对哪种的文件系统进行操作取决于命令中文件路径的URL中的前缀协议，如果没有前缀的话会读取fs.defaultFS属性，将这个作为默认文件系统

[root@iZy70xhj2z30yqZ ~]# hadoop fs -ls file:/// # 查看本地文件系统
22/05/31 16:16:22 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Found 22 items
-rw-r--r--   1 root root          0 2020-12-28 03:41 file:///.autorelabel
drwxr-xr-x   - root root      36864 2022-04-26 10:43 file:///bin
dr-xr-xr-x   - root root       4096 2020-12-28 11:49 file:///boot
drwxr-xr-x   - root root       4096 2021-02-21 11:00 file:///data
drwxr-xr-x   - root root       2980 2022-04-27 16:10 file:///dev
drwxr-xr-x   - root root       4096 2022-05-30 17:01 file:///etc
drwxr-xr-x   - root root       4096 2022-05-24 18:21 file:///home
drwxr-xr-x   - root root       4096 2022-04-26 10:42 file:///lib
dr-xr-xr-x   - root root      36864 2022-04-26 10:43 file:///lib64
drwx------   - root root      16384 2020-12-28 11:37 file:///lost+found
drwxr-xr-x   - root root       4096 2018-04-11 12:59 file:///media
drwxr-xr-x   - root root       4096 2018-04-11 12:59 file:///mnt
drwxr-xr-x   - root root       4096 2022-05-21 16:12 file:///opt
dr-xr-xr-x   - root root          0 2022-04-26 09:07 file:///proc
dr-xr-x---   - root root       4096 2022-05-31 16:04 file:///root
drwxr-xr-x   - root root        720 2022-04-26 23:32 file:///run
dr-xr-xr-x   - root root      12288 2022-05-05 11:38 file:///sbin
drwxr-xr-x   - root root       4096 2018-04-11 12:59 file:///srv
dr-xr-xr-x   - root root          0 2022-05-26 15:39 file:///sys
drwxrwxrwt   - root root       4096 2022-05-31 04:51 file:///tmp
drwxr-xr-x   - root root       4096 2020-12-28 11:37 file:///usr
drwxr-xr-x   - root root       4096 2020-12-28 03:41 file:///var

root@iZy70xhj2z30yqZ ~]# echo 1 >> 1.txt # 创建一个1.txt，其中内容为1
[root@iZy70xhj2z30yqZ ~]# ls
1.txt  oneinstack  ReadMe
[root@iZy70xhj2z30yqZ ~]# echo 2 >> 2.txt # 创建一个2.txt，其中内容为2
[root@iZy70xhj2z30yqZ ~]# ls
1.txt  2.txt  oneinstack  ReadMe
[root@iZy70xhj2z30yqZ ~]# echo 3 >> 3.txt # 创建一个3.txt，其中内容为3
[root@iZy70xhj2z30yqZ ~]# ls
1.txt  2.txt  3.txt  oneinstack  ReadMe
[root@iZy70xhj2z30yqZ ~]# hadoop fs -appendToFile 2.txt 3.txt /1.txt #将2，3.txt中的内容追加到1.txt中
[root@iZy70xhj2z30yqZ ~]# hadoop fs -cat /1.txt
1
2
3

hadoop fs -appendToFile 主要用于小文件的合并

hadoop fs -mv 可以移动文件到指定的目录下，可以使用该命令移动数据，重命名文件的名称

HDFS

HDFS主要解决了大数据存储的问题，它是横跨在多台计算机上的存储系统，并且提供了统一的访问接口，可以像是普通的文件系统来使用

是Hadoop的分布式文件存储系统，是可以运行在通用硬件上的分布式文件系统，它具有高度的容错性，适合部署在廉价的硬件上，同时HDFS还能提供高吞吐量的数据访问，适合大规模数据集上的应用，HDFS放宽了一部分POSIX约束（可移植操作系统接口，是电气与电子工程师协会为要在各种unix操作系统上运行软件，而定义API的一系列互相关联的标准的总称定义）用来实现流式读取系统数据的目的

他的设计目标：

具有故障检测和自动快速恢复的功能；被设计为用来批处理文件；更加注重数据访问的高吞吐量；支持大文件；大部分的HDFS使用的是一次写入多次修改的模型

HDFS安全模式

SafeMode是NameNode的一种特殊状态（Active/Standby/SafeMode模式），在安全模式下文件系统只接受读数据请求，而不接受修改、删除，当NN主节点启动时，HDFS首先进入安全模式，DN在启动的时候会向NN发送心跳，并汇报可用block的状态，当整个系统达到安全标准时，HDFS会自动离开安全模式

进入安全模式的三种情况

一、HDFS集群正常的冷启动，NN会在SafeMode情况下维持很长一段时间，原理：当HDFS冷启动时，这是内存中的元数据只能从fsimage中得到，但是fsiamge中并不包含block所在DN的信息，这时NN默认会认为所有的block都已经丢失，从而进入安全模式，然后随着DN的陆续启动，会向NN发送心跳汇报自己拥有的block信息，然后NN将block的信息补全，然后退出安全模式

二、block丢失率达到0.01%。原理：当NN发现block的丢失率达到0.01%，会进入安全模式。丢失率可以通过手动配置，默认是在配置文件 hdfs-default.xml 中定义了最小的副本率为 dfs.namenode.safemode.threshold-pct=0.999f.

三、手动进入安全模式：

# 手动进入安全模式
hdfs dfsadmin -safemode enter

#手动退出安全模式
hdfs dfsadmin -safemode leave

#查看集群是否处于安全模式
hdfs dfsadmin -safemode get

分布式存储系统的核心包括：

1.分布式存储：

在大数据时代，数据量的飞速增长对于存储也提出了要求，所以有两种的解决方式来存放海量数据：

1.单机纵向扩展：在传统的理解里，如果单机的存储空间不足，磁盘不足加磁盘，无法持续

**2.多机横向扩展：机器不足加机器，理论上无线扩展**

2.元数据的记录功能

元数据记录了文件信息及其存储位置，用来**快速定位文件位置**

3.文件分块存储

文件存储到 不同的机器上，可以针对不同的块**进行并行操作提高效率**

4.副本备份机制

不同的机器设置备份，冗余存储，**保障数据安全**

下面的图是官方给出的HDFS的官方示意图，我们可以从中看出：

1.采用了master/slave架构，主要包括NameNode（主），DataNode（从）

2.采用的分布式的文件存储

3.NN存储元数据，DN存放数据

4.副本备份机制

5.文件的分块存储

NameNode

是分布式文件系统的核心，架构中的主角色，主要用于维护和管理文件系统元数据，包括名称空间目录树结构、文件和块的位置信息、访问权限等信息，所以NameNode是唯一的访问HDFS接口，NN内部通过内存和磁盘文件两种方式管理元数据，保存在内存中的原因是内存的交互速度特别块，查找速度快，但是在断电之后内存中的数据将会丢失，所以在磁盘中同样有存储着元数据，通过定期的合并，保证元数据的安全。

管理文件系统的命名空间
记录每个数据块在DN上的位置和副本信息
协调客户端对文件的访问
记录命名空间的改动或者命名空间属性的变化
NN使用日志记录HDFS元数据的改动，使用映像文件存储文件系统的命名空间。

NN的fsimage和editlog

NN的启动流程：

第一次启动NN时，会生成fsimage和editlog文件，不是第一次启动的话，会直接加载fsimage和editlog文件到内存中

在HDFS中必然要多次频繁的访问元数据，并且还要求DN可以快速的响应客户端的请求，所以这是元数据就无法存储到磁盘上，必须要存储到内存中，但是如果停电就会导致所有的元数据的丢失，为了解决这个问题，所以我们在磁盘上作出相应的备份fsimage，当内存中的元数据发生变化时，fsimage同步作出变化，从而保证数据的一致性，但是如果元数据每变化一次，fsimage就做出相应的操作，会导致效率低下，所以这时我们引入editlog文件，editlog文件同样存在磁盘上但是我们只对它进行追加操作，每当客户端对元数据做出了操作，就将元数据的更新操作。追加到editlog上，再对editlog和fsimage进行定期的合并操作。为了减轻NN的负担，合并操作由SNN完成。

HDFS的checkpoint机制

SNN向NN发出合并请求，NN将当前的editlog改名为edits，并且新建Editlog持续化工作，将改名之后的eidts文件和本地的fsimage旧文件发送给SNN，SNN将edits和fsimage旧文件进行合并形成新的fsimgae文件，将新的fsimage文件发送给NN，将最新的fsimage文件进行保存，并删除旧文件。

解释：

SNN向NN发出请求的条件：SNN会周期性的检查editlog文件的大小（默认五分钟），通过NameNodeProtocol.getEditLogSize()获取editlog的大小，当editlog的大小达到指定的大小，会发出合并请求,如果editlog很小则不合并，当达到合并的大小时，SNN会通过doCheckpoint（）的方法开启一次检查点，在doCheckpoint（）方法中会启用RollEditlog（）方法通知名称节点，让名称节点做准备。此时NN会停止editlog的调用，然后会生成一个新的edit.new文件，后续对文件元数据的改动会记录到这个文件中。
SNN会通过NN内置的http服务器Jetty，以Get的方式获取edits文件与fsimage文件，Get方法中携带了fsimage和edits的路径
SNN会将fsimage载入到内存中并逐一执行editlog中的操作，生成fsimage.ckpt文件
执行结束之后，SNN会向NN发送http请求，通知NN合并结束，NN通过http Get方式获取fsimage.ckpt文件。
SNN会通过NameNodeProtocol.rollFSImage()方法告诉NN完成一次检查点，NN在处理该方法时，会将fsimage.ckpt改名为fsimage，将edit.new改名为edit

SNN合并fsimage和editlog是在内存中完成，此时SNN中的数据就和NN在检查点之前的数据一样了；SNN和NN的内存大小是一样的；默认检查的时间间隔是一小时；另外SNN默认每隔五分钟使用NameNodeProtocol.getEditLogSize()来检查editlog的大小

注意事项：

NN并不持久化存储每一个文件各个块所在的DN的位置信息，这些信息在系统启动时会从DN重建；NN所在的机器通常配置有大量的内存；NN是Hadoop中的单点故障

DataNode

DN是HDFS中的从角色，负责具体的数据块存储，DN的数量决定着存储能力

职责：

DN负责最终数据块block的存储，是从角色，也称为slave；在DN启动时，会将自己注册到NN中，并且汇报自己所持有的块列表；DN关闭时不会影响数据的可用性（副本备份机制）；DN所在的机器通常配置有大量的磁盘，因为数据存储在DN上。

负责所在的物理节点的存储管理
一次写入，多次读取
文件由数据块组成一般数据块的大小为64M
数据尽量分散到各个节点

SecondaryNamenode

SNN充当着NN的辅助节点，但是不能代替NN，主要是帮助NN进行fsimage和editlog文件的合并

NameSpace（命名空间）：

HDFS支持传统的层次型文件组织结构，文件系统的命名空间中的层次结构和大多数为文件系统的层次结构相似，NN用于维护NameSpace命名空间，任何针对于文件系统命名空间或者属性的操作都会被NN记录，HDFS会提供一个统一的抽象目录树，客户端通过路径来访问，其余的操作有HDFS完成。

NN宕机的解决方式：

第一种方式

HDFS中只有一个NameNode所以当它宕机时，Hadoop本身提供了通过SecondaryNameNode的备份数据来恢复NameNode的元数据的方案，但是因为checkpoint（每次checkPoint时SecondaryNameNode才会与NameNOde合并数据）的问题，但是每一次checkpoint都会有一段时间的间隔，无法做到SNN与NN的元数据一直相同，所以说在NN宕机的时间里，会有部分数据无法被存储，丢失数据的量取决于checkpoint的时间间隔。我们可以通过缩短checkpoint的时间周期的做法来减少损失的数据量，但是因为checkpoint非常损耗性能，所以我们很难通过这种方式来完成NN的恢复，如果要求数据不允许有损失，那我们基本就可以放弃这种方式来恢复NN

第二种方式：

NFS——— 一种即时备份NN的元数据的方案，设置多个目录，包括NFS目录，让nameNode在持久化元数据的同时写入多个目录

Master/slave架构（主从架构）：

部署多个节点，其中只有一个节点为主节点（NameNode），其他的节点都是从节点（DataNode），NN作为master服务，主要负责管理文件系统的元数据，以及客户端对文件呢系统的访问（文件被分割成块的信息+块归属于DN的信息）

DN作为slave，每一个物理节点对应一个DN，管理块信息，主要是通过心跳定时发送到NN，主要负责处理客户端的读写请求。

冷备和热备

冷备份：

在Hadoop1中，SNN会按照时间阈值或者是edits日志文件的大小，周期性的将fsimage和editlogs合并生成新的fsimage并替换原来的fsimage，将新的fsimage推给NN，减少NN的启动时间，非实时merge，如果NN宕机，就会导致元数据的丢失，

热备份：

引入新问题NameNode HA

NameNode HA

首先什么叫NameNode HA：NameNode High Availablity 即高可用。NameNode很重要一旦宕机就会导致存储数据服务停止，并且基于Hadoop的组件都无法工作，所以需要NameNode HA，在NameNode HA中，SNN就不需要了。

在HA架构下有两个NameNode，一主一从，实现HA的关键在于：

1、如何保持两个NameNode保持同步：在active NameNode宕机之后Standby NameNode迅速的替换主NameNode提供服务，在之前已经了解到了NameNode的启动需要消耗很长时间，并且在启动时需要读取fsimage和editlog文件，用来在内存中恢复NN的元数据，但是fsimage中并不包含block的位置信息，这是NN会进入安全模式，等待所有的DN汇报自己所拥有的block(blockreport过程)，等到这个过程完成，NN退出安全模式，才算真正的启动，在NN启动的整个过程中包含两个部分，分别是读取fsimage和editlog文件，以及blockreport，在HA架构下如果想保证Active和Standby NN数据相等，就需要将两部分的信息同步。

2、如何防止脑裂：在HA架构中拥有两个NN，一旦它们之间失去了联系，就会默认彼此宕机，会争抢计算机资源，会导致一系列的问题

3、如何保证两个NN在切换时，保证正在连接的客户端不会察觉，而且必须保证无论在任何情况下只有一个NN对外服务。

在上网查询之后，我发现HA架构是基于Paxos算法实现的然后接下来我们来学习Paxos算法

Paxos算法

首先声明这个算法很晦涩难懂，我不一定能理解

它的背景：Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一，其解决的问题就是在分布式系统中如何就某个值（决议）达成一致。（我复制的）

针对它的背景进行理解：

首先什么叫做基于消息传递，我的个人理解是在默认系统内传递的消息进行附加在上面进行传递信息，百度百科给出解释，消息传递：并行计算机中各台处理机通过传递消息包来实现通信和同步的机制，所以更正我的理解：这个算法是在Hadoop的三个节点（2个NN，一个JN我也不知道JN是啥一会回到HA架构再看）中进行发送接受消息包来进行通信和同步，高度容错特性不解释了，一致性算法，个人理解是通信之间的节点保持一致，经过百度可知，一致性算法的原理是，一致性算法的出现是为了解决一致性问题，一致性问题是指对一组服务器（集群），给定一组操作，需要使用一种协议使得它们的结果达成一致，看起来就像是一台服务器。第一句话就是这样基本理解了，就是Paxos算法是一种使用消息包传递信息，并且具有高度容错的是一组服务器或者集群达成一致的算法。背景就理解到这。

面试的时候：不要把这个Paxos算法达到的目的和分布式事务联系起来，而是针对Zookeeper这样的master-slave集群对某个决议达成一致，也就是副本之间写或者leader选举达成一致。我觉得这个算法和狭义的分布式事务不是一样的。
在常见的分布式系统中，总会发生诸如机器宕机或网络异常（包括消息的延迟、丢失、重复、乱序，还有网络分区）(也就是会发生异常的分布式系统)等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致。也可以理解成分布式系统中达成状态的一致性。------全是复制的我懒得看了

对Paxos算法保持一致性换一种理解：假设一个场景，在一个分布式数据库系统中，如果每个一个节点都执行相同的操作，那他们最后得到的结果就是一样的，我们为了得到这个一致性的结果我们就需要保证它们能执行相同的操作，所以我们就在指令上添加一致性算法，保证每个节点看到的指令都是一样的。别问我怎么添加的我不想看。

在之前我们学过在分布式系统中为了保持可靠性有多副本机制，而存在多个副本就会导致数据不一样的情况，所以我们必须有一个一致性算法来保持副本中数据的一致性，要是数据都不一致了，那就不叫副本了，和上面的分布式数据库相同，分布式集群中每一个节点在初始时数据时相同的，我们接下来对他们进行一样的操作，最后它们的数据也就是一样的。这个每一个节点指的是节点和它们的副本。Paxos算法就是为了解决分布式中的一致性问题而诞生的。在分布式系统中多个节点之间存在着两种的通讯模型：共享内存、消息传递，而Paxos算法就是基于消息传递模型的。得，又出现了新的问题。

节点之间的通讯模型：

嘿嘿没找到

继续Paxos问题：

在分布式系统中，会出现机器宕机、网络异常等问题，而Paxos算法的目的就在于当系统出现这些问题时依旧能保持在集群内部对某些数据的值保持一致，个人理解：例如在Hadoop中加入NN宕机了那么他依旧能够保证Active NN和Standby NN中的元数据相同。理解的有问题。

拜占庭问题：
拜占庭将军问题：是指拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。问题是这些将军在地理上是分隔开来的，只能依靠通讯员进行传递命令，但是通讯员中存在叛徒，它们可以篡改消息，叛徒可以欺骗某些将军采取进攻行动；促成一个不是所有将军都同意的决定，如当将军们不希望进攻时促成进攻行动；或者迷惑某些将军，使他们无法做出决定。

而在Paxos中默认不存在拜占庭问题，即信道安全，发出的信号不会被篡改。从理论上来讲（我服了，别讲了行吗），在异步系统（这又是啥）和不可靠信道上完成一致性时不可能的，而且往往需要达成一致性的分布式系统，基本上位于同一个局域网上，基本上不存在消息被篡改的情况，另外由于硬件或者网络问题所造成的消息不完整，只需要简单的校验算法即可。所以基本不存在消息不可靠的情况。

异步系统：

同步：他先给A女写了封信然后发了出去。等了好几天 A女给他回了信，之后他才给B女写信。就是说等到一个任务返回或者结束他才继续往下做他想做的任务。

异步：他先给A女写了封信，然后发了出去，马上又给B女写了封信也发了出去。就是说不用等到一个任务结束就去做下一个任务。

但是如果第一个任务需要第二个任务的返回值那就得用同步让第一个任务等待第二个任务结束后，获取第二个任务的返回值，在继续往下做。

他写的实在是太简单明了了。。。。

好了Paxos算法到此为止，后面太长了埋个坑以后看

继续HA架构：

在上面我们提出了实现HA的关键节点，接下来我们需要解决这些问题：

1、首先如何保持Activate NN和Standby NN保持内部元数据的同步：Standby NN周期性的从NN获取editlog文件，同时DN在向NN执行blockreport操作的同时，也向SNN执行blockreport操作。

2、如何防止脑裂：添加额外的心跳线、使用磁盘锁正在使用的NN锁住磁盘，但是需要主动解锁，所以会出现一方突然死机却未解锁的情况，所以添加智能锁，正在使用的一方发现心跳线全部停止会解开磁盘锁、设置仲裁机制，例如设置参考ip，当双方发现心跳停止时，就会主动ping参考ip，为响应的一方则是出现问题的主动重启。

3、如何保证active NN和Standby NN切换时用户不会察觉：

我看不懂，埋个坑以后看

HDFS文件写入

核心概念——Pipeline管道

这是HDFS在上传文件写数据过程中采用的一种数据传输方式，在写入数据时：客户端将数据写入第一个数据节点，第一个数据节点保存数据之后将块复制到第二个节点，后者保存后在讲数据复制到第三个节点。这就是管道。

为什么采用管道而不是拓扑式传输

因为数据以管道的形式进行传输，顺序沿着一个方向传输，这样能够充分的利用每一台机器的带宽，避免网络网络瓶颈和高延迟时的连接，最小化推送所有数据的延时

核心概念——ACK应答响应

ACK是确认字符，在数据通信中，接收方给发送方的一种传输类控制字符，表示发来的数据已接收确认无误；在管道传输的过程中传输的反方向会进行ACK校验，确保数据安全

核心概念——默认的三副本存储策略

采取机架感知策略备份数据存放

机架感知策略

数据块以及数据块的副本存放在那个DN上才会使集群更加安全、数据更不容易损坏的一种策略。

机架感知策略的工作原理：

第一个节点：

集群内部：优先选择与客户端在相同的节点作为第一个节点(client在集群内部的选择）

集群外部：选择资源丰富且不忙碌的节点作为第一个节点(client不在集群中)

第二个节点：

选择与第一个节点不在同一个机架上的节点

第三个节点：

选择与第二个节点不相同机架的其他节点

第N个节点：

与前面不重复的其他节点

HDFS副本的选择：

HDFS会尽量选取近的副本，用来降低整体宽带和读取延迟

文件写入流程

HDFS客户端创建对象实例DistributedFileSystem，该对象中封装了与HDFS文件操作系统相关的方法
调用DistributedFlieSystem对象中的create( )方法，通过RPC请求NN创建文件，这时NN会执行各种检查判断：目标文件是否存在、父目录是否存在、客户端是否具有创建该文件的权限。检查通过，NN会为本次请求记下一条记录，返回FSDataOutputStream输出流对象给客户端用于写数据
客户端通过输出流写入数据
客户端写入数据时，将数据分为数据包（packet ，64k），内部组件DataStreamer请求NN挑选适合存储数据副本的一组DN地址，DataStreamer将数据包流式传输到pipeline的第一个DN，该DN存储数据包，并将它发送到pipeline的第二个DN，同样的第二个DN存储数据包，并将它发送到pipeline的第三个DN。
在传输的反方向上，会通过ACK机制校验数据包是否传输成功
在客户端完成数据写入后，在FSDataOutputStream输出流上调用close（）方法关闭。
DistributedFileSystem联系NN告知其文件写入完成，等待NN确认，因为NN已经知道文件由哪些块组成，因此只需要等待最小复制块即可返回成功（默认是1）

Block的定义：

一般情况下磁盘都有最小读写单位的概念，就是block，HDFS中的block的大小一般为128M（hadoop2.7.2之前为64MB），比其他的一般都大。

关于block为什么定义大小为128M：

因为在hdfs中一般寻址时间为10ms，当寻址地址为传输时间的1%时为最佳状态(因为此时的损耗最小)，机械硬盘文件顺序读写的速度为100MB/s,普通固态为500MB/s,pcie固态的速度可以达到2000MB/s,因此块的大小可以分别设为128MB,512MB,2048MB。

文件的读取流程:

首先是客户端向NN发送读取请求->NN向客户端返回block信息，以及其所在的DN的信息->客户端向DN请求数据

HDFS是如何保证数据的安全可靠的

冗余副本策略
机架感知策略
心跳机制
安全模式
校验和：客户端通过读取检验和检查数据块是否损坏，来判断是否需要读取副本
回收站：删除文件，会先到回收站，其中的文件可以快速的恢复
元数据保护：映像文件和事务日志是NN的核心系统可以配置同时拥有多个副本
快照：支持存储某个时间点的映像，需要时可以使数据重返这个时间点的状态

HDFS的文件配置

core-site.xml文件（核心模块配置）

hadoop.tmp.dir设置本地保存数据路径

fs.defaultFS设置他的接口问9000

hdfs-site.sh文件（hdfs文件系统模块配置）

dfs.replication设置冗余副本数量，默认为3

<name>dfs.namenode.name.dir </name>NameNode的数据存放地址，也就是NN存放元数据的位置

<name>dfs.datanode.data.dir </name>设置dataNode的数据存放地址，也就是DN存放block的目录

hadoop-env.sh文件

设置java路径

mapred-site.xml文件（将mapred-site.xml.template重命名为 .xml的文件）

<configuration>
    <!-- 指定mr框架为yarn方式,Hadoop二代MP也基于资源管理系统Yarn来运行 -->
    <property>
        <name>mapreduce.framework.name</name>
        <value>yarn</value>
    </property>
  
    <!-- 开启mapreduce的小任务模式，用于调优 -->
    <property>
        <name>mapreduce.job.ubertask.enable</name>
        <value>true</value>
    </property>
  
    <!-- 配置mapreduce的jobhistory内部通讯地址。可以查看我们所有运行完成的任务的一些情况 -->
    <property>
        <name>mapreduce.jobhistory.address</name>
        <value>hadoop01:10020</value>
    </property>

    <!-- 配置mapreduce 的jobhistory的访问地址 -->
    <property>
        <name>mapreduce.jobhistory.webapp.address</name>
        <value>hadoop02:19888</value>
    </property>
  
</configuration>

yarn-site.xml文件

<configuration>
    <!-- 指定我们的resourceManager运行在哪台机器上面 -->
    <property>
        <name>yarn.resourcemanager.hostname</name>
        <value>hadoop01</value>
    </property>

    <!-- NodeManager的通信方式 -->
    <property>
        <name>yarn.nodemanager.aux-services</name>
        <value>mapreduce_shuffle</value>
    </property>

    <!-- 日志的聚合功能，方便我们查看任务执行完成之后的日志记录 -->
    <property>
        <name>yarn.log-aggregation-enable</name>
        <value>true</value>
    </property>
    <!-- 聚合日志的保存时长 -->
    <property>
        <name>yarn.log-aggregation.retain-seconds</name>
        <value>604800</value>
    </property>

    <!--yarn总管理器的IPC通讯地址-->
    <property>
        <name>yarn.resourcemanager.address</name>
        <value>hadoop01:8032</value>
    </property>

    <!--yarn总管理器调度程序的IPC通讯地址-->
    <property>
        <name>yarn.resourcemanager.scheduler.address</name>
        <value>hadoop01:8030</value>
    </property>

    <!--yarn总管理器的IPC通讯地址-->
    <property>
        <name>yarn.resourcemanager.resource-tracker.address</name>
        <value>hadoop01:8031</value>
    </property>

    <!--yarn总管理器的IPC管理地址-->
    <property>
        <name>yarn.resourcemanager.admin.address</name>
        <value>hadoop01:8033</value>
    </property>

    <!--yarn总管理器的web http通讯地址-->
    <property>
        <name>yarn.resourcemanager.webapp.address</name>
        <value>singlehost:8088</value>
    </property>
  
</configuration>

MapReduce

MapReduce的核心思想：分而治之

所谓“分而治之"就是将一个复杂的问题，按照一定的“分解"方法等价成规模较小的若干个部分，然后逐个解决，分别找出各部分的结果，然后最终把各部分的结果组成整个问题的结果。

Map表示第一部分，负责“拆分"：即把复杂的任务拆分为若干个“简单的子任务"来并行处理，可以拆分的前提是这些小任务可以并行计算，彼此之间不存在依赖关系。

Reduce表示第二部分，负责“合并"：即对map阶段的结果进行全局汇总。

这两个阶段合起来就是MapReduce的思想的体现。

（1）应对大数据处理场景

对于相互之间不具有计算依赖关系的大数据计算任务，实现并行的最自然的办法是采用MapReduce的分而治之的策略

首先是Map阶段进行拆分，把大数据拆分为若干个小数据，多个程序同时并行计算产生中间结果；然后是Reduce聚合阶段，通过程序对并行的结果进行最终的汇总，得出最终的结果

不可拆分的计算任务或相互之间有依赖关系的数据无法计算

（2）构建抽象编程模型

MapReduce借鉴了函数式语言中的思想，用Map和Reduce两个函数提供了高层的并行编程模型

map：对一组数据进行某种重复式的处理

reduce：对Map的中间结果进行某种进一步的结果整理

MapReduce中定义了如下的Map和Reduce两个抽象的编程接口，由用户去编程实现：

map：（k1：k2）->（k2：v2）

reduce：（k2：[v2]）->（k3：v3）

通过以上两个编程接口，Mapreduce处理的数据类型是<key:value >键值对

（3）统一架构、隐藏底层细节

如何提供统一的计算框架，如果没有统一封装底层细节，那么程序员就需要考虑诸如数据存储、划分、分发、结果收集、错误恢复等诸多细节，为此MapReduce设计并且提供了统一的计算框架，为程序员隐藏了绝大多数的系统层次的处理细节。

MapReduce最大的亮点在与通过抽象模型和计算框架将做什么和怎么做分开了，为程序员提供了一个高层和抽象的接口和框架。

程序员只需要编写少量的处理应用本身计算问题的业务代码，至于如何完成这个并行计算任务所相关的诸多的系统层细节被隐藏起来，交给计算框架去完成

分布式计算

分布式计算是一种计算方法，和集中式计算是相对的。随着计算技术的发展，有一些应用需要非常大的算力才能完成，如果采用集中式计算需要消耗非常多的时间来完成，分布式计算将该应用分解为小的部分，分配给多台计算机处理，这样可以节约整体的计算时间，大大的提升计算效率。

MapReduce的特点

易于编程：

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

良好的扩展性：

当计算机资源得不到满足时，可以通过增加机器来提升它的算力，基于MR的分布式计算的算力会随着节点数目的不断增加而保持线性的增长

高容错性：

设计一系列的措施来防止错误，因为他是分布式部署搭建的，任何一台机器宕机，他都会将其上面的计算任务转移到另一个节点上运行，不影响整个任务的完成，该过程是有Hadoop内部完成的。

适合海量数据的离线处理：

可以处理TB、PB级别的数据

MR的局限性

局限性并不代表它并不能完成，而是说并不适合这些方面

实时计算性能差

MR主要用于离线作业，并不能实现秒级或者亚秒级的数据响应

不能进行流式计算

流式计算的特点是数据是源源不断得计算，并且数据是动态的，而MR作为离线计算框，主要针对静态数据，数据是不能动态变化的。

MR实例进程

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

MRAppMaster：负责整个MR程序的过程调度以及状态协调（只有一个）

MapTask：负责整个Map阶段的数据处理流程（可以有一个或者多个）

ReduceTask：负责整个Reduce阶段的数据处理流程（可以有一个或者多个）

阶段组成：

一个MR程序只能有一个Map阶段和一个Reduce阶段，或者只有Map阶段，如果用户的业务逻辑非常复杂，那就只能多个MR程序串行运行。

MR数据类型

在整个的MR程序中，数据都是以kv键值对的形式进行流装的；

MR整体执行流程

Map阶段

第一阶段：把输入目录下的文件按照一定的标准进行逻辑切片（block的大小），形成切片，每一个切片由一个MapTask进行处理

第二阶段：对切片中的数据按照一定的规则读取解析返回 <key,value>对，默认的是按行进行数据读取，key是每一行的起始位置偏移量，value是本行的文本内容（TextInputFormat）

第三阶段：调用Mapper类中的map方法处理数据，每读取解析出来一个 <key,value>，调用一次map方法

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

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

第六阶段：对所有的溢出文件进行最终的merge合并，成为一个文件

内存缓冲区

在map任务阶段，输出数据不能继续存储到内存上

Reduce阶段

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

第二阶段：把拉取的数据进行合并merge即把分散的数据合并为一个大的数据，再对合并的数据进行排序

第三阶段：对排序后的键值对调用reduce方法。键相等的键值对调用一次reduce方法，最后将这些键值对存储到HDFS中

Shuffle过程

在MR中的shuffle过程是将map端的无规则输出按照指定的规则进行“打乱"成具有一定规则的数据，以便reduce端进行接收以及处理。一般情况下将从Map产生输出端开始到Reduce端去的数据作出输入之前的过程称为shuffle

Map端的shuffle

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

Spill阶段：当内存中的数据达到一定的阈值时会将数据写入本地磁盘，在将数据写入本地磁盘之前会对数据进行一次排序的操作，如果配置了combiner，还会将有相同分区号和key的数据进行排序

Merge阶段：把所有的溢出的临时文件进行一次合并操作，确保一个MapTask最终只产生一个中间数据文件

Reduce阶段的shuffle

Copy阶段：ReduceTask启动Fetcher线程到已经完成MapTask的节点上复制一份属于自己的数据

Merge阶段：在ReduceTask阶段远程复制数据的同时，会在后台开启两个线程对内存到本地的数据文件进行合并操作

Sort阶段：在对数据进行合并的同时，会进行排序操作，由于MapTask阶段已经对数据进行了局部的排序，ReduceTask只需保证Copy的数据的最终整体有效即可

Shuffle机制的弊端

Shuffle是MapReduce程序的核心与精髓，是MapReduce的灵魂所在

但是MR的shuffle也是被诟病最多的地方，MR速度慢与shuffle阶段有很大的关系

Shuffle中频繁的涉及到数据在内存与磁盘之间的多次反复

YARN集群

主从结构集群，包含两个部分ResourceManager和NodeManager

YARN是一个通用的资源管理系统和调度平台

YARN功能说明

通用：不仅仅支持MR程序，理论上还支持各种计算程序。

资源管理平台：集群的硬件资源和程序运行相关的必入内存、CPU等；磁盘的管理系统是HDFS

调度平台：多个程序同时申请计算资源如何分配，调度的规则（算法）

YARN概述

可以把Hadoop yarn理解为一个分布式的操作系统平台，而MR等计算程序就相当于运行在操作系统上的应用程序，yarn为这些程序提供了运行所需要的资源（内存、CPU等）

Hadoop的地位，yarn在其中功不可没，因为有了yarn，更多的计算框架可以接入到HDFS中，正式因为yarn的存在，其他的计算框架可以更多的专注于提升计算性能的提升。

YARN的架构

ResourceManager、NodeManager---->集群物理层面，一主多从

ApplicationMaster（App Mstr）-----> App层面

上面的统称为YARN的3大组件

Container容器（硬件资源的抽象）

ResourceManager（RM）

是YARN集群的主角色，决定系统中的所有应用程序之间资源分配的最终权限，即最终仲裁者，接收用户的作业提交，并通过NM分配、管理各个机器上的计算资源

NodeManager（NM）

YARN中的从角色，每台机器上有一个，负责管理本机器上的计算资源，根据RM的命令，启动container容器、监视容器的资源使用情况，并且向主角色RM会报资源的使用情况。

ApplicationMaster（AM）

用户每提交一个程序均包含一个AM，程序中的老大，负责程序内部的各个阶段的资源申请，监督程序的执行情况。

核心交互流程

MR作业的提交：Client--->RM

资源的申请：MrAppMaster--->RM

MR作业状态回报--->Container（Map ｜ Reduce task）--->Container（MrAppMaster）

节点的状态汇报 NM--->RM

整体概述

当用户向YARN中提交了一个应用程序后，YARN将会分为两个步骤来执行程序：

第一个阶段：客户端申请资源启动运行本次程序中的ApplicationMaster

第二个阶段：ApplicationMaster根据本次的程序内部具体情况进行资源申请，并且监控她的整个运行过程，直到运行完成

MR提交YARN交互流程

用户通过客户端向YARN中的ResourceManager提交应用程序（比如说Hadoop jar提交MR程序）
ResourceMansger为给应用程序分配第一个container（容器），并与对应的NodeManager通信，要求他在这个container中启动这个应用程序的ApplicationMaster。
AppplicationMaster启动之后，首先向ResourceManager注册并且保持通信，这样的话，用户可以直接通过ResourceManager查看本次应用程序的运行状态（处理了百分之几）
AM为本次程序内部的各个Task任务向RM申请资源，并且监控它的运行状态，在不同container中运行同一个程序的，都会对AM进行汇报，AM监控程序的运行状态，所以AM才是程序的老大。
一旦ApplicationMaster申请到资源后，便与对应的NM进行通行，要求它启动任务
NM为任务设置好运行环境后，将任务启动命令写到一个脚本中，并且通过该脚本启动任务。

YARN资源调度器Scheduler（ResourceManager的内部组件）

如何理解资源调度

在理想的情况下，应用程序提出的请求将会立即得到YARN的批准，然而在实际中资源是有限的，并且在繁忙的集群上，应用程序通常需要等待才能得到满足，YARN调度程序的工作之一是根据一些定义的策略为应用分配资源

在YARN中负责给应用分配资源的就是Scheduer，他是YARN中的核心组件之一，完全应用于资源的调度，并不跟踪程序的运行，并且调度并不存在最佳，所以YARN给出了多种调度器和分配策略

调度器策略

FIFO Scheduler（先进先出调度器）

是Hadoop1中提出的调度器并且保存了下来，是先出先出的策略，并不考虑优先级和范围，适用于负载较低的小规模集群，他拥有一个控制全局的队列queue，默认的queue名称为default，该调度器会获取所有的资源作用于这个全局的queue

优势：无需配置、先到先得、易于执行

劣势：任务的优先级不会变高，高优先级的任务需要等待，不适合共享集群

Capacity Schedluer（容量调度器）

Hadoop3的默认调度策略，该策略允许多个组织共享整个集群资源，每一个组织可以获得一部分的计算能力，通过为每个组织分配专门的队列，然后再为每一个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务。

Capacity可以理解为一个个的资源队列，这个资源队列是用户自己去分配的，队列的内部又可以进行垂直划分，这样的话一个组织内部的多个成员就可以共享这个队列资源了，在一个队列的内部采用的是FIFO策略

Capacity Schedluer调度器以队列为单位进行划分。简单来说就是一个个队列有独立的资源，队列的资源和结构是可以进行分配的。

特性优势：

层次化的队列设计：层次化的管理，可以更容易、更合理的分配和限制资源的使用
容量保证：每一个队列都可以设置一个资源的占比，保证每一个队列都不会占用整个集群的资源
安全：每个队列有严格的访问控制，用户只能向自己的队列里面提交任务，而不能修改或访问其他任务的队列
弹性分配：空闲的资源可以被分配给任何队列，当多个队列出现争用时，则会按照权重进行平衡

Fair Scheduler（公平调度器）

提供了YARN应用程序公平的共享大型集群中资源的一种方式，使所有的应用在平均情况下随着时间的流逝可以获得相等的资源份额

设计目标是为所有的应用分配公平的资源（对公平的定义通过参数来进行设置）

公平调度可以在多个队列间进行工作，允许资源共享和抢占

如何理解公平：

有两个用户A和B，每一用户都有自己的队列

刚开始的时候，A启动了一个作业由于没有B，所以A占用了所有的资源

然后B在A的作业仍在运行的时候启动了一个作业，经过一段时间A和B各自的作业都使用了一半的资源

在B运行一个作业的时候，有开启了一个作业，这是B的第二个作业，将会与B的另一个作业共享资源，因此B的每一个作业都拥有资源的四分之一，而A将拥有二分之一，结果就是资源在用户间公平的共享。

特性优势：

分层队列：队列可以按层次结构排列以划分资源，并可以配置权重以按特定比例共享集群
基于用户或组的队列映射：可以根据提交任务的用户名或组来分配队列，如果任务指定了一个队列，则在该队列中提交任务
资源抢占：根据应用的分配，抢占和分配资源可以是友好的或者是强制的，默认不启用抢占资源
保证最小配额：可以设置队列最小资源，允许将保证的最小份额分配给队列，保证用户可以启动任务。当队列不能满足最小资源时，可以从其他的队列抢占，名，当队列的资源使用不完时，可以讲资源分配给其他队列使用
允许资源共享：即当一个应用运行时，如果其他队列没有任务执行时，则可以使用其他队列，当其他队列有应用需要资源时再将占用的队列释放出来。所有的应用都从资源队列中分配资源
默认不限制每个队列和用户可以同时运行应用的数量：可以通过配置来进行限制，限制并行执行应用数量并不会导致任务失败，超出的应用在队列中等待。

标签：HDFS,NN,文件,root,Hadoop,数据,节点
From： https://www.cnblogs.com/baiyunhao/p/17208725.html