HDFS读写流程（史上最精炼详细）
如需转载，请注明出处：
概述
开始之前先看看其基本属性，HDFS（Hadoop Distributed File System）是GFS的开源实现。
特点如下：
能够运⾏在廉价机器上，硬件出错常态，需要具备⾼容错性
⾯向⼤规模数据集，能够进⾏批处理、能够横向扩展
简单⼀致性模型，假定⽂件是⼀次写⼊、多次读取
缺点：
不⽀持低延迟数据访问
不适合⼤量⼩⽂件存储（因为每条元数据占⽤空间是⼀定的）
不⽀持并发写⼊，⼀个⽂件只能有⼀个写⼊者
不⽀持⽂件随机修改，仅⽀持追加写⼊
HDFS中的block、packet、chunk
很多博⽂介绍HDFS读写流程上来就直接从⽂件分块开始，其实，要把读写过程细节搞明⽩前，你必须知道block、packet与chunk。下⾯分别讲述。
1. block
这个⼤家应该知道，⽂件上传前需要分块，这个块就是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中。 HDFS写流程
写详细步骤：
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⼀般情况下都是强调强⼀致性）
HDFS读流程
读相对于写，简单⼀些
读详细步骤：
1. client访问NameNode，查询元数据信息，获得这个⽂件的数据块位置列表，返回输⼊流对象。
2. 就近挑选⼀台datanode服务器，请求建⽴输⼊流 。
3. DataNode向输⼊流中中写数据，以packet为单位来校验。
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_a
│ │ │ ├── blk_1073741826
│ │ │ └── blk_a
│ │ └── rbw
│ └── VERSION
└── in_use.lock
in_use.lock表⽰DataNode正在对⽂件夹进⾏操作
rbw是“replica being written”的意思，该⽬录⽤于存储⽤户当前正在写⼊的数据。
Block元数据⽂件（*.meta）由⼀个包含版本、类型信息的头⽂件和⼀系列校验值组成。校验和也正是存在其中。
若有其他好的细节，欢迎⼤家补充交流！
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议