Hbase基础概念

大家好，欢迎来到IT知识分享网。

Apache HBase™ 是 以 hdfs为数据存储的 ，一种分布式、可扩展的 NoSQL数据库。

一、HBase的数据模型

未解释:数据没有经过反序列化，不能被直接读取。

稀疏的:Hbase是一种NoSql数据库，不像Mysql这样的关系型数据库；Mysql在建表时就已经为数据预留好位置，即使该字段数值为空，这个位置也不能被占用；Hbase为<K,V>型数据库，不会存储空值。

1.HBase数据存储结构

HBase可以用于存储多种结构的数据，以 JSON为例，存储的数据原貌为：

{ 
     "row_key1":{ 
     "personal_info":{ 
     "name":"zhangshan", "city":"北京", "phone":"131" }, "office_info":{ 
     "tel":"010-", "address":"aimyon36" } }, "row_key11":{ 
     "personal_info":{ 
     "name":"lisi", "city":"上海", "phone":"132" }, "office_info":{ 
     "tel":"010-", "address":"aimyon36" } }, "row_key22".... } 

逻辑结构
物理存储结构
物理存储结构即为数据映射关系，而在概念视图的空单元格，底层实际根本不存储。

HBase数据存储依靠HDFS，HDFS存储数据具有一次写入，多次读取的特点，其不支持对数据进行修改，但是HBase存储数据为KV型，通过对相同的K再次写入，根据TimeStamp不可逆的特点，每次写入的数据的时间戳都比上一个数据的时间戳大，从而完成版本号的维护和数据的更新。

HBase底层使用KV数据类型存储，但是用户无需关心底层的存储逻辑，只需要了解其表结构的存储即可 ，其存储Key为(Row Key，Column Family，ColumnQualifier，Timestamp，Type)，因此在涉及表时RowKey的设定尤为重要

2.HBase存储概念

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

2）Table
类似于关系型数据库的表概念。不同的是，HBase 定义表时只需要声明列族即可，不需要声明具体的列。因为数据存储时稀疏的，所有往HBase 写入数据时，字段可以动态、按需指定。因此，和关系型数据库相比，HBase 能够轻松应对字段变更的场景。

3）Row
HBase 表中的每行数据都由一个RowKey 和多个Column（列）组成，数据是按照RowKey的字典顺序存储的，并且查询数据时只能根据RowKey 进行检索，所以RowKey 的设计十分重要。

4）Column
HBase 中的每个列都由Column Family(列族)和Column Qualifier（列值）进行限定，例如info：name，info：age。建表时，只需指明列族，而列限定符无需预先定义。

5）Time Stamp
用于标识数据的不同版本（version），每条数据写入时，系统会自动为其加上该字段，其值为写入HBase 的时间。

6）Cell
由{rowkey, column Family：column Qualifier, timestamp} 唯一确定的单元。cell 中的数据全部是字节码形式存贮。

7）Region
HBase按照Split策略将一张表横向切分成多个Region，每个Region实际上是一个文件夹，每个Region包含一定范围的Row Key，Region之间互不相交，从而实现表的分布式存储。

8）Store
HBase将每个Region按照列族进一步细分，分区Region中包含0或多个Store,一个Store包含一个列族。HBase中创建多个列族,则会形成多个Store,保存在Region中,如果Store数量大小过多,Region将会进行拆分,形成多个Region。

3.HBase基本架构

1）Master
实现类为HMaster，负责监控集群中所有的 RegionServer 实例。主要作用如下：
（1）管理元数据表格hbase:meta，接收用户对表格创建修改删除的命令并执行。
（2）监控region 是否需要进行负载均衡，故障转移和region 的拆分。
通过启动多个后台线程监控实现上述功能：

WAL预写日志技术，先将操作记录持久化，防止在操作过程中宕机，之后再进行实际操作。

2）Region Server
Region Server 实现类为HRegionServer，主要作用如下:
（1）负责数据cell 的处理，例如写入数据put，查询数据get 等
（2）拆分合并region 的实际执行者，有master 监控，有regionServer 执行。

RegionServer是HBase中的数据存储节点，它们负责处理客户端的读写请求。每个RegionServer通常包含多个Region，每个Region负责管理一张表的一部分数据。

3) Zookeeper
HBase通过 Zookeeper来做 master的高可用、 记录 RegionServer的 部署信息 、 并且存储
有 meta表的位置信息 。

HBase对于数据的读写操作时直接访问 Zookeeper的，在 2.3版本 推 出 Master Registry模式，客户端可以直接访问 master。 使用此功能，会加大对 master的压力，减轻对 Zookeeper的压力。

