深入理解HDFS

一、HDFS介绍

HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集（Large Data Set）的应用处理带来了很多便利。

HDFS优点

1.高容错性

• 数据自动保存多个副本。它通过增加副本的形式，提高容错性
• 某一个副本丢失以后，它可以自动恢复

2.适合批处理

• 它是通过移动计算而不是移动数据
• 它会把数据位置暴露给计算框架。

3.适合处理大数据

• 处理数据达到 GB、TB、甚至PB级别的数据。
• 能够处理百万规模以上的文件数量，数量相当之大。
• 能够处理10K节点的规模

4.流式文件访问

• 一次写入，多次读取。文件一旦写入不能修改，只能追加（这是算缺点吗）。
• 它能保证数据的一致性（通过校验机制）

5.可构建在廉价机器上

• 它通过多副本机制，提高可靠性。
• 它提供了容错和恢复机制。比如某一个副本丢失，可以通过其它副本来恢复。

HDFS 缺点

1.低延时数据访问

• 比如毫秒级的来存储数据，这是不行的，它做不到。

• 它适合高吞吐率的场景，就是在某一时间内写入大量的数据。但是它在低延时的情况下是不行的，比如毫秒级以内读取数据，这样它是很难做到的。

  HDFS是单Master的，所有的对文件的请求都要经过它，当请求多时，肯定会有 延时。

2.小文件存储

• 存储大量小文件的话，它会占用 NameNode大量的内存来存储文件、目录和块信息（元信息）。这样是不可取的，因为NameNode的内存总是有限的。
• 小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。

3、并发写入、文件随机修改

• 一个文件只能有一个写，不允许多个线程同时写。
• 仅支持数据 append（追加），不支持文件的随机修改。

针对HDFS缺点可能的改进措施

高延迟问题：

使用缓存或多master设计可以降低client的数据请求压力，以减少延时。

存储小文件问题：

1、利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。

2、横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。

3、多Master设计，正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件。（Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。）

二、HDFS存储数据

架构图

1.png

HDFS 采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。

Client：就是客户端。

​ 1、切分文件：文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。

​ 2、与 NameNode 交互，获取文件的位置信息。

​ 3、与 DataNode 交互，读取或者写入数据。

​ 4、Client 提供一些命令来管理 HDFS，比如启动或者关闭HDFS。

​ 5、Client 可以通过一些命令来访问 HDFS。

NameNode：就是 master，它是一个主管、管理者。

​ 1、管理 HDFS 的名称空间（namespace）。

​ 2、管理数据块（Block）映射信息

​ 3、配置副本策略

​ 4、处理客户端读写请求。

DataNode：就是Slave，NameNode 下达命令，DataNode 执行实际的操作。

​ 1、存储实际的数据块。

​ 2、执行数据块的读/写操作。

Secondary NameNode：并非 NameNode 的热备份（两个节点同时运行，一个挂掉了切换另一个）。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。

​ 1、辅助 NameNode，分担其工作量。

​ 2、定期合并 fsimage和fsedits，并推送给NameNode。

​ 3、在紧急情况下，可辅助恢复 NameNode。

三、HDFS读写数据流程

HDFS写数据流程

客户端将数据写入HDFS的流程图如下：

2.png

流程如下：

• 使用HDFS提供的客户端Client， 向远程的Namenode发起RPC请求
• Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录， 否则会让客户端抛出异常；
• 当客户端开始写入文件的时候， 客户端会将文件切分成多个packets， 并在内部以数据队列“data queue（ 数据队列） ”的形式管理这些packets， 并向Namenode申请blocks， 获取用来存储replications的合适的datanode列表， 列表的大小根据Namenode中replication的设定而定；
• 开始以pipeline（ 管道） 的形式将packet写入所有的replications中。 客户端把packet以流的方式写入第一个datanode， 该datanode把该packet存储之后， 再将其传递给在此pipeline中的下一个datanode， 直到最后一个datanode， 这种写数据的方式呈流水线的形式。
• 最后一个datanode成功存储之后会返回一个ack packet（ 确认队列） ， 在pipeline里传递至客户端， 在客户端的开发库内部维护着”ack queue”， 成功收到datanode返回的ack packet后会从”ack queue”移除相应的packet。
• 如果传输过程中， 有某个datanode出现了故障， 那么当前的pipeline会被关闭， 出现故障的datanode会从当前的pipeline中移除， 剩余的block会继续剩下的datanode中继续以pipeline的形式传输， 同时Namenode会分配一个新的datanode， 保持replications设定的数量。
• 客户端完成数据的写入后， 会对数据流调用close()方法， 关闭数据流；

