文章目录
- HDFS初识
- HDFS优缺点
- 认识架构
- 关于block
- 数据存储策略
- 数据读写
- 写操作
- 读操作
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相同机架的另一个节点上
- 若还有其他副本，则随机挑选节点存放
数据读写
以下内容摘自博客 http://www.daniubiji.cn/archives/596
写操作
有一个文件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,host3
block2:host7,host8,host4- block的位置是有先后顺序的，先读block1，再读block2，而且block1去host2上读取，然后block2去host7上读取
上面例子中，client位于机架外，那么如果client位于机架内某个DataNode上，例如client是host6，那么读取的时候，遵循的规律是：优选读取本机架上的数据
漫画版读取流程：
