暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

Hadoop介绍 (三)——HDFS工作原理

R语言数据分析与建模 2020-08-12
243




一.HDFS工作原理

HDFS(分布式文件系统)源自2003年10月Google发表的一篇GFS论文,它是GFS的克隆版。想起吴军老师的《数学之美》谈到我就想明白了一件事情,如果想要讲明白一件事情,一定要把他的历史渊源都讲明白,这样我们才能对其理解透彻,而不是单纯学到会用就好。那我们详细拆解它吧,加油!

GFS(Google File System)是一个可扩展的分布式文件系统。用于大型的,分布式的,对大量数据进行访问的应用。它运行于廉价的普通硬件上并提供容错功能,可以给大量的客户提供总体性能比较高的服务。Google公司为了存储海量搜索数据而设计的GFS,不仅仅是一个文件系统,它包括数据冗余,支持低成本的数据快照,除了提供常规的创建,删除,打开,关闭,读,写文件操作,GFS还提供附加记录的操作。根据Google应用程序的具体情况,因为对文件的随机写入操作几乎不存在的,读操作也是经常按照顺序的,绝大部分文件的修改是采用在文件尾部追加数据,这样的记录追加操作允许多个客户端对同一个文件数据进行追加,对于实现多路结果合并,以及生产者-消费者队列非常有用。并且记录追加操作要保证每个客户端的追加操作都是原子性的,多个客户端可以在不需要额外的同步锁定的情况下,同时对一个文件追加数据。


client是一套类似于传统文件系统的API接口函数,是一组专用接口,应用程序通过访问这些端口来实现操作;

chunk服务器负责具体的存储工作,它要做的是拆分块chunk保存在本地硬盘上,读写块数据。

master节点管理所有文件系统元数据,管理系统范围内的活动。

在GFS中,存储的文件被分成固定64MB的chunk,每一个chunk在创建时会被master分配一个不变的,全球唯一的64位chunk标识。chunk 服务器根据这个标识和字节范围来读写块数据,chunk是以本地数据保存的。为了保证可靠性,chunk在不同的机器中复制多份,默认为3份,副本有3个用途:chunk创建,重新复制和重新负载均衡。chunk的复制是有master负责的。

chunk服务器存储的元数据有3类,即文件和chunk的命名空间,文件和chunk的对应关系,每个chunk 副本的存放地点。这些信息被存储在master服务器内存中,保证了master服务器的操作速度。前两种类型的数据也会以记录变更日志的方式,记录操作系统的系统日志文件中,而日志文件存储在本地磁盘上,同时日志会被日志被复制到其他远程master服务器上,避免单点故障。第三种元数据chunk 的存放地点不会被持久保存,只是在master服务器启动或者新的chunk服务器加入时,由master服务器加入时,由master 向各个chunk服务器轮询它们所存储的chunk 信息。

应用程序读取数据流程:1.应用指定读取某个文件的某段数据,因为数据段是定长的,client可以计算出这段数据跨越了几个数据块,client把文件名和需要的数据块索引发送给master;2.master根据文件名查找命名空间和文件一块映射,得到需要的数据块副本所在的地址,将数据块的ID和其他其他副本的地址反馈给client;3.client选择一个副本,联系chunk服务器索取需要的数据;4.chunk 服务器返回数据给client.每个chunk以块为单位划分,每个块64kb,对应一个32bit校验和。如果读取chunk时,数据和校验和不匹配,就返回错误,从而使得client选择其他的chunk服务器上的副本。

应用程序数据的流程:1.client首先发送请求(包括文件名)到GFS的master;2.master通过查找返回相应的所有的chunk 服务器以及chunk信息;3.client根据这些信息给chunk服务器发送请求,去执行操作。一次写入,必须在所有副本全部写入成功,才算成功写入。

master仅仅通过几个字节的信息告诉客户端哪个chunk服务器具有他所需要的chunk。由于chunksize很大,客户端不必跟master有很多交互就可以获得大量的数据。从而解决了性能瓶颈问题。

HDFS基本认为GFS的简化版,由于时间以及应用场景等各方面原因对GFS功能做了一定的简化,大大降低了复杂度。Hadoop分布式文件系统(HDFS)是一种为在普通商用硬届上运行而设计的分布式文件系统。它与现有的分布式文件系统有很多相似之处。但是,与其他分布式文件系统不同的地方很值得注意:HDFS高容错,可部署在低成本硬件上。HDFS提供对应用程序数据的高吞吐量访问,适用于具有大数据集的应用程序。HDFS放宽了一部分POSIX约束,来实现流氏读取文件系统的目的HDFS最初在Apache Nutch网络搜索引擎项目中提出,是Apache Hadoop Core项目的一部分。

