1）、逻辑模型
Hbase 以表的形式存储数据，每个表由行和列组成，每个列属于一个特定的列族。
表中由行和列确定的存储单元称为一个元素，每个元素保存了同一份数据的多个版本，由时间戳来标识。行健是数据行在表中的唯一标识，并作为检索记录的主键。行健可以是任意字符串（最长64KB），并按照字典序进行存储。
访问表中行的三种方式：(1)通过单个行健访问（2）给定行健的范围访问（3）全表扫描
列的定义：<列族>:<限定符>，Hbase在磁盘上按照列族存储数据
元素由行健、列（<列族>:<限定符>）和时间戳唯一确定，元素中的数据以字节码的形式存储，没有类型之分。
2）物理模型
Hbase是按照列存储的稀疏行/列矩阵，物理模型实际上就是把概念模型中的一个行进行分割，并按照列族进行存储，表中的空值不被存储
3）Region服务器
Hbase在行的方向上将表分成了多个Region，每个Region包含了一定范围内（根据行健进行划分）的数据。每个表最初只有一个Region，随着表中记录数的不断增加超过某个阈值时形成新的Region。
Region是Hbase中分布式存储和负载均衡的最小单位，即一个表的所有Region会分布在不同的Region服务器上，但一个Region内的数据只会存储在一个服务器上。
物理上所有数据都存储在HDFS上，并由Region服务器提供数据服务，通常一台计算机只运行一个Region服务器程序（HRegionServer），每个HRegionServer管理多个Region实例（HRegion），其中HLog是用来做灾难备份的，使用的是预写式日志。
每个Region服务器只维护一个HLog，所有来自不同表的Region日志是混合在一起的，这样做的目的是不断追加单个文件，可以减少磁盘寻址次数，提高对表的写性能。但不易恢复。
每个Region有一个或多个Store组成，每个Store保存一个列族的所有数据。每个Store又是由一个memStore和零个或多个StoreFile组成，StoreFile则是以HFile的格式存储在HDFS上的。
当客户端进行更新操作时，先连接有关的HRegionServer，然后向Region提交变更。提交的数据互首先写入WAL和MemStore中，当MemStore中数据累积到某个阈值时，HRegionServer就会启动一个单独的线程将MemStore中的内容刷新到磁盘，形成一个StoreFile.
当StoreFile文件的数量增长到一定阈值后，就会将多个StoreFile合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出Hbase只有增加数据，所有的更新和删除操作都是在后续的合并中进行的。StoreFile在合并过程中会逐步形成更大的StoreFile，当单个StoreFile大小超过一定阈值后，会把当前的Region分割成两个Region，并由HMaster分配到相应的Region服务器上，实现负载均衡。
4）主服务器
HMaster将Region分配给Region服务器，协调Region服务器的负载并维护集群的状态。HMaster不会对外提供数据服务，而是由Region服务器负责所有Region的读写请求和操作。如果HRegionServer发生故障终止，Hmaster会通过ZooKeeper感知到并处理相应的Log文件，然后将失效的Region进行重新分配。此外，HMaster还负责管理表的schema和对元数据的操作。
因HMaster值维护表和Region的元数据而不参与数据的输入输出，HMaster失效仅会导致所有的元数据无法被修改，但表的数据读写还是可以正常进行的。
5）元数据表
用户表的Region元数据存储在.META.表中，随着Region增加，.META.表中数据也会增加，并分裂成多个Region。
为了定位.META.表中各个Region的位置，把.META.表中所有Region的元数据保存在-ROOT-表中，最后有ZooKeeper记录-ROOT-表的位置信息
客户端访问用户数据前先访问ZooKeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据的存放位置
-ROOT-表永远不会被分割，它只有一个Region。.META.表的Region全部保存在内存中