Hbase概述与读写流程

Hbase概述与读写流程

一、Hbase概述

Hbase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，用于存储海量的结构化或者半结构化，非结构化的数据（底层是字节数组做存储的）

HBase是Hadoop的生态系统之一，是建立在Hadoop文件系统（HDFS）之上的分布式、面向列的数据库，通过利用Hadoop的文件系统提供容错能力。如果需要进行实时读写或者随机访问大规模的数据集的时候，会考虑使用HBase。

HBase是可以提供实时计算的分布式数据库，数据被保存在HDFS分布式文件系统上，由HDFS保证期高容错性;

1.1、HBase是如何基于hadoop提供实时性呢？

​ HBase上的数据是以StoreFile(HFile)二进制流的形式存储在HDFS上block块儿中；

​ 但是HDFS并不知道的HBase用于存储什么，它只把存储文件认为是二进制文件，也就是说，HBase的存储数据对于HDFS文件系统是透明的。

1.2、稀疏性

HBase中需要根据行键、列族、列限定符和时间戳来确定一个单元格，因此，可以视为一个“四维坐标”，即[行键, 列族, 列限定符, 时间戳]

1.3、数据模型

HBase通过表格的模式存储数据，每个表格由列和行组成，其中，每个列又被划分为若干个列族（colnum family），请参考下面的图：

image-20220608214455582

表：HBase的数据同样是用表来组织的，表由行和列组成，列分为若干个列族，行和列的坐标交叉决定了一个单元格。

行：每个表由若干行组成，每个行有一个行键作为这一行的唯一标识。访问表中的行只有三种方式：通过单个行键进行查询、通过一个行键的区间来访问、全表扫描。

列族：一个HBase表被分组成许多“列族”的集合，它是基本的访问控制单元。

列修饰符（列限定符）：列族里的数据通过列限定符（或列）来定位

单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]

时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引

1.4、Hbase区域

HBase自动把表水平划分为区域（Region），每个区域都是有若干连续行构成的，一个区域由所属的表、起始行、终止行（不包括这行）三个要素来表示。

一开始，一个表只有一个区域，但是随着数据的增加，区域逐渐变大，等到它超出设定的阈值大小，就会在某行的边界上进行拆分，分成两个大小基本相同的区域。然后随着数据的再增加，区域就不断的增加，如果超出了单台服务器的容量，就可以把一些区域放到其他节点上去，构成一个集群。也就是说：集群中的每个节点（Region Server）管理整个表的若干个区域。所以，我们说：区域是HBase集群上分布数据的最小单位。

1.4.1、Memstore 与 storefile

  1. 一个region由多个store组成，一个store对应一个CF（列簇）

  2. store包括位于内存中的memstore和位于磁盘的storefile写操作先写入 memstore，当memstore中的数据达到某个阈值，hregionserver会启动 flashcache进程写入storefile，每次写入形成单独的一个storefile

  3. 当storefile文件的数量增长到一定阈值后，系统会进行合并（minor、 major compaction），在合并过程中会进行版本合并和删除工作 （majar），形成更大的storefile。

  4. 当一个region所有storefile的大小和超过一定阈值后，会把当前的region 分割为两个，并由hmaster分配到相应的regionserver服务器，实现负载均衡。

  5. 客户端检索数据，先在memstore找，找不到再找storefile

  6. HRegion是HBase中分布式存储和负载均衡的最小单元。最小单元就表 示不同的HRegion可以分布在不同的HRegion server上。

  7. HRegion由一个或者多个Store组成，每个store保存一个columns family。

  8. 每个Strore又由一个memStore和0至多个StoreFile组成。

如图：StoreFile 以HFile格式保存在HDFS上。

image-20220608221644247

image-20220608221654847

1.5、Hbase系统架构

image-20220608221621833

1.5.1、组件介绍

HBase由三种类型的服务器以主从模式构成：

  • Region Server：负责数据的读写服务，用户通过与Region server交互来实现对数据的访问。
  • HBase HMaster：负责Region的分配及数据库的创建和删除等操作。
  • ZooKeeper：负责维护集群的状态（某台服务器是否在线，服务器之间数据的同步操作及master的选举等）。