4) HDFS
HDFS为 Hbase提供最终的底层数据存储服务，同时为 HBase提供高 容错 的支持。

二、HBase Shell

1.DDL(Data Definition Language)

1.namespace

hbase:002:0> help 'create_namespace' 

2）创建命名空间 bigdata

hbase:003:0> create_namespace 'bigdata' 

3）查看所有的命名空间

hbase:004:0> list_namespace 

HBase中的namespace类似于mysql中的database

2.table

hbase:005:0> create 'bigdata:student', {NAME => 'info', VERSIONS => 5}, {NAME => 'msg'} 

hbase:009:0> create 'student1','info' 

HBase中建表需要指定列族，不需要具体指定列，列名和列值能够在添加数据时动态添加。

Versions说明:HBase底层使用HDFS存储，通过version控制数据时效，此处设置为5，那么在检索时，只能获取最新的5个版本。

hbase:013:0> list 

describe：查看一个表的详情

hbase:014:0> describe 'student1' 

hbase:017:0> disable 'student1' hbase:018:0> drop 'student1' 

在HBase中，执行drop命令后，表的数据会被移动到/hbase/archive目录下，并不会直接从HDFS删除。后台会有进程定期检查这些数据，如果这张表没有快照，则会删除数据。如果表有快照，则会保留数据。因此，在执行drop命令后，表数据不会立即删除，而是在后续进程中逐步删除。

2.DML（Data Manipulation Language）

1.写入数据

在 HBase 中如果想要写入数据，只能添加结构中最底层的 cell。可以手动写入时间戳指定 cell 的版本，推荐不写默认使用当前的系统时间。

hbase:019:0> put 'bigdata:student','1001','info:name','zhangsan' hbase:020:0> put 'bigdata:student','1001','info:name','lisi' hbase:021:0> put 'bigdata:student','1001','info:age','18' 

如果重复写入相同 rowKey，相同列的数据，会写入多个版本进行覆盖。

HBase底层使用HDFS对数据进行存储，HDFS只支持一次写入，多次读取，HBasemore吧使用timestamp维护一条数据的版本号。

2.读取数据

hbase:022:0> get 'bigdata:student','1001' hbase:023:0> get 'bigdata:student','1001' , { 
   COLUMN => 'info:name'} 

也可以修改读取 cell 的版本数，默认读取一个。最多能够读取当前列族设置的维护版本数。

hbase:024:0>get 'bigdata:student','1001' , { 
   COLUMN => 'info:name', VERSIONS => 6} 

scan 是扫描数据，能够读取多行数据，不建议扫描过多的数据，推荐使用 startRow 和stopRow 来控制读取的数据，默认范围左闭右开。

hbase:025:0> scan 'bigdata:student',{STARTROW => '1001',STOPROW => '1002'} 

row_key在Hbase中存储会按字典序进行排序

HBase scan操作类似于数据库系统中的游标，可以用于扫描HBase表中的数据。用户可以选择性地提供startRow和stopRow参数来定义扫描的起始行和终止行。如果没有显示地指定起始行，scan操作会从表的起始位置开始获取数据；当遇到了与设置的终止行相同或者大于终止行的行键时，scan操作会终止。

3.删除数据

hbase:026:0> delete 'bigdata:student','1001','info:name' 

deleteall 表示删除所有版本的数据，即为当前行当前列的多个 cell。（执行命令会标记数据为要删除，不会直接将数据彻底删除，删除数据只在特定时期清理磁盘时进行）

hbase:027:0> deleteall 'bigdata:student','1001','info:name' 

在HBase中，delete操作并不会立即将数据从磁盘上删除，而是将数据标记为删除状态。直到发生Major_compaction操作时，数据才会被真正从磁盘上删除。因此，delete操作后，数据不会立即删除，而是在后续的Major_compaction进程中删除。

三、HBase组成架构

1. Master架构

HMaster通过zookeeper与regionServer进行交流，保证消息的一致性。

元数据表 Meta 表格介绍：

全称 hbase：meta，只是在 list 命令中被过滤掉了，本质上和 HBase 的其他表格一样。

RowKey:([table],[region start key],[region id])

列族:列名
info：regioninfo 为 region 信息，存储一个 HRegionInfo 对象。
info：server 当前 region 所处的 RegionServer 信息，包含端口号。
info：serverstartcode 当前 region 被分到 RegionServer 的起始时间。

负载均衡器线程能够通过meta表中的列值info:server获取region的信息，能够通过修改meta表和修改数据完成负载均衡。

