关于hadoop:史上最全Hadoop-核心-HDFS-分布式文件系统详解上万字建议收藏

Hadoop 分布式系统框架中，首要的根底性能就是文件系统，在 Hadoop 中应用 FileSystem 这个抽象类来示意咱们的文件系统，这个抽象类上面有很多子实现类，到底应用哪一种，须要看咱们具体的实现类，在咱们理论工作中，用到的最多的就是 HDFS(分布式文件系统)以及 LocalFileSystem(本地文件系统)了。

在古代的企业环境中，单机容量往往无奈存储大量数据，须要跨机器存储。对立治理散布在集群上的文件系统称为 分布式文件系统。

HDFS（Hadoop Distributed File System）是 Hadoop 我的项目的一个子项目。是 Hadoop 的外围组件之一，Hadoop 十分适于存储大型数据 (比方 TB 和 PB)，其就是应用 HDFS 作为存储系统. HDFS 应用多台计算机存储文件，并且提供对立的拜访接口，像是拜访一个一般文件系统一样应用分布式文件系统。

HDFS 是一个主 / 从（Mater/Slave）体系结构，由三局部组成：NameNode 和 DataNode 以及 SecondaryNamenode：

NameNode 负责管理整个 文件系统的元数据，以及每一个门路（文件）所对应的数据块信息。
DataNode 负责管理用户的 文件数据块，每一个数据块都能够在多个 DataNode 上存储多个正本，默认为 3 个。
Secondary NameNode 用来监控 HDFS 状态的辅助后台程序，每隔一段时间获取 HDFS 元数据的快照。最次要作用是 辅助 NameNode 治理元数据信息。

首先，它是一个文件系统，用于存储文件，通过对立的命名空间目录树来定位文件；

其次，它是分布式的，由很多服务器联结起来实现其性能，集群中的服务器有各自的角色。

1. master/slave 架构（主从架构）

HDFS 采纳 master/slave 架构。个别一个 HDFS 集群是有一个 Namenode 和肯定数目的 Datanode 组成。Namenode 是 HDFS 集群主节点，Datanode 是 HDFS 集群从节点，两种角色各司其职，独特协调实现分布式的文件存储服务。

2. 分块存储

HDFS 中的文件在物理上是分块存储（block）的，块的大小能够通过配置参数来规定，默认大小在 hadoop2.x 版本中是 128M。

3. 名字空间（NameSpace）

HDFS 反对传统的档次型文件组织构造。用户或者应用程序能够创立目录，而后将文件保留在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统相似：用户能够创立、删除、挪动或重命名文件。
Namenode 负责保护文件系统的名字空间，任何对文件系统名字空间或属性的批改都将被 Namenode 记录下来。
HDFS 会给客户端提供一个对立的形象目录树，客户端通过门路来拜访文件，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。

4. NameNode 元数据管理

咱们把目录构造及文件分块地位信息叫做元数据。NameNode 负责保护整个 HDFS 文件系统的目录树结构，以及每一个文件所对应的 block 块信息（block 的 id，及所在的 DataNode 服务器）。

5. DataNode 数据存储

文件的各个 block 的具体存储管理由 DataNode 节点承当。每一个 block 都能够在多个 DataNode 上。DataNode 须要定时向 NameNode 汇报本人持有的 block 信息。存储多个正本（正本数量也能够通过参数设置 dfs.replication，默认是 3）

6. 正本机制

为了容错，文件的所有 block 都会有正本。每个文件的 block 大小和正本系数都是可配置的。应用程序能够指定某个文件的正本数目。正本系数能够在文件创建的时候指定，也能够在之后扭转。

7. 一次写入，屡次读出

HDFS 是设计成适应一次写入，屡次读出的场景，且不反对文件的批改。
正因为如此，HDFS 适宜用来做大数据分析的底层存储服务，并不适宜用来做网盘等利用，因为批改不不便，提早大，网络开销大，老本太高。

如果没有配置 hadoop 的环境变量，则在 hadoop 的装置目录下的 bin 目录中执行以下命令，如已配置 hadoop 环境变量，则可在任意目录下执行

help

格局:  hdfs dfs -help 操作命令
作用: 查看某一个操作命令的参数信息

格局：hdfs dfs -ls  URI
作用：相似于 Linux 的 ls 命令，显示文件列表

lsr

格局  :   hdfs  dfs -lsr URI
作用  : 在整个目录下递归执行 ls, 与 UNIX 中的 ls- R 相似

mkdir

格局：hdfs  dfs  -mkdir [-p] <paths>
作用 :   以 <paths> 中的 URI 作为参数，创立目录。应用 - p 参数能够递归创立目录

put

格局：hdfs dfs -put <localsrc >  ... <dst>
作用：将单个的源文件 src 或者多个源文件 srcs 从本地文件系统拷贝到指标文件系统中（<dst> 对应的门路）。也能够从规范输出中读取输出，写入指标文件系统中

