Hbase复习

Hbase复习

Hbase是构建在HDFS之上、分布式的、面向列的开源数据库，google bigtable的开源实现，主要用于存储海量的数据。

hbase vs 关系型数据库

1、hbase支持大数据，一个表数十亿行，上百万列

2、面向列：列拿出来存储在一块连续的空间，适合做分析，传统关系数据库面向行，一行存储在一块连续的空间，查找一个字段，读一整行，IO效率不高

3、适合稀疏数据，对于null的列，不占用空间，表可以设计的非常稀疏

4、数据单一，hbase都是string，可以做压缩

5、列可以根据需要动态增加，同一张表中不同的行有截然不同的列

6、hbase只有普通的增删改查等操作，没有表之间的关系查询

7、不支持跨行、跨表的事务

关系型数据库集群做不大，曲线式增加，有瓶颈，限制于事务

Web端口

hmaster的web接口参数：hbase.master.info.port 默认16010

http：//hbase_master_server:16010

RegionServer的web接口参数：hbase.regionserver.info.port 默认值是16030

http：//hbase_region_server:16030

Hbase’集群组成

HDFS集群（底层存储）

Hbase集群（Hmaster、 RegionServer)

Zookeeper集群（管理协调者）

Regions
数据切分：先横向拆分（行）、再纵向拆分（列族）

Region：由一个或者多个store组成，每个store保存一个列族，每个store又由一个memstore缓冲区和storeFile组成，storeFile以HFile格式保存在HDFS，删除操作不是删除文件，而是追加log，查找是查最版本的状态

当MemStore满了以后会Flush成一个StoreFile，file文件数量增长的一定法制，会触发compact合并操作，即将多个StoreFiles合并成一个，合并过程会对cell进行版本合并和数据删除

hbase只增加数据，更新和删除操作都是在compact过程进行

Hmaster：负责Region管理分配、DDL（删表等操作），HMaster失效会导致所有元数据无法被修改，表的读写可以正常进行

Region Server：数据读写，Split，Region迁移

架构
Master/Slave架构

hbase、传统数据库、es都是先写到日志文件，再写到内存，就认为写入成功，保证宕机数据不丢失，之后有flush机制刷到磁盘

客户端Client

和zookeeper通信，找到数据入口地址
使用hbase RPC机制与HMaster和HRegionserver通信
与HMaster通信进行管理类操作
与HRegionserver通信进行读写类操作

META信息存在zookeeper，客户端访问会缓存这些位置信息，只是缓存当前rowkey对应HRegion的位置，，随着时间推移，客户端缓存信息越来越多，以至于不需要查找meta table信息，除非HRegion宕机或Region split

Zookeeper在Hbae中作用：

保证集群中只有一个Master

存储Region的寻址入口

监控RegionServer上线和下线信息

存储hbase schema和table元数据

rowkey设计原则

1、长度原则

一般为10-100bytes，原因：

hbase将部分数据加载到内存当中，如果rowkey过长，内存的有效利用率就会下降

目前操作系统都是64位系统，内存8字节对齐，控制在16字节，8字节的整数倍利用了操作系统的最佳特性

2、散列原则

rowkey的高位字节采用散列字段处理，由程序随即生成。低位放时间字段，这样将提高数据均衡分布，各个regionServer负载均衡的几率

如果不进行散列处理，首字段直接使用时间信息，所有该时段的数据都将集中到一个regionServer当中，这样当检索数据时，负载会集中到个别regionServer上，造成热点问题，会降低查询效率。

3、唯一原则

必须在设计上保证其唯一性，rowkey是按照字典顺序排序存储的，因此，设计rowkey的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。但是这里的量不能太大，如果太大需要拆分到多个节点上去。

rowkey设计方法

1、加盐

在rowkey的前面分配随机数，当给rowkey随机前缀后，它就能分布到不同的region中

2、预分区

所谓预分区，就是预先创建hbase表分区。这需要我们明确rowkey的取值范围和构成逻辑。

不预分区会出现两个问题：

第一点，就是我们所说的热点问题，数据会继续往一个region中写，出现写热点问题；

第二点，则是拆分合并风暴，当用户的region大小以恒定的速度增长，region的拆分会在同一时间发生，因为同时需要压缩region中的存储文件，这个过程会重写拆分后的region，这将会引起磁盘I/O上升 。

对于拆分合并风暴，通常我们需要关闭hbase的自动管理拆分。然后手动调用hbase的split（拆分）和major_compact（压缩），对其进行时间控制，来分散I/O负载。

3、哈希

加盐和预分区rowkey设计方法中，并没有完整运用到rowkey设计的散列原则。只运用加盐和预分区rowkey设计方法，数据会无序随机分布在hbase集群当中，这并没有让我们利用到hbase根据字典顺序排序的这一特点。

我们可以把一些希望放在一起的rowkey部分作为参数，传入哈希函数当中，将得到的哈希值模以500，余数添加到rowkey首部中，再结合预分区设计方法，就能将数据均匀分布到regionServer当中。

同时，我们还能将相同rowkey的数据收集到一台节点上，在避免热点问题的情况下，充分利用hbase字典排序的优点。

4、反转

对于以手机号码这样比较固定开头的rowkey（例如开头177,159,138），但是它的后几位都是随机的，没有规律的。我们可以将手机号反转之后作为rowkey，这样就避免了热点问题。

这就是rowkey设计的另一种方法反转，通过反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。