小白看架构 · HDFS1.0架构

HDFS,是一个分布式文件存储系统。那我们自然可以去联想比如fastdfs等我们java领域的分布式文件系统。大概是下面这样子的,那么HDFS

有什么区别呢?为什么就能在大数据领域成为一个不可或缺的基础组件呢?

小白网上搜索了很多关于HDFS的设计理念和优点。如下:

首先肯定是支持超大数据集,几十亿的数据,通过分布式存储,分散到多台机器上去,妥妥的没毛病。

高可用性,大数据需要大量的机器去承载数据,一般都会采用普通的服务器去集群部署,是机器就会故障,更不用说不是那种专业的商用数据服务器了。HDFS可以自动探查到集群中的某个机器故障了,会自动进行故障恢复。

流式数据处理,大概意思就是基于流的形式来读写数据,保证高吞吐量的读写。

简化的一致性模型,一次写入,多次读。没有读写冲突,一致性也不需要额外维护。一个文件只有一次写入,之后只能追加,不能随便修改之前的数据。

尽量移动计算,不要移动数据。通过MapReduce或者其他计算框架计算时,尽可能是让计算任务靠近数据,而不要通过网络去移动传输数据。

        HDFS的架构是什么样子呢?常见的有主从架构,master-slave模式。这里就要介绍一下概念,首先NameNode,一个jvm进程,一个集群只有一个,可以看成是master,是整个集群的中心指挥官,其实就是文件命名空间,文件目录的形式,/a/b/c,可以通过目录去对应文件。这里有一个block的概念,一个大的文件最终存储到硬件上会分成几个块,比如1G,分成8块,每块128M,可能会存储到机器1,机器2,或者更多。

       DataNode,运行在每一台要存储数据的机器上,对这台机器上存储的文件数据进行交互,管理。负责管理一个文件最终存储到本机器的具体的一个或多个块,block1,block3,可能还有一个block2在其他机器上。

       那么,当你想要查找某个文件的时候,就可以问NameNode,他在哪里?NameNode就告诉你这个文件有几个块,分别在哪几台机器上。那么你就可以去和这几台机器通信,获取对应的文件块。

       我们再来看看NameNode里面的元数据这个概念,元数据,包括文件目录结构,以及目录结构下有哪些文件,每个文件有几个block,各个block存储在哪一台DataNode机器上,基本这些构成了元数据,存储在NameNode机器的内存中,当然还有些文件权限,文件限制等元数据。这是一种文件系统的层级目录,目录->子目录->文件,所以我们可以创建目录,创建文件,读写文件,像我们操作文件一样。而且hadoop里面我们通过Linux的很多命令都可以进行操作,hadoop fs -mkdir -p /usr/local/1.txt 这个就是创建目录和文件。hadoop fs -put 文件 就是上传文件,等等。

       那么,当我们的客户端进行各个文件操作的时候,肯定会对元数据进行操作和修改,这里的元数据是就是都交给NameNode进行管理的。NameNode里有一个概念叫做EditLog。编辑操作日志,当你操作一次文件,就记录一条日志,每一条日志都会写到磁盘中持久化。一条条日志可以还原出整个文件目录层级。还有个概念叫做FsImage。所有的目录结构,文件和DataNode,Block的映射关系。这些会完整地存储到FsImage里面,并且FsImage是存储在磁盘文件上,持久化存储。

       NameNode在内存中维护着一份元数据,所有的读写操作都是操作的内存,这样子会有很高的性能。然后每隔一段时间,执行一个叫做Checkpoint操作,这里的间隔时间是可以配置的,会读取磁盘里所有的EditLog文件,全部都还原到内存中一个FsImage缓存,然后将FsImage重新写入到磁盘中,并且将EditLog都清理掉。

每次NameNodeode启动的时候也会读取FsImage文件和EditLog文件去下载一份缓存到内存中。

        那么hadoop到底是怎么通过fsimage和EditLog来实现元数据的管理存储机制呢?hadoop1.x时候,NameNode启动,将fsImage读入内存,根据EditLog一条条还原元数据到最新状态,将最新的fsimage写入磁盘文件,接着清空掉EditLog。紧接着,NameNode不断修改元数据,直接修改内存中的元数据,并且将变更日志记录到EditLog中去。并且为了防止EditLog变得越来越大,定时做checkpoint,将最新的元数据fsimage写入到磁盘,清除掉EditLog。

       还有个问题就是定时做checkpoint操作,将editLog和fsimage合并,会有很多读写,很消耗性能和时间,这时就有一个一个架构方案,引入了Secondary NameNode系统组件。一般它部署在一台新的机器上,专门在后台做checkpoint操作,每隔一段时间,通知NameNode先不要写EditLog,可以暂时写一个newEditlog,然后拉取NameNode的EditLog和FsImage到本地,进行合并,写一份新的fsimage到磁盘。然后将最新的fsimage推送到NameNode上,同时呢,NameNode也会将NewEditLog改为Editlog。Secondary NameNodeameNode也是NameNode的一个冷备份。如果NameNode挂掉了,最多损失checpoint之后一些元数据变更,大部分元数据还在fsImage在Secondary NameNod上有一份存储着。一般一小时一次或者EditLog大小超过64MB,就会执行一次。紧接着,又出现了了一个checkpoint Node 其实就和Secondary NameNode一样,做同样的操作。

  紧接着还出现了一种架构,就是Backup Node,出现的初衷也是为了checkpoint Node那种下载EditLog和fsimage进行合并的思路。backupNode是什么思路呢?backupNode就是在内存中放入一份和NameNode一样的fsImage数据,同时还接受NameNode传输过来的EditLog流,然后写入到自己本地。同时将EditLog应用到内存的fsimage中。backupNode还会定时做checkpoint操作,将内存中的数据写到磁盘上fsimage文件,覆盖老的fsimage,将EditLog清空。

       这些就是小白学到的HDFS1.0的架构。不过现在HDFS3.0都出来了,小白还要再接再厉,继续努力学习。文中有错误的地方欢迎碧友们指出来,谢谢。

你可能感兴趣的:(小白看架构 · HDFS1.0架构)