hadoop学习2.docx

hadoop学习2.docx

《hadoop学习2.docx》由会员分享，可在线阅读，更多相关《hadoop学习2.docx（12页珍藏版）》请在冰点文库上搜索。

hadoop学习2

Hadoop分布式文件系统-HDFS

  当数据集超过一个单独的物理计算机的存储能力时，便有必要将它分不到多个独立的计算机上。

管理着跨计算机网络存储的文件系统称为分布式文件系统。

Hadoop的分布式文件系统称为HDFS，它是为以流式数据访问模式存储超大文件而设计的文件系统。

∙“超大文件”是指几百TB大小甚至PB级的数据；

∙流式数据访问：

HDFS建立在这样一个思想上-一次写入、多次读取的模式是最高效的。

一个数据集通常由数据源生成或者复制，接着在此基础上进行各种各样的分析。

HDFS是为了达到高数据吞吐量而优化的，这有可能以延迟为代价。

对于低延迟访问，HBase是更好的选择。

∙商用硬件：

即各种零售店都能买到的普通硬件。

这种集群的节点故障率蛮高，HDFD需要能应对这种故障。

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

∙低延迟数据访问：

需要低延迟数据访问在毫秒范围内的应用不合适HDFS

∙大量的小文件：

HDFS的NameNode存储着文件系统的元数据，因此文件数量的限制也由NameNode的内存量决定。

∙多用户写入、任意修改文件：

HDFS中的文件只有一个写入者，而且写操作总是在文件的末尾。

它不支持多个写入者，或者在文件的任意位置修改。

1.HadoopV1中HDFS的架构和原理

1.1HDFS的结构

这里的Client代表用户通过名称节点和数据节点交互来访问整个文件系统。

它提供一个类似于POSIX的文件系统接口，因此用户在编程时并不需要知道名称节点和数据节点及其功能。

Client通过RPC来调用NameNode和DataNode。

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

比如：

在Hadoopv0.23之前，在整个HDFS集群中只有一个命名空间，并且只有单独的一个NameNode，这个NameNode负责对这单独的一个命名空间进行管理。

Namenode中命名空间以层次结构组织中存储着文件名和BlockID的对应关系、BlockID和具体Block位置的对应关系。

这个单独的Namenode管理着数个Datanode，Block分布在各个Datanode中，每个Datanode会周期性的向此Namenode发送心跳消息，报告自己所在Datanode的使用状态。

Block是用来存储数据的最小单元，通常一个文件会存储在一个或者多个Block中，默认Block大小为64MB。

之后，HDFS中增加了BackupNameNode/SecondaryNameNode。

Namenode会实时将变化的HDFS的信息同步给BackupNamenode。

BackupNamenode顾名思义是用来做Namenode的备份的。

1.2HDFS中的文件操作

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.3HDFS适用的场景

1.4.Hadoop1.0中HDFS的缺陷

1.BlockStorage和namespace高耦合

 当前namenode中的namespace和blockmanagement的结合使得这两层架构耦合在一起，难以让其他可能namenode实现方案直接使用blockstorage。

 2.namenode扩展性

 HDFS的底层存储是可以水平扩展的（解释：

底层存储指的是datanode，当集群存储空间不够时，可简单的添加机器已进行水平扩展），但namespace不可以。

当前的namespace只能存放在单个namenode上，而namenode在内存中存储了整个分布式文件系统中的元数据信息，这限制了集群中数据块，文件和目录的数目。

3.性能

 文件操作的性能制约于单个namenode的吞吐量，单个namenode当前仅支持约60K的task，而下一代ApacheMapReduce将支持多于100K的并发任务，这隐含着要支持多个namenode。

4.隔离性

 现在大部分公司的集群都是共享的，每天有来自不同group的不同用户提交作业。

单个namenode难以提供隔离性，即：

某个用户提交的负载很大的job会减慢其他用户的job，单一的namenode难以像HBase按照应用类别将不同作业分派到不同namenode上。

2.Hadoop2中的HDFS 

2.1HDFSHA：

解决NameNode单点故障

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

1.SecondaryNameNode：

它不是HA，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。

