hadoop之HDFS
分布式文件系统HDFS
需要实现以下的一些目标:
1. 廉价的硬件设备
2. 流数据读写(和传统系统区别的地方,全部的数据一股脑的读取)
3. 大数据集(一个文件可能有时候大到好几个T)
4. 简单的文件模型(获取了批量处理的特性,只能追加,不可以修改)
5. 强大的跨平台特性(java开发的)
HDFS的一些局限性:
1. 不适合低延迟的数据访问(不能满足实时的处理需求)
2. 无法高效存储大量的小文件(小文件目录索引太大会让内存数据变大)
3. 不支持多用户写入及任意修改文件
HDFS块:
块要比普通文件大很多,面向大规模存储,为了减少寻址时候的开销。
优点:
1. 支持大规模文件的存储,将一个大文件切割,放到不同的机器上面
2. 简化系统的设计,块的大小是固定的,方便管理元数据
3. 方便数据的备份
NameNode | DataNode |
存储元数据(数据目录) | 存储文件内容 |
元数据保存在内存中 | |
NameNode的数据结构:
FsImage:用于维护文件系统树以及文件树中所有的文件和文件夹的元数据
(文件的复制等级,修改和访问时间,访问权限,块大小,组成文件的块)
EditLog:操作日志文件,记录了所有对文件的创建,删除,重命名等操作
NameNode的启动:
FsImage加载到内存,然后与EditLog合并,得到一个新的FsImage,然后创建一个空的EidtLog。这样做的原因是,FsImage太大,数据的修改会让系统变慢,所以文件的修改操作会在EditLog中执行,这样就快多了。
当EditLog变大怎么办?
SecondaryNameNode!!!!
(1) SecondaryNameNode会定期和NameNode通信,请求其停止使用EditLog文件,暂时将新 的操作写到一个新的edit.new上面,这个操作是瞬间完成的
(2) SecondaryNameNode通过HTTP GET从NameNode上获取FsImage和EditLog文件,下载到本地对应的目录下
(3) 将下载的FsImage载入内存,一条条执行EditLog文件中的更新,这个过程就是FsImage和EditLog的合并操作
(4) SecondaryNameNode执行完(3)之后,通过POST方式将新的FsImage文件发送给NameNode
(5)NameNode替换FsImage,edit.new替换EditLog
DataNode负责具体数据的存储:
每个数据节点的数据保存到本地的linux文件系统当中
通信协议:
所有的HDFS协议都是构建在TCP/IP协议上面的
客户端通过一个可配置的端口向名称节点发起TCP链接,使用客户端协议与名称节点交互
名称节点和数据节点之间使用数据节点协议交互
客户端与数据节点的交互是通过RPC(Remote Procedure Call)实现。
HDFS设置唯一的名称节点的局限性:
1. 命名空间的限制,所有的元数据保存在内存中,内存有上线,所以容纳的对象也有了上限
2. 性能的限制
3. 隔离的问题,命名空间只有一个
4. 集群的可用性,一旦故障怎么办(第二名称节点是冷备份,不是热备份,需要停止一段时间才能启动,在后来的HDFS 2.0进行了改善)
存储原理
冗余数据的保存:
1. 冗余会加快数据的传输速度,可以并行的访问
2. 容易检查数据错误
3. 保证数据的可靠性,一旦一个坏了,被系统周期性探测到会自动生成一个新的。
数据的存放:
第一个副本:如果是集群内部请求的,放在上传文件的数据节点,如果是集群外提交的放在一个磁盘不太满,cpu不太忙的节点
第二个副本:与第一个副本不同的机架上
第三个副本:第一个副本相同的机架上
第四个副本:随机
数据的读取:
读取数据的时候,从名称节点获取不同的副本存放位置的列表,列表包含了副本所在的数据节点,可以调用API来确定客户端和这个数据节点所属的机架ID,如果ID相同就选择这个副本,不同就随机找一个。
数据的错误与恢复:
名称节点出错:
在1.0当中需要停止用第二名称节点恢复(在2.0中已经不需要停机)
数据节点出错:
数据节点会定期向名称节点发送“心跳”信息。
发生故障,或者网络中断的时候,没有收到心跳节点的数据会被标记为“宕机”,节点上面所有的数据都会标记“不可读”,名称节点不会再给他们发送请求
一旦发现数据块备份数量小于冗余因子,就会启动数据冗余复制,生成新的副本
HDFS和其他发你不是文件系统最大区别是可以调整冗余数据的位置。
数据出错:
当磁盘损坏的时候,数据出错。
客户端在读取到数据的时候会使用md5和sha1校验码,去顶读取到正确的数据
如果校验出错将会客户端请求另一个数据节点读取该文件块,并且向名称节点报告文件快错误。
数据的读写过程
FileSystem 通用的文件系统抽象基类