Hbase学习笔记

1 HBase介绍

(1) HBase是什么

HBase是一个开源的非关系型分布式、实时数据库(Nosql)，运行于HDFS文件系统之上，因此key容错地存储海量稀疏的数据。

海量稀疏就是说不能保证每一个key它的列都有value。

关系型数据库：mysql、oracle

非关系型数据库：Nosql

(2) HBase特点

大量数据存储在HDFS，少量在内存上

特点：高可靠、高并发读写、面向列、可伸缩、易构建

面向列：数据库的存储来说它分两种，一个是行存储，一个是列存储

(3) 行存储：传统关系型数据库

• 优点:写入一次性完成，保持数据完整性(一步写完一整行)
• 缺点:数据读取过程中产生冗余数据，若有少量数据可以忽略

比如：下面图片，要去只是读取name字段的内容，但是读取的时候是会全部字段读取的，只是过滤出name的内容输出，优点是写，缺点是读。

(4) 列存储：Nosql数据库

优点：读取过程不会产生冗余数据，特别适合对数据完整性要去不高的大数据领域

缺点：写入效率差，保证数据完整性方面差

比如下图，查找name的数据，就是直接查找name就行了，不会再查找其他的，不会产生冗余数据；稀疏数据，不能保证每一个key它的列都有value，所以是保证数据完整性方面差。

(5) Hbase优势：海量数据存储、快速随机访问、大量写操作的应用

(6) Hbase应用场景：互联网搜索引擎数据存储、海量数据写入、消息中心、内容服务系统、大表复杂&多维度索引、大批量数据读取

应用：主要就是把非结构化数据转换成结构化数据，通过Hbase数据库进行结构化维护

2 数据模型

(1) 组件

Rowkey：是Byte array，是表中每条记录的”主键”，方便快速查找。

时间戳：新修改的排前面，每一个时间戳背后都代表一个版本，具体存了多少版本可通过配置设置。

Column Family：列族，拥有一个名称(string)，包含一个或者多个相关列。

Column：属于一个column family，familyName:columnName，每条记录可以动态添加。

Version Number：类型为Long。默认值是系统时间戳，可由用户自定义。

Value(Cell): Byte array 。

(2) 二分法目的就是为了检索

(3) Hbase Schema设计的时候要指定好CF列族，一个CF里面包含多个columnqualifier，每一个CF代表的属性是不一样的。

比如下图：Rowkey=Itemid，有两个CF，一个是物品属性，一个是用户行为

(4) rowkey按顺序排序，时间戳倒序排序

(5) 修过记录，不会在原来记录修改，是会复制这条，在复制的记录上修改，这样可以回头看这条数据的所有记录。

(6) 三维有序：rowkey(主键)，列(columnfamily、columnqualifier)，时间戳

如：{rowkey =>{family => {qualifier => {version}}}} ===》a:cf1:bar:13456321:9

3 物理模型

(1) 物理模型支撑数据模型的实现

(2) Hbase一张表由一个或多个Hregion(区域)组成，region是按行划分的，

记录之间按照Row Key的字典，Hbase相当于MR里面的Partition，相同的key肯定会在一个region上。

(3) Region是对应Table的一个Region，然后HRegion相当于是对应Region的封装，Region是逻辑概念，HRegion是物理概念。每个逻辑的region背后都是有HRgion去封装的。

(4) 一个用户的表格它可以分出多个区域，然后每一个region包含了很多的行，也就是记录，region内部rowkey是按顺序排序的，region与region之间也是按照这种全局排序的。

(5) Redion按大小分隔的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阈值的时候，Hregion就会等分为两个新的Hregion。当table中的行越来越多，就会有更多的Hregion。

(6) Region有默认大小，10G，数据超过10G，就会分裂为小region，Region是HBase中数据分布的最小单位。

(7) Hbase的锁，是行粒度，行锁定的(读写行不能同步)

(8) region类似一个节点，所在的机器名字就叫regionServer，一个region仅属于一台机器，如果一个regionserver挂了，里面的数据会被其他的regionserver接管。

(9) Hdfs中，为了数据平衡，一个datanode挂了，里面的block也会被其他的datanode接管，这里regionserver也是一样的。

(10)一个region只能属于一个regionserver，但一个regionserver是可以拥有多个region(不一定来自同一个table)

