Hadoop----HDFS(分布式文件系统)

HDFS–分布式文件系统

存储模型：字节

• 文件线性切割成块（Block）:偏移量 offset （byte）

• Block分散存储在集群节点中

• 单一文件Block大小一致，文件与 文件可以不一致

• Block可以设置副本数，副本分散在不同节点中，副本数不要超过节点数量

• 文件上传可以设置Block大小和副本数

• 已上传的文件Block副本数可以调整，大小不变

• 只支持一次写入多次读取，同一时刻只有一个写入者

架构模型：

• 文件元数据MetaData，文件数据

  • 元数据 （是指文件的描述信息）

  • 数据本身

• （主）NameNode节点保存文件元数据：单节点 posix 虚拟目录树

• （从）DataNode节点保存文件Block数据：多节点

• DataNode与NameNode保持心跳，就是不断的提交Block列表给NameNode

• HdfsClient(客户端)与NameNode交互元数据信息

• HdfsClient与DataNode交互文件Block数据

NameNode（NN）

​ NameNode是整个文件系统的管理节点，它维护着整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表。接收用户的请求。

• 基于内存存储 ：不会和磁盘发生交换
  • 只存在内存中
  • 持久化 （拍快照，日志记录）
    • NameNode的metadate信息在启动后会加载到内存
    • metadata存储到磁盘文件名为”fsimage”
    • Block的位置信息不会保存到fsimage
    • edits记录对metadata的操作日志
• NameNode主要功能：
  • 接受客户端的读写服务
  • 收集DataNode汇报的Block列表信息
• NameNode保存metadata信息包括
  • 文件owership和permissions
  • 文件大小，时间
  • （Block列表：Block偏移量），位置信息 （快照和日志记录不会记录位置信息）
  • Block每副本位置（由DataNode上报）

DataNode（DN）

提供真实文件数据的存储服务。

• 本地磁盘目录存储数据（Block），文件形式
  • 文件块(block)：最基本的存储单位。对于文件内容而言，一个文件的长度大小是size，那么从文件的0偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好每一个块称为Block。HDFS在1.0中默认的Block大小是64MB，在2.0中默认是128MB。以一个256MB文件为例，共有256/128=2个Block。
  • 不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个Block数据块的存储空间
• 同时存储Block的元数据信息文件 （MD5保证数据的完整性）
• 启动DN时会向NN汇报block信息
• 通过向NN发送心跳保持与其联系（3秒一次），如果NN 10分钟没有收到DN的心跳，则认为其已经lost，并copy其上的block到其它DN
• Replication。多副本，默认是3个。(hdfs-site.xml的dfs.replication属性)

SecondaryNameNode（SNN）

• 它不是NN的备份（但可以做备份），它的主要工作是帮助NN合并edits log，减少NN启动时间。
• SNN执行合并时机(checkpoint)
  • 根据配置文件设置的时间间隔fs.checkpoint.period 默认3600秒
  • 根据配置文件设置edits log大小 fs.checkpoint.size 规定edits文件的最大值默认是64MB

​ 执行过程：从NameNode上下载元数据信息(fsimage,edits)，然后将两者合并，生成新的fsimage，在本地生成，并将其推送到NameNode，替换成fsimage。

ps：Secondary NameNode只存在于伪分布式系统中，真实集群中是不需要Secondary NameNode的。

HDFS优点：

• 高容错性
  • 数据自动保存多个副本
  • 副本丢失后，自动恢复
• 适合批处理
  • 移动计算而非数据
  • 数据位置暴露给计算框架（Block偏移量）
• 适合大数据处理
  • GB 、TB 、甚至PB 级数据
  • 百万规模以上的文件数量
  • 10K+ 节点
• 可构建在廉价机器上
  • 通过多副本提高可靠性
  • 提供了容错和恢复 机制

HDFS缺点：

• 低延迟数据访问
  • 比如毫秒级
  • 低延迟与高吞吐率
• 小文件存取
  • 占用NameNode 大量内存
  • 寻道时间超过读取时间
• 并发写入、文件随机修改
  • 一个文件只能有一个写者
  • 仅支持append

Block的副本放置策略

第一个副本：放置在上传文件的DN；如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点。
第二个副本：放置在于第一个副本不同的 机架的节点上（机架感知）。
第三个副本：与第二个副本相同机架的节点。
更多副本：随机节点

跳机制

​ 所谓的心跳机制就是每隔一段时间心跳一次。就是DataNode每隔一段时间会向DataNode汇报信息，如果某个块出现了问题 NameNode通过汇报的信息检测到某个块的副本集的数量小于配置的数量，就会通知其它保存此Block副本集的DataNode向别的机器复制Block。如果DataNode很长时间没有汇报，NameNode就会认为此DataNode宕机。

HDFS写过程

Client：

• 切分文件Block
• 按Block线性和NN获取DN列表 （副本数）（NN根据副本的放置策略选择的三个节点）
• 验证DN列表后以更小的单位流式传输数据
  • 各节点，两两通信确定可用
  • 通过pipline （管道的形式）传给第一个节点后，第一个节点再向传给第二节点，节点并行的一个一个传递数据。
• Block传输结束后：
  • DN向NN汇报Block信息（心跳机制）
  • DN向Client汇报完成
  • Client向NN汇报完成
• 获取下一个Block存放的DN列表
• 。。。。。。
• 最终Client汇报完成
• NN会在写流程更新文件状态

HDFS读流程

Client：

• 和NN获取一部分Block副本位置列表（NN根据Client择优选取副本的位置，排好序等着Client获取）
• 线性的获得DN获取Block，最终合并为一个文件
• 在Block副本列表中按距离择优选取（就近获取）
• 可以任意选择哪一块读取

HDFS文件系统数据读的流程很好的支撑了计算移动本地化读取。

安全模式

​ namenode启动的时候，首先将映像文件(fsimage)（在格式化时产生）载入内存，并执行编辑日志(edits)中的各项操作。
​ 一旦在内存中成功建立文件系统元数据的映射，则创建一个新的fsimage文件(这个操作不需要SecondaryNameNode)和一个空的编辑日志。
此刻namenode运行在安全模式。即namenode的文件系统对于客服端来说是只读的。(显示目录，显示文件内容等。写、删除、重命名都会失败)。
在此阶段Namenode收集各个datanode的报告，当数据块达到最小副本数以上时，会被认为是“安全”的， 在一定比例（可设置）的数据块被确定为“安全”后，再过若干时间，安全模式结束
当检测到副本数不足的数据块时，该块会被复制直到达到最小副本数，系统中数据块的位置并不是由namenode维护的，而是以块列表形式存储在datanode中。