[大数据]HBase学习笔记

Hbase

1、HBase简介

HBase基于 Google的BigTable论文而来，是一个分布式海量列式存储非关系型数据库系统，可以提供 超大规模数据集的实时随机读写。

1.1、什么是列式存储？

先看常规的关系型数据库MySQL的存储机制：下面的空值字段浪费存储空间

如果使用列式存储

对比：

1、mysql如果字段确定，不支持动态扩展列；列式存储则可以任意扩展

2、减少存储空间的浪费

1.2、HBase的特点

• 海量存储: 底层基于HDFS存储海量数据 ，HBase在HDFS之上提供了高并发的随机写和支持实时查询，这是HDFS不具备的。

• **列式存储: ** HBase表的数据是基于列族进行存储的，一个列族包含若干列

• **极易扩展: ** 底层依赖HDFS，当磁盘空间不足的时候，只需要动态增加DataNode服务节点就可以

• 高并发: 支持高并发的读写请求

• 稀疏: 稀疏主要是针对HBase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情 况下，是不会占用存储空间的。

• **数据的多版本: **HBase表中的数据可以有多个版本值，默认情况下是根据版本号去区分，版本号就 是插入数据的时间戳

• 数据类型单一: 所有的数据在HBase中是以字节数组进行存储

1.3、HBase的应用

• 交通方面：GPS信息，每天都有海量数据存储
• 金融方面：消费信息、贷款信息、信用卡还款信息
• 电商方面：交易信息、物流信息、游览信息
• 电信方面：通话信息

总结：HBase适合海量明细数据的存储，并且后期需要有很好的查询性能（单表超千万、上亿，且并发要求高）

2、HBase数据模型

HBase的数据也是以表的形式存储的

2.1、HBase逻辑结构

一个列族下可以任意添加列，不受任何限制

数据写到HBase的时候都会被记录一个时间戳，这个时间戳被我们当做一个版本。比如说，我们修改或者删除某一条的时候，本质上是往里边新增一条数据，记录的版本加一了而已。

2.2、HBase物理存储

2.3、HBase常见概念

3、HBase整体架构

• Client ：客户端，它提供了访问HBase的接口，并且维护了对应的cache来加速HBase的访问。

• Zookeeper

  • 实现HMaster的高可用
  • 存储HBase的元数据（meta表），无论是读还是写数据，都是去Zookeeper里边拿到meta元数据告诉给客户端去哪台机器读写数据
  • 对HMaster和HRegionServer进行监控

