Hadoop之Hbase

Posted 2022-08-28 zxn0628

HBase

 

一、简介

      Hbase是一个高可用、高性能、面向列、可伸缩、实时读写的分布式数据库 。

是一种构建在HDFS之上的分布式、面向列的存储系统。在需要实时读写、随机访问超大规模数据集时，可以使用HBase。

HBase 是Google Bigtable 的开源实现，与Google Bigtable 利用GFS作为其文件存储系统类似， HBase 利用Hadoop HDFS 作为其文件存储系统；Google 运行MapReduce 来处理Bigtable中的海量数据， HBase 同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable 利用Chubby作为协同服务， HBase 利用Zookeeper作为对应。

二、特点

      大：一个表可以有上亿行，上百万列。

 

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

 

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

 

无模式：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。

 

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

 

三、基本概念

Zookeeper ：

保证任何时候，集群中只有一个HMaster； 

实时监控HRegion Server的上线和下线信息，并实时通知给HMaster； 

存储HBase的schema和table元数据； 

HMaster需要知道哪些HRegionServer是活的,可用的。及HRegionServer的位置信息，以便管理HRegionServer。这些信息都有Zookeeper提供！

HMaster ：

HMaster可以启动多个，但是Zookeeper有Master Election机制保证且允许总有且只有一个Master在运行，来负责Table和Region的管理工作。 

管理HRegionServer的负载均衡，调整Region分布； 

Region Split后，负责新Region的分布； 

在HRegionServer停机后，负责失效HRegionServer上Region迁移工作。

Region Server ：

监控维护Region，处理对这些Region的响应，请求；

负责切分在运行过程中变得过大的Region。

RowKey：用于唯一标识Hbase中的一条数据（记录），不可重复，按照字典顺序排序，只能存储64k的字节数据，因此一般要求设计RowKey要简短。

TimeStamp：HBase自动赋值时间戳(也可自己实现)，作为版本号，64位整型。Hbase每个cell存储单元（k:v）对同一份数据有多个版本，通过时间戳来区分版本之间的差异，按时间倒叙排序。

CF(ColumnFamily):列族，可包含多列。权限控制，存储以及调优都是在列族层面进行的。HBase把同一列族里面的数据存储在同一目录下，由几个文件保存（StoreFile）。

Column:列，对应key，一列可以在多个版本中维护不同数据。

Cell:是一个字节数组。由rowkey,column(=<family>+<qualifier>),version唯一确定的单元。由rowkey，列族，列，版本唯一确定一个单元。

 

四、物理存储模型

 

Table分割为多个HRegion，每个HRegion分散在不同的RegionServer中。

 

 

每个HRegion由多个Store构成，每个Store由一个MemStore和0或多个StoreFile组成，每个Store保存一个Columns Family。

 

StoreFile以HFile格式存储在HDFS中。

五、shell命令

1.显示 所有的namespace

 

2.显示namespace下所有的表

 

3.创建 namespace

 

4.删除namespace

 

5.创建表

 

 

创建预分区表

 

6.显示所有的表

 

7.描述表

 

8.删除表

 

9.插入数据

 

10.修改数据

与put一样，指定相同的rowkey就相当于修改

11.查看数据

 

 

 

 

 

12.在Hbase shell之外执行hbase命令

echo "list" | hbase shell -n

hbase shell fileName

六、写数据

1.Client先访问zookeeper，寻找meta表所在的regionserver的地址(meta表保存着所有的region的元数据)

2.通过namespace、tableName及rowkey查询meta表，获取数据所属的region的regionserver的位置

3.找到对应的regionserver，把数据分别写到HLog和MemStore上一份

4.MemStore达到一个阈值后则把数据刷成一个StoreFile文件。（若MemStore中的数据有丢失，则可以总从HLog上恢复）

5.当多个StoreFile文件达到一定的数量后，会触发Compact合并操作，合并为一个StoreFile，（这里同时进行版本的合并和数据删除。）

6.当Storefile大小超过一定阈值后，会把当前的Region分割为两个（Split），并由Hmaster分配到相应的HRegionServer，实现负载均衡

 

MemStore Flush

