1. Hbase的集群架构

    首先hbase是hadoop的一个组件.而hadoop内部有很多的组件，这些组件几乎都依赖于hadoop最核心的两个东西建立起来的,一个是hdfs文件系统，另一个是mapreduce。当然hbase也不例外。

    hbase其实就是一个非关系型的数据库系统，可以将他和关系型数据库mysql类比一下，可能会便于

理解。

                                                                                                （此图引用于百度百科）

    Hbase有3种搭建方式：本地模式，伪分布模式和集群模式。那么一般情况下，我们便于学习Hbase的各种特性，只需要搭建伪分布模式即可。伪分布模式和集群模式的区别就是，hbase这个系统的所有守护进程全部运行在一个物理节点上和真正的分布在不同的物理节点之上。

    那么不论是伪分布和集群模式。其集群都包含几个主要的守护进程：HMaster，HRegionserver，zookeeper，以及client。那么我们通过命令行或者JavaApi或其他方式来使用Hbase时，都是通过client向hbase发送命令的。

    简单理解一下各个守护进程的作用：HMaster并不像hdfs中的Namenode那样，维护了整个系统的元数据，负责与client交互以实现对分节点的管理控制等全部统筹功能。Hmaster不负责与client有太多的交互，大部分情况下是由zookeeper来与client通信，然后实现对hbase的使用和管理。同时元数据也是由zookeeper来维护的，包括各个regionserver的地址等等。

    下面是一个简单的总结这两者各自的分工：

• Zookeeper

    保证任何时候，集群中只有一个running master

    存贮所有Region 的寻址入口

    实时监控Region Server 的状态，将Region server 的上线和下线信息，实时通知给Master

    存储Hbase 的schema,包括有哪些table，每个table 有哪些column family

• Master可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行

    为Region server 分配region

    负责region server 的负载均衡

    发现失效的region server 并重新分配其上的region

2. Hbase的存储方式和结构

    要讲Hbase的存储方式，我们从两方面来描述，一个是逻辑存储方式和物理的存储方式。（比如mysql中的二维关系表就是关系型数据库的逻辑存储结构，而这些表在硬盘上实际的存储形式便是所谓的物理存储方式）。

     Hbase的逻辑存储方式:

         表是稀疏表，所以可以类别mysql的关系表来理解，但是实际上并不是一回事。首先表有行健，列簇，列名，时间簇等几个概念。一个表定义之初，应该给出其表名，列簇信息。一行中，有多个固定的列簇，每个列簇下在插入数据时可以设置任意的列名。由一个行健，一个列簇+列名可以标定一个表中的单元格，而一个单元格中有由时间戳区分不同版本的值。表中的所有信息实际上都是以二进制形式存储的。不像关系表中支持那么多的数据类型。所以如果要用各种数据类型，只能由自己在程序中进行维护。

   Hbase的物理存储方式：

   Hbase的数据其实是由Hmaster进行配置，实际上存在各个Hregionserver中的。一个稀疏表是按行健进行排序和存储。这些表会按行被拆分为多个region存储道不同的regionserver中，一个regionserver中可以存储多region。这些region对应了表中的不同部分的行，而这些行实际也被划分为不同的文件存储，划分方式即是列簇，一个列簇一个文件，所以称之为面向列的数据库。那么这些文件实际上是放在hdfs里的，也就是以block的形式存储在硬盘上的。

   那么表是按rowkey的字典顺序来存储的，简单来说，就是对于rowkey，从左到右，译成ascii码来比大小排序。所以呢由于这个原因，在设计rowkey时，最好不要直接把时间戳这样的数据直接作为rowkey，因为这样会导致新产生的数据由于其时间戳都在一个范围内，导致存储的时候全部拥挤到某一个regionserver中。一般可以在时间戳前面加上散列值，设计成：（散列值：时间戳）这样的形式