Hadoop 分布式文件系统

    当数据集超过一个单独的物理计算机的存储能力时，便有必要将它分不到多个独立的计算机上。管理着跨计算机网络存储的文件系统称为分布式文件系统。Hadoop 的分布式文件系统称为 HDFS，它 是为 以流式数据访问模式存储超大文件而设计的文件系统。

• “超大文件”是指几百 TB 大小甚至 PB 级的数据；
• 流式数据访问：HDFS 建立在这样一个思想上 - 一次写入、多次读取的模式是最高效的。一个数据集通常由数据源生成或者复制，接着在此基础上进行各种各样的分析。HDFS 是为了达到高数据吞吐量而优化的，这有可能以延迟为代价。对于低延迟访问，HBase 是更好的选择。
• 商用硬件：即各种零售店都能买到的普通硬件。这种集群的节点故障率蛮高，HDFD需要能应对这种故障。

因此，HDFS 还不合适某些领域：

• 低延迟数据访问：需要低延迟数据访问在毫秒范围内的应用不合适 HDFS
• 大量的小文件：HDFS 的 NameNode 存储着文件系统的元数据，因此文件数量的限制也由NameNode 的内存量决定。
• 多用户写入、任意修改文件：HDFS 中的文件只有一个写入者，而且写操作总是在文件的末尾。它不支持多个写入者，或者在文件的任意位置修改。

1. Hadoop V1 中HDFS 的架构和原理

1.1 HDFS 的结构

这里的 Client 代表用户通过名称节点和数据节点交互来访问整个文件系统。它提供一个类似于 POSIX 的文件系统接口，因此用户在编程时并不需要知道名称节点和数据节点及其功能。

Client 通过 RPC 来调用 NameNode 和 DataNode。

HDFS 中大文件被分成默认64M一块的数据块分布存储在集群机器中。比如：

 

在 Hadoop v0.23之前，在整个HDFS集群中只有一个命名空间，并且只有单独的一个Name Node，这个 Name Node 负责对这单独的一个命名空间进行管理。Namenode中命名空间以层次结构组织中存储着文件名和BlockID的对应关系、BlockID和具体Block位置的对应关系。这个单独的Namenode管理着数个Datanode，Block分布在各个Datanode中，每个Datanode会周期性的向此Namenode发送心跳消息，报告自己所在Datanode的使用状态。Block是用来存储数据的最小单元，通常一个文件会存储在一个或者多个Block中，默认Block大小为64MB。之后，HDFS 中增加了 BackupNameNode/SecondaryNameNode。Namenode会实时将变化的HDFS的信息同步给Backup Namenode。Backup Namenode顾名思义是用来做Namenode的备份的。

 

 

1.2 HDFS 中的文件操作

1.2.1 文件读取

1. client 向 namenode 发出文件读请求

2. namenode 返回部分或者全部block列表，对每个block，返回有该block的datanode地址

3. client 选取最近的 datanode 读取block

4. 读取完一个 block，关闭通信，寻找下一个 datanode，读取该block

5. 读取完 block 进行 checksum，读取错误则从下一个拥有该 block 的datanode 读取

1.2.2 文件写入

1. client 向 namnode 发出文件创建请求

2. namenode 检查文件是否存在，如果不存在，则在文件系统的命名空间中创建一个新的文件，这是并没有块与之相联系。

3. client 将文件分成多个 packet，以 dataqueue 向 namenode 申请新的blocks

4. namenode 返回合适的block 存储packet 和 packet 副本

5. 以流形式，写入第一个 datanode

6. 该 datanode 以管道形式，写入下一个datanode，接着下一个 datanode，最后一个 datanode 存储成功后，返回 ack

1.2.3 副本放置策略

副本放置策略需要在可靠性与写入带宽和读取带宽之间进行权衡。默认配置下，一个Block 会有三份备份：

• 一份放置在于客户端相同的节点上。若客户端运行在集群之外，NameNode 会随即选择节点，不过系统会避免挑选那些太满或者太忙的节点。
• 一份放在与与第一份不同的随即选择的机架上（离架）
• 最后一份放在与第二份相同的机架上，但放在不同的节点上。

 

总体来说，这样的方法在稳定性（块存储在两个机架上）、写入带宽（写入操作只需要做一个单一网络转换）、读写性能（选择从两个机架中读取）和集群中块的分布（客户端只在本地机架写入一个块）之间，做了较好的权衡。

1.2.4 文件复制

1. NameNode 发现部分文件的 Block 不符合最小复制数这一要求或部分 DataNode 失效。

2. 通知DataNode 相互复制Block。

3. DataNode 开始直接相互复制。

1.3 HDFS 适用的场景

1.4. Hadoop 1.0 中 HDFS 的缺陷

1. Block Storage和 namespace 高耦合
  当前namenode中的namespace 和 block management 的结合使得这两层架构耦合在一起，难以让其他可能namenode实现方案直接使用block storage。
 2. namenode扩展性
  HDFS的底层存储是可以水平扩展的(解释：底层存储指的是datanode，当集群存储空间不够时，可简单的添加机器已进行水平扩展)，但namespace不可以。当前的namespace只能存放在单个namenode上，而namenode在内存中存储了整个分布式文件系统中的元数据信息，这限制了集群中数据块，文件和目录的数目。
