NameNode与Datanode的总结概述

5、hdfs的架构之文件的文件副本机制以及block块存储  
   

所有的文件都是以block块的方式存放在HDFS文件系统当中，在hadoop1当中，文件的block块默认大小是64M，hadoop2当中，文件的block块大小默认是128M，block块的大小可以通过hdfs-site.xml当中的配置文件进行指定

    <property>

       <name>dfs.block.size</name>

        <value>块大小 以KB为单位</value>//只写数值就可以

    </property>

5.1、抽象成数据块的好处

1.     一个文件有可能大于集群中任意一个磁盘
10T*3/128 = xxx块 2T，2T，2T 文件方式存—–>多个block块，这些block块属于一个文件

2.     使用块抽象而不是文件可以简化存储子系统

3.     块非常适合用于数据备份进而提供数据容错能力和可用性

5.2、块缓存

通常DataNode从磁盘中读取块，但对于访问频繁的文件，其对应的块可能被显示的缓存在DataNode的内存中，以堆外块缓存的形式存在。默认情况下，一个块仅缓存在一个DataNode的内存中，当然可以针对每个文件配置DataNode的数量。作业调度器通过在缓存块的DataNode上运行任务，可以利用块缓存的优势提高读操作的性能。

例如：
连接（join）操作中使用的一个小的查询表就是块缓存的一个很好的候选。
用户或应用通过在缓存池中增加一个cache directive来告诉namenode需要缓存哪些文件及存多久。缓存池（cache pool）是一个拥有管理缓存权限和资源使用的管理性分组。

例如一个文件 130M，会被切分成2个block块，保存在两个block块里面，实际占用磁盘130M空间，而不是占用256M的磁盘空间

5.3、hdfs的文件权限验证

hdfs的文件权限机制与linux系统的文件权限机制类似

r:read  w:write  x:execute  权限x对于文件表示忽略，对于文件夹表示是否有权限访问其内容

如果linux系统用户zhangsan使用hadoop命令创建一个文件，那么这个文件在HDFS当中的owner就是zhangsan

HDFS文件权限的目的，防止好人做错事，而不是阻止坏人做坏事。HDFS相信你告诉我你是谁，你就是谁

6、HDFS的元数据信息FSimage以及edits和secondaryNN的作用

在hadoop当中，使用如下架构的时候

也就是namenode就一个的时候，所有的元数据信息都保存在了FsImage与Eidts文件当中，这两个文件就记录了所有的数据的元数据信息，元数据信息的保存目录配置在了hdfs-site.xml当中

<property>

               <name>dfs.namenode.name.dir</name>

               <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas</value>

        </property>

<property>

               <name>dfs.namenode.edits.dir</name>

               <value>file:///export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits</value>

  </property>

6.1、FSImage与edits详解

客户端对hdfs进行写文件时会首先被记录在edits文件中。

edits修改时元数据也会更新。

每次hdfs更新时edits先更新后客户端才会看到最新信息。

fsimage:是namenode中关于元数据的镜像，一般称为检查点。

一般开始时对namenode的操作都放在edits中，为什么不放在fsimage中呢？

因为fsimage是namenode的完整的镜像，内容很大，如果每次都加载到内存的话生成树状拓扑结构，这是非常耗内存和CPU。

fsimage内容包含了namenode管理下的所有datanode中文件及文件block及block所在的datanode的元数据信息。随着edits内容增大，就需要在一定时间点和fsimage合并。

合并过程见SecondaryNameNode如何辅助管理FSImage与edits

6.2、FSimage文件当中的文件信息查看

官方查看文档

http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.14.0/hadoop-project-dist/hadoop-hdfs/HdfsEditsViewer.html

使用命令hdfs  oiv

cd  /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/current

hdfs oiv -i fsimage_0000000000000000864 -p XML-o hello.xml

6.3、edits当中的文件信息查看

官方查看文档

http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.14.0/hadoop-project-dist/hadoop-hdfs/HdfsEditsViewer.html

查看命令hdfs  oev

cd /export/servers/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits

hdfs oev -i [url=]edits_0000000000000000865-0000000000000000866[/url][a1]  -o myedit.xml -p XML

6.4、secondarynameNode如何辅助管理FSImage与Edits文件

①：secnonaryNN通知NameNode切换editlog

②：secondaryNN从NameNode中获得FSImage和editlog(通过http方式)

③：secondaryNN将FSImage载入内存，然后开始合并editlog，合并之后成为新的fsimage

④：secondaryNN将新的fsimage发回给NameNode

⑤：NameNode用新的fsimage替换旧的fsimage

完成合并的是secondarynamenode，会请求namenode停止使用edits,暂时将新写操作放入一个新的文件中（edits.new)。secondarynamenode从namenode中通过http get获得edits，因为要和fsimage合并，所以也是通过http get 的方式把fsimage加载到内存，然后逐一执行具体对文件系统的操作，与fsimage合并，生成新的fsimage，然后把fsimage发送给namenode，通过http post的方式。namenode从secondarynamenode获得了fsimage后会把原有的fsimage替换为新的fsimage,把edits.new变成edits。同时会更新fstime。

hadoop进入安全模式时需要管理员使用dfsadmin的save namespace来创建新的检查点。

secondarynamenode在合并edits和fsimage时需要消耗的内存和namenode差不多，所以一般把namenode和secondarynamenode放在不同的机器上。

fs.checkpoint.period: 默认是一个小时（3600s)

fs.checkpoint.size:  edits达到一定大小时也会触发合并（默认64MB)

看一看。