Hbase基础概念-自我梳理

最近在了解Hbase，写点学习笔记方便自己梳理知识逻辑，也同大家有些交流，希望也能帮到同样刚入门学习的新手，快速地了解其知识背景。因为很多专业词汇我不知其中文对应，所以就不翻译了，其实我认为有些词汇从中文看反而难以理解，英文更能让你快速get到其concept真正的意思。

1.Hbase特点

首先要从什么是Hbase，为什么要HBase？

一句话的话：非关系型数据库。

但为什么需要他，因为它

A.支持linear and modular scaling.

B. 自动Sharding： 就是说随着你的数据增长，tables不断变大，Hbase会自动把tables split到不同的regions，然后把regions分布到集群多台服务器中。

C... 后面不重要（又不是学文科，背课文）

相比较传统的RDBMS，HBase缺少了typed columns, secondaryindexes, triggers, 和高级query语言。

什么时候用Hbase：

A. big data. 要足够大，有数以千万以亿计rows。

B. 确定在你的处理数据中，那些相比较RDBMS确实的功能特点不重要。

C. 足够多的hardware. HBase用HDFS作为persistence store. HDFS本身也又有3备份的特性，所以要有足够的datanodes。当然我们在个人学习中是可以用单机模拟分布式集群的。

题外：HBase 和HDFS的区别

HDFS就是分布式文件系统，其目的是为了在集群中存储大文件，并不支持快速地查找。HBase因为通过把record按照key-value的形式来存放，所以支持快速查找，但它数据本身的存储仍然要依靠HDFS。后面的内容会说明HBase是怎么做到快速lookup，通过这个过程也就了解了整个HBase的设计理念。

 

2. Data Model

Hbase的目的是为了保存大tables同时能够在tables中快速索引。既然数据都是按照tables保存的，也就自然有行有列。

先用一句话明确中心：整个table可以看成多维map，通过row key，columnkey 和timestamp，map到一个value，在这里也就是an interpredted arrayof bytes.

 

Row:

一个行由一个rowkey和很多个column组成。整个table很多个rows，这些row按照rowkey的“字母“顺序排序。（这里就可以看出，Hbase的rowkey设计是很重要的，你可以根据自身需要，把类似rows通过rowkey的设计使它们聚集在一起，这样你在range query时很容易快速读取。举个例子，比如你有个城市出租车的数据集，假设你的应用要求是快速query一个区域内一段时间的出租车订单记录。比如我想知道2018.01.10 12AM-12.30AM，以上海博物馆为出发地的订单, 假设上海博物馆的地理坐标为121.482,  31.233 那么你的rowkey就可以设计为12148231233201801101200，12148231233201801101201...。这样rangequery时只需要很少的IO，可能只需要访问几个Blocks就可以读出所有符合条件的rows)。

Columns： 

Hbase中的column就由columnfamily和column qualifier组成，即column= columnfamily ： column qualifier。

Columnfamily:

用来协同一些columns和他们的对应value，为了更好的performance。因为每个column family可以规定自己的存储特性，比如对应的value是不是应该存在内存，是不是要压缩等等。有了column family，我们可以很方便地根据自身需要设计管理几行columns。注意，每个table的column families都是固定的，也就是新建这个表时，就已经规定好，并且每行的column family都一样，当然一些rows可能的一些column families可以是空的。从存储的角度上看，所有的columnfamily member都是存储在一起的，也就是“列存储”。

Column qualifier

在column family中，用来对一些数据提供index。有了column family，再用Column qualifier进行细分。不同于整个table，每个row的column family都是固定的，一样的，qualifier可以每个row根据需要而不同。也就是说每个row对应的column个数是不定的，但这些columns组成的 column families是固定的。

Cell：

由rowkey+column family+Column qualifier+timestamp组成的是cell，注意，不能简单把cell理解为row，因为每个cell中的一个value可能对应着多个版本。回到上面出租车的例子，一条行车记录中有一个column叫做track,用来记录出租车的形式路线，假如说1分钟获取一次位置，那么就会产生很多value，叫做cell.value, 每个value对应着以1分钟为增幅的timestamp，。 但是整条行车记录是一个cell。

TimeStamp

每个value对应着一个timestamp，系统默认的是数据写入时，Regionserver的时间作为timestamp，当然也可以根据自身需要而修改。

从这两图中加深理解。通过Rowkey+column failmies + quailifiers+timestamp map到一个value。也就是key-value的意思，这里key可以如下图不同组合，这样返回的value也就不同。

到此，我们就清楚了Hbase要处理和存储的big tables是什么样子的。下面接着看，Hbase是如何做到去存储和处理这些big tables的。

 

3.Hbase架构

上图就是Hbase的整体组成。

HRegion： 我们的集群里会有很多tables，每个tables被分成多个HRegion，每个HRegion就对应着我们前面提到的一段范围内的column family所对应的数据。初始状态下，每个table只有一个HRegion。随着数据的增长，HRegion会split成更多的子HRegion，缺省的情况下，每个HRegion大概100~200MB。

HRegionServer：每个table被分成了很多个HRegion，而这些HRegion存在哪里呢，就是HRegionServer，也就是我们集群中的每个节点机器。当然每个HRegionServer可以管理多个HRegion，这些HRegion可以来自多个不同的table。其实HRegionServer担任着整个系统“执行者”的角色，是真正干活。HRegionServer负责处理对它所管理的所有HRegion的读写请求。负责Region变大后的spilt，负责Storefile的合并工作，已经存储数据到HDFS。

HMaster：现在我们知道了table被分成HRegions，然后HRegions被分到HRegionServers上管理。HMaster就担任着分配HRegions到HRegionServers的角色。 这就意味着它需要时刻注视着整个集群的情况，比如HRegionServers的新添加或失效（也就是添加一个节点机器或者其失效），确保HRegionServers的均衡负载等等。当然我们需要用HMaster对table做些基本的修改操作，比如建立表和column family。

Client：Hbase Client顾名思义，可以理解为我们用户的角色了。Client可以直接query Catalog Tables 去获得我们想读的那段regions所在的位置，也就是所在的HRegionServer, 所以这个过程是不用通过HMaster的。

Catalog Tables(.MATA):

这张表就是列出了system中所有的regions，我们可以通过它了解我们的table都被分了那些regions，而这些regions又实际存在那些region servers中。Catalog Tables也叫做 .META。Catalog Tables本身就如同其它Hbase的table一样，它也是个table，通过HBase shell命令中list获得，保存路径在Zookeeper中。

Catalog Tables也是table，只不过存的是HRegion的信息，所以每row的key就是由table，region start key，region id组成，对应的value就是HRegion的具体信息，如图第二个info：server就是HRegion所在的HRegionServer。

 

http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf