Hadoop-2.4.1学习之NameNode -format源码分析

在Hadoop-2.X中,使用hdfs namenode –format对文件系统进行格式化。虽然无论是在生产环境还是测试环境中,已经使用了该命令若干次了,也大体了解该命令就是在本地文件系统中创建几个文件夹,但具体是如何执行的则需要通过阅读源代码来了解了。

要想看到该命令的源代码,需要看看hdfs脚本中是如何执行相应的java类的。在hdfs脚本中,下面的语句说明了实际执行的java类和参数,其中类为org.apache.hadoop.hdfs.server.namenode.NameNode,参数为-format。虽然在命令行中输入的为hdfs namenode –forma,但将namenode赋予了COMMAND,并进行了参数的移位,这样参数就剩下了-format。

COMMAND=$1
Shift

if [ "$COMMAND" = "namenode" ] ; then
  CLASS='org.apache.hadoop.hdfs.server.namenode.NameNode'
  HADOOP_OPTS="$HADOOP_OPTS $HADOOP_NAMENODE_OPTS"

exec "$JAVA" -Dproc_$COMMAND $JAVA_HEAP_MAX $HADOOP_OPTS $CLASS "[email protected]"

在eclipse中找到org.apache.hadoop.hdfs.server.namenode.NameNode,并定位到main方法,代码如下:

public static void main(String argv[]) throws Exception {
    if (DFSUtil.parseHelpArgument(argv, NameNode.USAGE, System.out, true)) {
      System.exit(0);
    }

    try {
      StringUtils.startupShutdownMessage(NameNode.class, argv, LOG);
      NameNode namenode = createNameNode(argv, null);
      if (namenode != null) {
        namenode.join();
      }
    } catch (Throwable e) {
      LOG.fatal("Exception in namenode join", e);
      terminate(1, e);
    }
  }

其中parseHelpArgument方法用于解析命令行参数,startupShutdownMessage方法输出启动和关闭的信息,NameNode的主要工作由createNameNode方法完成。在createNameNode中执行format方法之前先对参数进行了解析,具体代码如下,其中argv根据format时使用的参数可以为:-format [-clusterid cid ] [-force] [-nonInteractive](完整的命令为hdfs namenode [-format
[-clusterid cid ] [-force] [-nonInteractive]])。该方法用于设置StartupOption中的clusterId为cid,若使用了-force参数则StartupOption中的isForceFormat为true,若使用了-nonInteractive则将StartupOption中的isInteractiveFormat为false,后两个参数的默认值为false和true。

StartupOption startOpt = parseArguments(argv);

在createNameNode方法中与-format有关系的代码如下,且在执行完毕后返回null,结合main方法中的代码可以得知,HDFS的format执行完毕。format方法的参数分别为HdfsConfiguration、isForceFormat和isInteractiveFormat。

case FORMAT: {
        boolean aborted = format(conf, startOpt.getForceFormat(),
            startOpt.getInteractiveFormat());
        terminate(aborted ? 1 : 0);
        return null; // avoid javac warning
      }

接下来进入format方法,看看具体都执行了哪些操作,由于该方法是整个HDFS格式化的核心方法,所以会完整细致的分析该方法,这样势必会将整个方法分成几个部分,下面是第一部分的代码,这部分代码用于获取NameNode的NameServiceID和NameNode ID,并检查NameNode是否允许格式化,其中使用了参数dfs.namenode.support.allow.format,该参数的默认值为true(在生产环境中可以在格式化完成后将该参数设置为false,避免格式化正在运行的HDFS)。

String nsId = DFSUtil.getNamenodeNameServiceId(conf);
    String namenodeId = HAUtil.getNameNodeId(conf, nsId);
    initializeGenericKeys(conf, nsId, namenodeId);
    checkAllowFormat(conf);

    if (UserGroupInformation.isSecurityEnabled()) {
      InetSocketAddress socAddr = getAddress(conf);
      SecurityUtil.login(conf, DFS_NAMENODE_KEYTAB_FILE_KEY,
          DFS_NAMENODE_USER_NAME_KEY, socAddr.getHostName());
    }

第二部分代码如下,主要根据配置文件获取要格式化的目录、存储edits日志的目录等,以及在未指定clusterId的情况生成新的clusterId用于标识命名空间。

/*获取参数dfs.namenode.name.dir设置的目录,该值用于存储fsimage
    *默认值为file://${hadoop.tmp.dir}/dfs/name,
    *其中hadoop.tmp.dir定义在core-default.xml中,值为/tmp/hadoop-${user.name}
 */
Collection<URI> nameDirsToFormat = FSNamesystem.getNamespaceDirs(conf);
/*获取在primary和secondary namenode之间共享的edits目录
*相应的参数为dfs.namenode.shared.edits.dir
 */
    List<URI> sharedDirs = FSNamesystem.getSharedEditsDirs(conf);
    List<URI> dirsToPrompt = new ArrayList<URI>();
    dirsToPrompt.addAll(nameDirsToFormat);
dirsToPrompt.addAll(sharedDirs);
/*获取保存edits的目录,对应的参数为dfs.namenode.edits.dir
*若上面的参数没有配置,则使用与fsimage一致的目录
*/
    List<URI> editDirsToFormat = FSNamesystem.getNamespaceEditsDirs(conf);

    // if clusterID is not provided - see if you can find the current one
    String clusterId = StartupOption.FORMAT.getClusterId();
    if(clusterId == null || clusterId.equals("")) {
      //Generate a new cluster id
      clusterId = NNStorage.newClusterID();
    }
    System.out.println("Formatting using clusterid: " + clusterId);

