HBase基础知识：
一，HMater节点：可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行
1,为Region server 分配region,2,负责region server 的负载均衡,3,发现失效的region server 并重新分配其上的region.
二，Region Server节点：
维护Master 分配给它的region，处理对这些region 的IO 请求。
负责切分在运行过程中变得过大的region、
三，Client：
HBase Client通过RPC方式和HMaster、HRegionServer通信；一个HRegionServer可以存放1000个HRegion；底层Table数据存储于HDFS中，而HRegion所处理的数据尽量和数据所在的DataNode在一起，实现数据的本地化；数据本地化并不是总能实现，比如在HRegion移动(如因Split)时，需要等下一次Compact才能继续回到本地化。
四，Zookeeper
Zookeeper Quorum存储-ROOT-表地址、HMaster地址
HRegionServer把自己以Ephedral方式注册到Zookeeper中，HMaster随时感知各个HRegionServer的健康状况
Zookeeper避免HMaster单点问题
//http://www.blogjava.net/DLevin/archive/2015/08/22/426877.html 这篇博客讲的比较详细。
HBase：客户端有很多代码，可以远程访问ReginServer,Zookeeper。当在客户端创建一个表的时候，肯定就已经连上了一个ReginServer这样在这个节点上的Regin上直接占地方了，然后在往里写数据。客户端的另外的进程监视创建表，往.meta文件里写记录。Master怎么向ReginServer分配Regin估计是Reginserver通过Zookeeper注册，然后Master通过Zookeeper了解Reginserver的情况，然后给Reginserver分配资源。这种资源估计是只是一种数字而已。具体资源还得看Reginserver端的资源配置。
HBase有两张特殊的Table,-Root-和.META.
-Root-:记录了.META.表的Regin信息，-Root只有一个。
.META.:记录了用户创建的表的Regin信息，.META记录了多个region
Zookeeper中记录了-root-表的位置
Client访问用户数据之前需要首先访问Zookeeper,访问-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。这个地址被存在ZooKeeper中。默认的路径是：/hbase/root-region-server 。然后访问-root-表，接着访问.meta表，最后找到用户数据的位置去访问。
http://blog.csdn.net/chlaws/article/details/16918913
-ROOT-和.META.表结构
到目前为止我们已经学习了必须的背景知识，下面我们要正式开始介绍Client端寻找RegionServer的整个过程。我打算用一个假想的例子来学习这个过程，因此我先构建了假想的-ROOT-表和.META.表。
我们先来看.META.表，假设HBase中只有两张用户表：Table1和Table2，Table1非常大，被划分成了很多Region，因此在.META.表中有很多条Row用来记录这些Region。而Table2很小，只是被划分成了两个Region，因此在.META.中只有两条Row用来记录。这个表的内容看上去是这个样子的：
.META.行记录结构
假设.META.表被分成了两个Region，那么-ROOT-的内容看上去大概是这个样子的：
-ROOT-行记录结构