• HMaster(Master）

  • 为HRegionServer分配Region ，维护整个集群的负载均衡
  • 维护集群的元数据信息
  • 发现失效的Region，并将失效的Region分配到正常的HRegionServer上

• HRegionServer

  • 负责管理Region
  • 切分在运行过程中变大的Region
  • 它是处理客户端的读写请求，负责与HDFS底层交互，是真正干活的节点。

• Region

  • 每个Region由多个Store构成

  • 每个Store保存一个列族，表有几个列族，就有几个Store

  • 每个Store由一个MemStore和多个StoreFile组成，MemStore是Store在内存中的内容，写到文件后就是StoreFile。StoreFile底层是以HFile的格式保存。

总结：client请求到Zookeeper，然后Zookeeper返回HRegionServer地址给client，client得到Zookeeper返回的地址去请求HRegionServer，HRegionServer读写数据后返回给client。

4、HBase集群安装部署

(1)、下载安装包

• http://archive.apache.org/dist/hbase/1.3.1/

• hbase-1.3.1-bin.tar.gz

(2)、规划安装目录

/opt/xyc/servers/

(3)、上传安装包到服务器

(4)、解压安装包到指定的规划目录

tar -zxvf hbase-1.3.1-bin.tar.gz -C /opt/xyc/servers

(5)、修改配置文件

• 需要把hadoop中的配置core-site.xml 、hdfs-site.xml拷贝到hbase安装目录下的conf文件夹中

ln -s /opt/xyc/servers/hadoop-2.9.2/etc/hadoop/core-site.xml /opt/xyc/servers/hbase-1.3.1/conf/core-site.xml

 ln -s /opt/xyc/servers/hadoop-2.9.2/etc/hadoop/hdfs-site.xml /opt/xyc/servers/hbase-1.3.1/conf/hdfs-site.xml

• 修改conf目录下配置文件

  • 修改 hbase-env.sh

    #添加java环境变量
     export JAVA_HOME=/opt/module/jdk1.8.0_231 
    #指定使用外部的zk集群
     export HBASE_MANAGES_ZK=FALSE
    

  • 修改 hbase-site.xml

    <configuration>
         <!-- 指定hbase在HDFS上存储的路径 -->
        <property> 
            <name>hbase.rootdir</name>
            <value>hdfs://linux121:9000/hbase</value> 
        </property>
    
        <!-- 指定hbase是分布式的 --> 
        <property>
            <name>hbase.cluster.distributed</name>
            <value>true</value> 
        </property>
    
        <!-- 指定zk的地址，多个用“,”分割 --> 
        <property>
            <name>hbase.zookeeper.quorum</name>
            <value>linux121:2181,linux122:2181,linux123:2181</value>
        </property>
    </configuration>
    

  • 修改regionservers文件

    #指定regionserver节点 
    linux121
    linux122
    linux123
    

  • hbase的conf目录下创建文件backup-masters (Standby Master)

    linux122
    

(6)、配置hbase的环境变量

export HBASE_HOME=/opt/xyc/servers/hbase-1.3.1 
export PATH=$PATH:$HBASE_HOME/bin

(7)、分发hbase目录和环境变量到其他节点

rsync-script hbase-1.3.1

(8)、让所有节点的hbase环境变量生效

? 在所有节点执行 source /etc/profile

HBase集群的启动和停止

• 前提条件:先启动hadoop和zk集群
• 启动HBase:start-hbase.sh
• 停止HBase:stop-hbase.sh

HBase集群的web管理界面

启动好HBase集群之后，可以访问地址: HMaster的主机名:16010

5、HBase基本操作

5.1、进入Hbase客户端命令操作界面

hbase shell

5.2、查看帮助命令

help

5.3、查看当前数据库中有哪些表

list

5.4、创建表

• 创建一张lagou表， 包含base_info、extra_info两个列族

create 'lagou', 'base_info', 'extra_info'# 或者(Hbase建表必须指定列族信息)create 'lagou', {NAME => 'base_info', VERSIONS => '3'},{NAME => 'extra_info',VERSIONS => '3'}# VERSIONS 是指此单元格内的数据可以保留最近的 3 个版本 

5.5、添加数据操作

• 向lagou表中插入信息，row key为 rk1，列族base_info中添加name列标示符，值为wang

  put 'lagou', 'rk1', 'base_info:name', 'wang'
  

• 向lagou表中插入信息，row key为rk1，列族base_info中添加age列标示符，值为30

  put 'lagou', 'rk1', 'base_info:age', 30
  

• 向lagou表中插入信息，row key为rk1，列族extra_info中添加address列标示符，值为shanghai

  put 'lagou', 'rk1', 'extra_info:address', 'shanghai'
  

5.6、查询数据

5.6.1、通过rowkey进行查询

• 获取表中row key为rk1的所有信息

  get 'lagou', 'rk1'
  

5.6.2 、查看rowkey下面的某个列族的信息

• 获取lagou表中row key为rk1，base_info列族的所有信息

  get 'lagou', 'rk1', 'base_info'
  

5.6.3、 查看rowkey指定列族指定字段的值

• 获取表中row key为rk1，base_info列族的name、age列标示符的信息

  get 'lagou', 'rk1', 'base_info:name', 'base_info:age'
  

5.6.4 、查看rowkey指定多个列族的信息

• 获取lagou表中row key为rk1，base_info、extra_info列族的信息

  get 'lagou', 'rk1', 'base_info', 'extra_info'# 或者get 'lagou', 'rk1', {COLUMN => ['base_info', 'extra_info']} # 或者get 'lagou', 'rk1', {COLUMN => ['base_info:name', 'extra_info:address']} 
  

5.6.5、指定rowkey与列值查询

• 获取表中row key为rk1，cell的值为wang的信息

  get 'lagou', 'rk1', {FILTER => "ValueFilter(=, 'binary:wang')"}
  

5.6.6、指定rowkey与列值模糊查询

• 获取表中row key为rk1，列标示符中含有a的信息

  get 'lagou', 'rk1', {FILTER => "(QualifierFilter(=,'substring:a'))"}
  

5.6.7、查询所有数据

• 查询lagou表中的所有信息

  scan 'lagou'
  

5.6.8、列族查询

• 查询表中列族为 base_info 的信息

  scan 'lagou', {COLUMNS => 'base_info'}scan 'lagou', {COLUMNS => 'base_info', RAW => true, VERSIONS => 3}## Scan时可以设置是否开启Raw模式,开启Raw模式会返回包括已添加删除标记但是未实际删除的数据## VERSIONS指定查询的最大版本数
  

5.6.9、指定多个列族与按照数据值模糊查询

• 查询lagou表中列族为 base_info 和 extra_info且列标示符中含有a字符的信息

   scan 'lagou', {COLUMNS => ['base_info', 'extra_info'], FILTER => "(QualifierFilter(=,'substring:a'))"} 
  

5.6.10、rowkey的范围值查询(非常重要)

• 查询lagou表中列族为base_info，rk范围是[rk1, rk3)的数据(rowkey底层存储是字典序)

• 按rowkey顺序存储。

  scan 'lagou', {COLUMNS => 'base_info', SARTROW => 'rk1', ENDROW => 'rk3'}
  

5.6.11、指定rowkey模糊查询

• 查询lagou表中row key以rk字符开头的

  scan 'lagou',{FILTER=>"PrefixFilter('rk')"}
  

5.7、更新数据

更新操作同插入操作一模一样，只不过有数据就更新，没数据就添加

5.7.1、更新数据值

• 把lagou表中rowkey为rk1的base_info列族下的列name修改为liang

  put 'lagou', 'rk1', 'base_info:name', 'liang' 							
  

5.8、删除数据和表

5.8.1、指定rowkey以及列名进行删除

• 删除lagou表row key为rk1，列标示符为 base_info:name 的数据

  delete 'lagou', 'rk1', 'base_info:name' 
  

5.8.2、指定rowkey，列名以及时间戳信息进行删除

• 删除lagou表row key为rk1，列标示符为base_info:name的数据

  scan 'lagou', {COLUMNS => 'base_info', RAW => true, VERSIONS => 3} ROW     COLUMN+CELLrk1 		column=base_info:name, timestamp=1600660633870, value=zhao rk1			column=base_info:name, timestamp=1600660627447, value=li rk1     column=base_info:name, timestamp=1600660619655, value=wangdelete 'lagou', 'rk1', 'base_info:name',1600660619655 scan 'lagou', {COLUMNS => 'base_info', RAW => true, VERSIONS => 3} ROW    COLUMN+CELLrk1    column=base_info:name, timestamp=1600660633870, value=zhaork1    column=base_info:name, timestamp=1600660627447, value=li rk1    column=base_info:name, timestamp=1600660619655, type=Delete rk1    column=base_info:name, timestamp=1600660619655, value=wang1 row(s) in 0.0070 seconds
  

5.8.3、删除列族

• 删除 base_info 列族

  alter 'lagou', 'delete' => 'base_info' 	
  

5.8.4、清空表数据

• 删除lagou表数据

  truncate 'lagou' 
  

5.8.5、删除表

• 删除lagou表

  #先disable 再drop disable 'lagou' drop 'lagou' 		#如果不进行disable，直接drop会报错  ERROR: Table user is enabled. Disable it first. 							 					 			
  

6、HBase深入

6.1、HBase读数据流程

1）Client访问zookeeper，获取hbase:meta 表的位置（HRegionServer的位置），缓存该位置（meta表中存储了用户的region的位置信息）

2）从HRegionServer的meta表中查询对应请求的（namespace、表名、rowkey）所在的Region的位置信息，并获取region所对应的RegionServer的位置信息

3）找到这个region对应的regionServer，然后发送请求

4）查找对应的region

5）先从memstore查找数据，如果没有，再从BlockCache上读取

HBase上Regionserver的内存分为两个部分

• 一部分作为Memstore，主要用来写;
• 另外一部分作为BlockCache，主要用于读数据;

6)如果BlockCache中也没有找到，再到StoreFile上进行读取

从storeFile中读取到数据之后，不是直接把结果数据返回给客户端， 而是把数据先写入到BlockCache中，目的是为了加快后续的查询;然后在返回结果给客户端。

6.2、HBase写数据流程

1）Client访问zookeeper，获取hbase:meta 表的位置（HRegionServer的位置），缓存该位置（meta表中存储了用户的region的位置信息）

2）从HRegionServer的meta表中查询对应请求的（namespace、表名、rowkey）所在的Region的位置信息，并获取region所对应的RegionServer的位置信息

3)找到这个region对应的regionServer，然后发送请求

4)把数据分别写到HLog(write ahead log)和memstore各一份

5)memstore达到阈值后把数据刷到磁盘，生成storeFile文件

6)删除HLog中的历史数据

6.3、Flush（刷写）机制

(1)、当memstore的大小超过这个值的时候，会flush到磁盘,默认为128M

<property>   <name>hbase.hregion.memstore.flush.size</name>  <value>134217728</value></property>

(2)、当memstore中的数据时间超过1小时，会flush到磁盘

<property>   <name>hbase.regionserver.optionalcacheflushinterval</name>   <value>3600000</value></property>

(3)、HregionServer的全局memstore的大小，超过该大小会触发flush到磁盘的操作,默认是堆大小的40%