hdfs dfs -put  /rooot/bigdata.txt  /dir1

moveFromLocal

格局：hdfs  dfs -moveFromLocal  <localsrc>   <dst>
作用:  和 put 命令相似，然而源文件 localsrc 拷贝之后本身被删除

hdfs  dfs -moveFromLocal  /root/bigdata.txt  /

copyFromLocal

格局:  hdfs dfs -copyFromLocal <localsrc> ... <dst>
作用: 从本地文件系统中拷贝文件到 hdfs 门路去

appendToFile

格局: hdfs dfs -appendToFile <localsrc> ... <dst>
作用: 追加一个或者多个文件到 hdfs 指定文件中. 也能够从命令行读取输出.

 hdfs dfs -appendToFile  a.xml b.xml  /big.xml

moveToLocal

在 hadoop 2.6.4 版本测试还未未实现此办法
格局：hadoop  dfs  -moveToLocal [-crc] <src> <dst>
作用：将本地文件剪切到 HDFS

get

格局   hdfs dfs  -get [-ignorecrc]  [-crc]  <src> <localdst>

作用：将文件拷贝到本地文件系统。CRC 校验失败的文件通过 -ignorecrc 选项拷贝。文件和 CRC 校验能够通过 -CRC 选项拷贝

hdfs dfs  -get   /bigdata.txt  /export/servers

getmerge

格局: hdfs dfs -getmerge <src> <localdst>
作用: 合并下载多个文件，比方 hdfs 的目录 /aaa/ 下有多个文件:log.1, log.2,log.3,...

copyToLocal

格局:  hdfs dfs -copyToLocal <src> ... <localdst>
作用:  从 hdfs 拷贝到本地

格局：hdfs  dfs -mv URI   <dest>
作用：将 hdfs 上的文件从原门路挪动到指标门路（挪动之后文件删除），该命令不能跨文件系统

hdfs  dfs  -mv  /dir1/bigdata.txt   /dir2

格局：hdfs dfs -rm [-r]【-skipTrash】URI【URI。。。】作用：删除参数指定的文件，参数能够有多个。此命令只删除文件和非空目录。如果指定 -skipTrash 选项，那么在回收站可用的状况下，该选项将跳过回收站而间接删除文件；否则，在回收站可用时，在 HDFS Shell 中执行此命令，会将文件临时放到回收站中。

hdfs  dfs  -rm  -r  /dir1

格局: hdfs  dfs  -cp URI [URI ...] <dest>
作用：将文件拷贝到指标门路中。如果 <dest>  为目录的话，能够将多个文件拷贝到该目录下。-f
选项将笼罩指标，如果它曾经存在。-p
选项将保留文件属性（工夫戳、所有权、许可、ACL、XAttr）。

hdfs dfs -cp /dir1/a.txt  /dir2/bigdata.txt

cat

hdfs dfs  -cat  URI [uri  ...]
作用：将参数所批示的文件内容输入到 stdout

hdfs dfs  -cat /bigdata.txt

tail

格局: hdfs dfs -tail path
作用: 显示一个文件的开端

text

格局:hdfs dfs -text path
作用: 以字符模式打印一个文件的内容

chmod

格局:hdfs  dfs  -chmod  [-R]  URI[URI  ...]
作用：扭转文件权限。如果应用  -R 选项，则对整个目录无效递归执行。应用这一命令的用户必须是文件的所属用户，或者超级用户。

hdfs dfs -chmod -R 777 /bigdata.txt

chown

格局:  hdfs  dfs  -chmod  [-R]  URI[URI ...]
作用：扭转文件的所属用户和用户组。如果应用  -R 选项，则对整个目录无效递归执行。应用这一命令的用户必须是文件的所属用户，或者超级用户。

hdfs  dfs  -chown  -R hadoop:hadoop  /bigdata.txt

格局: hdfs dfs  -df  -h  path
作用: 统计文件系统的可用空间信息

格局: hdfs dfs -du -s -h path
作用: 统计文件夹的大小信息

count

格局: hdfs dfs -count path
作用: 统计一个指定目录下的文件节点数量

setrep

格局:  hdfs dfs -setrep num filePath
作用: 设置 hdfs 中文件的正本数量
留神: 即便设置的超过了 datanode 的数量, 正本的数量也最多只能和 datanode 的数量是统一的

expunge (慎用)

格局:  hdfs dfs  -expunge
作用: 清空 hdfs 垃圾桶

在多人共用 HDFS 的环境下，配置设置十分重要。特地是在 Hadoop 解决大量材料的环境，如果没有配额治理，很容易把所有的空间用完造成他人无奈存取。HDFS 的配额设定是针对目录而不是针对账号，能够让每个账号仅操作某一个目录，而后对目录设置配置。

