Hadoop笔记汇总系列第五篇-HDFS

Jimili
338 阅读7分钟

这是我参与更文挑战的第11天，活动详情查看: 更文挑战

背景

这是Hadoop笔记汇总系列的第五篇,把HDFS相关的底层知识点汇总了一下.

HDFS的一些实现细节

GFS和HDFS的实现上的不同之处

1、 快照（Snapshot）： GFS中的快照功能可以非常快的对文件或者目录进行拷贝，生成快照的方式叫copy-on-write。即文件的备份在某些时候只是将快照文件指向原chunk，增加对chunk的引用计数而已，等到chunk上进行了写操作时，Chunk Server才会拷贝chunk块，后续的修改操作落到新生成的chunk上。 而HDFS暂时并不支持快照功能，而是运用最基础的复制来完成。比如当HBase上的数据在进行重新划分时（过程类似于hash平衡），HDFS需要对其中的所有数据（P/T级的）进行复制迁移，而GFS只需要快照

2、 记录追加操作（append）： GFS的一致性模型同时支持写和记录追加操作 HDFS对于写操作的数据流和GFS的功能一样。但是，HDFS并不支持记录追加和并行写操作.一个文件一旦创建、写入、关闭之后就不需要修改了。这样的简单模型适合于Map/Reduce编程

3、 垃圾回收（GC）： GFS垃圾回收采用惰性回收策略，即master并不会立即回收程序所删除的文件资源。 GFS选择以一种特定的形式标记删除文件（通常是将文件名改为一个包含时间信息的隐藏名字），这样的文件不再被普通用户所访问。Master会定期对文件的命名空间进行检查，并删除一段时间前的隐藏文件（默认3天）。 HDFS并没有采用这样的垃圾回收机制，而是直接删除 应该说延迟回收和直接删除各有优势。延迟回收为那些“不小心“的删除操作留了后路。同时，回收资源的具体操作时在Master结点空闲时候完成，对GFS的性能有很好的提高。但是延迟回收会占用很大的存储空间

注: 目前Hadoop只支持单用户写，不支持并发多用户写。可以使用Append操作在文件的末尾添加数据，但不支持在文件的任意位置进行修改

HDFS的并发控制

客户端对于文件的读写不应该影响其他客户端对同一个文件的读写。要想实现近似原生文件系统的单个文件拷贝语义，分布式文件系统需要做出复杂的交互，例如采用时间戳，或者类似回调承诺（类似服务器到客户端的RPC回调，在文件更新的时候；回调有两种状态：有效或者取消。客户端通过检查回调承诺的状态，来判断服务器上的文件是否被更新过）。

HDFS并没有这样做，它的机制非常简单，任何时间都只允许一个写的客户端，文件经创建并写入之后不再改变，它的模型是 write-one-read-many ， 一次写，多次读。这与它的应用场合是一致，HDFS的文件大小通常是兆至T级的，这些数据不会经常修改，最经常的是被顺序读并处理，随机读很少，因此 HDFS非常适合MapReduce框架或者web crawler应用。HDFS文件的大小也决定了它的客户端不能像某些分布式文件系统那样缓存常用到的几百个文件

HDFS的文件复制功能

一个文件可以表示为其内容在不同位置的多个拷贝。这样做带来了两个好处：访问同个文件时可以从多个服务器中获取从而改善服务的伸缩 性，另外就是提高了容错能力，某个副本损坏了，仍然可以从其他服务器节点获取该文件。HDFS文件的block为了容错都将被备份，根据配置的 replication因子来，默认是3。

副本的存放策略也是很有讲究，一个放在本地机架的节点，一个放在同一机架的另一节点，另一个放在其他机架上。这 样可以最大限度地防止因故障导致的副本的丢失。不仅如此，HDFS读文件的时候也将优先选择从同一机架乃至同一数据中心的节点上读取block

HDFS文件系统的容错性

  1. 在Namenode和Datanode之间维持心跳检测，当由于网络故障之类的原因，导致Datanode发出的心跳包没有被Namenode正常收 到的时候，Namenode就不会将任何新的IO操作派发给那个Datanode，该Datanode上的数据被认为是无效的，因此Namenode会检 测是否有文件block的副本数目小于设置值，如果小于就自动开始复制新的副本并分发到其他Datanode节点
  2. 检测文件block的完整性，HDFS会记录每个新创建的文件的所有block的校验和。当以后检索这些文件的时候，从某个节点获取block，会首先确认校验和是否一致，如果不一致，会从其他Datanode节点上获取该block的副本
  3. 集群的负载均衡，由于节点的失效或者增加，可能导致数据分布的不均匀，当某个Datanode节点的空闲空间大于一个临界值的时候，HDFS会自动从其他Datanode迁移数据过来。
  4. Namenode上的fsimage和edits日志文件是HDFS的核心数据结构，如果这些文件损坏了，HDFS将失效。因而， Namenode可以配置成支持维护多 个 FsImage和 Editlog的拷贝。任何对 FsImage或者 Editlog的修改，都将同步到它们的副本上。 它总是选取最近的一致的 FsImage和 Editlog使用。 Namenode在 HDFS是单点存在，如果 Namenode所在的机器错误，手工的干预是必须的
  5. 文件的删除，删除并不是马上从Namenode移出namespace，而是放在/trash目录随时可恢复，直到超过设置时间才被正式移除

HDFS健壮性

HDFS 的主要目标就是实现在失败情况下的数据存储可靠性

  1. 硬盘数据错误、心跳检测和重新复制
  • 每个Datanode 节点都向 Namenode 周期性地发送心跳包
  • Namenode 通过心跳包的缺失检测到这一情况， 并将这些 Datanode 标记为 dead，不会将新的 IO 请求发给它们。
  • 寄存在 dead Datanode 上的任何数据将不再有效。Datanode 的死亡可能引起一些 block 的副本数目低于指定值， Namenode 不断地跟踪需要复制的 block，在任何需要的情况下启动复制。
  • 在下列情况可 能需要重新复制：某个 Datanode 节点失效，某个副本遭到损坏，Datanode 上的硬盘错 误，或者文件的 replication 因子增大
  1. 数据完整性
  • 从某个 Datanode 获取的数据块有可能是损坏的，这个损坏可能是由于 Datanode 的 存储设备错误、网络错误或者软件 bug 造成的。HDFS 客户端软件实现了 HDFS 文件内容 的校验和。当某个客户端创建一个新的 HDFS 文件，会计算这个文件每个 block 的校验和， 并作为一个单独的隐藏文件保存这些校验和在同一个 HDFS namespace 下。当客户端检 索文件内容，它会确认从 Datanode 获取的数据跟相应的校验和文件中的校验和是否匹配， 如果不匹配，客户端可以选择从其他 Datanode 获取该 block 的副本
  1. 元数据磁盘错误
  • FsImage 和 Editlog 是 HDFS 的核心数据结构。这些文件如果损坏了，整个 HDFS 实 例都将失效。因而，Namenode 可以配置成支持维护多个 FsImage 和 Editlog 的拷贝。 任何对 FsImage 或者 Editlog 的修改，都将同步到它们的副本上。这个同步操作可能会降 低 Namenode 每秒能支持处理的 namespace 事务。这个代价是可以接受的，因为 HDFS 是数据密集的，而非元数据密集。当 Namenode 重启的时候，它总是选取最近的一致的 FsImage 和 Editlog 使用
  1. 快照
  • 快照支持某个时间的数据拷贝，当 HDFS 数据损坏的时候，可以恢复到过去一个已知正确的时间点。HDFS 目前还不支持快照功能
avatar
文章
阅读
粉丝