The Hapdoop Distributed File System

请设置文章作者

发布于：Jun 5, 2022

次浏览

The Hapdoop Distributed File System论文笔记

三类分布式存储系统的区别

有三类存储系统：块存储系统, 对象存储系统, 文件存储系统。块存储面向的用户是软件系统，文件存储面向的用户的人，对象存储面向的用户是其他计算机软件

• 文件存储
  • 数据存储在文件系统上，用户通过文件路径索引获取到文件，底层文件系统会解析文件系统会以目录树的方式解析文件系统
  • 优点：用户可以以”目录-子目录-文件”的形式组织文件
  • 缺点：存储系统需要通过文件路径逐层查找，效率较低
• 块存储
  • 相当于直接提供一块磁盘，没有文件系统，文件系统用户可以根据自己的需求自行部署文件系统
  • 优点：用户可以灵活地根据实际情况定制最合适的文件系统
  • 缺点：偏底层，用户要真正使用需要一定成本，且不易共享
• 对象存储
  • 数据就相当于一个key-value哈希表的value，用户直接通过一个uuid获取(通常是一个url)，使用一个uuid就能访问就便于开发人员使用
  • 优点：便于软件开发人员使用，而且目录搜索的层级不像文件存储那么多，效率较高
  • 缺点：没次只能以一个对象为单位，不利于大数据连续地址的访问

回答问题

客户端读取HDFS中指定文件指定偏移量处的数据时的工作流程?

主要流程是：client首先跟NameNode通信，询问含有目标文件块的副本(DataNode)，之后client直接跟目标文件所在的DataNode通信完成数据传输。

其中为了提升整个分布式系统的可用性还有如下细节需要考虑：

1. 为了防止数据损坏导致与用户预期不一致，DataNode在它的metadata中保存有文件数据的checksum，这个checksum是client在写时计算好并随着文件数据一并传递到DataNode的。如果checksum不一致，client尝试从另一个DataNode读取
2. client会由近到远，首先会尝试从距离最近的DataNode读数据，并且比对checksum，如果checksum不一致，说明数据损坏，选择下一个近的DataNode进行读取

客户端向HDFS中指定文件追加写入数据的工作流是什么?

主要流程是：client首先跟NameNode通信，让NameNode选举出一组DataNode(三个)来作为副本(replica)保存待写入的数据，写入的数据将以流水线的方式，保存到这三个副本当中

如下细节能体现HDFS在高吞吐量方面做的努力：

1. 数据在流水线上数据传递，是由一个DataNode传递给另一个DataNode的，而不是由client一次性与所有DataNode通信，这样做一方面能够利用每个节点的吞吐量，另一方面可以可以利用上集群内网的传输效率，从而大大提升吞吐量
2. 为了充分利用吞吐量，所写数据会分批传输给DataNode，通常一次传输一个packet共64KB的数据，这里体现的批处理的思想
3. 因为数据在DataNode间以流水线的形式传递，所以DataNode的写的顺序由近及远，最小化网络传输的距离

新增加一个数据块时，HDFS如何选择存储存储该数据块的物理节点?

出于可用性和容错性的考虑，HDFS中DataNode是尽量不保存相同副本的(除非集群中节点数量不足)，并且在大规模的集群中，还引入了Rack节点这样的层次结构来简化NameNode和DataNode之间的互连。因此，在当rack数量充足时，同一个副本不会出现在一个rack两次。这样如何选择物理节点就是HDFS中一个重要的优化点。基本思路就是：让副本尽可能分散到整个集群中。

• 基本目标是尽可能最小化写开销和最大化可靠性、可用性、批量读性
  • 最小化写开销:
    • 数据以流水线的方式在DataNode间传递，而传递的顺序是由近及远，有一个DataNode传递给另一个DataNode，从而利用上每个节点的带宽最小化写开销
  • 最大化可靠性、可用性、批量读性:
    • 当新增一个数据块时，在一个副本写，其余第二第三个数据块将要写入到不同rack内的副本中，其余数据块将随机防止到节点中，目的是让副本尽可能分散
    • 这样，当副本数量小于2时，就能保证两个副本不会保存到相同的rack中，从保证可靠性
    • 由因为一个rack中的DataNode数据重叠的概率低，所以读的时候就可以减少rack间的交互，尽可能一次就访问到所有数据块，从而可用性和读效率得到提高

