2、HDFS读写流程

1 重要概念

2 读数据流程

3 写数据流程

4 数据完整性

1 重要概念

---

在介绍HDFS读写流程之前，有必要先搞清楚几个概念：block、packet与chunk。

1. block
   文件上传前需要分块，一般为128MB，可以去改但不推荐。因为块太小：寻址时间占比过高。块太大：Map任务数太少，作业执行速度变慢。它是最大的一个单位。

2. packet
   packet是第二大的单位，它是client端向DataNode或DataNode的PipLine之间传数据的基本单位，默认64KB。

3. chunk
   chunk是最小的单位，它是client向DataNode或DataNode的PipLine之间进行数据校验的基本单位，默认512Byte，因为用作校验，故每个chunk需要带有4Byte的校验位。所以实际每个chunk写入packet的大小为516Byte。由此可见真实数据与校验值数据的比值约为128 : 1。（即64*1024 / 512）

例如，在client端向DataNode传数据的时候，HDFSOutputStream会有一个chunk buff，写满一个chunk后，会计算校验和并写入当前的chunk。之后再把带有校验和的chunk写入packet，当一个packet写满后，packet会进入dataQueue队列，其他的DataNode就是从这个dataQueue获取client端上传的数据并存储的。同时一个DataNode成功存储一个packet后之后会返回一个ack packet，放入ack Queue中。

2 读数据流程

---

1.  HDFS客户端通过调用FileSystem对象的open()方法来打开希望读取的文件，对于HDFS来说，这个对象是DistributedFileSystem的一个实例。
2. DistributedFileSystem通过使用远程过程调用（RPC）来调用NameNode，以确定文件起始块的位置。对于每个块，NameNode返回具有该块副本的DataNode地址。此外，这些DataNode根据它们与客户端的距离来排序（根据集群的网络拓扑），如果该客户端本身就是一个DataNode，便从本地读取数据。接着DistributedFileSystem类返回一个FSDataInputStream对象（一个支持文件定位的输入流）给客户端以便读取数据。FSDataInputStream类转而封装DFSInputStream对象，该对象管理着DataNode和NameNode的 I/O。
3. 客户端对这个输入流调用read()方法，存储着文件起始几个块的DataNode地址的DFSInputStream随即连接距离最近的文件中第一个块所在的DataNode。
4. 通过对数据流反复调用read()方法，可以将数据从DataNode传输到HDFS 客户端。
5. 读取数据到块的末端时，DFSInputStream关闭与该DataNode的连接，然后寻找下一个块的最佳DataNode。在HDFS客户端所看来它一直在读取一个连续的流，这些对于客户端来说是透明的。
6. 客户端从流中读取数据时，块是按照打开DFSInputStream与DataNode新建连接的顺序读取的，它也会根据需要询问NameNode来检索下一批数据块的DataNode的位置，一旦客户端读取完毕，就会调用close()方法。但在读取时，DFSInputStream与DataNode通信时遇到错误，会尝试从这个块的另外一个最邻近DataNode读取数据，它也会记住那个故障DataNode，以保证以后不会反复读取该节点上后续的块。DFSInputStream也会通过校验和确认从DataNode发来的数据是否完整。如果发现有损坏的块，DFSInputStream会试图从其他DataNode读取其复本，也会将被损坏的块通知给NameNode。

HDFS读数据过程这一设计的一个重点是：客户端可以直接连接到DataNode检索数据，且NameNode告知客户端每个块所在的最佳DataNode，由于数据流分散在集群中的所有DataNode，所以这种设计能使HDFS扩展到大量的并发客户端。同时，NameNode只需要响应块位置的请求（这些信息存储在内存中，因而非常高效），无需响应数据请求，否则随着客户端数量的增长，NameNode会很快称为瓶颈。

3 写数据流程

---

1. 客户端向NameNode发出写文件请求。
2. 检查是否已存在文件、检查权限。若通过检查，直接先将操作写入EditLog，并返回输出流对象。（注：WAL，write ahead log，先写Log，再写内存，因为EditLog记录的是最新的HDFS客户端执行所有的写操作。如果后续真实写操作失败了，由于在真实写操作之前，操作就被写入EditLog中了，故EditLog中仍会有记录，我们不用担心后续client读不到相应的数据块，因为在第5步中DataNode收到块后会有一返回确认信息，若没写成功，发送端没收到确认信息，会一直重试，直到成功）
3. client端按128MB的块切分文件。
4. client将NameNode返回的分配的可写的DataNode列表和Data数据一同发送给最近的第一个DataNode节点，此后client端和NameNode分配的多个DataNode构成pipeline管道，client端向输出流对象中写数据。client每向第一个DataNode写入一个packet，这个packet便会直接在pipeline里传给第二个、第三个…DataNode。（注：并不是写好一个块或一整个文件后才向后分发）
5. 每个DataNode写完一个块后，会返回确认信息。（注：并不是每写完一个packet后就返回确认信息，个人觉得因为packet中的每个chunk都携带校验信息，没必要每写一个就汇报一下，这样效率太慢。正确的做法是写完一个block块后，对校验信息进行汇总分析，就能得出是否有块写错的情况发生）
6. 写完数据，关闭输输出流。
7. 发送完成信号给NameNode。（注：发送完成信号的时机取决于集群是强一致性还是最终一致性，强一致性则需要所有DataNode写完后才向NameNode汇报。最终一致性则其中任意一个DataNode写完后就能单独向NameNode汇报，HDFS一般情况下都是强调强一致性）

4 数据完整性

---

读写过程，数据完整性如何保持？

通过校验和。因为每个chunk中都有一个校验位，一个个chunk构成packet，一个个packet最终形成block，故可在block上求校验和。

HDFS 的client端即实现了对 HDFS 文件内容的校验和 (checksum) 检查。当客户端创建一个新的HDFS文件时候，分块后会计算这个文件每个数据块的校验和，此校验和会以一个隐藏文件形式保存在同一个 HDFS 命名空间下。当client端从HDFS中读取文件内容后，它会检查分块时候计算出的校验和（隐藏文件里）和读取到的文件块中校验和是否匹配，如果不匹配，客户端可以选择从其他 Datanode 获取该数据块的副本。

HDFS中文件块目录结构具体格式如下：

${dfs.datanode.data.dir}/
├── current
│ ├── BP-526805057-127.0.0.1-1411980876842
│ │ └── current
│ │ ├── VERSION
│ │ ├── finalized
│ │ │ ├── blk_1073741825
│ │ │ ├── blk_1073741825_1001.meta
│ │ │ ├── blk_1073741826
│ │ │ └── blk_1073741826_1002.meta
│ │ └── rbw
│ └── VERSION
└── in_use.lock

in_use.lock表示DataNode正在对文件夹进行操作
rbw是“replica being written”的意思，该目录用于存储用户当前正在写入的数据。
Block元数据文件（*.meta）由一个包含版本、类型信息的头文件和一系列校验值组成。校验和也正是存在其中。

参考文章

https://www.cnblogs.com/jnba/p/10550394.html