分布式文件系统HDFS
简介
全称 Hadoop Distributed File System
简称HDFS
解决海量数据的分布式存储问题。
分布式文件系统
在大数据时代,单台计算机无法存储海量数据,所以要使用集群来进行存储。
HDFS实现目标
- 兼容廉价的硬件设备
- 实现流数据读写(特点!)
- 支持大数据集(不限制文件大小)
- 支持简单的文件模型
- 强大的跨平台兼容性
HDFS自身的局限性
- 不适合低延迟数据访问(HDFS不具备实时性,不能满足实时性需求)
- 无法高效存储大量小文件(会导致元数据的索引结构非常庞大,这样检索的效率就会大大降低)
- 不支持多用户写入及任意修改文件
HDFS相关概念
块
整个HDFS当中最核心的概念。
作用:为了分摊磁盘读写开销,也就是在大量数据间分摊磁盘寻址的开销。
HDFS的一个块要比普通文件系统的块大很多。
为什么这么设计(大块)呢?
支持面向大规模数据存储
降低分布式节点的寻址开销
缺点:
如果块过大会导致MR就一两个任务在执行,这样就完全牺牲了MR的并行度,发挥不了分布式并行处理的效果。
HDFS采用这种抽象的块的概念设计好处
- 支持大规模文件存储
- 简化系统设计
- 适合数据备份
HDFS两大组件
名称节点
NameNode名称节点:存储着元数据
元数据:
- 文件是什么
- 文件被分成多少块
- 每个块和文件是怎么映射的
- 每个块被存储在哪个服务器上面
NameNode里的数据结构有这两种:
fsimage不保存数据的位置信息,数据的位置信息是在单独的一块内存中存放的。
当一个数据节点加进来,会向NameNode汇报。
由于editlog会不断增大,越来越大以后也会影响整个系统的性能。
第二名称节点secondaryNameNode就是为了解决这个问题,同时它也是名称节点的冷备份。
怎么解决EditLog不断增大的问题?
NameNode中维护的FsImage和EditLog这两个数据结构,EditLog会在整个过程中不断增大。
第二名称节点会定期和第一名称节点定期通信,在某个阶段会请求第一名称节点停止使用EditLog。
第一名称节点收到这个停止请求后,会马上停止,并生成一个edits.new文件,会把新到达的更新全写到edits.new里去,旧的EditLog等待第二名称节点来取走。
第二名称节点通过httpget把FsImage和EditLog都下载到本地,然后做合并操作,得到一个新的FsImage,再发送给名称节点。
第一名称节点会将FsImage和edits.new合并成Edit,成为新的EditLog。
数据节点
数据节点的数据会保存到各自本地的Linux文件中。