Hbase非关系型数据库简介

Hbase

HBase-Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式数据库。

Hadoop生态圈中，它是其中一部分且利用Hadoop HDFS作为其文件存储系统,利用Hadoop MapReduce来处理HBase中的海量数据,利用Zookeeper作为其分布式协同服务,主要用来存储非结构化和半结构化的松散数据（NoSQL非关系型数据库有redis、MongoDB等）。

关系型数据库和非关系型数据库

关系型数据库的3大优点：

容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解

使用方便：通用的SQL语言使得操作关系型数据库非常方便

易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率

关系型数据库的3大瓶颈：

高并发读写需求：网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈，并且很难能做到数据的强一致性。

海量数据的读写性能低：网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的。

扩展性和可用性差：在基于web的结构当中，数据库是最难（但是可以）进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。

非关系型数据库特点：

• 一般不支持ACID特性，无需经过SQL解析，读写性能高
• 存储格式：key value，文档，图片等等
• 数据没有耦合性，容易扩展

Hbase数据模型

• ROWKEY：决定一行数据，按字典顺序排序
• ColumnFamily列族：作为表结构的一部分，必须在建表时给出，一个列族可以包含多个列，不同列族在存储时占用不同的store。
• Qulifier列：为列族的子单元，由实际的业务场景需要决定
• Cell单元格：为行与列的交叉所决定，内容为具体的数据，以字节数组的形式存放，单元格是有版本的
• Timestamp时间戳：根据时间戳区分单元格每个版本的差异，类型为64位整型
• HLog：HLog SequeceFile的Value是HBase的KeyValue对象，即对应HFile中的KeyValue。存储hbase表的操作记录，KV数据信息

Hbase体系架构

Client：包含访问HBase的接口并维护cache来加快对HBase的访问。

HMaster：与RegionServer为一主多从架构，存在单点故障问题，一般设置多个HMaster，由Zookeeper提供协同服务。HMaster负责为RegionServer的负载均衡，管理用户对表的增删改操作，发现失效的RegionServer并重新分配其上的region。

Zookeeper：存储Hbase数据库中表的元数据信息metadata，为HMaster提供协同服务，存储所有region的寻址入口信息，Hbase高度依赖ZK。

RegionServer：负责维护region，处理对region的I/O请求。负责对过大region的切分。

HLog：在RegionServer中，存储表的元数据metadata与实际数据data，数据先存储在HLog后存储进region。

Region：存储在RegionServer中，表被划分为多个区域，存储在不同的region中，region超过一定大小就会裂变。

Store：一个region由多个store组成，一个store对应一个列族，包括MemStore和StoreFile。MemStore在内存中，StoreFile在磁盘中。数据先写入MemStore，达到某个阈值后落地到StoreFile。

Region裂变机制

当Region中所有的storefile大小之和过大，超过一定的阈值，就会发生裂变。

一张表可能很大，在表增大的过程中，存储表的Region会裂变成2个，当table中的行不断增多，就会有越来越多的region，一个RegionServer有过多的Region后，下一次裂变时Master会将分裂后的Region放到不同的RegionServer上存储，实现负载均衡。

Hbase强依赖于Zookeeper

Hbase表的元数据metadata存储在zookeeper中，而zookeeper还负责master的协同服务以及region入口地址的存储，如果zookeeper出现问题，hbase将无法正常工作。

Hbase的优化

• 采用预分区的方式，解决热点问题，预先定义几个分区region，用startkey和endkey区间界定，存储数据时不同的rowkey直接进入所属的分区。
• rowkey的设计符合规则：定长、唯一、符合业务逻辑、具有散列性
• 尽量不要设计超过3个列族（最好1个）
• 创建表的时候将inmemory设置为true，保证查询时能被cache命中
• 控制版本数量，如没有特殊需求maxVersions设置为1
• 设置TimeToLive生命周期，没有需求尽量设短
• 控制合并和裂变的过程，使其少占资源
• 写表操作可以通过设置多个Table并发写，多个线程并发写，最有效的办法是使用MapReduce任务确保任务并行。
• 同样读表操作也可以通过设置多个Table，多线程并发读，同样利用MapReduce保证并行。
• 利用BlockCache，设置更大的BlockCache占用内存比率可以增加读取时缓存的命中率