[大数据]HBase详解

一、HBase是什么

HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可以在廉价PC Server上搭建起大规模结构化存储集群。

1、HBase的基本架构

一、HBase是什么

HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可以在廉价PC Server上搭建起大规模结构化存储集群。

1、HBase的基本架构

典型的主从架构

• Master

  Master是所有Region Server 的管理者，其实现类为HMaster，主要作用

  • 对于表的操作：create、delete、alter
  • 对于Region Server的操作：分配Region到每个RegionServer，监控每个RegionServer的状态，负载均衡和故障转移

• RegionServer

  RegionServer为Region的管理者，其实现类为HRegionServer，主要作用如下：

  • 对于数据的操作：get、put、delete
  • 对于Region的操作：splitRegion、compactRegion

• Zookeeper

  • HBase通过Zookeeper实现Master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。

• HDFS

  • HDFS为HBase提供最终的底层数据存储服务，同时为HBase提供高可用的支持

• StoreFile

  • 保存实际数据的物理文件，StoreFile以File的形式存储在HDFS上。每个Store会有一个或多个StoreFile（HFile），数据在每个StoreFile中都是有序的

• MemStore

  • 写缓存，由于HFile中的数据要求有序的，所以数据存储在Memstore中，排好序后，等到达刷写时机才会刷写到HFile，每次刷写都会形成一个新的HFile

• WAL

  • 为了解决数据在内存中丢失的情况，数据会先写在一个叫做Write-Ahead log的文件中，然后再写入MemStore中。所以在系统出现故障的时候，数据可以通过这个日志文件重建

2、HBase的基本架构

从HBase的底层物理存储结构（K-V）来看，HBase更像是一个multi-dimensional map。

（1）Name Space

命名空间，类似于关系型数据库DataBase的概念，每个命名空间下有多个表。HBase有两个自带的命名空间，分别为hbase和default，hbase中存放的是HBase的内置表，default是用户默认使用的命名空间。

（2）Table

HBase定义表时只需要声明列族即可。

特点：

• 大：单表可以数十亿行，数百万列
• 无模式：同一个表的不同行可以有截然不同的列
• 面向列：存储、权限控制、检索均面向列
• 稀疏：空列不占用存储，表是稀疏的
• 多版本：每个单元中的数据可以有多个版本，默认版本号是插入的时间戳
• 数据类型单一：数据都是字符串，没有类型

（3）Region

在HBase中一个Table横向分成多个分区，每个分区叫做一个Region，不同的Region分布在不同的服务器上实现分布式的存取。Region是HBase中分布式存储和负载均衡的最小单元。

（4）Rowkey

HBase表中每行数据都由一个Rowkey和多个Column（列）组成，数据按照Rowkey进行字典序排序，只能根据Rowkey进行检索。

注意：HBase只有Rowkey索引，没有二级索引。

（5）Column

HBase 中的每个列都由Column Family(列族)和Column Qualifier(列限定符)进行限定。

（6）Timestamp

用于标识数据不同版本。

二、HBase操作

1、写流程

写流程：

1. Client先访问Zookeeper，获取hbase:meta 表位于哪个RegionServer

2. Client访问对应的RegionServer，获取到base:meta表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个RegionServer的哪个Region中。并将Table的Region信息和meta表的位置信息缓存在客户端的meta cache中，方便下次访问

3. Client请求目标的RegionServer

4. 将数据追加写入到WAL

5. 对数据写入到对应的MemStore，数据会在MemStore中排序

6. 向Client发送ack

7. 等达到MemStore的刷写时机后，将数据刷写到HFile

2、Flush

MemStore的刷写时机：

• 当某个MemStore的大小达到了hbase.hregion,memstore.flush.size（默认128M），其所在的region中所有的memstore都会刷写；当memstore的大小达到hbase.hregion,memstore.flush.size（默认128M） * hbase.hregion.memstore.block.multiplier（默认4）时，会阻止继续往该memstore写数据
• 当RegionServer中MemStore的总大小达到java.heapsize * hbase.regionserver.global.memstore.size（默认0.4）* hbase.regionserver.global.memstore.size.lower.limit（默认0.95），region会按照memstore大小一次进行刷写，直到regionserver中总的memstore值小于上述值
• 到达自动刷写的时间，也会触发flush。hbase.regionserver.optionalcacheflushinterval（默认1小时）
• 当WAL文件的数量超过hbase.regionserver.max.logs，region会按照时间顺序依次进行刷写，直到WAL文件数量减小到hbase.regionserver.max.logs以下

