hadoop配置文件加载顺序

  用了一段时间的hadoop,现在回来看看源码发现别有一番味道,温故而知新,还真是这样的

  在使用hadoop之前我们需要配置一些文件,hadoop-env.sh,core-site.xml,hdfs-site.xml,mapred-site.xml。那么这些文件在什么时候被hadoop使用?

  一般的在启动hadoop的时候使用最多就是start-all.sh,那么这个脚本都干了些什么?

start-all.sh

# Start all hadoop daemons. Run this on master node.
#特别的地方时要在master节点上启动hadoop所有进程

bin=`dirname "$0"`
bin=`cd "$bin"; pwd` #bin=$HADOOP_HOME/bin

if [ -e "$bin/../libexec/hadoop-config.sh" ]; then
. "$bin"/../libexec/hadoop-config.sh
else
. "$bin/hadoop-config.sh"
fi

# start dfs daemons
"$bin"/start-dfs.sh --config $HADOOP_CONF_DIR

# start mapred daemons
"$bin"/start-mapred.sh --config $HADOOP_CONF_DIR

加载hadoop-env.sh

  脚本先找到hadoop中的bin目录,在配置了hadoop环境变量的情况下该处可以使用$HADOOP_HOME/bin直接代替。接下来是执行hadoop-config.sh,这个文件可能会在$HADOOP_HOME/libexec目录或者是$HADOOP_HOME/bin目录下,在我使用的hadoop版本中是在$HADOOP_HOME/libexec目录下,在hadoop-config.sh文件中有下面这几行脚本

hadoop-config.sh

if [ -f "${HADOOP_CONF_DIR}/hadoop-env.sh" ]; then
. "${HADOOP_CONF_DIR}/hadoop-env.sh"
fi

测试$HADOOP_HOME/conf/hadoop-env.sh为普通文件后,通过  . "${HADOOP_CONF_DIR}/hadoop-env.sh"执行hadoop-env.sh这个脚本,ok,我们在hadoop-env.sh中配置的环境变量 JAVA_HOME 生效了,其实我感觉这个地方完全可以不用配置,为什么?因为我们在linux上安装hadoop肯定要安装java,那么安装时肯定都会配置JAVA_HOME,在/etc/profile中配置的环境变量在任何的shell进程中都生效。

加载core-*.xml,hdfs.*.xml文件

 

执行完hadoop-config.sh命令后,执行$HADOOP_HOME/start-dfs.sh。该脚本的作用是启动namenode,datename,secondarynamenode这三个与hdfs有关的进程

start-dfs.sh

# Run this on master node.

usage="Usage: start-dfs.sh [-upgrade|-rollback]"

bin=`dirname "$0"`
bin=`cd "$bin"; pwd`

if [ -e "$bin/../libexec/hadoop-config.sh" ]; then
. "$bin"/../libexec/hadoop-config.sh
else
. "$bin/hadoop-config.sh"
fi