HDFS 文件的限额配置容许咱们以文件个数，或者文件大小来限度咱们在某个目录下上传的文件数量或者文件内容总量，以便达到咱们相似百度网盘网盘等限度每个用户容许上传的最大的文件的量。

 hdfs dfs -count -q -h /user/root/dir1  #查看配额信息

后果：

hdfs dfs  -mkdir -p /user/root/dir    #创立 hdfs 文件夹
hdfs dfsadmin -setQuota 2  dir      # 给该文件夹上面设置最多上传两个文件，发现只能上传一个文件

hdfs dfsadmin -clrQuota /user/root/dir  # 革除文件数量限度

在设置空间配额时，设置的空间至多是 block_size * 3 大小

hdfs dfsadmin -setSpaceQuota 4k /user/root/dir   # 限度空间大小 4KB
hdfs dfs -put  /root/a.txt  /user/root/dir

生成任意大小文件的命令:

dd if=/dev/zero of=1.txt  bs=1M count=2     #生成 2M 的文件

革除空间配额限度

hdfs dfsadmin -clrSpaceQuota /user/root/dir

平安模式是 hadoop 的一种爱护机制，用于保障集群中的数据块的安全性。当集群启动的时候，会首先进入平安模式。当零碎处于平安模式时会检查数据块的完整性。

假如咱们设置的正本数（即参数 dfs.replication）是 3，那么在 datanode 上就应该有 3 个正本存在，假如只存在 2 个正本，那么比例就是 2 /3=0.666。hdfs 默认的正本率 0.999。咱们的正本率 0.666 显著小于 0.999，因而零碎会主动的复制正本到其余 dataNode，使得正本率不小于 0.999。如果零碎中有 5 个正本，超过咱们设定的 3 个正本，那么零碎也会删除多于的 2 个正本。

在平安模式状态下，文件系统只承受读数据申请，而不承受删除、批改等变更申请。在，当整个零碎达到平安规范时，HDFS 主动来到平安模式。30s

平安模式操作命令

    hdfs  dfsadmin  -safemode  get #查看平安模式状态
    hdfs  dfsadmin  -safemode  enter #进入平安模式
    hdfs  dfsadmin  -safemode  leave #来到平安模式

HDFS 将所有的文件全副形象成为 block 块来进行存储，不论文件大小，全副厚此薄彼都是以 block 块的对立大小和模式进行存储，不便咱们的分布式文件系统对文件的治理。

所有的文件都是以 block 块的形式寄存在 hdfs 文件系统当中，在 Hadoop 1 版本当中，文件的 block 块默认大小是 64M，Hadoop 2 版本当中，文件的 block 块大小默认是 128M，block 块的大小能够通过 hdfs-site.xml 当中的配置文件进行指定。

<property>
    <name>dfs.block.size</name>
    <value> 块大小 以字节为单位 </value> // 只写数值就能够
</property>

1) 一个文件有可能大于集群中任意一个磁盘
10T*3/128 = xxx 块 2T，2T，2T 文件形式存—–> 多个 block 块，这些 block 块属于一个文件
2) 应用块形象而不是文件能够简化存储子系统
3) 块非常适合用于数据备份进而提供数据容错能力和可用性

通常 DataNode 从磁盘中读取块，但对于拜访频繁的文件，其对应的块可能被显示的缓存在 DataNode 的内存中，以堆外块缓存的模式存在 。默认状况下，一个块仅缓存在一个 DataNode 的内存中，当然能够针对每个文件配置 DataNode 的数量。 作业调度器通过在缓存块的 DataNode 上运行工作，能够利用块缓存的劣势进步读操作的性能。

例如：
连贯（join）操作中应用的一个小的查问表就是块缓存的一个很好的候选。用户或利用通过在缓存池中减少一个 cache directive 来通知 namenode 须要缓存哪些文件及存多久。缓存池（cache pool）是一个领有治理缓存权限和资源应用的管理性分组。

例如:

一个文件 130M，会被切分成 2 个 block 块，保留在两个 block 块外面，理论占用磁盘 130M 空间，而不是占用 256M 的磁盘空间

hdfs 的文件权限机制与 linux 零碎的文件权限机制相似

r:read w:write x:execute
权限 x 对于文件示意疏忽，对于文件夹示意是否有权限拜访其内容

如果 linux 零碎用户 zhangsan 应用 hadoop 命令创立一个文件，那么这个文件在 HDFS 当中的 owner 就是 zhangsan

HDFS 文件权限的目标，避免坏蛋做错事，而不是阻止好人做好事。HDFS 置信你通知我你是谁，你就是谁

为了保障 block 块的安全性，也就是数据的安全性，在 hadoop2 当中，文件默认保留三个正本，咱们能够更改正本数以进步数据的安全性

、在 hdfs-site.xml 当中批改以下配置属性，即可更改文件的正本数

<property>
     <name>dfs.replication</name>
     <value>3</value>
</property>