(11)regionServer主要负责用户的IO(读写)请求，然后与HDFS进行交互，机器上有一个进程:HRegionServer，一个HRegionServer内部管理了一系列的HRegion对象

(12)表—》HTable：在Hbase中，一个数据表叫做HTable

(13)按RowKey范围分的Region—》Hegion—》RegionServers

(14)HRegionServer里面存储很多HRegion，HRegion有很多HStore组成，HStore是HBase核心存储单元，HStore内部由两部分组成：Memstore(内存区)和StoreFile(真正落地磁盘的数据)，这两部分均是有序kv的，即按key进行排序的，StoreFile本质是HFive，HFive直接落地到HDFS上(datanode)

(15)Mapreduce中map阶段，数据先读到内存，当数据达到80%，它就会自动锁住然后把这80%的数据进行从内存溢写到磁盘。

(16)Memstore是一块内存，主要负责写入数据，如果当达到Memstore的阈值(128M)，可改，会将内存信息Flush成为一个StoreFile，StoreFile存储在磁盘上。

(17)HRgion按列族(Column Family)—》多个HStore，一个列族就代表一个文件

(18)HStore对应着table中的Column Family，无论CF内部内部有多少数据，都会创建一个HStore，相同属性的数据要放到相同的CF中，避免一次访问，访问多个HStore，性能底下。

(19)HRgion是Hbase中分布式存储和负载均衡的最小单元，但并不是存储的最小单元，最小单元就表示不同的Hrgion可以分布在不同的HRgion server上。但一个Hregion是不好拆分到多个server上的。

(20)往HStore写数据是先往memStor去写，随着数据增多，memStor不断往外输出，然后变成一个个Storefile，Storefile多了的话需要一个合并机制。

(21)BlockCache是读缓存，类似像memStor一样的内存区域，是一个整体的缓冲区，加快读取。

(22)memstor是写缓存，它是在每一个HStore里面，HStore里面都有一个Memchche。

(23)RegionServer---Rgion----HRegion----HStore---MemStore-----StoreFile---HFive。

4 系统架构

(1) Hbase整个系统架构分为四部分：Client、Master、Zookeeper、RegionServer

(2) Client：访问Hbase的接口，并且有一个Cache，维护Cache加速RegionServer的访问

(3) Hdfs中，访问block，要先访问namedoce，从而得知block是在哪个datanode上，这个读表也是一样的，要先知道在哪一个regionserver，进而知道是哪一个region，才能去读key，Cache缓存中就有这些映射关系。没有Cache的话就需要去找zookeeper中寻址。

(4) Master

1. 负载均衡：管理和分配HRgion
2. DDL：就是增删改操作，对象是table，cf，namespace
3. 类似namenode，管理元数据，就是table的结构
4. ACL权限控制，就比如多个部门使用同一个HBase，不同部门权限不同

(5) Region Server

1. 管理和存放本地HRgion，即自己管理自己的HRgion
2. 提供了接口，读写HDFS来管理table中的数据
3. 本地化：跟mapreduce一样，数据不移动，计算框架移动，数据迁移需要时间，也怕损坏或丢失，一个HRegionServer可以存放1000个HRegion，尽可能保证HRegion的数据和datanode在一起，目的为了实现本地化，加快数据的读写。但是这个本地化不能总是满足和实现，因为region是会分裂不断移动的，只有当region分裂后的小region合并后，才能继续本地化。

(6) Zookeeper：协同和服务于分布式应用程序的一个服务

1. 保护集群只有一个Master(运行状态)
2. 存储所有Region的入口(ROOT)地址(新版本已经取消)
3. 实时监控Region Server的上下线信息，并通知Master，监控方式：心跳

(7) HBase里面可以有多个Master，但是真正服务的时候，只有一个Master来服务，数据存储在了zookeeper，Master挂了的话，不影响数据读取，但是会影响数据写入，进入影响到region的分裂，导致region越来越大，master也就无法实现负载均衡这一概念

(8) HDFS上的数据是真数据，而zookeeper存的数据是元数据

5 容错

(1) Zookeeper容错：zookeeper是一个可靠性地服务，一般配置3或5个zookeeper实例

(2) Zookeeper协调集群所有节点的共享信息，在HMaster和HregionServer连接到ZooKeeper后，创建Ephemeral(临时)节点，并使用Heartbeat机制维持这个节点的存活状态，如果某个Ephemeral节点实效，则HMaster会收到通知，并做相应的处理

