hadoop学习2.docx

1、hadoop学习2Hadoop 分布式文件系统 - HDFS 当数据集超过一个单独的物理计算机的存储能力时，便有必要将它分不到多个独立的计算机上。管理着跨计算机网络存储的文件系统称为分布式文件系统。Hadoop 的分布式文件系统称为 HDFS，它 是为 以流式数据访问模式存储超大文件而设计的文件系统。 “超大文件”是指几百 TB 大小甚至 PB 级的数据； 流式数据访问：HDFS 建立在这样一个思想上 - 一次写入、多次读取的模式是最高效的。一个数据集通常由数据源生成或者复制，接着在此基础上进行各种各样的分析。HDFS 是为了达到高数据吞吐量而优化的，这有可能以延迟为代价。对于低延迟访问，HB

2、ase 是更好的选择。 商用硬件：即各种零售店都能买到的普通硬件。这种集群的节点故障率蛮高，HDFD需要能应对这种故障。因此，HDFS 还不合适某些领域： 低延迟数据访问：需要低延迟数据访问在毫秒范围内的应用不合适 HDFS 大量的小文件：HDFS 的 NameNode 存储着文件系统的元数据，因此文件数量的限制也由NameNode 的内存量决定。 多用户写入、任意修改文件：HDFS 中的文件只有一个写入者，而且写操作总是在文件的末尾。它不支持多个写入者，或者在文件的任意位置修改。1. Hadoop V1 中HDFS 的架构和原理1.1 HDFS 的结构这里的 Client 代表用户通过名称节

3、点和数据节点交互来访问整个文件系统。它提供一个类似于 POSIX 的文件系统接口，因此用户在编程时并不需要知道名称节点和数据节点及其功能。Client 通过 RPC 来调用 NameNode 和 DataNode。HDFS 中大文件被分成默认64M一块的数据块分布存储在集群机器中。比如：在 Hadoop v0.23之前，在整个HDFS集群中只有一个命名空间，并且只有单独的一个Name Node，这个 Name Node 负责对这单独的一个命名空间进行管理。Namenode中命名空间以层次结构组织中存储着文件名和BlockID的对应关系、BlockID和具体Block位置的对应关系。这个单独的N

4、amenode管理着数个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.

5、client 向 namenode 发出文件读请求2. namenode 返回部分或者全部block列表，对每个block，返回有该block的datanode地址3. client 选取最近的 datanode 读取block4. 读取完一个 block，关闭通信，寻找下一个 datanode，读取该block5. 读取完 block 进行 checksum，读取错误则从下一个拥有该 block 的datanode 读取1.2.2 文件写入1. client 向 namnode 发出文件创建请求2. namenode 检查文件是否存在，如果不存在，则在文件系统的命名空间中创建一个新的文件，这

6、是并没有块与之相联系。3. client 将文件分成多个 packet，以 dataqueue 向 namenode 申请新的blocks4. namenode 返回合适的block 存储packet 和 packet 副本5. 以流形式，写入第一个 datanode6. 该 datanode 以管道形式，写入下一个datanode，接着下一个 datanode，最后一个 datanode 存储成功后，返回 ack1.2.3 副本放置策略副本放置策略需要在可靠性与写入带宽和读取带宽之间进行权衡。默认配置下，一个Block会有三份备份： 一份放置在于客户端相同的节点上。若客户端运行在集群之外，N

7、ameNode 会随即选择节点，不过系统会避免挑选那些太满或者太忙的节点。 一份放在与与第一份不同的随即选择的机架上（离架） 最后一份放在与第二份相同的机架上，但放在不同的节点上。总体来说，这样的方法在稳定性（块存储在两个机架上）、写入带宽（写入操作只需要做一个单一网络转换）、读写性能（选择从两个机架中读取）和集群中块的分布（客户端只在本地机架写入一个块）之间，做了较好的权衡。1.2.4 文件复制1.NameNode发现部分文件的Block不符合最小复制数这一要求或部分DataNode失效。2. 通知DataNode相互复制Block。3.DataNode开始直接相互复制。1.3 HDFS 适

8、用的场景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在内存中存储了整个分布式

9、文件系统中的元数据信息，这限制了集群中数据块，文件和目录的数目。3. 性能 文件操作的性能制约于单个namenode的吞吐量，单个namenode当前仅支持约60K的task，而下一代Apache MapReduce将支持多于100K的并发任务，这隐含着要支持多个namenode。4. 隔离性 现在大部分公司的集群都是共享的，每天有来自不同group的不同用户提交作业。单个namenode难以提供隔离性，即：某个用户提交的负载很大的job会减慢其他用户的job，单一的namenode难以像HBase按照应用类别将不同作业分派到不同namenode上。2. Hadoop 2 中的 HDFS2.1

10、 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 Standb

11、y，可也就仅限于此，并没有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

12、.0应该是借鉴了Facebook的做法。5. 还有若干解决方案，基本都是依赖外部的HA机制，譬如DRBD，Linux HA，VMware的FT等等。2.2 HDFS Federation：解决 NameNode 扩展性和性能问题单 NameNode 的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。同时，所有的元数据信息的读取和操作都需要与NN进行通信，

13、譬如客户端的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。这些name

14、node之间是联合的，也就是说，他们之间相互独立且不需要互相协调，各自分工，管理自己的区域。分布式的datanode被用作通用的数据块存储设备。每个datanode要向集群中所有的namenode注册，且周期性地向所有namenode发送心跳和块报告，并执行来自所有namenode的命令。一个block pool由属于同一个namespace的数据块组成，每个datanode可能会存储集群中所有block pool的数据块。每个block pool内部自治，也就是说各自管理各自的block，不会与其他block pool交流。一个namenode挂掉了，不会影响其他namenode。某个nam

15、enode上的namespace和它对应的block pool一起被称为namespace volume。它是管理的基本单位。当一个namenode/nodespace被删除后，其所有datanode上对应的block pool也会被删除。当集群升级时，每个namespace volume作为一个基本单元进行升级。2.2.2 HDFS Federation 优点扩展性和隔离性：支持多个namenode水平扩展整个文件系统的namespace。可按照应用程序的用户和种类分离namespace volume，进而增强了隔离性。通用存储服务：Block Pool 抽象层为HDFS的架构开启了创新之门

16、。分离block storage layer使得： 新的文件系统(non-HDFS)可以在block storage上构建 新的应用程序(如HBase)可以直接使用block storage层 分离的block storage层为将来完全分布式namespace打下基础设计简单：Federation 整个核心设计实现大概用了4个月。大部分改变是在Datanode、Config和Tools中，而Namenode本身的改动非常少，这样 Namenode原先的鲁棒性不会受到影响。虽然这种实现的扩展性比起真正的分布式的Namenode要小些，但是可以迅速满足需求，另外Federation具有良好的向后

17、兼容性，已有的单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分摊文件和负载，该方法更多的需要人工介入已达到理想的负载均衡。原文链接：注：以上内容皆来自于互联网。