hdfs读写流程_带你了解大数据组件之存储组件，HDFS分布式存储系统

文件系统与元数据

文件系统其实就相当于是字典，字典中有检字表还有正文。文件系统中有元数据和数据。

文件系统——>字典

元数据——>检字表

数据——>正文

文件系统中包含了数据和元数据，并且文件系统还是底层存储的组织者。它指定了数据块的使用方式和维护方式。

文件系统：NTFS、FAT32/16、ext2/3/4

HDFS认为硬件总是不可靠的。其实不仅是HDFS，整个Hadoop都认为硬件不可靠。在实际的统计中，IDC机房由于硬件故障导致的数据丢失或者是数据失效，57%都是由硬件故障造成的。所以HDFS不能将数据安全完全的依托于硬件来实现，因为大数据中，数据丢失所造成的损失是无法弥补的。那么对于HDFS来说，所有的数据保护都是由自身软件完成的。

无论是什么文件系统，都需要读写数据，那么HDFS在设计之初，就想到了一个问题，海量的数据写入都是为了做分析使用。所以对于历史性的分析数据来说，读的业务往往是大于写的业务的，而且是超过多倍。写业务一般也以新写入为主，改写基本没有。所以HDFS设计读写进程的时候，只设计了一个写进程，而设计了非常多的读进程，那么这样做，写进程对于读的影响就会占到最低，并且写进程的优先级最低。所以HDFS支持高吞吐量的数据读取。

HDFS在设计之初，就指定了一个准则，不管数据文件有多大，元数据固定150b。那么这样做就打破了文件系统对文件维护时元数据的大小。固定为150b之后，我们就可以存储大文件仍然使用很小的元数据开销。

为了能够快速的查找元数据，所以我们将元数据存放在内存中，而内存的大小是固定有限的。所以大量的小文件会占用过多的内存空间，导致内存利用率飚高。

HDFS不适合随机写入，第一个原因是因为读写进程的设计问题，另一个就是大量的业务会长期占用带宽，而随机写入会出现很高的延迟。

大文件的存储和低延迟的读取本质上是鱼和熊掌的关系。所以为了保证数据的正常写入，我们就牺牲了低延迟的读取功能。

所以在实际的选择中，一个业务应该使用什么文件系统其实更多的是根据业务的实际需求。

HDFS是运行在通用硬件平台上的文件系统。指的就是HDFS不论底层是什么系统，什么架构，都可以进行搭建。

HDFS使用的是WORM模型(Write once read many)这种类型的业务，数据一般在写入之后，就基本不再做更改了。那么HDFS根据Worm模型设计了一套操作，当数据写入完成之后，就不在允许更改。那么除此之外，HDFS还执行了一个操作叫做追加写。追加写允许用户向当前的文件结尾添加数据，但是只能添加一次，之后就被锁死无法追加，无法改写，除非删除数据，重新传输。

HDFS架构：

1.NameNode：名称节点，元数据节点，其主要工作是用于存储元数据和维护元数据。并且要记录用户对于元数据的更改信息(操作日志)。NameNode作为一个软件进程，平时是运行在内存中的，那么在开机时，Hadoop底层系统会将该进程调用运行在内存中。NameNode分为主备两个进程。平时由主来保证业务的正常执行，备用于做持久化操作。

2.DataNode：数据节点，其作用是维护和存储数据，并且还可以存储NameNode所维护的元数据和日志信息。DataNode需要周期性的上报自己所维护数据的摘要信息给NameNode，NameNode负责及时的更新元数据。

3.Client：Client是HDFS中的一个基本的进程，用于提供外部访问的接口，并且对内部来说，用于向DataNode和NameNode发起请求。相当于，用户提交一个请求给HDFS，Client受理该请求之后，会代理该用户进行HDFS的内部交互。这样做就可以保证HDFS内部的数据安全

HDFS-HA(进程安全性保护)

1.HDFS认为 硬件永远是不可靠的

2.底层组件的安全性由上层组件保护，上层组件安全性由zookeeper保护、

DataNode作为一个进程，负责维护数据，并且上报数据信息给NameNode，为了保证DataNode的安全性，那么HDFS设计DataNode必须定时上报心跳数据包给NameNode进行保活。但是DataNode周期性还要上报自己所维护的数据信息，所以周期性上报两个数据包不利于带宽并且过于繁杂，那么我们将心跳信息和维护的数据信息合并为一个信息，其实就是所维护的数据信息。那么NameNode收到维护的数据信息包，就相当于是收到了心跳数据。