(3) 临时节点特点/作用：监控和心跳，通过临时节点进行一个监控容错

(4) zookeeper是文件目录树结构的，维护了很多节点，每个节点可以存储一定的数据，节点路径是绝对路径的方式，节点的数据都是加密的，二进制形式。

(5) 除了HDFS存储信息，HBase还在Zookeeper中存储信息，其中的znode信息：

1. /hbase/root-region-server,Rootregion的位置
2. /hbase/table/-ROOT-，根元数据信息
3. /hbase/table/.META.，元数据信息
4. /hbase/master，当选的master
5. /hbase/backup-master，备选的Master
6. /hbase/rs，RegionServer的信息
7. /hbase/unassigned，未分配的Region

(6) Master容错

1. master挂了，zookeeper会重新选一个新的master
2. 无master过程中，不影响数据读取，但会影响数据写入，进而影响region分裂，region切分，负载均衡也就无法进行

(7) Region Server容错

定时向zookeeper汇报心跳，如果一旦时机内出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割，并派送给新的RegionServer(怎么分配？)

(8) 当RegionServer挂了，它里面运行的Region会迁移到新的节点上去，依赖的是预写功能

(9) WAL(Write-Ahead-Log)预写日志

1. 是Hbase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志
2. 在每次put、delete等一条记录时，首先将其数据写入到regionserver对应的Hlog文件的过程

(10)对数据操作的第一步是要把这个操作写到一个日志中去，这个日志不属于任何一个regionserver，这个日志是共享的数据区域，每一个regionserver都可以读这个HLog，这个数据区域存在HDFS上。

(11)当regionserver挂了，数据操作日志还在HDFS上，重新读取日志即可恢复数据，像mysql日志一样。

(12)客户端往RegionServer端提交数据的时候，会先写WAL日志，只有当WAL日志写成功以后，客户端才会被告诉提交数据成功，如果写WAL失败会告知客户端提交失败。后台数据可通过异步方式更新，跟HDFS写流程一样，写成功一份，即是数据提交成功，其他的异步来获取这份写成功的数据。

(13)数据落地过程

在一个regionserver上的所有的region都共享一个HLog，一次数据的提交是先写WAL，写入成功，再写memstore。当memstore值到达一定阈值(128M)，就会形成一个个StoreFile(理解为HFile格式的封装，本质上还是以HFile的形式存储的)

6 操作

(1) Hbase基础操作跟普通数据块是一样的，有PUT(写)，GET(读)，DELETE等，但这些只是针对单行记录来说的，如果需要多行操作，只能通过SCAN命令

(2) 扫描一段范围的Rowkey使用SCAN，由于Rowkey有序而让Scan变得有效

(3) GET和SCAN支持各种Filter(过滤)，将逻辑推给RegionServer，以此为基础可以实现复杂的查询，如where，时间戳

(4) 支持一些原子操作，INCREMENT、APPEND、CheckAnd{put,delete}

(5) 在单行上可以加锁，具备强一致性，这能满足很多应用的需求。强一致性是说能保证同一时间内数据不会出现多人同写，数据混乱的状态。

7 数据映射

(1) ROOT表和META表是两个比较特殊的表

1. META表记录了用户表的Region信息，里面可以有多个region，还存储有元数据
2. ROOT记录了META表的Region信息，ROOT只有一个region，zookeeper中记录了ROOT表的location

(2) 数据映射需要三步

1. 从zookeeper节点获取ROOT的地址，到达ROOT
2. ROOT表再去META表，拿取用户表的Region信息和元数据
3. META中的元数据记录了数据所在的RegionServer

(3) 但是Hbase0.96之后就去掉了ROOT表，因为：

1. 三次请求才能获取用户table真正所在位置，效率低
2. 去掉ROOT-Table，也还可以支持2^17(131072)个Hregion，对于集群阿里说，存储空间也足够

(4) 目前流程为：

1. 第一：从Zookeeper(/hbase/meta-region-server)找到META表

META表不会分裂，里面只存储了用户的元数据

1. 第二：从META的元数据中查找要访问的table表(应用层上的应用表)

即是映射了数据具体在哪一个HRegionServer上

1. 根据Rowkey去定位到相应数据

8 写流程--寻址

(1) 上面的映射流程就是寻址流程

