分布式文件系统HDFS

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）