最后一部分代码执行了创建fsimage和edits文件的工作,由于这两个文件的创建可以做为单独的源码分析进行,在此就不进行详细地分析,会有专门的文章学习这部分代码。

FSImage fsImage = new FSImage(conf, nameDirsToFormat, editDirsToFormat);
    try {
      FSNamesystem fsn = new FSNamesystem(conf, fsImage);
      fsImage.getEditLog().initJournalsForWrite();

      if (!fsImage.confirmFormat(force, isInteractive)) {
        return true; // aborted
      }
      fsImage.format(fsn, clusterId);

现在已经分析完了执行hdfs namenode –format命令时都执行了哪些操作,其实就是根据配置文件中的特定参数如dfs.namenode.name.dir等,将fsimage和edits文件写入这些目录,而fsimage和edits文件的创建及格式等留待后面分析。

时间: 2024-08-08 12:29:22

Hadoop-2.4.1学习之NameNode -format源码分析的相关文章

memcached学习笔记——存储命令源码分析上

原创文章,转载请标明,谢谢. 上一篇分析过memcached的连接模型,了解memcached是如何高效处理客户端连接,这一篇分析memcached源码中的process_update_command函数,探究memcached客户端的set命令,解读memcached是如何解析客户端文本命令,剖析memcached的内存管理,LRU算法是如何工作等等. 解析客户端文本命令 客户端向memcached server发出set操作,memcached server读取客户端的命令,客户端的连接状态

u-boot学习(三):u-boot源码分析

建立域模型和关系数据模型有着不同的出发点: 域模型: 由程序代码组成, 通过细化持久化类的的粒度可提高代码的可重用性, 简化编程 在没有数据冗余的情况下, 应该尽可能减少表的数目, 简化表之间的参照关系, 以便提高数据的访问速度 Hibernate 把持久化类的属性分为两种: 值(value)类型: 没有 OID, 不能被单独持久化, 生命周期依赖于所属的持久化类的对象的生命周期 实体(entity)类型: 有 OID, 可以被单独持久化, 有独立的生命周期(如果实体类型包含值类型,这个值类型就

EasyUI学习总结(三)——easyloader源码分析

EasyUI学习总结(三)--easyloader源码分析 easyloader模块是用来加载jquery easyui的js和css文件的,而且它可以分析模块的依赖关系,先加载依赖项.模块加载好了会调用parse模块来解析页面.把class是easyui开头的标签都转化成easyui的控件. 先看Demo1例子,再分析源代码. 1 <!DOCTYPE html> 2 <html> 3 <head> 4 <title>easyloader范例</tit

EasyUI学习总结(四)——parser源码分析

EasyUI学习总结(四)--parser源码分析 parser模块是easyloader第一个加载的模块,它的主要作用,就是扫描页面上easyui开头的class标签,然后初始化成easyui控件. 1 /** 2 * parser模块主要是解析页面中easyui的控件 3 */ 4 $.parser = { 5 // 是否自动解析 6 auto: true, 7 8 // 可以被解析的控件 9 plugins:['linkbutton','menu','menubutton','splitb

memcached学习笔记——存储命令源码分析下篇

上一篇回顾:<memcached学习笔记——存储命令源码分析上篇>通过分析memcached的存储命令源码的过程,了解了memcached如何解析文本命令和mencached的内存管理机制. 本文是延续上一篇,继续分析存储命令的源码.接上一篇内存分配成功后,本文主要讲解:1.memcached存储方式:2.add和set命令的区别. memcached存储方式 哈希表(HashTable) 哈希表在实践中使用的非常广泛,例如编译器通常会维护的一个符号表来保存标记,很多高级语言中也显式的支持哈希

Hadoop-2.4.1学习之Map任务源码分析(下)

在Map任务源码分析(上)中,对MAP阶段的代码进行了学习,这篇文章文章将学习Map任务的SORT阶段.如果Reducer的数量不为0,则还需要进行SORT阶段,但从上面的学习中并未发现与MAP阶段执行完毕调用mapPhase.complete()类似的在SORT阶段执行完毕调用sortPhase.complete()的源码,那SORT阶段是在什么时候启动的?对于Map任务来说,有输入就有输出,输入由RecordReader负责,输出则由RecordWriter负责,当Reducer的数量不为0

Hadoop-2.4.1学习之Map任务源码分析(上)

众所周知,Mapper是MapReduce编程模式中最重要的环节之一(另一个当然是Reducer了).在Hadoop-2.x版本中虽然不再有JobTracker和TaskTracker,但Mapper任务的功能却没有变化,本篇文章将结合源代码深入分析Mapper任务时如何执行的,包括处理InputSplit,mapper的输出.对输出分类等.在进行分析之前先明确几个概念:作业.任务.任务的阶段和任务的状态,可以将作业理解为要最终实现的功能或目的,比如统计单词的数量,而任务就是对该作业的拆分,只负

正式学习React(五) react-redux源码分析

磨刀不误砍柴工,咱先把react-redux里的工具函数分析一下: 源码点这里  shallowEqual.js 1 export default function shallowEqual(objA, objB) { 2 if (objA === objB) { 3 return true 4 } 5 6 const keysA = Object.keys(objA) 7 const keysB = Object.keys(objB) 8 9 if (keysA.length !== keys

驱动学习之led-class.c源码分析

1:subsys_initcall宏 #define __define_initcall(level,fn,id) \  static initcall_t __initcall_##fn##id __used     __attribute__((__section__(".initcall" level ".init"))) = fn      #define subsys_initcall(fn)        __define_initcall("