【2-2】HDFS的架构，元数据，客户端的上传和读取

HDFS的架构（HDFS architecture）

Namenode：负责管理

DataNode：存储数据

Secondary NameNode：一个Namenode的秘书

当一个客户端client想读取数据时：首先跟namenode打交道，获取一些“元数据”Metadata。

然后namenode要查询它的元数据信息——元数据信息保存在【内存里？掉电就丢失了】内存一份，磁盘一份（磁盘保存了一份镜像）

之后把元数据信息返回给客户端。

比如要读512M的数据，（4块），依次读取。倘若读取前三块之后，第四块存在别的机器上，可以再去别的地方读取块4【数据就近原则：在哪台机器上读取数据快，离我近，就读哪个，走一次交换机就能达到数据，就不走五次】

当一个客户端client想写数据时：写的时候还会复制副本。（见上节）

元数据的存储细节：内存一份，磁盘一份。

namenode里有什么？（文件Filename，副本3，被切分成了几块{blk_1，blk_2}，每一块被存放在哪台机器上，机器IP）

/test/a.log副本存了3份，被切分成了两块，第一块的三个副本存在了机器h0,h1,h3，第二块的三个副本存在h0,h2,h4

校验文件块是否损坏的方式：校验核（用原始的校验值和该文件的校验值相比较，以确定是否损坏）

什么是元数据：账本里的一条“账”，并不是真正的数据。

NameNode是干什么的：不仅仅是管理节点，还维护着文件系统的文件目录树。和文件，目录的元信息，和对应的数据块列表。还接受用户的请求【上传下载删除】

里面有：fsimage——元数据的镜像文件。存放在磁盘上【不是内存上】的叫fsimage，备份着内存中的元数据信息，但（伪分布式）并不是实时同步，真正的分布式是实时同

与之相对的，metadata存放在内存当中

edits：记录用户的操作日志。（该用户上传了一个文件，删除了一个文件，等等）

fstime：保存了用户最近一次checkpoint时间。即“最近一次做还原点的时间”

以上这些文件都是存在Linux文件系统里的，而不是HDFS。因为文件很小，在挂起的时候，将内存里的东西序列化到磁盘了，无需存在HDFS上

接下来，在Linux中找找这些东西

里面都是edits和fsimage文件。

NameNode的工作特点：namenode始终在内存中保存metadata【为了速度快】，用于处理用户的“读”请求。放在内存里当然很快了，放在磁盘里读的速度慢。

     在“写”请求时，namenode首先向edits里面写日志，让edits里面记录一条，再修改内存，让内存里面也加入一条信息，最后向客户端返回。

    Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，而是每一 段时间通过合并edits文件来更新内容。Secondary namenode就是用来合并fsimage和edits文件来更新NameNode的metedata的。

secondarynamenode：【集群里并没有，但伪分布式里面有】下载——合并——推送

lHA的一个解决方案。但不支持热备。配置即可。

l执行过程：从NameNode上下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，替换旧的fsimage.

l默认在安装在NameNode节点上，但这样...不安全！

内存到磁盘——序列化  磁盘到内存——反序列化

因为容易不安全，所以分在两个地方装namenode和secondarynamenode，如果一个烧掉了，另一个还在

默认每1个小时，secondarynamenode，就要把两个合并一下。或者edits文件大于64M，就要合并【因为edits文件存储数据越来越大】

如果我正在同步的时候，正在上传数据，那我要往edits.new里面写，

1.发送给namenode，2反馈给client，3开始在datanode里写数据，在3的同时，namenode要操作edits文件，倘若写入成功，edit+1，且，内存中的Metadata也+1

此时edits和fsimage里的数据没有同步，用上面那个图的secondary图合并同步，同步需要满足checkpoint。前文已提到。

上面那个黄色浅蓝的图，面试的时候很愿意考。关注一下