HDFS的DataNode负责存储所有Region Server所管理的数据，即HBase中的所有数据都是以HDFS文件的形式存储的。出于使Region server所管理的数据更加本地化的考虑，Region server是根据DataNode分布的。HBase的数据在写入的时候都存储在本地。但当某一个region被移除或被重新分配的时候，就可能产生数据不在本地的情况。这种情况只有在所谓的compaction之后才能解决。

Client

包含访问HBase的接口并维护cache来加快对HBase的访问

Zookeeper

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

存贮所有Region的寻址入口。

实时监控Region server的上线和下线信息。并实时通知Master

存储HBase的schema和table元数据

Master

为Region server分配region

负责Region server的负载均衡

发现失效的Region server并重新分配其上的region

管理用户对table的增删改操作

RegionServer

Region server维护region，处理对这些region的IO请求

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

HLog(WAL log)：

HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是 HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和 region名字外，同时还包括sequence number和timestamp，timestamp是” 写入时间”，sequence number的起始值为0，或者是最近一次存入文件系 统sequence number。

HLog SequeceFile的Value是HBase的KeyValue对象，即对应HFile中的 KeyValue

Region

HBase自动把表水平划分成多个区域(region)，每个region会保存一个表里面某段连续的数据；每个表一开始只有一个region，随着数据不断插 入表，region不断增大，当增大到一个阀值的时候，region就会等分会两个新的region（裂变）；

当table中的行不断增多，就会有越来越多的region。这样一张完整的表被保存在多个Regionserver上。

理解难点

　　1、flush刷新在HDFS上呈现究竟是怎么刷新的呢？？
　　　　我们目前刚刚学习的时候，添加数据，都是一条一条的put进去，而我们在put的数据比较少（小于128M）的时候，我们put完去HDFS上并未查看到我们put的文件，这是因为数据还在内存中，也就是还在memStore中，所以要想在HDFS中查看到，我们必须手动刷新到磁盘中，这是将memStore的数据刷新到StoreFile中去，这样我们在HDFS中就可以查看到了。　　

　　2、为什么Hbase不可以使用像Mysql那样进行查询？？
　　　　首先，我们应该可以感受到，我们在插入的时候，每行数据，有多少列，列名叫什么完全是我们自己定义的，之所以不支持像MySql那样对列进行查询和操作，因为不确定列的个数和名称。

　　3、数据最后存在HDFS上的，HDFS不支持删改，为什么Hbase就可以呢？？
　　　　这里有个思想误区，的确，数据是以HFile形式存在HDFS上的，而且HDFS的确是不支持删改的，但是为什么Hbase就支持呢？首先，这里的删除并不是真正意义上的对数据进行删除，而是对数据进行打上标记，我们再去查的时，就不会查到这个打过标记的数据，这个数据Hmaster会每隔1小时清理。修改是put两次，Hbase会取最新的数据，过期数据也是这个方式被清理。

二、Hbase读写流程

2.1、架构图

hbase架构

2.2、读流程

Hbase读取数据的流程：
1）是由客户端发起读取数据的请求，首先会与zookeeper建立连接
2）从zookeeper中获取一个hbase:meta表位置信息，被哪一个regionserver所管理着
     hbase:meta表：hbase的元数据表，在这个表中存储了自定义表相关的元数据，包括表名，表有哪些列簇，表有哪些region,每个region存储的位置，每个region被哪个regionserver所管理，这个表也是存储在某一个region上的，并且这个meta表只会被一个regionserver所管理。这个表的位置信息只有zookeeper知道。
3）连接这个meta表对应的regionserver,从meta表中获取当前你要读取的这个表对应的regionsever是谁。
     当一个表多个region怎么办呢？
     如果我们获取数据是以get的方式，只会返回一个regionserver
     如果我们获取数据是以scan的方式，会将所有的region对应的regionserver的地址全部返回。
4）连接要读取表的对应的regionserver,从regionserver上的开始读取数据：
       读取顺序：memstore-->blockcache-->storefile-->Hfile中
       注意：如果是scan操作，就不仅仅去blockcache了，而是所有都会去找。

2.3、写流程

--------------------------1-4步是客户端写入数据的流程-----------------