# get arguments
if [ $# -ge 1 ]; then
nameStartOpt=$1
shift
case $nameStartOpt in
(-upgrade)
;;
(-rollback)
dataStartOpt=$nameStartOpt
;;
(*)
echo $usage
exit 1
;;
esac
fi

# start dfs daemons
# start namenode after datanodes, to minimize time namenode is up w/o data
# note: datanodes will log connection errors until namenode starts
"$bin"/hadoop-daemon.sh --config $HADOOP_CONF_DIR start namenode $nameStartOpt
"$bin"/hadoop-daemons.sh --config $HADOOP_CONF_DIR start datanode $dataStartOpt
"$bin"/hadoop-daemons.sh --config $HADOOP_CONF_DIR --hosts masters start secondarynamenode

仔细看看不能发现,在start-dfs.sh中同样也会执行hadoop-config.sh,之所以有这一步,是因为我们不总是使用start-all.sh来启动hadoop的所有进程,有时候我们只需要使用hdfs而不需要MapReduce,此时只需要单独执行start-dfs.sh,同样hadoop-config.sh中定义的变量也会被文件系统相关进程使用,所以这里在启动namenode,datanode,secondarynamenode之前需要先执行hadoop-config.sh,同时hadoop-env.sh文件被执行。再来看看最后的三行代码,分别是启动namenode,datanode,secondarynamenode的脚本。启动hadoop后一共有5个进程,其中三个就是namenode,datanode,secondarynamenode,既然能启动进程说明对应的类中一定有main方法,看看源码就可以验证这一点,这不是重点,重点是来看看对应的类是怎么加载配置文件的。无论是namenode,还是dataname,还是secondarynamenode,他们在启动时都会加载core-*.xml和hdfs-*.xml文件,以org.apache.hadoop.hdfs.server.namenode.NameNode 这个类为例,其他的两个类org.apache.hadoop.hdfs.server.datanode.DataNode,org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode类似。

org.apache.hadoop.hdfs.server.namenode.NameNode

public class NameNode implements ClientProtocol, DatanodeProtocol,
NamenodeProtocol, FSConstants,
RefreshAuthorizationPolicyProtocol,
RefreshUserMappingsProtocol {
static{
Configuration.addDefaultResource("hdfs-default.xml");
Configuration.addDefaultResource("hdfs-site.xml");
}
...
}

看看静态代码块里面内容,会很兴奋,看到了hdfs-default.xml和hdfs-site.xml。对重点就在这里,static code block在类加载到jvm执行类的初始化时会执行(不是对象初始化)。Configuration.addDefaultResource("hdfs-default.xml");这段代码执行前会先将Configuration这个类加载jvm中,那么看下org.apache.hadoop.conf.Configuration这个类中的static code block干了些什么

org.apache.hadoop.conf.Configuration

static{
//print deprecation warning if hadoop-site.xml is found in classpath
ClassLoader cL = Thread.currentThread().getContextClassLoader();
if (cL == null) {
cL = Configuration.class.getClassLoader();
}
if(cL.getResource("hadoop-site.xml")!=null) {
LOG.warn("DEPRECATED: hadoop-site.xml found in the classpath. " +
"Usage of hadoop-site.xml is deprecated. Instead use core-site.xml, "
+ "mapred-site.xml and hdfs-site.xml to override properties of " +
"core-default.xml, mapred-default.xml and hdfs-default.xml " +
"respectively");
}
addDefaultResource("core-default.xml");
addDefaultResource("core-site.xml");
}

Configuration类在类的初始化时加载了core-default.xml和core-site.xml这两个文件。这样namenode在启动的时候就加载了core-*.xml和hdfs-*.xml文件,其中core-*.xml是由Configuration这个类加载的。

加载core-*.xml和mapred-*.xml文件

 

执行完start-dfs.xml后,执行start-mapred.sh,该脚本和start-hdf.sh差不多。

start-mapred.sh
# Start hadoop map reduce daemons. Run this on master node.

bin=`dirname "$0"`
bin=`cd "$bin"; pwd`

if [ -e "$bin/../libexec/hadoop-config.sh" ]; then
. "$bin"/../libexec/hadoop-config.sh
else
. "$bin/hadoop-config.sh"
fi

# start mapred daemons
# start jobtracker first to minimize connection errors at startup
"$bin"/hadoop-daemon.sh --config $HADOOP_CONF_DIR start jobtracker
"$bin"/hadoop-daemons.sh --config $HADOOP_CONF_DIR start tasktracker
 

该脚本同样也会执行hadoop-config.sh,同样也会执行hadoop-env.sh。这里和start-dfs.sh是统一的。最后两行代码是启动jobtracker和tasktracker进程的。同样对应着两个类org.apache.hadoop.mapred.JobTracker和org.apache.hadoop.mapred.TaskTracker

以org.apache.hadoop.mapred.JobTracker为例,org.apache.hadoop.mapred.TaskTracker类似

org.apache.hadoop.mapred.JobTracker

public class JobTracker implements MRConstants, InterTrackerProtocol,
JobSubmissionProtocol, TaskTrackerManager, RefreshUserMappingsProtocol,
RefreshAuthorizationPolicyProtocol, AdminOperationsProtocol,
JobTrackerMXBean {

static{
Configuration.addDefaultResource("mapred-default.xml");
Configuration.addDefaultResource("mapred-site.xml");
}
...
}

ok,有了上面的解释,现在已经很明白了。JobTracker启动时加载了core-*.xml和mapred-*.xml文件,其中core-*.xml是由Configuration完成的。

summarize:

使用start-all.sh启动hadoop所有的进程时,各种配置文件得加载顺序:

HDFS:hadoop-env.sh --> core-default.xml --> core-site.xml --> hdfs-default.xml --> hdfs-site.xml

Mapred:hadoop-env.sh --> core-default.xml --> core-site.xml --> mapred.default.xml --> mapred.site.xml

注意到一点,core-*.xml系统的文件总是优先加载,而且hadoop中5个进程都会加载,这也说明core-*.xml是公共的基础库,被大家伙共享。

配置文件时在进程启动时加载的,这也可以证明如果修改了hadoop的配置文件,无论是系统配置文件还是管理员配置文件,都需要重新启动进程生效。

时间: 2024-11-23 20:53:22

hadoop配置文件加载顺序的相关文章

shell脚本,配置文件加载顺序,以及什么时候加载。

在linux系统中,有/etc/profile,/etc/bashrc ,~/.bash_profile,~/bashrc这四个配置文件,这些文件,会自动的在某些时候加载,也就是点一下,一般都是些别名,特殊变量里面.四个有加载顺序,最先加载的是etc开头的/etc/profile,然后是/etc/.bashrc,有一些版本没有/etc/.bashrc了已经,这俩叫做全局的,然后会根据登陆的用户加载家目录下的profile bashrc.为什么要这么加载有原因?如果全局设定a=1,你的家目录自己设

Springboot配置文件加载顺序

使用Springboot开发的时候遇到了配置的问题,外部config里的配置文件本来没有配置https怎么启动还是https呢,原来开发中测试https在classpath路径的配置文件添加https的配置,最后打包jar,加载配置文件的时候由于config里面的配置文件没有配置https,就用classpath里面的配置了,在外部config把https关闭既可以(ssl.enabled=false),下面是Springboot加载配置文件的顺序,这里记录一下. Springboot从下面的位

yii2 配置文件加载顺序, 以及调用自定义配置信息。

在配置上一般有以下问题: 每个团队成员都会有自己的配置项,提交这样的配置项将会影响其他团队成员: 生产库密码和API密钥不应该出现在代码库中: 有多个服务器环境的情况:开发.测试.生产:每一种环境应该有自己的配置项: 每种情况都去定义所有的配置选项,是非常重复且要花大量时间去维护. 为了解决这些问题,yii引入了一种简单的环境概念.每一种环境被一套在environments目录中的文件所表示.init命令用于切换这些环境.它所做的就是从环境目录复制一切交给根目录下的所有应用程序. 默认有2套环境

struts2中配置文件加载的顺序是什么?

struts2的StrutsPrepareAndExecuteFilter拦截器中对Dispatcher进行了初始化 在Dispatcher类的init方法中定义了配置文件的加载顺序(下面是源码) public void init() { if (configurationManager == null) { configurationManager = createConfigurationManager(DefaultBeanSelectionProvider.DEFAULT_BEAN_NA

3springboot:springboot配置文件(外部配置加载顺序、自动配置原理,@Conditional)

1.外部配置加载顺序 SpringBoot也可以从以下位置加载配置: 优先级从高到低 高优先级的配置覆盖低优先级的配置,所有的配置会形成互补配置  1.命令行参数 所有的配置都可以在命令行上进行指定 先打包在进行测试 java -jar spring-boot-02-config-02-0.0.1-SNAPSHOT.jar --server.port=8087 --server.context-path=/abc 指定访问的路径 多个配置用空格分开: --配置项=值 -- 由jar包外向jar包

Spring Boot配置文件的加载顺序

配置文件的加载顺序, 后加载的会覆盖先加载的:也就是properties配置文件的内容会替换掉.yml及.yaml文件的内容 原文地址:https://www.cnblogs.com/niwotaxuexiba/p/10849376.html

dubbo配置文件的加载顺序详解(图示)

Dubbo配置文件的加载顺序 ? 在使用apache dubbo.version2.7.3 时,配置文件的加载情况.以provider提供服务者为例. 配置文件 ,以下四个配置文件. 其优先级 application.properties #Dubbo config dubbo.application.name=boot-ego-user-service-provider dubbo.registry.address=zookeeper://127.0.0.1:2181 dubbo.protoc

java web项目启动加载顺序

web.xml加载过程(步骤):       1.启动WEB项目的时候,容器(如:Tomcat)会去读它的配置文件web.xml.读两个节点: <listener></listener> 和 <context-param></context-param> 2.紧接着,容器创建一个ServletContext(上下文),这个WEB项目所有部分都将共享这个上下文. 3.容器将<context-param></context-param>转

(转载)web.xml 中的listener、 filter、servlet 加载顺序及其详解

首先可以肯定的是,加载顺序与它们在 web.xml 文件中的先后顺序无关.  但不会因为 filter 写在 listener 的前面而会先加载 filter.  最终得出的结论是:listener -> filter -> servlet 同时还存在着这样一种配置节:context-param,它用于向 ServletContext 提供键值对,即应用程序上下文信息.我们的 listener, filter 等在初始化时会用到这些上下文中的信息,那么 context-param 配置节是不是