Hbase逻辑结构
Hbase是建立在hdfs分布式存储系统之上(但是在hive下层)的一个列存储非关系型数据库,本质上,它是将数据按一定逻辑存储在hdfs上,而hive既可以调用hbase来操作数据(速度比直接hive+hdfs慢4倍左右),也可以直接接入hdfs来操作数据。具体的整个分布式数据库结构关系如下:
Hbase的逻辑存储结构如下所示:
首先解释一下上面的表中的若干概念:
l Row:hbase中的一行就对应的关系型数据库中的行。
l RowKey:行键,相当于关系型数据表中的主键,可以由多个值组合而成。
l Data:一个row key对应的数据块,由若干个列族构成。
l Columns family:列族。每个列族由一个key: {columns}构成,这个键值对中的值由若干个列构成。
l Column:列。对应关系型数据表中的每个列,这边的列结构是key: value,其中key就是列名,value就是该行数据在该列的值。
如果把上述的hbase结构转换为普通的关系型数据库结构,则如下:
Rowkey | Info | Roles | |||
| Height | State | Asf | Hadoop | Hive |
Cutting | 9ft | CA | Director | Founder | Null |
Tlipcon | 5ft7 | CA | committer | Null | Contributor |
它可以看做是info表和roles表以rowkey做连接得到的冗余表,可以看出在hbase表中,不存储某行数据null值的列。(其中的Hadoop按时间戳做的,用途不明)个人理解hbase的逻辑存储为将原关系型数据库的若干个相关表(即主键相同)按主键进行聚合,原来的列被聚合成一个(列族 -> 列)的二级结构,并且只有二级,不像mongodb那样有任意级。
Hbase的特点:
(1) 表的规模可以非常庞大。由于我们可以将关系型数据库中多个表按照同一个rowkey整合到同一个hbase表中,而不再需要表与表关联,比如一个用户相关的表,如果在关系型数据库里,可能会涉及用户画像表和用户行为表,而在hbase中,可以直接将用户画像数据和用户行为数据分别放置在hbase表的两个列族里。
(2) 无模式:每一行有一个主键和若干个列族(列族数量和key要相同),列族里面可以有任意数量的列(不同行的列可以不同)
(3) 数据类型单一:在hbase中存储的不管是key还是value还是什么值,都统一是字符串。
(4) 面向列:按照列(族)来存储数据(下面的物理存储过程可以看出来),并且通过列族来进行独立检索。
(5) 数据稀疏存储:上面提到过,hbase不存储某行数据null值的列,因此它存储空间利用率较高(类比图的矩阵存储和二元组存储)。
Hbase的物理存储
Hbase先会将行按照rowkey进行字典排序;然后按行将数据表划分成若干个region,每个region存储在一个store server上,一个表一开始会只有一个region(里面有一行数据),随着插入行增加,region也会增加(当超过一个region的阈值则加一个region)。如下图所示:
而每个region又被按照列族进行划分(称之为store),每个store里放置一个memstore(就是列族的key)和若干storefile(即每个列),确切的说这个存的是这个region包含的行这一列的数据,也就是所谓的按列存储,而列的每行被称之为Hfile。Memset是存储在storeserver的内存中的,而那些storefile则是存在外存中。如下图所示:
具体解释一下storefile和hfile:比如有K个行被划分在同一个region里,然后得到的该region某列的storefile就是一个K*1的列,对应K行数据,而这个列中每一行就是一个hfile。
上图描述了整个hbase的存储机制。另外还有hbase系统中一些组件的介绍,见参考的博客。
Hbase适用的场景:
(1) 数据量非常大(此时用关系型数据库如果要进行表间关联就处理困难了)
(2) 需要随机读写数据(面向列存储良好支持了这个特性)
(3) 对数据的读写访问操作比较简单(最好不要与其他表发生关系)
Hbase和直接使用hdfs的优劣:
两者都具有良好的容错性和扩展性,都可以扩展到成百上千个节点。
参考:
http://blog.csdn.net/woshiwanxin102213/article/details/17584043