HBase是一个高性能、面向列、可伸缩的开源分布式NoSQL数据库，是Google Bigtable的开源实现。
HBase的思想和应用和传统的RDBMS，NoSQL等有比较大的区别，这篇文章从HBase的架构和关键的Rowkey设计入手，快速学习相关应用。
一、 HBase设计特性
HBase概述
HBase是一个构建在HDFS上的分布式列存储系统，将数据按照表、行和列进行存储，与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。
HBase与HDFS区别
HDFS是Hadoop Distribute File System 的简称，也就是Hadoop的一个分布式文件系统。
实际应用中，Spark以及 Hadoop 的 MapReduce，可以理解为一种计算框架。
而 HDFS 可以认为是为计算框架服务的存储层。HBase 是一种列式的分布式数据库，类似于 Hive，HBase 底层依赖 HDFS 来作为其物理存储。
二、 HBase数据模型
HBase是基于Google BigTable模型开发的，典型的key/value系统。
Hbase逻辑视图
- RowKey：是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要。
- Column Family：列族，拥有一个名称(string)，包含一个或者多个相关列
- Column：属于某一个columnfamily，familyName:columnName，每条记录可动态添加
- Value：Byte array
Hbase支持的操作
所有操作均是基于rowkey的；
支持CRUD（ Create、 Read、 Update和Delete）和Scan；
-
单行操作 Put Get Scan
-
多行操作 Scan MultiPut
没有内置join操作，可使用MapReduce解决。
三、 HBase物理结构
Region虽然是分布式存储的最小单元，但并不是存储的最小单元。Region由一个或者多个Store组成，每个store保存一个columns family，每个Strore又由一个memStore和0至多个StoreFile组成，StoreFile包含HFile；memStore存储在内存中，StoreFile存储在HDFS上。
Region的存储策略
- Table中所有行都按照row key的字典序排列；
- Table在行的方向上分割为多个Region；
- Region按大小分割的，每个表开始只有一个region，随着数据增多，region不断增大，当增大到一个阀值的时候，region就会等分会两个新的region，之后会有越来越多的region；
- Region是Hbase中分布式存储和负载均衡的最小单元，不同Region分布到不同RegionServer上。
HFile的结构
HFile是HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile。
除了HFile，HBase还有HLog File。
HLog File是HBase中WAL（Write Ahead Log） 的存储格式，物理上是Hadoop的Sequence File。
四、 HBase设计与架构
整体架构
HBase采用Master/Slave架构搭建集群，整体架构包括HMaster节点、HRegionServer节点、ZooKeeper集群，底层的数据存储于HDFS中，涉及到HDFS的NameNode、DataNode等。
HMaster解析
HMaster是HBase主/从集群架构中的中央节点，通常一个HBase集群存在多个HMaster节点,其中一个为Active Master，其余为Backup Master。HMaster管理HRegionServer，实现其负载均衡，负责管理和分配HRegion，比如在HRegion split时分配新的HRegion。
- 发现失效的Region server并重新分配其上的region
- 实现DDL操作（Data Definition Language，namespace和table的增删改，column familiy的增删改等）
- 管理namespace和table的元数据（实际存储在HDFS上）
- 处理schema更新请求
HRegionServer解析
HRegionServer存放和管理本地HRegion，读写HDFS，管理Table中的数据。 Client直接通过HRegionServer读写数据（从HMaster中获取元数据，找到RowKey所在的HRegion/HRegionServer后）。
- 维护master分配给他的region，处理对这些region的io请求
- 负责切分正在运行过程中变的过大的region
ZooKeeper集群
ZooKeeper是协调系统，用于存放整个HBase集群的元数据以及集群的状态信息。 实现HMaster主从节点的failover。
HBase Client通过RPC方式和HMaster、HRegionServer通信，一个HRegionServer可以存放1000个HRegion。 底层Table数据存储于HDFS中，而HRegion所处理的数据尽量和数据所在的DataNode在一起，实现数据的本地化，在HRegion移动(如因Split)时，需要等下一次Compact才能继续回到本地化。
五、 HBase最佳实践
HBase适合的场景
- 大数据量存储，大数据量高并发操作
- 读写访问均是非常简单的操作
Rowkey如何设计
（1）针对查询优化
除了全表扫描以外，HBase的查询实现只支持两种方式：
- get：指定rowkey获取唯一一条记录
- scan：按指定的条件获得一批记录，通过rowKey的range匹配一个范围，然后通过多种filter在范围内筛选
如果我们想提升查询效率，必须在rowKey的设计上下功夫。
HBase的rowKey是基于字典排序的，具体来说是基于key的ASCII码来排序，一般的rowkey是通过业务上的多个因素相互组合，一步步确定查找范围。
比如时间肯定是我们应该加到rowKey里的一个查询因子，一个开始时间跟一个截止时间就形成了一个时间段范围，就能固定一个结果集范围。
（2）合适的长度
rowkey是一个二进制码流，可以是任意字符串，最大长度64kb，实际应用中一般为10-100bytes，以byte[]形式保存，一般设计成定长。
- 数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比如100个字节，在上亿级别的海量数据下，会造成存储空间的浪费
- MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率
- 目前操作系统是都是64位系统，内存8字节对齐，可以控制在16个字节或者32字节等
（3）更好的散列设计
如果rowkey按照时间戳的方式递增，不要将时间放在二进制码的前面，建议将rowkey的高位作为散列字段，由程序随机生成，低位放时间字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。如果没有散列字段，字段前缀部分直接是时间信息，大量数据数据都会集中在一个RegionServer上，造成热点问题，降低查询效率。
Region分区优化
（1）避免热点Region
HBase中的行是按照rowkey的字典顺序排序的，这种设计将相关的行以及会被一起读取的行存取在临近位置，便于scan。
HBase中，表会被划分为n个Region，托管在RegionServer中，StartKey与EndKey表示这个Region维护的rowKey范围。
默认的策略是当一个Region过大时，进行一次分裂(region-split)操作，后续的rowkey会被分配到新的Region。
明显这种策略很容易出现热点Region，大量访问会使热点region所在的单个机器响应缓慢，引起性能下降甚至region不可用，
同时会影响同一个RegionServer上的其他region，由于主机无法服务其他region的请求。
在设计Region时应该设计良好的数据访问模式以使集群被充分，均衡的利用。
（2）预分区设计
解决热点Region问题的一个策略就是通过对rowkey进行Hash进行预分区。
这里又设计到rowkey的设计问题，设计rowkey时尽量把前缀部分打散，可以使用随机数等， 只要region所管理的start-end keys范围比较随机，那么就可以解决写热点问题。
更进一步，可以预估系统的容量，规划可能的Region数量，通过一个路由算法进行负载均衡。
本文转自邴越博客园博客，原文链接：http://www.cnblogs.com/binyue/p/6675391.html，如需转载请自行联系原作者