Client 发动文件上传申请，通过 RPC 与 NameNode 建设通信, NameNode 查看指标文件是否已存在，父目录是否存在，返回是否能够上传；
Client 申请第一个 block 该传输到哪些 DataNode 服务器上；
NameNode 依据配置文件中指定的备份数量及机架感知原理进行文件调配, 返回可用的 DataNode 的地址如：A, B, C；

Hadoop 在设计时思考到数据的平安与高效，数据文件默认在 HDFS 上寄存三份，存储策略为本地一份，同机架内其它某一节点上一份，不同机架的某一节点上一份。

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 将 pipelineack 发送给 Client；
当一个 block 传输实现之后，Client 再次申请 NameNode 上传第二个 block，反复步骤 2；

在本地网络中，两个节点被称为“彼此近邻”是什么意思？在海量数据处理中，其次要限度因素是节点之间数据的传输速率——带宽很稀缺。这里的想法是将两个节点间的带宽作为间隔的衡量标准。

节点间隔：两个节点达到最近的独特先人的间隔总和。

例如，假如有数据中心 d1 机架 r1 中的节点 n1。该节点能够示意为 /d1/r1/n1。利用这种标记，这里给出四种间隔形容。

Distance(/d1/r1/n1, /d1/r1/n1)=0（同一节点上的过程）

Distance(/d1/r1/n1, /d1/r1/n2)=2（同一机架上的不同节点）

Distance(/d1/r1/n1, /d1/r3/n2)=4（同一数据中心不同机架上的节点）

Distance(/d1/r1/n1, /d2/r4/n2)=6（不同数据中心的节点）

1）低版本 Hadoop 正本节点抉择

第一个正本在 client 所处的节点上。如果客户端在集群外，随机选一个。

第二个正本和第一个正本位于不雷同机架的随机节点上。

第三个正本和第二个正本位于雷同机架，节点随机。

2) Hadoop2.7.2 正本节点抉择

第一个正本在 client 所处的节点上。如果客户端在集群外，随机选一个。

第二个正本和第一个正本位于雷同机架，随机节点。

第三个正本位于不同机架，随机节点。

Client 向 NameNode 发动 RPC 申请，来确定申请文件 block 所在的地位；
NameNode 会视状况返回文件的局部或者全副 block 列表，对于每个 block，NameNode 都会返回含有该 block 正本的 DataNode 地址；这些返回的 DN 地址，会依照集群拓扑构造得出 DataNode 与客户端的间隔，而后进行排序，排序两个规定：网络拓扑构造中距离 Client 近的排靠前；心跳机制中超时汇报的 DN 状态为 STALE，这样的排靠后；
Client 选取排序靠前的 DataNode 来读取 block，如果客户端自身就是 DataNode，那么将从本地间接获取数据(短路读取个性)；
底层上实质是建设 Socket Stream（FSDataInputStream），反复的调用父类 DataInputStream 的 read 办法，直到这个块上的数据读取结束；
当读完列表的 block 后，若文件读取还没有完结，客户端会持续向 NameNode 获取下一批的 block 列表；
读取完一个 block 都会进行 checksum 验证，如果读取 DataNode 时呈现谬误，客户端会告诉 NameNode，而后再从下一个领有该 block 正本的 DataNode 持续读。
read 办法是并行的读取 block 信息，不是一块一块的读取；NameNode 只是返回 Client 申请蕴含块的 DataNode 地址，并不是返回申请块的数据；
最终读取来所有的 block 会合并成一个残缺的最终文件。

从 HDFS 文件读写过程中，能够看出，HDFS 文件写入时是串行写入的，数据包先发送给节点 A，而后节点 A 发送给 B，B 在给 C；而 HDFS 文件读取是并行的，客户端 Client 间接并行读取 block 所在的节点。

namenode 工作机制
1. 第一次启动 namenode 格式化后，创立 fsimage 和 edits 文件。如果不是第一次启动，间接加载编辑日志和镜像文件到内存。
2. 客户端对元数据进行增删改的申请。
3. namenode 记录操作日志，更新滚动日志。
4. namenode 在内存中对数据进行增删改查。
secondary namenode
1. secondary namenode 询问 namenode 是否须要 checkpoint。间接带回 namenode 是否查看后果。
2. secondary namenode 申请执行 checkpoint。
3. namenode 滚动正在写的 edits 日志。
4. 将滚动前的编辑日志和镜像文件拷贝到 secondary namenode。
5. secondary namenode 加载编辑日志和镜像文件到内存，并合并。
6. 生成新的镜像文件 fsimage.chkpoint。
7. 拷贝 fsimage.chkpoint 到 namenode。
8. namenode 将 fsimage.chkpoint 重新命名成 fsimage。

