HBase数据模型
HBase的数据通过行键，列族，列限定符，时间戳这四维来定位，一个行可以有一个行键和任意多个列，单元格是具体存储数据的地方
HBase概念视图
HBase物理视图： 按照列族为单位进行存储
HBase的实现原理
一个Hbase表被划分成多个Region，数据在Hbase运作过程中会不断增加，这时，当一个Region增大到一定程度会分裂成多个新的Region。不同的Region会被分配到不同的Region服务器上，但是对于同一个Region绝对不会拆分到不同的Region服务器上去。
Region的定位问题：
HBase设计了三层结构实现Region的寻址和定位
region的寻址过程： 首先访问ZooKeeper服务器取出ROOT表的地址 ，然后根据ROOT表找到.META表的地址，最后根据.META表找到用户数据表地址，取出用户数据
HBase的三层结构中各层次的名称和作用
层次 | 名称 | 作用 |
第一层 | Zookeeper文件 | 记录了-ROOT-表的位置信息 |
第二层 | -ROOT-表 | 记录了.META.表的Region位置信息；-ROOT-表只能有一个Region，绝对不会再进行分裂。通过-ROOT-表，就可以访问.META.表中的数据 |
第三层 | .META.表 | 记录了用户数据表的Region位置信息，.META.表可以有多个Region，保存HBase中所有用户数据表的Region位置信息 |
为了加快访问速度，.META.表全部Region都会被保存在内存中
HBase的三层结构能否满足企业实际的存储需求？
假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为128MB，那么，上面的三层结构可以保存的用户数据表的Region数目的计算方法是：
（-ROOT-表能够寻址的.META.表的Region个数）×（每个.META.表的Region可以寻址的用户数据表的Region个数）那么三层结构可以保存的Region数目是（128MB/1KB）×（128MB/1KB）=
总容量=
所以能够满足企业的使用需求
HBase运行机制
HBase的系统架构
客户端： 访问HBase的接口
Zookeeper服务器： 实现协同管理服务，维护和管理整个HBase集群，包括检测Region服务器故障
Master： 对表增删改查，负责不同Region服务器的负载均衡，负责调整分裂、合并后Region的分布，负责重新分配故障、失效的Region服务器
Region服务器： 负责用户数据的存储和管理，Region服务器向HDFS文件系统中读写数据
一个Region服务包括多个Region，这些Region共用一个公共的HLog；每个Region按照列簇进行存储，单独构成一个Store，一个Store就是代表一个列簇；一个Store中的数据不是直接写到底层中去，而是先写到MemStore（缓存）中，缓存满了后再flush到StoreFile磁盘文件中；StoreFile是HBase中的表示形式，底层是借助于HDFS中称为HFile的文件存储。
为什么每个Region服务的Region共用一个HLog？ 主要为了提高对表的写操作性能。比如有1000个Region，那么分配1000个HLog时，打开1000个文件，每次针对不同的Region写入不同的HLog，效率低下。
用户读写数据过程
写入数据时，为了保证数据的安全和可恢复性，先写入HLog日志文件中，再写入MemStore缓存中，只有保证MemStore对应的HLog中的数据被完整写到磁盘中，MemStore中的数据才能被刷写到磁盘
读取数据时， 先访问MemStore缓存，缓存中没找到才去磁盘中的StoreFile寻找
缓存刷新
①系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记；
②每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件；
③每个Region服务器都有一个自己的HLog文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务
StoreFile的合并和分裂的过程
只有当磁盘中刷写生成的StoreFile文件数量达到一定的阈值后，才进行StoreFile的合并；但是，当合并生成的StoreFile越来越大时，又会引发分裂操作。