3、读流程

读流程：

1. Client 先访问zookeeper，获取hbase:meta 表位于哪个Region Server
2. 访问对应的Region Server，获取hbase:meta 表，根据读请求的namespace:table/rowkey，查询 出目标数据位于哪个Region Server 中的哪个Region 中。并将该table 的region 信息以及meta 表的位置信息缓存在客户端的meta cache，方便下次访问
3. 与目标Region Server 进行通讯
4. 分别在Block Cache(读缓存)，MemStore 和Store File(HFile)中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本(time stamp)或者不同的类型(Put/Delete)
5. 将从文件中查询到的数据块(Block，HFile 数据存储单元，默认大小为64KB)缓存到BlockCache
6. 将合并后的最终结果返回给客户端

4、StoreFile Compaction

• Minor Compaction：会将临近的若干个较小的HFile合并成一个较大的HFile，但不会清理过期和删除的数据
• Major Compaction：会将一个Store下的所有的HFile合并成一个大HFile，并且会清理掉过期和删除的数据

5、Region Split

时机：

• 当一个Region中的某个Store下的所有StoreFile的总大小超过hbase.hregion.max.filesize，该region就会进行拆分(0.94 版本之前)
• 当1 个region 中的某个Store 下所有StoreFile 的总大小超过Min(R^2 *“hbase.hregion.memstore.flush.size”，hbase.hregion.max.filesize")，该Region 就会进行拆分，其中R 为当前Region Server 中属于该Table 的个数(0.94 版本之后)

三、HBase优化

1、HDFS层优化

• 允许HDFS append：hdfs-site.xml，hbase-site.xml

  dfs.support.append=true 
  

• 优化DataNode允许打开的最大文件数：hdfs-site.xml

  dfs.datanode.max.transfer.threads > 4096
  

• 优化高延迟操作的等待时间：hdfs-site.xml

  dfs.image.transfer.timeout
  

• 设置压缩

  mapreduce.map.output.compress设置为true 
  mapreduce.map.output.compress.codec设置为 org.apache.hadoop.io.compress.SnappyCodec或者其他压缩编码
  

2、HBase自身优化

• 设置RPC监听数量：hbase-site.xml

  hbase.regionserver.handler.count，读写请求较多时增加
  

• 优化HStore文件大小：hbase-site

  hbase.hregion.max.filesize：默认10G，如果需要在HBase上跑MR，则建议调小此值，避免map任务执行时间过长
  

• 写缓存优化：hbase-site

  hbase.client.write.buffer：客户端缓存，增大可减少RPC请求次数，但是会消耗更多内存
  

• 指定scan.next 一次扫描HBase获取的行数

  hbase.client.scanner.caching
  

• 优化compact：hbase-site.xml

  #禁用major compaction 
  hbase.hregion.majorcompaction设置为0 
  #闲时，比如夜间脚本触发，例如合并test表 
  major_compact 'test'
  

• 采用合适压缩算法、开启布隆过滤器

  ColumnFamilyDescriptor cfDesc=ColumnFamilyDescriptorBuilder
                          .newBuilder(Bytes.toBytes("F"))
                          .setCompressionType(Compression.Algorithm.SNAPPY)
  .setCompactionCompressionType(Compression.Algorithm.SNAPPY)
                          .setDataBlockEncoding(DataBlockEncoding.PREFIX)
   	 											.setBloomFilterType(BloomType.ROW)
  												.build();
  #也可以命令行建表时指定
  

3、预分区

create 'test_pre_split1','f1',SPLITS => ['10', '20', '30', '40']
create 'test_pre_split','f1',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

4、Rowkey设计

• 设计原则
  • 查询要用到的字段拼接到Rowkey
  • 查询语句中作为条件出现的最多字段的顺序越靠前
  • 一定要带散列前缀
• 设计技巧
  • hash前缀
  • 时间反转
  • 随机加严
• 每月建表
• 预建分区

典型的主从架构

• Master

  Master是所有Region Server 的管理者，其实现类为HMaster，主要作用

  • 对于表的操作：create、delete、alter
  • 对于Region Server的操作：分配Region到每个RegionServer，监控每个RegionServer的状态，负载均衡和故障转移

• RegionServer

  RegionServer为Region的管理者，其实现类为HRegionServer，主要作用如下：

  • 对于数据的操作：get、put、delete
  • 对于Region的操作：splitRegion、compactRegion

• Zookeeper

  • HBase通过Zookeeper实现Master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。

• HDFS

  • HDFS为HBase提供最终的底层数据存储服务，同时为HBase提供高可用的支持

• StoreFile

  • 保存实际数据的物理文件，StoreFile以File的形式存储在HDFS上。每个Store会有一个或多个StoreFile（HFile），数据在每个StoreFile中都是有序的

• MemStore

  • 写缓存，由于HFile中的数据要求有序的，所以数据存储在Memstore中，排好序后，等到达刷写时机才会刷写到HFile，每次刷写都会形成一个新的HFile

• WAL

  • 为了解决数据在内存中丢失的情况，数据会先写在一个叫做Write-Ahead log的文件中，然后再写入MemStore中。所以在系统出现故障的时候，数据可以通过这个日志文件重建

2、HBase的基本架构

从HBase的底层物理存储结构（K-V）来看，HBase更像是一个multi-dimensional map。

（1）Name Space

命名空间，类似于关系型数据库DataBase的概念，每个命名空间下有多个表。HBase有两个自带的命名空间，分别为hbase和default，hbase中存放的是HBase的内置表，default是用户默认使用的命名空间。

（2）Table

HBase定义表时只需要声明列族即可。

特点：

• 大：单表可以数十亿行，数百万列
• 无模式：同一个表的不同行可以有截然不同的列
• 面向列：存储、权限控制、检索均面向列
• 稀疏：空列不占用存储，表是稀疏的
• 多版本：每个单元中的数据可以有多个版本，默认版本号是插入的时间戳
• 数据类型单一：数据都是字符串，没有类型

（3）Region

在HBase中一个Table横向分成多个分区，每个分区叫做一个Region，不同的Region分布在不同的服务器上实现分布式的存取。Region是HBase中分布式存储和负载均衡的最小单元。

（4）Rowkey

HBase表中每行数据都由一个Rowkey和多个Column（列）组成，数据按照Rowkey进行字典序排序，只能根据Rowkey进行检索。

注意：HBase只有Rowkey索引，没有二级索引。

（5）Column

HBase 中的每个列都由Column Family(列族)和Column Qualifier(列限定符)进行限定。

（6）Timestamp

用于标识数据不同版本。

二、HBase操作

1、写流程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SfELz8DT-1630326534639)(/Users/juzi/Library/Application Support/typora-user-images/image-20210830193850739.png)]

