本文共 3317 字，大约阅读时间需要 11 分钟。

HDFS初识

Hadoop生态系统架构图

1.0版本：

2.0版本： HDFS是Hadoop Distribute File System的简称，位于生态系统图最底层的，是Hadoop的一个分布式文件系统。

HDFS优缺点

优点：

• 高容错性，数据自动保存多个副本，副本丢失后自动恢复

• 存储超大文件，MB、GB、TB级别的文件，百万规模以上的文件数量，10K+节点规模

• 最高效的访问模式，一次写入、多次读取（流式数据访问）。HDFS存储的数据集作为Hadoop的分析对象，在数据集生成后，长时间在此数据集上做分析

• 运行在普通廉价的服务器上，HDFS设计理念之一就是让它能运行在普通 硬件之上，即便硬件出现故障，也可以通过容错策略来保证数据的高可用

缺点：

• 不适用于对数据访问要求低延迟的场景，由于HDFS是为高数据吞吐量应用而设计的，必然以高延迟为代价

• 不适合存储大量小文件，HDFS中元数据（文件的基本信息，如文件名称、创建时间等）存储在NameNode的内存中，而NameNode一般为单节点，小文件数量达到一定程度，NameNode的内存吃不消

认识架构

如上图所示，HDFS也是按照Master和Slave的结构，分为NameNode、SecondaryNameNode、DataNode这几个角色。

HDFS默认会将一个文件分割成均等的好几个block，128M为1个block，然后将block按键值对存储在HDFS上，并将键值对的映射关系存到NameNode的内存中

• Client：切分文件，与NameNode交互，获取文件位置信息；与DataNode交互，进行数据读写

• NameNode：Master节点（只有一个），管理数据块的映射，处理客户端读写请求，NameNode中存储的是fsimage+editslog

• Secondary NameNode：分担NameNode的工作量，是NameNode的冷备份。相当于一个定时线程，会被定期唤醒，默认1小时唤醒，主要是从NameNode上获取fsimage和editslog来进行合并，然后再发送给NameNode，减少NameNode的工作量，防止文件太大，导致在NameNode重启时候再合并耗时过长

• Standby NameNode：NameNode的热备，除了能够完成Secondary NameNode的工作以外，还可以在NameNode出现故障时，快速切换为新的NameNode。所以一般若存在Standby NameNode情况下，Secondary NameNode是不需要的。

• DataNode：Slave节点（有多个），负责存储Client发送来的数据块block，执行数据块的读写操作，周期性的向NameNode发送心跳报告自己的状态

• 热备份：b是a的热备份，如果a坏掉，那么b马上运行代替a工作

• 冷备份：b是a的冷备份，如果a坏掉，那么b不能马上代替a工作，但是b上存储a的一些信息，减少a坏掉之后的损失

• fsimage：元数据镜像（文件系统的目录树）

• editslog：元数据的操作日志（针对文件系统做的修改操作记录）

关于block

• HDFS默认文件块block大小为128MB，如果一个文件小于block大小，则它并不占用整个block空间大小

• block不宜过大，MapReduce的Map任务一次只能处理一个block的数据，block过大会使启动的Map数量减少，影响并行处理速度

• HDFS无法高效存储大量小文件

  • 检索效率：HDFS中NameNode的元数据保存在内存中，过多的小文件需要大量内存空间，降低数据检索效率
  • 寻址开销：访问大量小文件，需要不断从一个DataNode跳到另一个DataNode，寻址开销增大
  • 线程开销：MapReduce处理大量小文件时会产生过多的Map任务，线程管理开销会大大增加

数据存储策略

HDFS默认副本的参数有3个，即每个block的副本有3个

• 副本1存放在同Client的节点上

• 副本2存放在不同于Client机架（Rack）的节点上

• 副本3存放在与副本2相同机架的另一个节点上

• 若还有其他副本，则随机挑选节点存放

数据读写

以下内容摘自博客

写操作

有一个文件FileA，100M大小。Client将FileA写入到HDFS上

HDFS按默认配置，即默认一个block为64M（这里讲的是Hadoop1.0），分为三份副本

HDFS分布在三个机架上Rack1，Rack2，Rack3

• Client将FileA按64M分块，分成两块，block1和block2

• Client向NameNode发送写数据请求，如图蓝色虚线①------>

• NameNode节点，记录block信息，并返回可用的DataNode，如粉色虚线②--------->

  原理：

  a、NameNode具有RackAware机架感知功能，这个可以配置

  b、若client为DataNode节点，那存储block时，规则为：副本1，同client的节点上；副本2，不同机架节点上；副本3，同第二个副本机架的另一个节点上；其他副本随机挑选

  c、若client不为DataNode节点，那存储block时，规则为：副本1，随机选择一个节点上；副本2，不同副本1的其他机架上；副本3，同副本2相同机架的另一个节点上；其他副本随机挑选

• client向DataNode发送block1，发送过程是以流式写入

  流式写入过程：

  a、将64M的block1按64k的package划分

  b、然后将第一个package发送给host2

  c、host2接收完后，将第一个package发送给host1，同时client向host2发送第二个package

  d、host1接收完第一个package后，发送给host3，同时接收host2发来的第二个package

  e、以此类推，如图红线实线所示，直到将block1发送完毕

  f、host2,host1,host3向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示

  g、client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就真完成了。如图黄色粗实线

  h、发送完block1后，再向host7，host8，host4发送block2，如图蓝色实线所示

  i、发送完block2后，host7,host8,host4向NameNode，host7向Client发送通知，如图浅绿色实线所示

  j、client向NameNode发送消息，说我写完了，如图黄色粗实线。。。这样就完毕了

通过以上写过程，我们可以得知：

a、写1T文件，我们需要3T的存储，3T的网络流量带宽

b、在执行读或写的过程中，NameNode和DataNode通过HeartBeat进行通信，确定DataNode活着。如果发现DataNode死掉了，就将死掉的DataNode上的数据，放到其他节点去。读取时，要读其他节点去

c、挂掉一个节点，没关系，还有其他节点可以备份；甚至，挂掉某一个机架，也没关系；其他机架上，也有备份

漫画版的写入流程：

读操作

读操作就简单一些了，如图所示，client要从datanode上读取FileA，而FileA由block1和block2组成 那么，读操作流程为：

• client向namenode发送读请求

• namenode查看Metadata信息，返回fileA的block的位置

  block1:host2,host1,host3block2:host7,host8,host4

• block的位置是有先后顺序的，先读block1，再读block2，而且block1去host2上读取，然后block2去host7上读取

上面例子中，client位于机架外，那么如果client位于机架内某个DataNode上，例如client是host6，那么读取的时候，遵循的规律是：优选读取本机架上的数据

漫画版读取流程：

转载地址：http://hzpxi.baihongyu.com/