Hadoop之namenode-yellowcong

hadoop中的namenode是整个文件系统的管理节点。他维护整个系统的文件目录树、文件/文件的数据元信息和每个文件所对应的块，同时负责接收用户的请求

namenode配置文件

hadoop的文件都存在于我们在core-site.xml配置的hadoop.tmp.dir，

<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="configuration.xsl"?><!--  Licensed under the Apache License, Version 2.0 (the "License");  you may not use this file except in compliance with the License.  You may obtain a copy of the License at    http://www.apache.org/licenses/LICENSE-2.0  Unless required by applicable law or agreed to in writing, software  distributed under the License is distributed on an "AS IS" BASIS,  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  See the License for the specific language governing permissions and  limitations under the License. See accompanying LICENSE file.--><!-- Put site-specific property overrides in this file. --><configuration> <property>    <name>fs.defaultFS</name>    <value>hdfs://localhost:9000</value>    <final>true</final>  </property>  <property>    <name>hadoop.tmp.dir</name>     <!--这是我们配置的地方-->    <value>/usr/hadoop/tmp</value>  </property></configuration>

tmp目录结构

目录下面存在 data、name、namesecondary目录，目录所对应的hadoop服务

目录 hadoop服务 data DataNode name NameNode namesecondary SecondaryNameNode

NameNode结构

name下面存在一个current目录，目录下面就是当前的namenode的文件存储信息了

fsimage：元数据镜像文件。存储某一时段NameNode内存元信息
edits：操作日志文件
fstime:保存最近一次checkpoint时间

下面是一个标准的dfs.namenode.name.dir目录结构，注意edits和fsimage也可以通过配置放到不同目录中

    ├── current      │ ├── VERSION      │ ├── edits_0000000000000000001-0000000000000000007      │ ├── edits_0000000000000000008-0000000000000000015      │ ├── edits_0000000000000000016-0000000000000000022      │ ├── edits_0000000000000000023-0000000000000000029      │ ├── edits_0000000000000000030-0000000000000000030      │ ├── edits_0000000000000000031-0000000000000000031      │ ├── edits_inprogress_0000000000000000032      │ ├── fsimage_0000000000000000030      │ ├── fsimage_0000000000000000030.md5      │ ├── fsimage_0000000000000000031      │ ├── fsimage_0000000000000000031.md5      │ └── seen_txid      └── in_use.lock  

1、VERSION

 #Thu May 19 10:13:22 CST 2016      namespaceID=1242163293      clusterID=CID-124668a8-9b25-4ca7-97bf-5dd5c25041a9      cTime=1455091012961      storageType=NAME_NODE      blockpoolID=BP-180412957-192.168.1.8-1419305031110      layoutVersion=-60  

• layoutVersion - HDFS metadata版本号，通常只有HDFS增加新特性时才会更新这个版本号
• namespaceID/clusterID/blockpoolID - 这三个ID在整个HDFS集群全局唯一，作用是引导Datanode加入同一个集群。在HDFS Federation机制下，会有多个Namenode，所以不同Namenode直接namespaceID是不同的，分别管理一组blockpoolID，但是整个集群中，clusterID是唯一的，每次format namenode会生成一个新的，也可以使用-clusterid手工指定ID
• storageType - 有两种取值NAME_NODE /JOURNAL_NODE，对于JournalNode的参数dfs.journalnode.edits.dir，其下的VERSION文件显示的是JOURNAL_NODE
• cTime - HDFS创建时间，在升级后会更新该值

2、edits_start transaction ID-end transaction ID

finalized edit log segments，在HA环境中，Standby Namenode只能读取finalized log segments，

3、edits_inprogress__start transaction ID

当前正在被追加的edit log，HDFS默认会为该文件提前申请1MB空间以提升性能

4、fsimage_end transaction ID

每次checkpoing（合并所有edits到一个fsimage的过程）产生的最终的fsimage，同时会生成一个.md5的文件用来对文件做完整性校验

5、seen_txid

保存最近一次fsimage或者edits_inprogress的transaction ID。需要注意的是，这并不是Namenode当前最新的transaction ID，该文件只有在checkpoing(merge of edits into a fsimage)或者edit log roll(finalization of current edits_inprogress and creation of a new one)时才会被更新。

这个文件的目的在于判断在Namenode启动过程中是否有丢失的edits，由于edits和fsimage可以配置在不同目录，如果edits目录被意外删除了，最近一次checkpoint后的所有edits也就丢失了，导致Namenode状态并不是最新的，为了防止这种情况发生，Namenode启动时会检查seen_txid，如果无法加载到最新的transactions，Namenode进程将不会完成启动以保护数据一致性。

6、in_use.lock

防止一台机器同时启动多个Namenode进程导致目录数据不一致

SecondaryNameNode

HDFS的SecondayNameNode会定期（dfs.namenode.checkpoint.period，默认3600秒）的对最近的fsimage和一批新edits文件进行Checkpoint（也可以手工命令方式），Checkpoint发生后会将前一次Checkpoint后的所有edits文件合并到新的fsimage中，HDFS会保存最近两次checkpoint的fsimage。Namenode启动时会把最新的fsimage加载到内存中。这样保证了数据的最新，将SecondayNameNode和NameNode放在同一台机器上，不安全。