HBase应用快速学习

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数量，通过一个路由算法进行负载均衡。