HBase Configuration过程

(2012-10-22 15:56:10)

转载▼

 HBase客户端API中，我们看到对HBase的任何操作都需要首先创建HBaseConfiguration类的实 例。为HBaseConfiguration类继承自Configuration类，而Configuration类属于Hadoop核心包中实现的类， 该类的主要作用是提供对配置参数的访问途径。

Configuration类中的配置参数都是来自于Hadoop的配置文件中，而这些配置文件在Configuration类中被当做一个个资源 (Resource)，每个资源都包含了一组以XML格式存在的name/value对，事实上，这些资源每一个都是单独的XML文件，例如HBase安 装配置中提到过的core-site.xml等。对于Configuration类而言，最重要的就是提供访问配置信息的接口，该类提供了一系列的 Set/Get方法用于读写特定名称(name)的值(value)。此外，Configuration类除了提供加载默认配置文件的方法外，还提供了addResource方法加载指定的xml配置文件，这样就允许一些基于Hadoop的子项目甚至是用户自己定义的配置参数被加载使用。

addResource类共有4种方式加载指定的配置信息：

Ø  String:加载指定文件名的配置文件，该文件须在Hadoop的classpath中。

Ø  Path:直接加载本地文件系统上以该参数为完整路径的配置文件。

Ø  URL: 指定配置文件的Url路径并加载。

Ø  InputStream:从输入流中反序列化所得到的配置对象。

Configuration类在默认情况下，会按照顺序加载下列配置文件：

Ø  core-default.xml:该文件包含了Hadoop的只读配置参数。

Ø  core-site.xml:该文件即用户设置的Hadoop配置参数。

由于Configuration类同时提供了对参数的Set方 法，而处于集群的安全性等原因，管理员可能并不像某些参数在后期被改动，这时可以将配置文件中不希望被改动的参数设置为 final，Configuration类在加载配置参数后，就会禁止对声明为final的参数的改动。如下图所示，可以设置core-site.xml 中的fs.default.name参数为final，以禁止该值被修改。

值得注意的是，早期版本的Hadoop配置是通过hadoop-
site.xml文件实现的，在近期的版本中，该配置文件已被弃用，而改用core-site.xml、mapred-site.xml和hdfs-
site.xml结合来完成配置。因此，在载入配置文件时，Hadoop会检查在classpath中是否存在hadoop-site.xml，如果存在
则会在日志中输出一条DEPRECATED的Warnning信息。

在了解了Configuration类之后，我们再分析其子类HBaseConfiguration类。下图为
HBaseConfiguration类的类图，除了继承自Configuration类之外，该类还实现了一下私有或共有的方法。从功能上讲，该类也是
提供对HBase配置参数的访问。

从图中可以看到，该类有两个构造函数：

public
HBaseConfiguration();

public
HBaseConfiguration(finalConfiguration c);

这两个构造函数是用来实例化
HBaseConfiguration类的，然而只在早期版本中使用，目前我们分析的0.90.4以及后期版本中，这两个构造函数都已被启用。由于新的
HBaseConfiguration类中所有的成员变量和成员方法都被声明为static，因此该类已经被禁止实例化，而当我们需要使用
HBaseConfiguration对HBase的配置信息进行访问时，事实上获得的是一个Configuration类的实例。

privatestatic Configuration
conf = null;

static{

conf = HBaseConfiguration.create();

}

显然，HBaseConfiguration.create()方法返回的是一个能够访问HBase配置信息的Configuration的实例。

publicstatic Configuration
create() {

Configuration conf = new Configuration();

return addHbaseResources(conf);

}

create()方法中主要做两个操作：首先创建一个Configuration类的实例conf，然后调用addHbaseResources方法对conf实例进行处理并将处理后的conf实例返回给该方法的调用者。

进一步，我们再分析addHbaseResources方法会执行那些操作：

public static
ConfigurationaddHbaseResources(Configuration conf) {

conf.addResource("hbase-default.xml");

conf.addResource("hbase-site.xml");

checkDefaultsVersion(conf);

checkForClusterFreeMemoryLimit(conf);

return conf;

}

首先，调用conf对象的addResource(Stringname)方法，依照次序加载如下配置文件：

Ø  hbase-default.xml:该文件是hbase的默认配置参数。

Ø  hbase-site.xml:该文件为用户对hbase的配置参数。

然后，调用
checkDefaultsVersion(Configurationconf)方法，该方法通过conf实例获取
hbase.defaults.for.version的值，即配置文件hbase-default.xml中的版本信息，同时获取当前运行的HBase
的版本信息，如果默认配置文件中的版本号不同于当前运行的HBase的版本号，则会抛出一个RuntimeException，报告配置文件与当前
HBase环境的版本不一致。

最后，调用checkForClusterFreeMemoryLimit(Configuration
conf)方法，该方法通过conf实例获取两个参数：

Ø  hbase.regionserver.global.memstore.upperLimit:RegionServer
中每个MemStore的内存上限比例，超过这个值，一个新的update操作将被挂起，并强制执行flush操作。默认值为0.4，表示最大比例为堆大
小的40%。

Ø  hfile.block.cache.size:HFile文件的块缓存大小占堆内存大小的比例。默认值为0.2，表示最大比例为20%。

获取这两个参数的值后，该方法将判断这两个参数的总大小是否超过
堆内存大小的80%，如果这两个参数之和超过0.8，就会抛出一个RuntimeException，报告当前MemStore和BlockCache所
占堆内存比例超过要成功执行集群操作的阈值上限。这里参数之和不能超过0.8的原因，是由于在HConstants类中，定义了一个
HBASE_CLUSTER_MINIMUM_MEMORY_THRESHOLD常量，该常量的值为0.2，该值为集群成功启动所需要的最小空闲堆内存百
分比，即集群成功启动所需要的空余堆空间至少为堆大小的20%。因此，当MemStore和BlockCache所占堆空间比例超过80%时，将导致集群
无法成功启动