3. 性能
  文件操作的性能制约于单个namenode的吞吐量，单个namenode当前仅支持约60K的task，而下一代Apache MapReduce将支持多于100K的并发任务，这隐含着要支持多个namenode。
4. 隔离性
  现在大部分公司的集群都是共享的，每天有来自不同group的不同用户提交作业。单个namenode难以提供隔离性，即：某个用户提交的负载很大的job会减慢其他用户的job，单一的namenode难以像HBase按照应用类别将不同作业分派到不同namenode上。

 

2. Hadoop 2 中的 HDFS 

2.1 HDFS HA：解决 NameNode 单点故障

在Hadoop 2.0之前，也有若干技术试图解决 NameNode 单点故障的问题，在这里做个简短的总结

1. Secondary NameNode：它不是HA，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。当NameNode(以下简称NN)失效的时候，Secondary NN并无法立刻提供服务，Secondary NN甚至无法保证数据完整性：如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失。
2. Backup NameNode (HADOOP-4539)。它在内存中复制了NN的当前状态，算是Warm Standby，可也就仅限于此，并没有failover等。它同样是阶段性的做checkpoint，也无法保证数据完整性。
3. 手动把name.dir指向NFS。这是安全的Cold Standby，可以保证元数据不丢失，但集群的恢复则完全靠手动。
4. Facebook AvatarNode。Facebook有强大的运维做后盾，所以Avatarnode只是Hot Standby，并没有自动切换，当主NN失效的时候，需要管理员确认，然后手动把对外提供服务的虚拟IP映射到Standby NN，这样做的好处是确保不会发生脑裂的场景。其某些设计思想和Hadoop 2.0里的HA非常相似，从时间上来看，Hadoop 2.0应该是借鉴了Facebook的做法。
5. 还有若干解决方案，基本都是依赖外部的HA机制，譬如DRBD，Linux HA，VMware的FT等等。

 

2.2 HDFS Federation：解决 NameNode 扩展性和性能问题

 单 NameNode 的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。同时，所有的元数据信息的读取和操作都需要与NN进行通信，譬如客户端的addBlock、getBlockLocations，还有DataNode的blockRecieved、sendHeartbeat、blockReport，在集群规模变大后，NN成为了性能的瓶颈。

 

HDFS Federation 是 Hadoop 最新发布版本Hadoop-0.23.0 中为解决HDFS单点故障而提出的namenode水平扩展方案。该方案允许HDFS创建多个namespace以提高集群的扩展性和隔离性。

2.2.1 HDFS Federation 架构

    为了水平扩展namenode，Federation使用了多个独立的 namenode/namespace。这些namenode之间是联合的，也就是说，他们之间相互独立且不需要互相协调，各自分工，管理自己的区域。分布式的datanode被用作通用的数据块存储设备。每个datanode要向集群中所有的namenode注册，且周期性地向所有namenode发送心跳和块报告，并执行来自所有namenode的命令。

　　一个block pool由属于同一个namespace的数据块组成，每个datanode可能会存储集群中所有block pool的数据块。

　　每个block pool内部自治，也就是说各自管理各自的block，不会与其他block pool交流。一个namenode挂掉了，不会影响其他namenode。

　　某个namenode上的namespace和它对应的block pool一起被称为namespace volume。它是管理的基本单位。当一个namenode/nodespace被删除后，其所有datanode上对应的block pool也会被删除。当集群升级时，每个namespace volume作为一个基本单元进行升级。

2.2.2 HDFS Federation 优点

　　扩展性和隔离性：支持多个namenode水平扩展整个文件系统的namespace。可按照应用程序的用户和种类分离namespace volume，进而增强了隔离性。

　　通用存储服务：Block Pool 抽象层为HDFS的架构开启了创新之门。分离block storage layer使得：

　　<1> 新的文件系统(non-HDFS)可以在block storage上构建

　　<2> 新的应用程序(如HBase)可以直接使用block storage层

　　<3> 分离的block storage层为将来完全分布式namespace打下基础

　　设计简单：Federation 整个核心设计实现大概用了4个月。大部分改变是在Datanode、Config和Tools中，而Namenode本身的改动非常少，这样 Namenode原先的鲁棒性不会受到影响。虽然这种实现的扩展性比起真正的分布式的Namenode要小些，但是可以迅速满足需求，另外Federation具有良好的向后兼容性，已有的单Namenode的部署配置不需要任何改变就可以继续工作

2.2.3 HDFS Federation不足

　　1.单点故障问题

　　HDFS Federation并没有完全解决单点故障问题。虽然namenode/namespace存在多个，但是从单个namenode/namespace看，仍然存在单点故障：如果某个namenode挂掉了，其管理的相应的文件便不可以访问。Federation中每个namenode仍然像之前HDFS上实现一样，配有一个secondary namenode，以便主namenode挂掉一下，用于还原元数据信息。

　　2. 负载均衡问题

　　HDFS Federation采用了Client Side Mount Table分摊文件和负载，该方法更多的需要人工介入已达到理想的负载均衡。

　　原文链接：http://shitouer.cn/2012/12/hdfs-federation-introduction/

 

注：以上内容皆来自于互联网。