HBase Configuration过程

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配置参数的访问。

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

<code>

      public HBaseConfiguration();

      public HBaseConfiguration(finalConfiguration c);

</code>

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

<code>

      privatestatic Configuration conf = null;

      static{

             conf = HBaseConfiguration.create();

      }

</code>

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

<code>

      publicstatic Configuration create() {

          Configuration conf = new Configuration();

          return addHbaseResources(conf);

      }

</code>

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

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

<code>

      public static ConfigurationaddHbaseResources(Configuration conf) {

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

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

         checkDefaultsVersion(conf);

         checkForClusterFreeMemoryLimit(conf);

          return conf;

      }

</code>

       首先，调用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%时，将导致集群无法成功启动。

本帖为原创内容，转载请声明出处：http://hi.baidu.com/ritchie_wang/item/d24c2dfe3911c1753d198bda