NameNode维护元数据，存在有主备进程，NameNode作为HDFS的顶级进程会周期性的通过ZKFC进程(zookeeper failover contaller)向Zookeeper上报心跳信息。一旦主节点没有上报心跳 ，那么Zookeeper就认为主节点故障，从而通过zkfc联系备节点下发故障切换指令。备NameNode转换角色为主NameNode。

备节点平时不参与业务，但是备节点参与了日志合并的元数据持久化操作，备节点通过JN进程联系主节点获取用户对元数据的操作日志，执行元数据持久化。

那么保护进程安全是通过HDFS-HA实现的，那么保护数据安全也需要HDFS来实现，因为HDFS认为硬件总是不可靠的。

作为一个组件软件，HDFS如果想要在不依赖硬件的前提下去保护数据，那么就需要通过备份的形式实现，也就是副本机制。

在HDFS中，我们通过三副本来实现。那么相当于每写入一份数据，就等同于写了4份数据。

在一个数据中心内，会存在有很多的机柜，那么我们认为如果两份数据存储在相同的设备上，也就是指数据存储在同一台服务器上，那么两个数据的距离为0，如果两份数据存储在相同机架上的不同的服务器上，那么距离为2，如果两份数据存储在不同的机柜中，那么距离为4。

首先源数据按照规则写入，第一份副本，要求距离和源数据为0。第二份数据要求距离和源数据为2/4，由机器随机选择。第三份数据要求距离和源数据为4/2

系统默认一个数据有3个副本，那么如果想要增大副本数，后边的副本随机写。副本至少3个。

元数据持久化：

1.Fsimage.iso文件是文件系统元数据的镜像文件，那么在系统开机时，系统将该文件加载到内存中，之后的所有读写都是在内存中完成的，和fsimage无关。

2.editlog：记录的是用户对于元数据的操作日志。

没有元数据持久化会怎么样

由于系统开机的时候加载的是fsimage。而这

个文件是一直都没有更新的，因为系统开机加载之后就不在使用了，那么元数据镜像文件将会一直保持在一个时间点，而数据的时间点会一直持续推移，那么随着时间的流逝，我们会发现元数据镜像中记录的元数据和数据的差异越来越大，这个时候如果系统重启，那么为了弥补这种差异，我们必须使用editlog中记录的日志回滚fsimage，但是回滚的时间非常长。所以为了减小回滚的时间，其实也就是减小元数据镜像文件和数据的差异，所以我们要周期性的去更新元数据镜像文件。这也就是元数据持久化，所以元数据持久化通过周期性更新fsimage文件，来保证当系统重启的时候，不会由于过长时间的回滚元数据造成系统的长时间加载和等待。

持久化过程:

1.当editlog满64m或者是1h的时候，那么备NameNode通知主NameNode生成Editlog.new文件，并且获取主NameNode上的Editlog文件(这里的获取是复制，Editlog.new是记录本次持久化开始，到下一次持久化开始前的元数据操作日志)。

2.备NameNode获取Fsimage文件，并且通过JN进程获取Editlog。

3.下一步备NameNode进行文件合并，将Editlog中的操作日志合并到Fsimage中，生成Fsimage.ckpt。

4.备端将Fsimage.ckpt回传到主NameNode上，然后用Fsimage.ckpt回滚Fsimage文件，其实做的就是覆盖操作。

5.旧的editlog被直接删除，editlog.new重命名为editlog

为什么editlog可以被直接删除？

因为editlog中的操作日志 已经被直接合并到新的fsimage中了，所以没有留存的必要。

重建数据盘丢失数据

当DataNode周期性没有上报心跳的时候，NameNode认为DataNode故障，所以在确认数据 安全性可以得到保证的情况下，NameNode会首先更改元数据。更改用户读取的位置信息。保证业务连续性。之后就要去做数据的恢复操作其实就是副本的重建操作。

HDFS读写流程

新写流程：

1.用户下发请求给Client。

2.Client收到请求之后通过Distributed FS进程联系NameNode要求NameNode创建元数据。

3.NameNode收到请求之后，会创建元数据并且分配写空间。之后返回创建完成给Distributed FS

4.Client下一步会通过FSOutputStream将数据下发到DataNode中，DataNode收到之后，写完成并且启动副本机制，副本机制是由DataNode控制的。

5.数据写入完成之后，写源数据的DataNode向Client返回一个写完成。

6.Client收到写完成之后，会再次通过Distributed FS去联系NameNode补充元数据。

7.补充完成之后NameNode会向Client返回修改完成的信息。Client向用户返回写完成的结果

HDFS详解