注意：在客户端对元数据进行操作的时候才会连接 master，如果对数据进行读写，直接连接
zookeeper 读取目录/hbase/meta-region-server 节点信息
，该节点会记录 meta 表格的位置。直接读取即可，不需要访问 master，这样可以减轻 master 的压力，相当于 master 专注 meta 表的
写操作，客户端可直接读取 meta 表。

2. RegionServer架构

HBase中存储的最小单位是Region，一个Region由一个或多个Store组成。

MemStore写缓存
写缓存，由于 HFile 中的数据要求是有序的，所以在接收Put请求后，数据是先存储在 MemStore 中，排好序后，等到达刷写时机才会刷写到 HFile，每次刷写都会形成一个新的 HFile，写入到对应的文件夹 store 中。

每个Store都有对应的一个MemStore，方便对存储的RowKey进行排序。

WAL预写日志
由于数据要经 MemStore 排序后才能刷写到 HFile，但把数据保存在内存中会有很高的概率导致数据丢失，为了解决这个问题，数据会先写在一个叫做 Write-Ahead logfile 的文件中，然后再写入MemStore 中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。

BlockCache读缓存
读缓存，每次查询出的数据会缓存在 BlockCache 中，方便下次查询。

四、HBase读写流程

1.写流程

（1）首先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server管理；

由于meta表的数据只在创建连接时获取，如果在获取连接后的一段时间内没有进行操作，HBase中可能由于发生Region的拆分或合并导致meta表数据变更；当获取连接后的一段时间后在进行操作请求时，有可能发生找不到对应Region的情况。

MemStore Flush

当属于Region中的一个MemStore刷写时，属于该Region的MenStore都会进行刷写

MemStore 刷写由多个线程控制，条件互相独立：
主要的刷写规则是控制刷写文件的大小，在每一个刷写线程中都会进行监控:

因为线程的周期性监控，有可能上一次监控时大小达到120M，还没有进行刷写，导致OOM

当 region server 中 memstore 的总大小达到高水位线

时，会同时阻止继续往所有的 memstore 写数据。

HFile(StoreFile)结构

HFile 是存储在 HDFS 上面每一个 store 文件夹下实际存储数据的文件。里面存储多种内容。包括数据本身（keyValue 键值对）、元数据记录、文件信息、数据索引、元数据索引和一个固定长度的尾部信息（记录文件的修改情况）。

键值对按照块大小（默认 64K）保存在文件中，数据索引按照块创建，块越多，索引越大。每一个 HFile 还会维护一个布隆过滤器（就像是一个很大的地图，文件中每有一种 key，就在对应的位置标记，读取时可以大致判断要 get 的 key 是否存在 HFile 中）。

可以通过 HBase 提供的命令来查看存储在 HDFS 上面的 HFile 元数据内容。

bin/hbase hfile -m -f /hbase/data/命名空间/表名/regionID/列族/HFile 名 

2.读流程

读缓存中缓存了数据的元信息，如果缓存命中就能够直接找到数据。

（3）不管读缓存中是否已经有数据了（可能已经过期了），都需要再次读取写缓存和store 中的文件。

读取写缓存是为了查找对应rowkey的最新版本，读取store是为了查找出数据的所有版本。

（4）最终将所有读取到的数据合并版本，按照 get 的要求返回即可。

1.合并读取数据优化

每次读取数据都需要读取三个位置，最后进行版本的合并。效率会非常低，所有系统需要对此优化。

布隆过滤器有可能发生哈希冲突，不同的rowkey可能具有相同的Hash值，导致扫描文件的发生。

2.StoreFile Compaction

由于 memstore 每次刷写都会生成一个新的 HFile，文件过多读取不方便，所以会进行文件的合并，清理掉过期和删除的数据，会进行 StoreFile Compaction。

Compaction 分为两种，分别是 Minor Compaction 和 Major Compaction。Minor Compaction会将临近的若干个(默认3个)较小的 HFile 合并成一个较大的 HFile，并清理掉部分过期和删除的数据，有系统使用一组参数自动控制，Major Compaction 会将一个 Store 下的所有的 HFile 合并成一个大 HFile，并且会清理掉所有过期和删除的数据，由参数hbase.hregion.majorcompaction控制，默认 7 天。

Minor Compaction 控制机制：
参与到小合并的文件需要通过参数计算得到，有效的参数有 5 个
（1）hbase.hstore.compaction.ratio（默认 1.2F）合并文件选择算法中使用的比率。
（2）hbase.hstore.compaction.min（默认 3） 为 Minor Compaction 的最少文件个数。
（3）hbase.hstore.compaction.max（默认 10） 为 Minor Compaction 最大文件个数。
（4）hbase.hstore.compaction.min.size（默认 128M）为单个 Hfile 文件大小最小值，小于这
个数会被合并。
（5）hbase.hstore.compaction.max.size（默认 Long.MAX_VALUE）为单个 Hfile 文件大小最大
值，高于这个数不会被合并。

