1.1简介
HDFS实现目标
兼容廉价的硬件设备
实现流数据读写
支持大数据集
支持简单的文件模型
强大的跨平台兼容性HDFS自身的局限性
不适合低延迟数据访问
无法高效存储大量小文件
不支持多用户写入及任意修改文件
2.1概念
块的概念
支持面向大规模数据存储
降低分布式节点的寻址开销HDFS采用这种抽象的块的概念设计好处
1.支持大规模文件存储: 文件以块为单位进行存储,一个大规模文件可以被分拆成若干个文件块,不同的文件块可以被分发到不同的节点上,因此,一个文件的大小不会受到单个节点的存储容量的限制,可以远远大于网络中任意节点的存储容量
2.简化系统设计: 首先,大大简化了存储管理,因为文件块大小是固定的,这样就可以很容易计算出一个节点可以存储多少文件块;其次,方便了元数据的管理,元数据不需要和文件块一起存储,可以由其他系统负责管理元数据
适合数据备份: 每个文件块都可以冗余存储到多个节点上,大大提高了系统的容错性和可用性
两大组件
NameNode | DataNode
存储元数据 | 存储文件内容
元数据保存在内存中 | 文件内容保存在磁盘
保存文件,block,datanode之间的映射关系 | 维护了block id 到datanode本地文件的映射关系
NameNode
提供元数据服务
1.文件是什么
2.文件被分成多少块
3.每个块和文件是怎么映射的
4.每个块被存储到在哪个服务器上面名称节点
包含FsImage 和 EditLog
名称节点运行期间EditLog不断变大的问题
SecondaryNameNode的工作情况:
(1)SecondaryNameNode会定期和NameNode通信,请求其停止使用EditLog文件,暂时将新的写操作写到一个新的文件edit.new上来,这个操作是瞬间完成,上层写日志的函数完全感觉不到差别;
(2)SecondaryNameNode通过HTTPGET方式从NameNode上获取到FsImage和EditLog文件,并下载到本地的相应目录下;
(3)SecondaryNameNode将下载下来的FsImage载入到内存,然后一条一条地执行EditLog文件中的各项更新操作,使得内存中的FsImage保持最新;这个过程就是EditLog和FsImage文件合并;
(4)SecondaryNameNode执行完(3)