HDFS为了更好的服务于应用,提供了类似于linux命令的shell接口和API接口,此外HDFS还可以通过Http协议支持用户通过浏览器客户端对HDFS平台上的文件目录和数据进行检索服务。

HDFS介绍

传统模式与HDFS模式同样在客户端有3个大小分别为1TB,100GB,10GB的文件,为了防止机器宕机导致数据丢失等问题,文件多以副本的形式存储命名为node1,node2,node3,node4,node5的5台服务器中,这些服务器的存储能力也是巨大的,例如每台机器存储能力是10TB,即共50TB的存储能力,足以存储这3个文件。客户端把3个文件以3副本的形式存储在5台机器的同时,生成文件与文件存储位置对应的映射关系文件,存储在主节点上。

1.映射关系文件:保证程序通过映射关系到指定机器找到需要的文件。

2.多副本存储:保证1台或者2台机器出现故障时,程序可以通过映射文件找到其他副本,保证数据的完整性。

在这种分布式存储的模式解决了大文件在一台机器上存储不便的时候,将其分散存储在多台机器上的问题。在进行文件读写的时候,可以通过元数据(如映射文件)定位找到需要的内容。但在传统的模式下,有的机器(如node5)存储负担很小的情况。可以扩展一下思维,如果海量的数据普遍存在这样的情况,那么集群中的存储负载会出现倾斜的问题,在进行读取,计算,也会出现一些节点拖后腿的情况。总之,这种经典传统分布式存储模式,虽然解决了原来一台机器完成不了的计算问题(大文件,大数据计算),但是同时也有一些不足之处。

1.负载难以均衡:因为文件大小不一致,所以导致集群中各个节点磁盘利用率不均匀。

2.把一个文件存储在一个节点。如果这个文件过大,需要并行处理,会很难实现。如果启动多线程,每个线程都要从这个节点上拉取这个文件的内容,这个节点会成为网络瓶颈,不适合分布式文件处理。

HDFS存储模式支持结构化,半结构化数据均匀分布存储。这种模式将文件切分成等大的数据块Block,再以多副本的方式进行存储。整个系统把分块,分发,容错等过程比较难的地方都抽象掉,使用户感觉在操作一块硬盘那样容易,完善了     传统分布式存储的不足,降低了开发的难度。

1.功能强大,操作简单,易用。

2. 良好的扩展性。可以动态增加服务器集群的节点数,解决集群的在线扩容的问题。例如目前集群的存储能力不够,磁盘空间已满,可以添加新的机器,在线把这些机器增加到Hadoop集群中,以达到在线的空间的扩展,另外,用户可以通过HDFS的一些工具,对已经数据进行重新分布,以达到数据在新增节点以及老的节点均衡分布的目的。

3.高容错性。在大数据平台下,节点众多,故期望在HDFS架构时,能够把错误检测和快速自动恢复作为重要的目标来考量。例如多副本冗余存储的策略,保证在个别节点失效时,数据不丢失,这也是容错性的表现之一。

4.支持流氏数据访问。运行在HDFS上的应用与普通应用不同,它支持以流式访问数据集的方式。有效实现了一次写入,多次读取的模型,尽量最小化硬盘的寻址开销。在考虑数据访问低延迟问题的同时,更着重考虑数据访问的高吞吐量问题。

5.适合PB量级以上的海量数据存储。

6异构软硬件平台间的可移植性。



二.HDFS的体系结构

HDFS采用master/slave架构。一个HDFS集群由一个NameNode和一定数量的DataNode组成。NameNode是一个中心服务器(master机),负责管理文件系统的命名ta空间(Name Space)以及客户端对文件的访问。集群中的DataNode一般是集群中的一台服务器(slave)充当一个node节点,启动一个DataNode的守护进程,负责管理它所在节点的存储。

HDFS体系中的关系点就是NameNode和DataNode的关系

client(客户端):客户端是值需要访问HDFS文件服务的用户或者应用。

Metadada(元数据):方便集群和文件管理,存储文件系统目录树信息(如文件名,目录名,文件和目录的从属关系,文件和目录的大小,创建和最后访问的时间,权限),文件和块的对应关系,以及文件组成信息(如块的存储位置,机器名,快名,块ID)。



NameNode(命名节点):集群中的管理者用于存储HDFS的元数据(MetaData),维护系统的命名空间,执行文件系统的命名空间(管理是指命名空间支持对HDFS中的目录,文件和块做类似文件系统的创建,修改,删除等基本操作)操作,如打开,关闭,重命名文件或者目录等。维护HDFS状态镜像文件FSImage和日志文件EditLog等。注意,FSImage和EditLog是HDFS的核心数据结构,这些文件的损坏可能会导致HDFS实例的无法正常运行。