(2) 从这个过程中，可以发现客户会缓存这些位置信息，然而第二步它只是缓存当前RowKey对应的HRegion的位置，因而如果下一个要查的Rowkey不在同一个HRegion中，则需要继续查询META所在的HRegion，然而随着时间的推移，客户端缓存的位置信息越来越多，以至于不需要再次查找hbase:meta Table的信息，除非某个HRegion因为宕机或Split被移动，此时需要重新查询并且更新缓存。

可以说是客户端缓存越来越多，可以自己去找了，不需要meta

(3) META表存储了所有用户HRegion的位置信息，然后这个HRegion位置信息技术你要访问的具体的那个应用表的地址。

9 写流程--写入

(1) Client 也是先访问 zookeeper，找到 Meta 表，并获取 Meta 表信息。

(2) 确定当前将要写入的数据所对应的RegionServer 服务器和Region。

(3) Client 向该 RegionServer服务器发起写入数据请求，然后RegionServer 收到请求并响应。

(4) Client 先把数据写入到 HLog，以防止数据丢失。

(5) 然后将数据写入到Memstore。

(6) 如果Hlog 和Memstore 均写入成功，则这条数据写入成功。在此过程中，如果Memstore达到阈值，会把Memstore 中的数据flush 到StoreFile 中。

(7) 当Storefile 越来越多，会触发Compact 合并操作，把过多的Storefile 合并成一个大的Storefile。当Storefile 越来越大，Region 也会越来越大，达到阈值后，会触发Split 操作，将Region 一分为二。

尖叫提示：因为内存空间是有限的，所以说溢写过程必定伴随着大量的小文件产生。

10 读流程

(1) HRegionServer 保存着 meta 表以及表数据，要访问表数据，首先 Client 先去访问zookeeper，从zookeeper 里面获取meta 表所在的位置信息，即找到这个meta 表在哪个HRegionServer 上保存着。

(2) 接着Client 通过刚才获取到的HRegionServer 的IP 来访问Meta 表所在的HRegionServer，从而读取到Meta，进而获取到Meta 表中存放的元数据。

(3) Client 通过元数据中存储的信息，访问对应的 HRegionServer，然后扫描所在HRegionServer 的Memstore 和Storefile 来查询数据。

(4) 最后HRegionServer 把查询到的数据响应给Client。

11 Compaction

(1) 问题：随着写入不断增多，flush次数不断增多，Hfile文件越来越多，所以HBase需要对这些文件进行合并；

(2) Compaction会从一个region的一个store中选择一些hfile文件进行合并。合并原理很简单，从这些待合并的数据文件中读出KeyValues，再按照由小到大排列后写入一个新的文件中。之后，这个新生成的文件就会取代之前待合并的所有文件对外提供服务；

(3) Minor Compaction：是指选取一些小的、相邻的StoreFile将它们合并成一个更大的StoreFile，在这个过程中不会处理已经deleted或expired的cell。一次MinorCompaction的结果是更少并且更大的StoreFile；

(4) Major Compaction：是指将所有的StoreFile合并成一个StoreFile，这个过程还会清理三类无意义数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据；

(5) Major Compaction时间会持续比较长，整个过程会消耗大量系统资源。对上层业务有比较大的影响。因此线上业务都会将关闭自动触发Major Compaction功能，改为手动在业务低峰期触发；

(6) Compaction本质：使用短时间的IO消耗以及带宽消耗换取后续查询的低延迟；

(7) compact的速度远远跟不上HFile生成的速度，这样就会使HFile的数量越来越多，导致性能急剧下降。为了避免这种情况，在HFile的数量过多的时候会限制写请求的速度；

(8)合并主要有两个：region合并和storefile合并。

12 Split

(1) 当一个Region太大时，将其分裂成两个Region；

(2) Split和MajorCompaction可以手动或者自动做。

13 Hbase表结构设计

(1) Row key的设计，region里按字母顺序进行排序(byte排序)

Itemid 0-->9999，策略：逆序、hash(md5、crc32)

假设rowkey=ip地址，逆序存储会很有效

目的：Weight了减少数据倾斜。

192.168.0.1--->1.0.861.291

(2) CF的设计：尽量少，建议CF数据量1-2个，尽量1个

flush和region合并的时候，触发基本单位是region级别的，

其实memstore里面通常仅存有少量的数据，是不需要flush的。