Hadoop中HDFS写入文件的原理剖析

197次阅读

共计 1861 个字符，预计需要花费 5 分钟才能阅读完成。

要为即将到来的大数据时代最准备不是，下面的大白话简单记录了 Hadoop 中 HDFS 在存储文件时都做了哪些个事情，位将来集群问题的排查提供一些参考依据。

步入正题

创建一个新文件的过程：

第一步：客户端通过 DistributedFilesystem 对象中的 creat（）方法来创建文件，此时，RPC 会通过一个 RPC 链接协议来调用 namenode，并在命名空间中创建一个新文件，namenode 执行各种权限以及文件 isexist 的检查，dfs 返回一个输出流，否则抛出 IOEXCEPTION。输出流控制一个 DFSoutPutstream，负责处理数据节点和名称节点之间的通信

第二步：客户端开始通过输出流写入数据，DFSoutPutstream 将客户端写入的数据分成一个个的数据包包，然后写入到 dfs 中的一个 queue，这些 queue 中的数据包被 dfs 中的数据流管理，数据流通过一定的分发机制，将这些数据包形成副本并存放在 datanode 上，当前例如我们设置的 dfs.replication=3，则需要将副本放在三个 datanode 上，这三个 datanode 会通过一个管线连接，数据流将包分流给管线中第一个的 datanode，这个节点会存储包并且发送给管线中的第二个 datanode。同样地，第二个数据节点存储包并且传给管线中第三个 datanode

（我就不画流程图了，大家肯定能想明白咯）

第三步：其实第三步应该归属到第二步里面，上一步中所提到的 DFSoutPutstream 有一个内部等待确认 queue，专门用来存放 datanode 收到的数据包，只有管线中所有的 datanode 收到副本并且存储成功返回成功标识后等待确认 queue 才会移除所有的数据包。大家此时可能要问了，如果在复制过程中管线中的某一个 datanode 发生了故障，hadoop 是如何处理的呢？这就是 hadoop 的容错的强大之处了；

首先、管线会关闭，等待确认队列中的所有数据包都会被添加回到数据队列，由此可以保证数据包的完整性和顺序性

其次、当前块中取一个正常的数据节点，使其联系 namenode，将故障节点告知 namenode、由此下次故障节点恢复后能将里面残留的不完整的副本文件清空。

第三、故障节点被删除，余下的数据包继续写入到剩下的节点中。namenode 注意到当前的副本不足（dfs.replication=3），则会在另外一个 datanode 上安排创建新的副本。

此时问题就来了（挖掘技术哪家强？？），如果在写入期间，datanode 大规模的发生故障怎么办眤？？

其实这种情况很少发生但林子大了什么鸟都有是不是，我们在部署 hadoop 有一个配置选项：dfs.replication.min 一般默认是 1 , 意思就是说只要有一个节点成功，则 hdfs 就认为本次写入时成功的，后续的它本身会自己去意识到副本数的不足而去进行复制冗余。

最后、书接上文，客户端写入完成后就会通过 DistributedFilesystem 调用 close（）方法，该方法有一个神奇的作用，它会将数据队列剩下的所有包包都放在等待确认 queue 中，并等待确认，namenode 中已经记录下来了所有副本存放的 datanode。

看完理论知识和大家用简单地大白话分享下，可有意思了

Hadoop 中 HDFS 读取文件的原理剖析 http://www.linuxidc.com/Linux/2015-02/113639.htm

Hadoop 中 HDFS 读取和写入的工作原理 http://www.linuxidc.com/Linux/2015-02/112775.htm

将本地文件拷到 HDFS 中 http://www.linuxidc.com/Linux/2013-05/83866.htm

从 HDFS 下载文件到本地 http://www.linuxidc.com/Linux/2012-11/74214.htm

将本地文件上传至 HDFS http://www.linuxidc.com/Linux/2012-11/74213.htm