所有的元数据信息都保留在了 FsImage 与 Eidts 文件当中，这两个文件就记录了所有的数据的元数据信息，元数据信息的保留目录配置在了 hdfs-site.xml 当中

        <!--fsimage 文件存储的门路 -->
        <property>
                <name>dfs.namenode.name.dir</name>
                <value>file:///opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas</value>
        </property>
        <!-- edits 文件存储的门路 -->
        <property>
                <name>dfs.namenode.edits.dir</name>
                <value>file:///opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits</value>
          </property>

客户端对 hdfs 进行写文件时会首先被记录在 edits 文件中。

edits 批改时元数据也会更新。

每次 hdfs 更新时 edits 先更新后客户端才会看到最新信息。

fsimage：是 namenode 中对于元数据的镜像，个别称为检查点。

个别开始时对 namenode 的操作都放在 edits 中，为什么不放在 fsimage 中呢？

因为 fsimage 是 namenode 的残缺的镜像，内容很大，如果每次都加载到内存的话生成树状拓扑构造，这是十分耗内存和 CPU。

fsimage 内容蕴含了 namenode 治理下的所有 datanode 中文件及文件 block 及 block 所在的 datanode 的元数据信息。随着 edits 内容增大，就须要在肯定工夫点和 fsimage 合并。

应用命令 hdfs oiv

cd  /opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/current
hdfs oiv -i fsimage_0000000000000000112 -p XML -o hello.xml

查看命令 hdfs oev

cd  /opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits
hdfs oev -i  edits_0000000000000000112-0000000000000000113 -o myedit.xml -p XML

secnonaryNN 告诉 NameNode 切换 editlog。
secondaryNN 从 NameNode 中取得 FSImage 和 editlog(通过 http 形式)。
secondaryNN 将 FSImage 载入内存，而后开始合并 editlog，合并之后成为新的 fsimage。
secondaryNN 将新的 fsimage 发回给 NameNode。
NameNode 用新的 fsimage 替换旧的 fsimage。

实现合并的是 secondarynamenode，会申请 namenode 停止使用 edits，临时将新写操作放入一个新的文件中（edits.new)。

secondarynamenode 从 namenode 中 通过 http get 取得 edits，因为要和 fsimage 合并，所以也是通过 http get 的形式把 fsimage 加载到内存，而后逐个执行具体对文件系统的操作，与 fsimage 合并，生成新的 fsimage，而后把 fsimage 发送给 namenode，通过 http post 的形式。

namenode 从 secondarynamenode 取得了 fsimage 后会把原有的 fsimage 替换为新的 fsimage，把 edits.new 变成 edits。同时会更新 fsimage。

hadoop 进入平安模式时须要管理员应用 dfsadmin 的 save namespace 来创立新的检查点。

secondarynamenode 在合并 edits 和 fsimage 时须要耗费的内存和 namenode 差不多，所以个别把 namenode 和 secondarynamenode 放在不同的机器上。

fsimage 与 edits 的合并机会取决于两个参数，第一个参数是默认 1 小时 fsimage 与 edits 合并一次。

第一个参数：工夫达到一个小时 fsimage 与 edits 就会进行合并

dfs.namenode.checkpoint.period     3600

第二个参数：hdfs 操作达到 1000000 次也会进行合并

dfs.namenode.checkpoint.txns       1000000

第三个参数：每隔多长时间查看一次 hdfs 的操作次数

dfs.namenode.checkpoint.check.period   60

为了保障元数据的安全性，咱们个别都是先确定好咱们的磁盘挂载目录，将元数据的磁盘做 RAID1

namenode 的本地目录能够配置成多个，且每个目录寄存内容雷同，减少了可靠性。

具体配置计划:
hdfs-site.xml

    <property>
         <name>dfs.namenode.name.dir</name>
         <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas</value>
    </property>

在咱们的 secondaryNamenode 对 namenode 当中的 fsimage 和 edits 进行合并的时候，每次都会先将 namenode 的 fsimage 与 edits 文件拷贝一份过去，所以 fsimage 与 edits 文件在 secondarNamendoe 当中也会保留有一份，如果 namenode 的 fsimage 与 edits 文件损坏，那么咱们能够将 secondaryNamenode 当中的 fsimage 与 edits 拷贝过来给 namenode 持续应用，只不过有可能会失落一部分数据。这里波及到几个配置选项

namenode 保留 fsimage 的配置门路

<!--  namenode 元数据存储门路，理论工作当中个别应用 SSD 固态硬盘，并应用多个固态硬盘隔开，冗余元数据 -->
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas</value>
    </property>

namenode 保留 edits 文件的配置门路

<property>
        <name>dfs.namenode.edits.dir</name>
        <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits</value>
</property>

secondaryNamenode 保留 fsimage 文件的配置门路

<property>
        <name>dfs.namenode.checkpoint.dir</name>
        <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/snn/name</value>
</property>

secondaryNamenode 保留 edits 文件的配置门路

<property>
        <name>dfs.namenode.checkpoint.edits.dir</name>
        <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/snn/edits</value>
</property>