HDFS采用了哪些措施应对数据块损坏或丢失?

HDFS使用了很多措施来应对数据的损坏和丢失，对所有的情况考虑也比较全面，包括有意无意的数据损坏，数据恢复的开销等。总结一下就是：应对数据损坏和丢失的思路的备份，应对恢复开销的思路是”多段备份”。主要体现在以下方面：

• 定期CheckPoint: NameNode会定期创建checkpoint，checkpoint就是当前状态的一个备份，他会合并日志和当前状态的信息并持久化存储起来，当错误发生时可以从checkpoint进行恢复
• CheckPoint备份: 将checkpoint保存到不同存储器中，如保存到不同磁盘卷中和保存到远端NFS中。总之，就是给checkpoint做个备份，这个备份可以在本地地也可以在远端的。保存在本地不同物理设备可以在单设备故障时快速恢复，保存在远端可以防止单节点失效。
• Snapshot: 为了方式数据修改时对整系统产生不可逆的影响(如软件更新)，HDFS提供快照机制，提供”后悔”的可能，防止了失误导致的数据错误。
• BackupNode: 相当于NameNode在内存中的备份，在内存中保存NameNode的状态，错误发生是NameNode可以先尝试从BackupNode内存中快速恢复，否则再总CheckpointNode的磁盘中恢复。
• Block scanner: 文件的matedata中会记录有文件的checksum，每个DataNode都有一个Block Scanner定期扫描文件比对文件数据的checksum，当发现数据损坏时会通知NameNode，NameNode将该节点标记为损坏，但不立刻将其删除，而是先保留该损坏块然后产生一个新的完好的副本。当完好的副本数量到达阈值时，损坏的数据才会被删除。这么做后即使所有节点同时失效用户也能从损坏的数据中找回部分。

其中，CheckPoint持久化防止了数据丢失。CheckPoint备份的散布防止了单节点失效。SnapShot防止了操作失误导致的数据丢失或额外的恢复开销。BackupNode则利用了系统结构分层原理的思想，利用内存备份降低了恢复开销。Block scanner加”延后删除”的策略则让在数据已经损坏并无法恢复的情况下，尽量降低损失。CheckPoint备份到本地的不同存储器也降低了数据恢复的开销。多阶段的恢复方案和现实很多”备用计划”分形相似。

HDFS采用了什么措施应对主节点失效问题?

• 主节点的checkpoint会保存到其他存储设备中，可以是节点本地的其他存储器也可以是远端的存储器。本质上就是对主节点状态也做备份
• 另外，checkpoint的备份会保存在本地和远端，散布到集群当中，预防了单点失效问题

NameNode维护的”数据块-物理节点对应表”需不需要在硬盘中备份?为什么?

不需要，因为:

1. DataNode每隔1小时会发送一个block report信息给NameNode，block report中就包含DataNode的id，大小等DataNode最新信息。
2. 每次操作都会触发DataNode发送heartbeats心跳信号给NameNode，Name这时需要确认DataNod数据的可用性，之后通过对心跳信息的回复会让DataNode立刻发送block report，从而获得DataNode的最新情况，这样也能恢复出”映射表”

亮点

• 分阶段”策略”，讨价还价，降低恢复开销
• 备份，容错
• 分散，单点失效

不足

future work中似乎看到了点设计缺陷。可扩展性问题，还有就是java的问题: 垃圾回收机制。

• 可扩展性问题
• java垃圾回收机制问题
  • 在内存待的就需要考虑java的自动垃圾回收
  • NameNode要在内存中记录DataNode信息，如block位置信息等
  • 并且NameNode是单一节点
  • 因为在大数据场景下，DataNode位置信息经常变动和失效恢复等，NameNode(内存)中的记录就会可能发送大规模改变，导致自动垃圾回收，导致死机
  • 提出的解决办法是多NameNode，但是多NameNode的维护也是问题，而且我感觉治标不治本