写流程：

1. Client先访问Zookeeper，获取hbase:meta 表位于哪个RegionServer

2. Client访问对应的RegionServer，获取到base:meta表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个RegionServer的哪个Region中。并将Table的Region信息和meta表的位置信息缓存在客户端的meta cache中，方便下次访问

3. Client请求目标的RegionServer

4. 将数据追加写入到WAL

5. 对数据写入到对应的MemStore，数据会在MemStore中排序

6. 向Client发送ack

7. 等达到MemStore的刷写时机后，将数据刷写到HFile

2、Flush

MemStore的刷写时机：

• 当某个MemStore的大小达到了hbase.hregion,memstore.flush.size（默认128M），其所在的region中所有的memstore都会刷写；当memstore的大小达到hbase.hregion,memstore.flush.size（默认128M） * hbase.hregion.memstore.block.multiplier（默认4）时，会阻止继续往该memstore写数据
• 当RegionServer中MemStore的总大小达到java.heapsize * hbase.regionserver.global.memstore.size（默认0.4）* hbase.regionserver.global.memstore.size.lower.limit（默认0.95），region会按照memstore大小一次进行刷写，直到regionserver中总的memstore值小于上述值
• 到达自动刷写的时间，也会触发flush。hbase.regionserver.optionalcacheflushinterval（默认1小时）
• 当WAL文件的数量超过hbase.regionserver.max.logs，region会按照时间顺序依次进行刷写，直到WAL文件数量减小到hbase.regionserver.max.logs以下