接下来咱们来模仿 namenode 的故障复原性能

杀死 namenode 过程: 应用 jps 查看 namenode 的过程号 , kill -9 间接杀死。
删除 namenode 的 fsimage 文件和 edits 文件。

根据上述配置, 找到 namenode 搁置 fsimage 和 edits 门路. 间接全副 rm -rf 删除。

拷贝 secondaryNamenode 的 fsimage 与 edits 文件到 namenode 的 fsimage 与 edits 文件夹上面去。

根据上述配置, 找到 secondaryNamenode 的 fsimage 和 edits 门路, 将内容应用 cp -r 全副复制到 namenode 对应的目录下即可。

重新启动 namenode, 察看数据是否存在。

datanode 工作机制

一个数据块在 datanode 上以文件模式存储在磁盘上，包含两个文件，一个是数据自身，一个是元数据包含数据块的长度，块数据的校验和，以及工夫戳。
DataNode 启动后向 namenode 注册，通过后，周期性（1 小时）的向 namenode 上报所有的块信息。(dfs.blockreport.intervalMsec)。
心跳是每 3 秒一次，心跳返回后果带有 namenode 给该 datanode 的命令如复制块数据到另一台机器，或删除某个数据块。如果超过 10 分钟没有收到某个 datanode 的心跳，则认为该节点不可用。
集群运行中能够平安退出和退出一些机器。

数据完整性

当 DataNode 读取 block 的时候，它会计算 checksum。
如果计算后的 checksum，与 block 创立时值不一样，阐明 block 曾经损坏。
client 读取其余 DataNode 上的 block。
datanode 在其文件创建后周期验证 checksum。

掉线时限参数设置

datanode 过程死亡或者网络故障造成 datanode 无奈与 namenode 通信，namenode 不会立刻把该节点断定为死亡，要通过一段时间，这段时间暂称作超时时长。HDFS 默认的超时时长为 10 分钟 +30 秒。如果定义超时工夫为 timeout，则超时时长的计算公式为：

timeout = 2 dfs.namenode.heartbeat.recheck-interval + 10 dfs.heartbeat.interval。

而默认的 dfs.namenode.heartbeat.recheck-interval 大小为 5 分钟，dfs.heartbeat.interval 默认为 3 秒。

须要留神的是 hdfs-site.xml 配置文件中的 heartbeat.recheck.interval 的单位为毫秒，dfs.heartbeat.interval 的单位为秒。

<property>
    <name>dfs.namenode.heartbeat.recheck-interval</name>
    <value>300000</value>
</property>
<property>
    <name>dfs.heartbeat.interval </name>
    <value>3</value>
</property>

DataNode 的目录构造
和 namenode 不同的是，datanode 的存储目录是初始阶段主动创立的，不须要额定格式化。

在 /opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/datanodeDatas/current 这个目录下查看版本号

    cat VERSION 
    
    #Thu Mar 14 07:58:46 CST 2019
    storageID=DS-47bcc6d5-c9b7-4c88-9cc8-6154b8a2bf39
    clusterID=CID-dac2e9fa-65d2-4963-a7b5-bb4d0280d3f4
    cTime=0
    datanodeUuid=c44514a0-9ed6-4642-b3a8-5af79f03d7a4
    storageType=DATA_NODE
    layoutVersion=-56

具体解释:

storageID：存储 id 号。

clusterID 集群 id，全局惟一。

cTime 属性标记了 datanode 存储系统的创立工夫，对于刚刚格式化的存储系统，这个属性为 0；然而在文件系统降级之后，该值会更新到新的工夫戳。

datanodeUuid：datanode 的惟一识别码。

storageType：存储类型。

layoutVersion 是一个负整数。通常只有 HDFS 减少新个性时才会更新这个版本号。

datanode 也能够配置成多个目录，每个目录存储的数据不一样。即：数据不是正本。具体配置如下：

- 只须要在 value 中应用逗号分隔出多个存储目录即可

  cd /opt/hadoop-2.6.0-cdh5.14.0/etc/hadoop
  <!--  定义 dataNode 数据存储的节点地位，理论工作中，个别先确定磁盘的挂载目录，而后多个目录用，进行宰割  -->
          <property>
                  <name>dfs.datanode.data.dir</name>
                  <value>file:///opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/datanodeDatas</value>
          </property>

需要阐明:

随着公司业务的增长，数据量越来越大，原有的数据节点的容量曾经不能满足存储数据的需要，须要在原有集群根底上动静增加新的数据节点。

复制一台新的虚拟机进去

将咱们污浊的虚拟机复制一台进去，作为咱们新的节点

批改 mac 地址以及 IP 地址

批改 mac 地址命令
    vim /etc/udev/rules.d/70-persistent-net.rules
批改 ip 地址命令
    vim /etc/sysconfig/network-scripts/ifcfg-eth0

敞开防火墙，敞开 selinux

