HBase简述

简介

HBase（Hadoop Database）是一个多版本，高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。
HBase利用Hadoop HDFS作为其文件存储系统。提供高可靠，高性能，列存储，可伸缩 ，实时读写，适用于非结构化数据存储的数据库系统。
HBase利用Hadoop MapReduce来处理HBase中的海量数据。
HBase利用Zookeeper作为分布式协调服务。

特点

数据量大：一个表可以有上亿行，上百亿列（列多时，插入变慢）

面向列：面向列（族）的存储和权限控制，列（族）独立检索。

稀疏：对于未空（null）的列，并不占用存储空间，因此，表可以设计的非常稀疏。

多版本：每个call中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳。

无类型：HBase中的数据都是字符串，没有类型。

强一致性：同一行数据的读写只在同一台Region Server上进行。

有限查询方式：仅支持三种查询方式（单个rowkey查询，通过rowkey的range查询，全表扫描）

高性能随机读写

数据模型

行键(row key)，类似于MySQL中的主键。 行键是HBase表天然自带的。

列族(column family)，列的集合。
HBase中列族是需要在定义表时指定的，列是在插入记录时动态增加的。
HBase表中的数据，每个列族单独一个文件。
一个Column Family中可以有任意多个Column组成，即Column Family支持动态扩展，无需预先定义Column的数量以及类型，所有Column均以二进制格式存储，用户需要自行进行类型转换。

时间戳(timestamp)，列(也称作标签、修饰符)的一个属性。
行键和列确定的单元格，可以存储多个数据，每个数据含有时间戳属性，数据具有版本特性。
如果不指定时间戳或者版本，默认取最新的数据。

物理存储

1、面向列的存储
2、一张表可以被分成若干个region 。
3、行按照rowkey进行字典序排序 。
4、支持随机读写 。
5、region是负载均衡调度的最小单位 。
6、region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。

6、HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。
事实上，HRegion由一个或者多个Store组成，每个store保存一个columns family。每个Strore又由一个memStore和0至多个StoreFile组成。如图：

StoreFile以HFile格式保存在HDFS上。

体系结构

读写过程
Hbase使用MemStore和StoreFile存储对表的更新。
数据在更新时，首先写入Log(WAL log)和内存(MemStore)中，
MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。
于此同时，系统会在zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了。(minor compact)
当系统出现意外时，可能导致内存(MemStore)中的数据丢失，此时使用Log(WAL log)来恢复checkpoint之后的数据。

StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的 StoreFile达到一定的阈值后，就会进行一次合并(major compact),将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行split，等分为两个StoreFile。
由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的StoreFile和MemStore，将他们按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，合并的过程还是比较快。

1、Client

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

2、Zookeeper

保证任何时候，集群中只有一个Master；
存贮所有Region的寻址入口；
实时监控Region server的上线和下线信息，并实时通知给Master;
存储HBase的schema和table元数据；

3、Master

为Region server分配region；
负责Region server的负载均衡；
发现失效的Region server，并重新分配其上的region；
管理用户对table的增删改查操作。

4、Region Server

负责维护region，处理对这些region的IO请求；
负责切分在运行过程中变得过大的region。

Region定位流程图

5、ROOT表

-ROOT-：记录了.META.表中每个Region信息，-ROOT-表最多只有一个region。
Zookeeper中记录了-ROOT-表的location。

6、META表

.META.：记录了各个用户表的每个Region信息，.META.可以有多个regoin。

HBase部署架构

HBase操作

1、flush
内存容量有限，需要定期将内存中的数据flush到磁盘，每次flush，每个region的每个column family都会产生一个HFile读取操作，region serve会把多个HFile数据归并到一起。

2、compaction
flush操作产生的HFile会越来越多，需要归并来减少HFile的数量，旧数据会被清理。

3、split
HFile大小增长到某个阂值就会Split，同时把Region Split成两个region ，这两个region被分发到其他不同的region server上。

4、scan
hbese原生提供的方法，顺序扫库；当然可以使用mapreduce并发扫库的方法。

5)Bulk Load
快速导入大批量数据的方法。

存储模型

1.一个table中的region会被随机分配给一个region server。
2.region是分布式存储和负载均衡的最小单元。

Region定位

系统如何找到某个row key (或者某个 row key range)所在的region？
bigtable 使用三层类似B+树的结构来保存region位置。

第一层是保存zookeeper里面的文件，它持有root region的位置。
第二层root region是.META.表的第一个region其中保存了.META.表其它region的位置。通过root region，我们就可以访问.META.表的数据。
.META.是第三层，它是一个特殊的表，保存了Hbase中所有数据表的region 位置信息。

说明：
1、root region永远不会被split，保证了最需要三次跳转，就能定位到任意region 。
2、.META.表每行保存一个region的位置信息，row key 采用表名+表的最后一行编码而成。
3、为了加快访问，.META.表的全部region都保存在内存中。
假设，.META.表的一行在内存中大约占用1KB。并且每个region限制为128MB。
那么上面的三层结构可以保存的region数目为：
(128MB/1KB) * (128MB/1KB) = = 2(34)个region
4、client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的region**(其中三次用来发现缓存失效，另外三次用来获取位置信息)**。

HFile结构

1、基于block的存储结构
2、block的索引驻留内存

HFile分为六个部分：
Data Block 段—–保存表中的数据，这部分可以被压缩。
Meta Block 段 (可选的)–—保存用户自定义的key-value对，可以被压缩。
File Info 段–—-HFile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。
Data Block Index 段—-–Data Block的索引，每条索引的key是被索引的block的第一条记录的key。
Meta Block Index段 (可选的)–Meta Block的索引。
Trailer–—这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer**保存了每个段的起始位置**(段的Magic Number用来做安全check)，然后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个 block读取到内存中，再找到需要的key。DataBlock Index采用LRU机制淘汰。
HFile的Data Block，Meta Block通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。目标Hfile的压缩支持两种方式：Gzip，Lzo。