<property>   <name>hbase.regionserver.global.memstore.size</name>   <value>0.4</value></property>

(4)手动flush

flush tableName

6.4、阻塞机制

以上介绍的是Store中memstore数据刷写磁盘的标准，但是Hbase中是周期性的检查是否满足以上标准满足则进行刷写，但是如果在下次检查到来之前，数据疯狂写入Memstore中，会出现什么问 题呢?

会触发阻塞机制，此时无法写入数据到Memstore，数据无法写入Hbase集群。

• memstore中数据达到512MB

  计算公式:

  hbase.hregion.memstore.flush.size*hbase.hregion.memstore..block.multiplier 
  

  • hbase.hregion.memstore.flush.size刷写的阀值，默认是 134217728，即128MB。
  • hbase.hregion.memstore.block.multiplier是一个倍数，默认 是4。

• RegionServer全部memstore达到规定值

  • hbase.regionserver.global.memstore.size.lower.limit是0.95
  • hbase.regionserver.global.memstore.size是0.4
  • 堆内存总共是 16G，
  • 触发刷写的阈值是:6.08GB
  • 触发阻塞的阈值是:6.4GB

6.5、Compact合并机制

在hbase中主要存在两种类型的compac合并

• minor compact 小合并

  • 将Store中多个HFile(StoreFile)合并为一个HFile

     这个过程中，删除和更新的数据仅仅只是做了标记，并没有物理移除，这种合并的触发频率很高。
    

  • minor compact文件选择标准由以下几个参数共同决定:

     <!--待合并文件数据必须大于等于下面这个值--> <property>	<name>hbase.hstore.compaction.min</name>	<value>3</value> </property><!--待合并文件数据必须小于等于下面这个值--> <property>	<name>hbase.hstore.compaction.max</name>	<value>10</value></property><!--默认值为128m,表示文件大小小于该值的store file 一定会加入到minor compaction的store file中 --><property>	<name>hbase.hstore.compaction.min.size</name>  <value>134217728</value></property><!--默认值为LONG.MAX_VALUE，表示文件大小大于该值的store file 一定会被minor compaction排除--> <property>	<name>hbase.hstore.compaction.max.size</name>	<value>9223372036854775807</value> </property>
    

  • 触发条件

    • memstore flush
      在进行memstore flush前后都会进行判断是否触发compact

    • 定期检查线程

      周期性检查是否需要进行compaction操作,由参数:hbase.server.thread.wakefrequency决定，默认值是10000 millseconds

• major compact 大合并

  • 合并Store中所有的HFile为一个HFile

    这个过程有删除标记的数据会被真正移除，同时超过单元格maxVersion的版本记录也会被删除。合并频率比较低，默认7天执行一次，并且性能消耗非常大，建议生产关闭(设置为 0)，在应用空闲时间手动触发。一般可以是手动控制进行合并，防止出现在业务高峰期。

    • major compaction触发时间条件

       <!--默认值为7天进行一次大合并，--> <property>	<name>hbase.hregion.majorcompaction</name>	<value>604800000</value> </property>
      

    • 手动触发

       ##使用major_compact命令  major_compact tableName
      

6.6、Region拆分机制

Region中存储的是大量的rowkey数据，当region中数据过多时，直接影响查询效率。所以当Region过大时，HBase会拆分Region。

6.6.1、拆分策略

• ConstantSizeRegionSplitPolicy （0.94版本前默认切分策略）

  当region大小大于某个阈值(hbase.hregion.max.filesize=10G)之后就会触发拆分，一个region等分为2个region。弊端 : 拆分策略对于大表和小表没有明显的区分。- 阈值设置较大对大表比较友好，但小表就有可能不会触发分裂，极端情况下可能就1个，这对业务来说并不是什么好事。- 阈值设置较小对小表比较友好，但大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来 说都不是一件好事。
  