在下面列出的任何条件下触发MemStore刷新。最小flush单位是每个region，而不是单个MemStore级别。

(1)当MemStore达到指定的大小时hbase.hregion.memstore.flush.size(默认134217728)，属于其区域的所有MemStore都将刷新到磁盘，检查周期由hbase.server.thread.wakefrequency参数决定，默认10000毫秒。

(2)当整个MemStore使用率达到指定的值时 hbase.regionserver.global.memstore.upperLimit(memstore占用的总堆内存的比例,默认0.4)，来自不同region的MemStores将刷新到磁盘，以减少RegionServer中的MemStore总体使用量。region将刷新其MemStore，直到整个MemStore使用率降至或略低于此值默认为hbase.regionserver.global.memstore.size（0.95）的95％。

(3) 当一个region的memstore总量达到hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size (默认2*128M)时，会阻塞这个region的写操作，并强制刷写到HFile。

(4）手动flush ,flush 命令。

compact

当MemStore超过阀值的时候，就要flush到HDFS上生成一个HFile。因此随着不断写入，HFile的数量将会越来越多，根据前面所述，HFile数量过多会降低读性能。为了避免对读性能的影响，可以对这些HFile进行compact操作，把多个HFile合并成一个HFile。compact操作需要对HBase的数据进行多次的重新读写，因此这个过程会产生大量的IO。可以看到compact操作的本质就是以IO操作换取后续的读性能的提高。

(1)Minor操作只用来做部分文件的合并操作以及包括minVersion=0并且设置ttl的过期版本清理，不做任何删除数据、多版本数据的清理工作.

(2)Major操作是对Region下的HStore下的所有StoreFile执行合并操作，最终的结果是整理合并出一个文件。

触发compact条件

1.后台线程检查，检查是否需要compact周期=hbase.server.compactchecker.interval.multiplier*hbase.server.thread.wakefrequency(1000*10000)，一旦文件数 >= hbase.hstore.compactionThreshold(默认值3)，就会触发minor compact。执行minor compact最大的文件数是 hbase.hstore.compaction.max(默认值是10)。需要说明的是，minor compact都是以Store为单位进行的，而在Flush触发条件下，整个Region的所有Store都会执行minor compact，所以会在短时间内执行多次minor compact。然后判断是否需要major compact，条件为最早的HFile生成的时间是否在[ hbase.hregion.majorcompaction - hbase.hregion.majorcompaction * hbase.hregion.majorcompaction.jitter , hbase.hregion.majorcompaction + hbase.hregion.majorcompaction * hbase.hregion.majorcompaction.jitter ]间隔内。hbase.hregion.majorcompaction(默认604800000 7天)，hbase.hregion.majorcompaction.jitter(默认为0.50，此参数防止major cmpact在同一时间发生)

2.手动执行

compact

major_compact

 

split

split策略hbase.regionserver.region.split.policy(默认值org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy)

 

七、读数据

1.zookeeper中存储了meta表的region信息，所以先从zookeeper中找到meta表region的位置，然后读取meta表中的数据。meta中又存储了用户表的region信息。

2.根据namespace、表名和rowkey在meta表中找到对应的region信息

3.找到这个region对应的regionserver

4.查找对应的region

先从MemStore找数据，如果没有，就到Blockcache中找，再到StoreFile上读(为了读取的效率)。

 

Blockcache

hfile.block.cache.size（默认大小0.4）

LruBlockCache算法

包含三个级别的Block优先级队列：

Single：如果一个Block第一次被访问，则放在这一优先级队列中；

Multi：如果一个Block被多次访问，则从Single队列移到Multi队列中；

InMemory：如果一个Block是inMemory的，则放到这个队列中。

思想就是如果Blockcache占满后优先保留InMemory中的数据，然后是Multi，最后是Single

八、热点问题

检索habse的记录首先要通过row key来定位数据行。当大量的client访问hbase集群的一个或少数几个节点，造成少数region server的读/写请求过多、负载过大，而其他region server负载却很小，就造成了“热点”现象。大量访问会使热点region所在的单个主机负载过大，引起性能下降甚至region不可用。

分割region

 

 

移动region