敞开防火墙
    service iptables stop
敞开 selinux
    vim /etc/selinux/config

更改主机名

更改主机名命令，将 node04 主机名更改为 node04.hadoop.com
vim /etc/sysconfig/network

四台机器更改主机名与 IP 地址映射

四台机器都要增加 hosts 文件
vim /etc/hosts

192.168.52.100 node01.hadoop.com  node01
192.168.52.110 node02.hadoop.com  node02
192.168.52.120 node03.hadoop.com  node03
192.168.52.130 node04.hadoop.com  node04

node04 服务器关机重启

node04 执行以下命令关机重启
    reboot -h now

node04 装置 jdk

node04 对立两个门路
    mkdir -p /export/softwares/
    mkdir -p /export/servers/

而后解压 jdk 安装包，配置环境变量

解压 hadoop 安装包

在 node04 服务器下面解压 hadoop 安装包到 /export/servers , node01 执行以下命令将 hadoop 安装包拷贝到 node04 服务器
    cd /export/softwares/
    scp hadoop-2.6.0-cdh5.14.0- 本人编译后的版本.tar.gz node04:$PWD

node04 解压安装包
    tar -zxf hadoop-2.6.0-cdh5.14.0- 本人编译后的版本.tar.gz -C /export/servers/

将 node01 对于 hadoop 的配置文件全副拷贝到 node04