DataNode(数据节点):文件系统的工作节点,存储实际的数据。受客户端或NameNode调度存储和检索数据,并定期向NameNode发送它们所存储的列表。在DataNode的复制过程中提供同步send/receive的操作。

Block(块):文件系统读写的最新数据单元。HDFS中考虑元数据大小,大数据的工作效率和整个集群的吞吐量问题,将块默认为最大值。也可以配置参数或者java程序指定块的大小。

Rack(机架):大型Hadoop集群是以机架的形式来组织的,同一个机架上不同节点上的网络状况比不同机架之间的节点的更为理想。

Replication(复制):为了在大集群中可靠存储超大文件,大文件被切割成大小的Block后,以多副本形式存储在集群中,这期间涉及到数据块节点复制的问题。

Read(读):指HDFS不同节点间的数据读取的过程。

Write(写):指HDFS不同节点间数据写入的过程

从内部看,一个文件其实被分成一个或多个数据块(Block),这些块被存储在一组DataNode上。NameNode执行文件系统的命名空间操作,如打开,关闭,重新命名文件或者目录。它也复制确定数据块(Block)到具体的DataNote的映射。DataNote负责处理文件系统客户端的读写请求,并在NameNOde在统一调度下进行数据块的创建,删除和复制。

NameNode和DataNote被设计为可在商用机器上运行的软件。

在HDFS中,任何一个文件,目录和Block,在HDFS中都会表示为一个object,存储在NameNode的内存中,每一个object占用150bytes的内存空间。当NameNode启动的时候,首先会把FSImage里面的所有内容映射到内存中,然后一条一条的去执行edits中的记录,然后等待各个DataNode向自己汇报的信息来组装BlockMap,从而离开安全模式。所谓的BlockMap结构,就是记录Block的元数据(加载在NameNode的内存中)和对应的实际数据(存储在DataNode)中的映射关系。真正的每个Block对应DataNode到的列表信息在Hadoop中并没有进行持久性进行存储,而是所有DataNode启动时,每个DataNode对本地磁盘进行扫描,将本DataNote上保存的Block信息汇报给NameNode,NameNode在接收到每个DataNode块信息以及所在的DataNode信息保存在内存中。HDFS就是通过这种块信息汇报的方式来完成Block-datanodeslist对应表构建。DataNode向NameNode汇报块信息的过程被称为BlockReport,而NameNode将block-datanodeslist对应表信息保存在一个BlockMap的数据结构中。因此可以得出一个非常重要的结论:NameNode不会定期向各个DataNode去“索取”信息,而是各个DataNode定期向NameNode汇报块的信息。当组装完NameNode和BlockMap的信息后,基本上整个HDFS启动就完成了,可以顺利离开这个安全模式。由此可知启动速度是两个因素决定的:1.执行各个edits文件的时间。2.各个DataNode向NameNode汇报块信息的进度。

分布式系统中复制数据事物的实现过程如下:

客户端在一系列的对象副本中请求单一操作。一个事物在有副本对象的场景下与无副本对象的场景的表现应该是一样的(这个属性被称为one-copy serializability),而且每个副本管理器RM提供了一定的并发控制能力和恢复对象能力。

read-one指的是读操作只会在单一的RM执行,毕竟只是读操作而已,而write-all则要在每个RM上应用到,所以它的体系结构要求,当到来一个读请求时,所有的RM都要执行一遍,至于请求怎么传达到各个副本管理器,不需要客户端一个个请求到每个MR里,MR之间可以自己交流,传播信息。

副本管理器的复制是为了防止MR意外发生宕机或者通信失败,要求复制一个与它一样数据的MR,以便能够选择另外的方式进行操作。

网络的分区会导致副本管理器的group分成两个或两个以上的子组,而子组之间由于分区的原因是无法进行通信的,所以这往往造成数据不一致的问题。解决这个问题的方法是进行数据可用复制算法。应用到每个区中,当分区已经被修复的时候,再进行冲突认证。

edits文件:文件存放是在NameNode已经启动的情况下,Hadoop文件系统的所有更新操作的记录,HDFS进行所有写的操作,都会写入到edits文件中。

FSImage镜像文件是Hadoop文件系统元数据的一个永久性的检查点,其中包含所有整个HDFS文件系统的所有目录和文件inode的序列化信息。

HDFS中的Block副本放置策略

NameNode选择一个DataNode去存储Block副本的过程被称为副本存放,这个过程策略其实就是在可靠性和读写带宽间进行权衡的。在考虑副本存储问题之前先来考虑两个问题:1.把所有的副本存放在同一个节点上,能够保证写带宽,但是这个可靠性完全是假的。一旦这个节点失效,所有的数据都会丢失。Mapper或者Reducer任务的所有副本被打散在不同的节点上,可靠性提高了,但是带宽又成了问题。







文章转载自R语言数据分析与建模,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论