namenode维护的变量有哪些

         之前的blog都是讲namenode的动态行为，今天来分析下静态数据，例如namenode到底维护了哪些变量。

namenode的主要工作都在FSNamesystem这个类中（有4749行代码），这里为了分析方便，我将用真实的例子来讲，例如我将文件的分块大小设置为512字节，这样是为了方便测试，然后我从本地copy了一个622字节的文件到hdfs文件系统上，这样文件就会被分为2块了，从datanode的存储数据目录看（/home/dikar/hadoop/tmp/dfs/data/current）一共生成了2个块文件，第一个块文件大小为512字节，第二个块文件大小为110字节（比较悲剧的是我的文件按照字节截取后再合起来就不是我之前的那个文件了，他没有考虑到我文件自身换行的完整性），我这里有2个datanode节点，第一个节点的ip是10.0.18.121 第二个节点的ip是10.0.18.122。以下是datanode中各个文件的信息

121节点上的  VERSION文件

#Sat Mar 12 15:55:05 CST 2011
namespaceID=1257554030
storageID=DS-863408884-127.0.0.1-50010-1299916505769
cTime=0
storageType=DATA_NODE
layoutVersion=-18

 122节点上的  VERSION文件

#Sat Mar 12 15:54:37 CST 2011
namespaceID=1257554030
storageID=DS-2139341662-127.0.0.1-50010-1299916477580
cTime=0
storageType=DATA_NODE
layoutVersion=-18

 这里127.0.0.1是我的机器名对应的ip，因为在host文件里有127.0.0.1和机器名的对应关系，故先取的127.0.0.1这个ip了，其实应该是取真实的eth接口上的ip地址，不过这个只是显示的问题。

注意到namespaceID都是一样的，其实这个是namenode上的id，我们可以看下namenode上VERSION文件的内容

#Sat Mar 12 21:59:56 CST 2011
namespaceID=1257554030
cTime=0
storageType=NAME_NODE
layoutVersion=-18

 我上传到hdfs上保存的文件名是test55，然后因为分块在datanode上生成了2个文件（2个datanode上的都是一样），2个分块后的文件名是

blk_-3134592920494009076
blk_-6874669727371532738

 有了上面的信息描述，那么我们就进入到FSNamesystem中看它在内存中维护了哪些变量。

 

// datanode networktoplogy
NetworkTopology clusterMap = new NetworkTopology();

   这个维护网络拓扑关系，因为我对机架采取的是默认配置，故都在一个机架上，这里保存的内容如下

 

Number of racks: 1
Expected number of leaves:2
/default-rack/10.0.18.122:50010
/default-rack/10.0.18.121:50010

   针对取最近节点的算法还是不错的，以后专门写一篇来分析下。

DNSToSwitchMapping dnsToSwitchMapping

   这个保存的数据内容如下：（比较简洁）

 

10.0.18.122=/default-rack
10.0.18.121=/default-rack

   以上2个都是和节点网络远近算法相关的数据。

 

Host2NodesMap host2DataNodeMap = new Host2NodesMap()

   这个保存的是datanode的ip与datanode描述对象的一个映射关系，保存的数据内容如下

10.0.18.122=org.apache.hadoop.hdfs.server.namenode.DatanodeDescriptor;@18e95d9
10.0.18.121=org.apache.hadoop.hdfs.server.namenode.DatanodeDescriptor;@10098b

 针对DatanodeDescriptor对象我会单独一篇文章来讲。

接下来是最重要的2个数据变量了，也是占内存比较大的。

/**
   * Stores the datanode -> block map.
   * <p>
   * Done by storing a set of {@link DatanodeDescriptor} objects, sorted by
   * storage id. In order to keep the storage map consistent it tracks
   * all storages ever registered with the namenode.
   * A descriptor corresponding to a specific storage id can be
   * <ul>
   * <li>added to the map if it is a new storage id;</li>
   * <li>updated with a new datanode started as a replacement for the old one
   * with the same storage id; and </li>
   * <li>removed if and only if an existing datanode is restarted to serve a
   * different storage id.</li>
   * </ul> <br>
   * The list of the {@link DatanodeDescriptor}s in the map is checkpointed
   * in the namespace image file. Only the {@link DatanodeInfo} part is
   * persistent, the list of blocks is restored from the datanode block
   * reports.
   * <p>
   * Mapping: StorageID -> DatanodeDescriptor
   */

  NavigableMap<String, DatanodeDescriptor> datanodeMap =
    new TreeMap<String, DatanodeDescriptor>();

   内存里数据格式大概如下

 

{
key:"DS-2139341662-127.0.0.1-50010-1299916477580"
value:DatanodeDescriptor{
        storageId:DS-2139341662-127.0.0.1-50010-1299916477580
        blockInfo{
            INodeFile{
            name:test55
            blocks:[blk_-3134592920494009076_1002,    
                        blk_-6874669727371532738_1002]
            }
        }

}
key:"DS-863408884-127.0.0.1-50010-1299916505769"
value:DatanodeDescriptor{
         storageId:DS-863408884-127.0.0.1-50010-1299916505769
         blockInfo{
            INodeFile{
            name:test55
            blocks:[blk_-3134592920494009076_1002,    
                        blk_-6874669727371532738_1002]
            }
}
}

 

   DatanodeDescriptor中保存了block的信息，这个等分析DatanodeDescriptor再说。

 

/**
 * This class maintains the map from a block to its metadata.
 * block's metadata currently includes INode it belongs to and
 * the datanodes that store the block.
 */
BlocksMap blocksMap 

    BlocksMap中具体管存储的是

 

Map<BlockInfo, BlockInfo> map

    对于BlockInfo我也会在后面安排专门的文章来分析。

    我们来看下BlocksMap里的内存数据

    因为map里的key value都是一样的，故只列出key

{
key1/value1 :BlockInfo{
        blockId:-6874669727371532738
        INodeFIle{
             name:test55
              blocks:[blk_-3134592920494009076_1002,
                          blk_-6874669727371532738_1002]
         }
      }
key2/value2:BlockInfo{
        blockId:-3134592920494009076
        INodeFIle{
             name:test55
              blocks:[blk_-3134592920494009076_1002,
                          blk_-6874669727371532738_1002]
         }
      }

}

 针对INodeFile也需要单独的一篇来分析。