当NameNode（以下简称NN）失效的时候，SecondaryNN并无法立刻提供服务，SecondaryNN甚至无法保证数据完整性：

如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失。

2.BackupNameNode（HADOOP-4539）。

它在内存中复制了NN的当前状态，算是WarmStandby，可也就仅限于此，并没有failover等。

它同样是阶段性的做checkpoint，也无法保证数据完整性。

3.手动把name.dir指向NFS。

这是安全的ColdStandby，可以保证元数据不丢失，但集群的恢复则完全靠手动。

4.FacebookAvatarNode。

Facebook有强大的运维做后盾，所以Avatarnode只是HotStandby，并没有自动切换，当主NN失效的时候，需要管理员确认，然后手动把对外提供服务的虚拟IP映射到StandbyNN，这样做的好处是确保不会发生脑裂的场景。

其某些设计思想和Hadoop2.0里的HA非常相似，从时间上来看，Hadoop2.0应该是借鉴了Facebook的做法。

5.还有若干解决方案，基本都是依赖外部的HA机制，譬如DRBD，LinuxHA，VMware的FT等等。

2.2HDFSFederation：

解决NameNode扩展性和性能问题

 单NameNode的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T（这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block）。

同时，所有的元数据信息的读取和操作都需要与NN进行通信，譬如客户端的addBlock、getBlockLocations，还有DataNode的blockRecieved、sendHeartbeat、blockReport，在集群规模变大后，NN成为了性能的瓶颈。

HDFSFederation是Hadoop最新发布版本Hadoop-0.23.0中为解决HDFS单点故障而提出的namenode水平扩展方案。

该方案允许HDFS创建多个namespace以提高集群的扩展性和隔离性。

2.2.1HDFSFederation架构

  为了水平扩展namenode，Federation使用了多个独立的namenode/namespace。

这些namenode之间是联合的，也就是说，他们之间相互独立且不需要互相协调，各自分工，管理自己的区域。

分布式的datanode被用作通用的数据块存储设备。

每个datanode要向集群中所有的namenode注册，且周期性地向所有namenode发送心跳和块报告，并执行来自所有namenode的命令。

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

　　每个blockpool内部自治，也就是说各自管理各自的block，不会与其他blockpool交流。

一个namenode挂掉了，不会影响其他namenode。

　　某个namenode上的namespace和它对应的blockpool一起被称为namespacevolume。

它是管理的基本单位。

当一个namenode/nodespace被删除后，其所有datanode上对应的blockpool也会被删除。

当集群升级时，每个namespacevolume作为一个基本单元进行升级。

2.2.2HDFSFederation优点

　　扩展性和隔离性：

支持多个namenode水平扩展整个文件系统的namespace。

可按照应用程序的用户和种类分离namespacevolume，进而增强了隔离性。

　　通用存储服务：

BlockPool抽象层为HDFS的架构开启了创新之门。

分离blockstoragelayer使得：

　　<1>新的文件系统（non-HDFS）可以在blockstorage上构建

　　<2>新的应用程序（如HBase）可以直接使用blockstorage层

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

　　设计简单：

Federation整个核心设计实现大概用了4个月。

大部分改变是在Datanode、Config和Tools中，而Namenode本身的改动非常少，这样Namenode原先的鲁棒性不会受到影响。

虽然这种实现的扩展性比起真正的分布式的Namenode要小些，但是可以迅速满足需求，另外Federation具有良好的向后兼容性，已有的单Namenode的部署配置不需要任何改变就可以继续工作

2.2.3HDFSFederation不足

　　1.单点故障问题

　　HDFSFederation并没有完全解决单点故障问题。

虽然namenode/namespace存在多个，但是从单个namenode/namespace看，仍然存在单点故障：

如果某个namenode挂掉了，其管理的相应的文件便不可以访问。

Federation中每个namenode仍然像之前HDFS上实现一样，配有一个secondarynamenode，以便主namenode挂掉一下，用于还原元数据信息。

　　2.负载均衡问题

　　HDFSFederation采用了ClientSideMountTable分摊文件和负载，该方法更多的需要人工介入已达到理想的负载均衡。

　　原文链接：

注：

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