• 只要写入了dfs.replication.min的复本数（ 默认为1），写操作就会成功， 并且这个块可以在集群中异步复制， 直到达到其目标复本数（replication的默认值为3），因为namenode已经知道文件由哪些块组成， 所以它在返回成功前只需要等待数据块进行最小量的复制。

  
  3.png

从上面的图中，我们可以清楚的看出NameNode对应于用户的三个动作分别
以create、 addBlock、 complete来进行相关的处理。现在，我就来详细的分析NameNode的这三个动作是如何实现的。

• NameNode的create动作主要是为客户端传过来的文件名在HDFS的Namesystem中申请一个名字空间，并为之建立一个响应的iNode，当然，这个iNode的状态是underConstruction，然后为这个客户创建一个该文件的租约，就是文件的独占锁，以防止其它的客户端对这个文件同时写。
• NameNode的addBlock动作主要是为文件创建一个新的Block，并为这个Block的副本分配存储DataNode节点，最后给客户端返回一个LocatedBlock对象，该对象包含Block的副本应该存放的位置。在这里我想说得是，NameNode节点此时并不保存该Block的副本位置，而是等到成功接收该Block的数据节点自动报告时它才正式记录该Block的一个副本的位置，这样做是由于HDFS不能保证Block一开始分配的数据节点都能成功结束Block。
• NameNode的complete动作就是更改与当前文件节点相关的状态，同时释放文件的租约。另外，NameNode还要判断文件的所有Blocks的副本是否已满足，对于还不满足的Blocks， NameNode将其放入neededReplications队列中，让其它的后台线程来负责这些Block的副本情况。
  block是datanode存放数据的基本单位

HDFS读数据流程

客户端读取HDFS中的数据流程图如下：

4.png

• 使用HDFS提供的客户端Client， 向远程的Namenode发起RPC请求；
• Namenode会视情况返回文件的部分或者全部block列表， 对于每个block， Namenode都会返回有该block拷贝的DataNode地址；
• 客户端Client会选取离客户端最近的DataNode来读取block； 如果客户端本身就是DataNode， 那么将从本地直接获取数据；
• 读取完当前block的数据后， 关闭当前的DataNode链接， 并为读取下一个block寻找最佳的DataNode；
• 当读完列表block后， 且文件读取还没有结束， 客户端会继续向Namenode获取下一批的block列表；
• 读取完一个block都会进行checksum验证， 如果读取datanode时出现错误， 客户端会通知Namenode， 然后再从下一个拥有该block拷贝的datanode继续读。

四、HDFS的安全威胁

大量小文件上传问题 （拒绝服务）

namenode中的块映射表，命名空间数据 文件元数据和

消耗cpu

寻找文件耗时 拒绝服务

随着文件数增加 上传文件时间数增加

数据回收的延迟问题（信息泄露）

在数据回收的过程中，即使文件系统中的trash文件夹下的文件夹被删除后（1小时后），数据块没有被真正删除，而是需要等待副本管理器扫描到该块后才能被彻底删除（6小时后），即HDFS上删除文件一定时间内，datanode上文件依然存在

导致结果，在延迟时间段内窃取数据

数据块权限问题（信息泄露）

所有数据块都以明文的方式，按文件格式存储在HDFS的数据节点的操作系统之上，块文件存储时在节点上的默认权限为允许其他用户读，导致操作系统上任何用户都能窃取该数据块的内容

负载均衡脆弱性问题（信息泄露+拒绝服务）

节点动态增加时，hadoop不自动提供负载均衡操作（管理员手动操作）

在负载均衡成功后，源数据节点没有能够及时删除已经拷贝走的冗余数据块，而是继续占用节点空间，造成资源浪费（注意跟垃圾回收的不同）

在上述缺陷下，当系统资源不足的情况下，当用户继续上传新文件但系统没有可用空间，就会拒绝用户的上传操作

伪节点问题（信息泄露）

datanode和namenode之间的交互信息会被窃取，以后数据也可能流入这个假的节点中

通过发送假ip（这个ip可能是正在死亡的节点（合法节点）的），这样假几点就会被当做真节点，真节点死亡