node01 执行以下命令，将 hadoop 的配置文件全副拷贝到 node04 服务器下面
    cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/
    scp ./* node04:$PWD

创立 dfs.hosts 文件

在 node01 也就是 namenode 所在的机器的 /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop 目录下创立 dfs.hosts 文件

[root@node01 hadoop]# cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop
[root@node01 hadoop]# touch dfs.hosts
[root@node01 hadoop]# vim dfs.hosts

增加如下主机名称（蕴含新退役的节点）node01
node02
node03
node04

node01 编辑 hdfs-site.xml 增加以下配置

在 namenode 的 hdfs-site.xml 配置文件中减少 dfs.hosts 属性

node01 执行以下命令 :

cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop
vim hdfs-site.xml

# 增加一下内容
    <property>
         <name>dfs.hosts</name>
         <value>/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/dfs.hosts</value>
    </property>
    <!-- 动静高低线配置: 如果配置文件中有, 就不须要配置 -->
    <property>
        <name>dfs.hosts</name>
        <value>/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/accept_host</value>
    </property>
    
    <property>
        <name>dfs.hosts.exclude</name>
        <value>/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/deny_host</value>
    </property>

刷新 namenode
- node01 执行以下命令刷新 namenode

[root@node01 hadoop]# hdfs dfsadmin -refreshNodes
Refresh nodes successful

更新 resourceManager 节点
- node01 执行以下命令刷新 resourceManager

[root@node01 hadoop]# yarn rmadmin -refreshNodes
19/03/16 11:19:47 INFO client.RMProxy: Connecting to ResourceManager at node01/192.168.52.100:8033

namenode 的 slaves 文件减少新服务节点主机名称

node01 编辑 slaves 文件，并增加新增节点的主机，更改完后，slaves 文件不须要散发到其余机器下面去

node01 执行以下命令编辑 slaves 文件 :
    cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop
    vim slaves
    
增加一下内容:     
node01
node02
node03
node04

独自启动新增节点

node04 服务器执行以下命令，启动 datanode 和 nodemanager : 
    cd /export/servers/hadoop-2.6.0-cdh5.14.0/
    sbin/hadoop-daemon.sh start datanode
    sbin/yarn-daemon.sh start nodemanager

应用负载平衡命令，让数据平均负载所有机器

node01 执行以下命令 : 
    cd /export/servers/hadoop-2.6.0-cdh5.14.0/
    sbin/start-balancer.sh

创立 dfs.hosts.exclude 配置文件

在 namenod 所在服务器的 /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop 目录下创立 dfs.hosts.exclude 文件，并增加须要服役的主机名称

node01 执行以下命令 : 
    cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop
    touch dfs.hosts.exclude
    vim dfs.hosts.exclude
增加以下内容:
    node04.hadoop.com

特地留神：该文件当中肯定要写真正的主机名或者 ip 地址都行，不能写 node04

编辑 namenode 所在机器的 hdfs-site.xml

编辑 namenode 所在的机器的 hdfs-site.xml 配置文件，增加以下配置

cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop
vim hdfs-site.xml

#增加一下内容:
    <property>
         <name>dfs.hosts.exclude</name>
         <value>/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/dfs.hosts.exclude</value>
   </property>

刷新 namenode，刷新 resourceManager

在 namenode 所在的机器执行以下命令，刷新 namenode，刷新 resourceManager : 

hdfs dfsadmin -refreshNodes
yarn rmadmin -refreshNodes

节点服役实现，进行该节点过程

期待服役节点状态为 decommissioned（所有块曾经复制实现），进行该节点及节点资源管理器。留神：如果正本数是 3，退役的节点小于等于 3，是不能服役胜利的，须要批改正本数后能力服役。

node04 执行以下命令，进行该节点过程 : 
    cd /export/servers/hadoop-2.6.0-cdh5.14.0
    sbin/hadoop-daemon.sh stop datanode
    sbin/yarn-daemon.sh stop nodemanager

从 include 文件中删除服役节点

namenode 所在节点也就是 node01 执行以下命令删除服役节点 :
    cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop
    vim dfs.hosts
    
删除后的内容: 删除了 node04
node01
node02
node03

node01 执行一下命令刷新 namenode，刷新 resourceManager

hdfs dfsadmin -refreshNodes
yarn rmadmin -refreshNodes

从 namenode 的 slave 文件中删除服役节点

namenode 所在机器也就是 node01 执行以下命令从 slaves 文件中删除服役节点 : 
    cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop
    vim slaves
删除后的内容: 删除了 node04 
node01
node02
node03

如果数据负载不平衡，执行以下命令进行平衡负载

node01 执行以下命令进行平衡负载
    cd /export/servers/hadoop-2.6.0-cdh5.14.0/
    sbin/start-balancer.sh

所有的数据都是以一个个的 block 块存储的，只有咱们可能将文件的所有 block 块全副找进去，拼接到一起，又会成为一个残缺的文件，接下来咱们就来通过命令将文件进行拼接:

上传一个大于 128M 的文件到 hdfs 下面去

咱们抉择一个大于 128M 的文件上传到 hdfs 下面去，只有一个大于 128M 的文件才会有多个 block 块。

这里咱们抉择将咱们的 jdk 安装包上传到 hdfs 下面去。

node01 执行以下命令上传 jdk 安装包

cd /export/softwares/
hdfs dfs -put jdk-8u141-linux-x64.tar.gz  /

web 浏览器界面查看 jdk 的两个 block 块 id

这里咱们看到两个 block 块 id 别离为

1073742699 和 1073742700

那么咱们就能够通过 blockid 将咱们两个 block 块进行手动拼接了。

依据咱们的配置文件找到 block 块所在的门路

依据咱们 hdfs-site.xml 的配置，找到 datanode 所在的门路
<!--  定义 dataNode 数据存储的节点地位，理论工作中，个别先确定磁盘的挂载目录，而后多个目录用，进行宰割  -->
        <property>
                <name>dfs.datanode.data.dir</name>
                <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/datanodeDatas</value>
        </property>
        
        
进入到以下门路 : 此基础门路为 上述配置中 value 的门路
cd /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/datanodeDatas/current/BP-557466926-192.168.52.100-1549868683602/current/finalized/subdir0/subdir3

1. 执行 block 块的拼接

将不同的各个 block 块依照程序进行拼接起来，成为一个残缺的文件
cat blk_1073742699 >> jdk8u141.tar.gz
cat blk_1073742700 >> jdk8u141.tar.gz
挪动咱们的 jdk 到 /export 门路，而后进行解压
mv  jdk8u141.tar.gz /export/
cd /export/
tar -zxf jdk8u141.tar.gz
失常解压，没有问题，阐明咱们的程序依照 block 块存储没有问题

作者简介：
园陌，目前就任于一家大而舒适的互联网公司，数据开发工程师
公众号【五分钟学大数据】的原创作者
本篇文章首发于公众号，版权归思否与公众号【五分钟学大数据】独特所有，转载请注明本申明！

关于hadoop:史上最全Hadoop-核心-HDFS-分布式文件系统详解上万字建议收藏

1. HDFS 概述

2. HDFS 架构

3. HDFS 的个性

4. HDFS 的命令行应用

5. hdfs 的高级应用命令

5.1. HDFS 文件限额配置

5.1.1. 数量限额

5.1.2. 空间大小限额

5.2. HDFS 的平安模式

6. HDFS 的 block 块和正本机制

6.1 形象为 block 块的益处

6.2 块缓存

6.3 hdfs 的文件权限验证

6.4 hdfs 的正本因子

7. HDFS 文件写入过程（十分重要）

7.1 网络拓扑概念

7.2 机架感知（正本节点抉择）

8.HDFS 文件读取过程（十分重要）

9. NameNode 工作机制以及元数据管理（重要）

9.1 namenode 与 datanode 启动

9.2 FSImage 与 edits 详解

9.3 FSimage 文件当中的文件信息查看

9.4 edits 当中的文件信息查看

9.5 secondarynameNode 如何辅助治理 FSImage 与 Edits 文件

9.6 namenode 元数据信息多目录配置

9.7 namenode 故障复原

10 datanode 工作机制以及数据存储

10.1 退役新数据节点

10.1.1 环境筹备

10.1.2 退役新节点具体步骤

10.2 服役旧数据

11 block 块手动拼接成为残缺数据