3、读流程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-I4dp7N8m-1630326534640)(/Users/juzi/Library/Application Support/typora-user-images/image-20210830195250971.png)]

读流程：

1. Client 先访问zookeeper，获取hbase:meta 表位于哪个Region Server
2. 访问对应的Region Server，获取hbase:meta 表，根据读请求的namespace:table/rowkey，查询 出目标数据位于哪个Region Server 中的哪个Region 中。并将该table 的region 信息以及meta 表的位置信息缓存在客户端的meta cache，方便下次访问
3. 与目标Region Server 进行通讯
4. 分别在Block Cache(读缓存)，MemStore 和Store File(HFile)中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本(time stamp)或者不同的类型(Put/Delete)
5. 将从文件中查询到的数据块(Block，HFile 数据存储单元，默认大小为64KB)缓存到BlockCache
6. 将合并后的最终结果返回给客户端

4、StoreFile Compaction

• Minor Compaction：会将临近的若干个较小的HFile合并成一个较大的HFile，但不会清理过期和删除的数据
• Major Compaction：会将一个Store下的所有的HFile合并成一个大HFile，并且会清理掉过期和删除的数据

5、Region Split

时机：

• 当一个Region中的某个Store下的所有StoreFile的总大小超过hbase.hregion.max.filesize，该region就会进行拆分(0.94 版本之前)
• 当1 个region 中的某个Store 下所有StoreFile 的总大小超过Min(R^2 *“hbase.hregion.memstore.flush.size”，hbase.hregion.max.filesize")，该Region 就会进行拆分，其中R 为当前Region Server 中属于该Table 的个数(0.94 版本之后)

三、HBase优化

1、HDFS层优化

• 允许HDFS append：hdfs-site.xml，hbase-site.xml

  dfs.support.append=true 
  

• 优化DataNode允许打开的最大文件数：hdfs-site.xml

  dfs.datanode.max.transfer.threads > 4096
  

• 优化高延迟操作的等待时间：hdfs-site.xml

  dfs.image.transfer.timeout
  

• 设置压缩

  mapreduce.map.output.compress设置为true 
  mapreduce.map.output.compress.codec设置为 org.apache.hadoop.io.compress.SnappyCodec或者其他压缩编码
  

2、HBase自身优化

• 设置RPC监听数量：hbase-site.xml

  hbase.regionserver.handler.count，读写请求较多时增加
  

• 优化HStore文件大小：hbase-site

  hbase.hregion.max.filesize：默认10G，如果需要在HBase上跑MR，则建议调小此值，避免map任务执行时间过长
  

• 写缓存优化：hbase-site

  hbase.client.write.buffer：客户端缓存，增大可减少RPC请求次数，但是会消耗更多内存
  

• 指定scan.next 一次扫描HBase获取的行数

  hbase.client.scanner.caching
  

• 优化compact：hbase-site.xml

  #禁用major compaction 
  hbase.hregion.majorcompaction设置为0 
  #闲时，比如夜间脚本触发，例如合并test表 
  major_compact 'test'
  

• 采用合适压缩算法、开启布隆过滤器

  ColumnFamilyDescriptor cfDesc=ColumnFamilyDescriptorBuilder
                          .newBuilder(Bytes.toBytes("F"))
                          .setCompressionType(Compression.Algorithm.SNAPPY)
  .setCompactionCompressionType(Compression.Algorithm.SNAPPY)
                          .setDataBlockEncoding(DataBlockEncoding.PREFIX)
   	 											.setBloomFilterType(BloomType.ROW)
  												.build();
  #也可以命令行建表时指定
  

3、预分区

create 'test_pre_split1','f1',SPLITS => ['10', '20', '30', '40']
create 'test_pre_split','f1',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

4、Rowkey设计

• 设计原则
  • 查询要用到的字段拼接到Rowkey
  • 查询语句中作为条件出现的最多字段的顺序越靠前
  • 一定要带散列前缀
• 设计技巧
  • hash前缀
  • 时间反转
  • 随机加严
• 每月建表
• 预建分区