Hbase的写入数据流程：
1）由客户端发起写数据请求，首先会与zookeeper建立连接
2）从zookeeper中获取hbase:meta表被哪一个regionserver所管理
3）连接hbase:meta表中获取对应的regionserver地址 (从meta表中获取当前要写入数据的表对应的region所管理的regionserver) 只会返回一个regionserver地址
4）与要写入数据的regionserver建立连接，然后开始写入数据，将数据首先会写入到HLog，然后将数据写入到对应store模块中的memstore中
（可能会写多个），当这两个地方都写入完成之后，表示数据写入完成。


-------------------------后面的步骤是服务器内部的操作-----------------
异步操作
5）随着客户端不断地写入数据，memstore中的数据会越来多，当内存中的数据达到阈值（128M/1h）的时候，放入到blockchache中，生成新的memstore接收用户过来的数据，然后当blockcache的大小达到一定阈值（0.85）的时候，开始触发flush机制，将数据最终刷新到HDFS中形成小的Hfile文件。

6）随着不断地刷新，storefile不断地在HDFS上生成小HFIle文件，当小的HFile文件达到阈值的时候（3个及3个以上）,就会触发Compaction机制，将小的HFile合并成一个大的HFile.

7）随着不断地合并，大的HFile文件会越来越大，当达到一定阈值（2.0版本之后最终10G）的时候，会触发分裂机制（split）,将大的HFile文件进行一分为二，同时管理这个大的HFile的region也会被一分为二，形成两个新的region和两个新的HFile文件，一对一的进行管理，将原来旧的region和分裂之前大的HFile文件慢慢地就会下线处理。

2.3、Region的分裂策略

region中存储的是一张表的数据，当region中的数据条数过多的时候，会直接影响查询效率。当region过大的时候，region会被拆分为两个region，HMaster会将分裂的region分配到不同的regionserver上，这样可以让请求分散到不同的RegionServer上，已达到负载均衡 , 这也是HBase的一个优点 。

  • ConstantSizeRegionSplitPolicy

    0.94版本前，HBase region的默认切分策略

    当region中最大的store大小超过某个阈值(hbase.hregion.max.filesize=10G)之后就会触发切分，一个region等分为2个region。

    但是在生产线上这种切分策略却有相当大的弊端（切分策略对于大表和小表没有明显的区分）：

    • 阈值(hbase.hregion.max.filesize)设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，形成热点，这对业务来说并不是什么好事。
    • 如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来说都不是一件好事。

  • IncreasingToUpperBoundRegionSplitPolicy

    0.94版本~2.0版本默认切分策略

    ​ 总体看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大的store大小大于设置阈值就会触发切分。
    但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系.

    region split阈值的计算公式是：

    • 设regioncount：是region所属表在当前regionserver上的region的个数

    • 阈值 = regioncount^3 * 128M * 2，当然阈值并不会无限增长，最大不超过MaxRegionFileSize（10G),当region中最大的store的大小达到该阈值的时候进行region 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了

    特点

    • 相比ConstantSizeRegionSplitPolicy，可以自适应大表、小表；
    • 在集群规模比较大的情况下，对大表的表现比较优秀
    • 对小表不友好，小表可能产生大量的小region，分散在各regionserver上
    • 小表达不到多次切分条件，导致每个split都很小，所以分散在各个regionServer上

  • SteppingSplitPolicy

    2.0版本默认切分策略

    ​ 相比 IncreasingToUpperBoundRegionSplitPolicy 简单了一些
    ​ region切分的阈值依然和待分裂region所属表在当前regionserver上的region个数有关系

    • 如果region个数等于1，切分阈值为flush size 128M * 2
    • 否则为MaxRegionFileSize。

    这种切分策略对于大集群中的大表、小表会比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不会再产生大量的小region，而是适可而止。

2.4、Compaction（合并）操作

Minor Compaction：

  • 指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次 Minor Compaction 的结果是更少并且更大的StoreFile。

Major Compaction：

  • 指将所有的StoreFile合并成一个StoreFile，这个过程会清理三类没有意义的数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，major compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发major compaction功能，改为手动在业务低峰期触发。
posted @ 2022-09-21 21:15  伍点  阅读(448)  评论(0)  编辑  收藏  举报