• IncreasingToUpperBoundRegionSplitPolicy （ 0.94版本~2.0版本默认切分策略）

  一个region大小大于设置阈值就会触发切分。但是这个阈值不是一个固定的值，而是会在一定条件下不断调整的值。调整规则和region所属表在当前regionserver上的region个数有关系.region split的计算公式是: regioncount^3 * 128M * 2，当region达到该size的时候进行split  例如: 第一次split:1^3 * 256 = 256MB 第二次split:2^3 * 256 = 2048MB 第三次split:3^3 * 256 = 6912MB 第四次split:4^3 * 256 = 16384MB > 10GB，因此取较小的值10GB 后面每次split的size都是10GB了
  

• SteppingSplitPolicy （2.0版本默认切分策略）

  该切分策略的切分阈值又发生了变化，但依然和待分裂region所属表在当前regionserver上的region个数有关系。如果region个数等于1，切分阈值为flush size * 2，否则为MaxRegionFileSize。这种切分策略对于大集群中的大表、小表会比IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不会再产生大量的小region，而是适可而止。
  

• KeyPrefixRegionSplitPolicy

  根据rowKey的前缀对数据进行分组，这里是指定rowKey的前多少位作为前缀，比如rowKey都是16位的，指定前5位是前缀，那么前5位相同的rowKey在进行region split的时候会分到相同的region中。
  

• DelimitedKeyPrefixRegionSplitPolicy

  保证相同前缀的数据在同一个region中.例如rowKey的格式为:userid_eventtype_eventid，指定的delimiter为 _ ，则split的的时候会确保userid相同的数据在同一个region中。
  

• DisabledRegionSplitPolicy

  不启用自动拆分, 需要指定手动拆分
  

6.6.2、应用

Region拆分策略可以全局统一配置，也可以为单独的表指定拆分策略。

• 通过hbase-site.xml全局统一配置(对hbase所有表生效)

  <property> 		<name>hbase.regionserver.region.split.policy</name> 	    	<value>  		org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy  	</value></property>
  

• 通过Java API为单独的表指定Region拆分策略

  HTableDescriptor tableDesc = new HTableDescriptor("test1"); tableDesc.setValue(HTableDescriptor.SPLIT_POLICY,                                              											IncreasingToUpperBoundRegionSplitPolicy.class.getName()); tableDesc.addFamily(new HColumnDescriptor(Bytes.toBytes("cf1"))); admin.createTable(tableDesc);
  

• 通过HBase Shell为单个表指定Region拆分策略

  hbase> create 'test2', {METADATA => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy'}},{NAME => 'cf1'}
  

6.7、HBase表的预分区

6.7.1、为何要预分区?

当一个table刚被创建的时候，Hbase会给table分配一个默认的region。此时，所有的读写请求都会访问到同一个regionServer的同一个region中，达不到负载均衡的效果，集群中的其他regionServer就可能会处于比较空闲的状态。

解决问题：用预分区（pre-splitting）,在创建table的时候就配置好，生成多个region。

好处：

• 增加数据读写效率

• 负载均衡，防止数据倾斜

• 方便集群容灾调度region

6.7.2、手动指定预分区

create 'person','info1','info2',SPLITS => ['1000','2000','3000']

也可以把分区规则创建于文件中

vim split.txtcreate 'student','info',SPLITS_FILE => '/root/hbase/split.txt'

6.8、Region合并机制

Region的合并不是为了性能，而是出于维护的目的。

需求:

把student表中的2个region数据进行合并 : student,,1593244870695.10c2df60e567e73523a633f20866b4b5. student,1000,1593244870695.0a4c3ff30a98f79ff6c1e4cc927b3d0d.

通过Merge类 (冷合并Region)

通过org.apache.hadoop.hbase.util.Merge类，不需要进入hbase shell，直接执行(需要先关闭hbase集群):

hbase org.apache.hadoop.hbase.util.Merge student \ student,,1595256696737.fc3eff4765709e66a8524d3c3ab42d59. \ student,aaa,1595256696737.1d53d6c1ce0c1bed269b16b6514131d0.

通过online_merge (热合并Region)

不需要关闭hbase集群，在线进行合并

online_merge的传参是Region的hash值，即Region名称中在最后两个.之间的字符串部分。

# 需要进入hbase shell:merge_region 'c8bc666507d9e45523aebaffa88ffdd6','02a9dfdf6ff42ae9f0524a3d8f4c7777'