小合并机制为拉取整个 store 中的所有文件，做成一个集合。之后按照从旧到新的顺序遍历。
判断条件为：
① 过小合并，过大不合并
② 文件大小/ hbase.hstore.compaction.ratio < (剩余文件大小和) 则参与压缩。所有把比值设置过大，如 10 会最终合并为 1 个特别大的文件，相反设置为 0.4，会最终产生 4 个 storeFile。不建议修改默认值
③ 满足压缩条件的文件个数达不到个数要求（3 <= count <= 10）则不压缩。

3.Region Split

Region 切分分为两种，创建表格时候的预分区即自定义分区，同时系统默认还会启动一个切分规则，避免单个 Region 中的数据量太大。

预分区（自定义分区）
每一个 region 维护着 startRow 与 endRowKey，如果加入的数据符合某个 region 维护的rowKey 范围，则该数据交给这个 region 维护。那么依照这个原则，我们可以将数据所要投放的分区提前大致的规划好，以提高 HBase 性能。
1）手动设定预分区

create 'staff1','info', SPLITS => ['1000','2000','3000','4000'] 

2）生成 16 进制序列预分区

create 'staff2','info',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'} 

aaaa bbbb cccc dddd 

（2）然后执行：

create 'staff3', 'info',SPLITS_FILE => 'splits.txt' 

系统拆分
Region 的拆分是由 HRegionServer 完成的，在操作之前需要通过 ZK 汇报 master，修改对应的 Meta 表信息添加两列 info：splitA 和 info：splitB 信息。之后需要操作 HDFS 上面对应的文件，按照拆分后的 Region 范围进行标记区分，实际操作为创建文件引用，不会挪动数据。刚完成拆分的时候，两个 Region 都由原先的 RegionServer 管理。之后汇报给 Master，由Master将修改后的信息写入到Meta表中。等待下一次触发负载均衡机制，才会修改Region的管理服务者，而数据要等到下一次压缩时，才会实际进行移动。

不管是否使用预分区，系统都会默认启动一套 Region 拆分规则。不同版本的拆分规则有差别。系统拆分策略的父类为 RegionSplitPolicy。

0.94 版本之前 => ConstantSizeRegionSplitPolicy
（ 1 ） 当 1 个 region 中 的 某 个 Store 下 所 有 StoreFile 的 总 大 小 超 过hbase.hregion.max.filesize （10G），该 Region 就会进行拆分。0.94 版本之后，2.0 版本之前 => IncreasingToUpperBoundRegionSplitPolicy
（ 2 ） 当 1 个 region 中 的 某 个 Store 下 所 有 StoreFile 的 总 大 小 超 过
Min(initialSizeR^3 ,hbase.hregion.max.filesize”)，该 Region 就会进行拆分。其中 initialSize 的
默认值为 2
hbase.hregion.memstore.flush.size，R 为当前 Region Server 中属于该 Table 的
Region 个数（0.94 版本之后）。

2.0 版本之后 => SteppingSplitPolicy
（3）Hbase 2.0 引入了新的 split 策略：如果当前 RegionServer 上该表只有一个 Region，
按照 2 * hbase.hregion.memstore.flush.size 分裂，否则按照 hbase.hregion.max.filesize 分裂。

五、布隆过滤器

布隆过滤器是一种用于快速查询集合中元素是否存在的数据结构。它可以被看作是由一个很长的二进制向量和一系列随机映射函数组成。这个向量被初始化为全0，然后使用一系列哈希函数把输入数据映射到向量中的某个位置，并将这个位置的元素置为1。

当要查询一个元素是否在集合中时，同样将这个元素输入到哈希函数中，然后检查对应的k个位置的元素。如果有任意一个位置的元素为0，则表明该元素一定不在集合中。如果所有位置的元素均为1，则表明该集合有较大的可能性在集合中。但需要注意的是，一个元素被置为1有可能会受到其他元素的影响，这就是误判。

布隆过滤器的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。因为布隆过滤器只能记录元素是否存在，不能准确地记录元素的值，因此存在一定的误识别率。同时，由于布隆过滤器中的元素不能被删除，因此当集合中的元素被删除后，布隆过滤器中的位向量将无法更新，导致查询结果不准确。

布隆过滤器主要适用于大量数据的去重和检验，而HashSet等数据结构适合中小量数据的去重和检验。