Table of Contents
Hadoop简介
HDFS
存储模型
解释 : 已上传的Block大小不可改变的原因是每个Block大小一致,改变一个其他也会跟着改变,并且改变一个其它的偏移量也会改变,这是一个很消耗cpu的过程,Hadoop的目的就是节省出存储模型对cpu的消耗,从而更多用于文件计算上面。
至于可以追加数据的原因是 追加会导致 原本文件增加,又由于每块大小已经定了下来,所以只需增加一个或多个block即可解决。
其中默认的 Block 大小为 128MB , 副本数为3 ,其中每个副本分别在不同的计算机上,每台计算机上不允许出现相同的副本。
架构模型
看下图更好理解
解释 : 我们原本有一个很大的文件 , 然后将它分成很多部分,每一个部分被称为一个块,每一个块又存储在不同的计算机上,这些存储块的计算机就被称为DataNode,此时还有一台计算机并没有存储块,而是存储了哪个块存储在了哪台计算机上面,这个被称为NameNode。当客户端存储数据或者获取数据时都会先去访问 NameNode ,获得 将数据存储到哪台计算机或 从哪台计算机上获取数据 的信息,这个信息被称为元数据,其实就是属性包括块的存储位置、偏移量等等。然后会根据这个信息。HDFSClient 会去找指定的 DataNode。
NameNode
可能有人会认为 不会和磁盘发生交换又怎么持久化呢?
运行时有 内存和磁盘的双向交互才叫交换。
持久化:运行时往磁盘写,down机以后再重新启动会从磁盘读回,从而恢复内存。
当我们分配角色 在启动服务之前会有一次格式化,在这次格式化时,会第一次创建 名为fsimage的空目录,然后当开启服务以后,会分别从fsimage 和 edits 中读取内容, 显然由于第一次启动服务,这两个都是空目录。
当开启服务以后,NameNode会去读取fsimage和edits , 读到内存当中进行合并,然后重新写入一个fsimage到磁盘当中。
然后每隔指定的时间 会自动将 fsimage 和 edits 合并,并重新写入新的fsimage。这里 的 fsimage 与 edits 合并实际上是在另外一台机器上完成的,并不会影响 NameNode这台机器的工作。当 NameNode down机后,再次开启服务又会重新 读取fsimage,恢复最近一次的 metadata信息,同时 读取edits文件执行 最近一次保存metadata与down机这段时间的用户进行的操作。 刚才说的在 另外一台机器上完成的 这台机器就是 Secondary NameNode
DataNode
上图的 其上 含义 为:其它副本上 cp 一份到 其他DN
HDFS的优缺点
副本布置
官方推荐3个副本,场景是有多个机架,第一个副本在一个机架,第二个副本在另外一个机架上,第三个副本与第二个副本同机架,目的是预防整个机架瘫痪。官方说明是 第一个和第二个在同一个机架,第三个在另外一个机架,但源码与其描述不符。
HDFS读写流程
Pipeline : 上图中的 4 ,这条路线是一个管道,每一个block默认是128M,在传输的过程中会被切成更小的块64k,然后进行传输,很快一个64k的块就能够从FSData OutputStream 传递到 DataNode,此时会继续向下传递,创建副本,从而试第一个DataNode空闲出来,这时FSData OutputStream 又可以发送第二个64k的块。
第一个block传输完毕以后,DataNode会向namenode发送信息,告知自身的存储信息,之后client再上传其他block时就可以进行分配。
读取数据时,优先级为 本机datanode > 本机架 datanode > 其他机架 , 一般情况如果在其它机架都会经历3个交换机。
总结