从 HDFS 文件读写过程中，可以看出，HDFS 文件写入时是串行写入的，数据包先发送给节点A，然后节点A发送给B，B在给C；而HDFS文件读取是并行的， 客户端 Client 直接并行读取block所在的节点。
9. NameNode 工作机制以及元数据管理（重要）
namenode工作机制
第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
客户端对元数据进行增删改的请求。
namenode记录操作日志，更新滚动日志。
namenode在内存中对数据进行增删改查。
secondary namenode
secondary namenode询问 namenode 是否需要 checkpoint。直接带回 namenode 是否检查结果。
secondary namenode 请求执行 checkpoint。
namenode 滚动正在写的edits日志。
将滚动前的编辑日志和镜像文件拷贝到 secondary namenode。
secondary namenode 加载编辑日志和镜像文件到内存，并合并。
生成新的镜像文件 fsimage.chkpoint。
拷贝 fsimage.chkpoint 到 namenode。
namenode将 fsimage.chkpoint 重新命名成fsimage。
9.2 FSImage与edits详解所有的元数据信息都保存在了FsImage与Eidts文件当中，这两个文件就记录了所有的数据的元数据信息，元数据信息的保存目录配置在了 hdfs-site.xml 当中
<!--fsimage文件存储的路径--> <property> <name>dfs.namenode.name.dir</name> <value>file:///opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas</value> </property> <!-- edits文件存储的路径 --> <property> <name>dfs.namenode.edits.dir</name> <value>file:///opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits</value> </property>客户端对hdfs进行写文件时会首先被记录在edits文件中。
edits修改时元数据也会更新。
每次hdfs更新时edits先更新后客户端才会看到最新信息。
fsimage：是namenode中关于元数据的镜像，一般称为检查点。
一般开始时对namenode的操作都放在edits中，为什么不放在fsimage中呢？
因为fsimage是namenode的完整的镜像，内容很大，如果每次都加载到内存的话生成树状拓扑结构，这是非常耗内存和CPU。
fsimage内容包含了namenode管理下的所有datanode中文件及文件block及block所在的datanode的元数据信息。随着edits内容增大，就需要在一定时间点和fsimage合并。
9.3 FSimage文件当中的文件信息查看使用命令 hdfs oiv
cd /opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/namenodeDatas/current hdfs oiv -i fsimage_0000000000000000112 -p XML -o hello.xml 9.4 edits当中的文件信息查看查看命令 hdfs oev
cd /opt/hadoop-2.6.0-cdh5.14.0/hadoopDatas/dfs/nn/edits hdfs oev -i edits_0000000000000000112-0000000000000000113 -o myedit.xml -p XML 9.5 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。同时会更新fsimage。
hadoop进入安全模式时需要管理员使用dfsadmin的save namespace来创建新的检查点。
secondarynamenode在合并edits和fsimage时需要消耗的内存和namenode差不多，所以一般把namenode和secondarynamenode放在不同的机器上。
fsimage与edits的合并时机取决于两个参数，第一个参数是默认1小时fsimage与edits合并一次。
第一个参数：时间达到一个小时fsimage与edits就会进行合并
dfs.namenode.checkpoint.period 3600第二个参数：hdfs操作达到1000000次也会进行合并
dfs.namenode.checkpoint.txns 1000000第三个参数：每隔多长时间检查一次hdfs的操作次数
dfs.namenode.checkpoint.check.period 60 9.6 namenode元数据信息多目录配置为了保证元数据的安全性，我们一般都是先确定好我们的磁盘挂载目录，将元数据的磁盘做RAID1
namenode的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性。
具体配置方案: