文章目录
- HBase的基本介绍
- HBASE的适用场景
- Hbase和Hadoop之间的关系
- Hbase与RDBMS的关系
- Hbase特征简要说明
- hbase的基础架构
- HBase的底层原理
- HBase的表数据模型
- Row Key
- 列族Column Family
- 列 Column
- 时间戳
- Cell存储数据的最小单位
- VersionNum
- hbase物理存储
- region的切分
- Memstore与storefile
- HLog(WAL log)
- 读写过程
- 读请求过程
- 写请求过程
- region的管理
- region server上线
- region server下线
- Hmaster的上线
- Hmaster下线
- HBase三个重要机制
- 1、flush机制
- 2、compact机制
- 3、split机制
- hbase预分区
- HBase的rowKey设计技巧
- 热点问题如何解决？？？？？
HBase的基本介绍
Hbase 是建立在hdfs之上的一个数据库，不支持join等SQL复杂操作.支持的数据类型：byte[]，依靠横向扩展
一个表可以有上十亿行，上百万列。
面向列(族)的存储和权限控制
对于为空(null)的列，并不占用存储空间，是一个稀疏表。
HBASE的适用场景
海量数据、精确查询、快速返回
海量数据：指的是数据量的背景
精确查询：业务场景
快速返回：是业务对时效性的要求
Hbase和Hadoop之间的关系
HDFS
海量数据存储，适合一次性扫描大量数据。
适合一次写入多次读取
不适合频繁更新的数据
HBASE
不适合一次性扫描大量数据。适用一次扫描少量数据。
适合多次写入多次读取
habse
支持数据更新
支持删除数据
Hbase与RDBMS的关系
RDBMS
支持SQL查询
支持事务
支持Join
HBASE
不支持SQL查询
不支持事务
不 支持Join
Hbase特征简要说明
1、 海量存储
Hbase适合存储PB级别的海量数据，在几十到百毫秒内返回数据。
2、列式存储
这里的列式存储其实说的是列族存储
列族理论上可以很多，但实际上建议不要超过6个
3、 极易扩展
处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）
hbase在最初设计的时候就考虑了扩展性。
4、高并发
这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多
5、稀疏
在列数据为空的情况下，是不会占用存储空间的。
hbase的基础架构
1、Client
2 ZOOKEEPER
3 Master 管理者
4 Regionserver 工作者
HBase的底层原理
详细架构
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ypPWJkVA-1576574636380)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576142410861.png)]](https://img-blog.csdnimg.cn/20191217172538749.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTc0OTAxMQ==,size_16,color_FFFFFF,t_70)
Client：
访问数据的入口，包含访问hbase的API接口,维护着一些cache来加快对hbase的访问
Zookeeper：
1 zookeeper的选举机制保证任何时候，集群中只有一个master
2 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master
3 存储Hbase的schema,
4 存贮所有Region的寻址入口
Master职责
1 为Region server分配region
2 负责region server的负载均衡
3 发现失效的region server并重新分配其上的region
4 处理schema更新请求
说明：Hmaster短时间下线，hbase集群依然可用，长时间不行。
Region server的作用
1、 Region server维护Master分配给它的region，处理对这些region的IO请求
2、Region server负责切分在运行过程中变得过大的region
HBase的表数据模型
![ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fFUrQdIf-1576574636380)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576221183717.png)]](https://img-blog.csdnimg.cn/20191217172600416.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTc0OTAxMQ==,size_16,color_FFFFFF,t_70)
Row Key
最大长度是 64KB，完全可以自行设计。Hbase会对表中的数据按照rowkey排序（字典序）
row的设计是最有技术含量的工作
列族Column Family
列族是表的schema的一部分，而列不是。（schema包含表名和列族）
每个列都所属于某一个列族。一个列族可以包含多个列。一个列族与列的关系是一对多。
列 Column
列族下面的具体列。
时间戳
标记一个数据的不同版本
时间戳可以由hbase(在数据写入时自动 )赋值，hbase支持工程师自己定义时间戳。
每个 cell中，不同版本的数据按照时间倒序排序
![ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WjF0yuYr-1576574636381)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576222927816.png)]](https://img-blog.csdnimg.cn/20191217172622802.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTc0OTAxMQ==,size_16,color_FFFFFF,t_70)
hbase本身提供数据回收机制
1、保存数据的最后n个版本
2、保存最近一段时间内的版本
Cell存储数据的最小单位
如何确定一个精确的数据
由{row key, column( = +
VersionNum
数据的版本号，默认值为系统时间戳。
hbase物理存储
整体结构
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9eFQWPQi-1576574636381)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576223773710.png)]](https://img-blog.csdnimg.cn/20191217172637748.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTc0OTAxMQ==,size_16,color_FFFFFF,t_70)
一个regionserver内部可以有多个region,这多个region可能来自多个表或一个表。一个region只能属于一个regionserver.
region的切分
region按大小分割的(默认10G)。每个表一开始只有一个region，随着数据的增加，一个region逐渐变大，达到10G，进行分裂，等分成两个region.
Hregion是Hbase中分布式存储和负载均衡的最小单元
HRegion由一个或者多个Store组成，每个store保存一个column family。每个Strore又由一个memStore和0至多个StoreFile组成
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VnyacU8y-1576574636382)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576224286253.png)]](https://img-blog.csdnimg.cn/20191217172645991.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTc0OTAxMQ==,size_16,color_FFFFFF,t_70)
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7y0jA6Vz-1576574636383)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576224437317.png)]](https://img-blog.csdnimg.cn/2019121717265818.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTc0OTAxMQ==,size_16,color_FFFFFF,t_70)
Memstore与storefile
一个region由多个store组成，每个store包含一个列族的所有数据 Store包括位于内存的memstore和位于硬盘的storefile
客户端检索数据时，先在memstore找，找不到再找storefile
HLog(WAL log)
每个Region Server维护一个Hlog,而不是每个Region一个.
Hlog的切分机制
1、当数据写入hlog以后，hbase发生异常。关闭当前的hlog文件
2、当日志的大小达到HDFS数据块的0.95倍的时候，关闭当前日志，生成新的日志
3、每隔一小时生成一个新的日志文件
读写过程
读请求过程
前提：什么是meta表？
meta表述hbase系统自带的一个表。里面存储了hbase用户表的元信息。
元信息为：meta表内记录一行数据是用户表一个region的start key 到endkey的范围。
meta表存在什么地方？
meta表存储在regionserver里。 具体存储在哪个regionserver里？zookeeper知道。
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-blriqNHs-1576574636383)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576229218108.png)]](https://img-blog.csdnimg.cn/20191217172715979.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTc0OTAxMQ==,size_16,color_FFFFFF,t_70)
1 到zookeeper询问meta表在哪
2 到meta所在的节点（regionserver）读取meta表的数据
3 找到region 获取region和regionserver的对应关系，直接到regionserver读取region数据
写请求过程
![ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2ZAF2Z7S-1576574636385)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576456747119.png)]](https://img-blog.csdnimg.cn/20191217172815946.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTc0OTAxMQ==,size_16,color_FFFFFF,t_70)
1、Client先访问zookeeper，找到Meta表，并获取Meta表元数据。确定当前将要写入的数据所对应的HRegion和HRegionServer服务器。
2、Client向该HRegionServer服务器发起写入数据请求。
2.1 Client先把数据写入到HLog，以防止数据丢失。
2.2 然后将数据写入到Memstore。
3、Memstore达到阈值，会把Memstore中的数据flush到Storefile中
4、当Storefile越来越多，达到一定数量时，会触发Compact合并操作，将多个小文件合并成一个大文件。
5、Storefile越来越大，Region也会越来越大，达到阈值后，会触发Split操作，变成两个文件。
说明：hbasez 支持数据修改（伪修改），实际上是相同rowkey数据的添加。hbase只显示最后一次的添加。
region的管理
region的分配过程
前提：一个region只能分配给一个region server
1、master记录了当前有哪些可用的region server。以及当前哪些region分配给了哪些region server，哪些region还没有分配。
2、当需要分配的新的region，并且有一个region server上有可用空间时，master就给这个region server发送一个装载请求，把region分配给这个region server。
3、region server得到请求后，就开始对此region提供服务。
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O7zwBk8B-1576574636385)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576457883580.png)]](https://img-blog.csdnimg.cn/20191217172834323.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTc0OTAxMQ==,size_16,color_FFFFFF,t_70)
region server上线
前提：master使用zookeeper来跟踪region server状态。
1、当某个region server启动时，首先在zookeeper上的/hbase/rs目录下建立代表自己的znode。
2、 master订阅了/hbase/rs目录上的变更消息，当/hbase/rs目录下的文件出现新增或删除操作时，master可以得到来自zookeeper的实时通知。因此一旦region server上线，master能马上得到消息。
region server下线
前提：master使用zookeeper来跟踪region server状态。
1、当region server下线时，它和zookeeper的会话断开。
2、zookeeper而自动释放代表这台server的文件上的独占锁（znode）
3、zookeeper将变化发送给master
4、master 将挂掉的region server的region分配给其它还活着的regionserver。
Hmaster的上线
前提：hbase集群中可以设置多个Hmaster，真正对外提供服务的只有一个
1 从zookeeper上获取唯一 一个代表active master的锁，用来阻止其它master成为真正的master。
2 扫描zookeeper上的/hbase/rs节点，获得当前可用的region server列表。
3 master和每个region server通信，获得当前已分配的region和region server的对应关系。
4 master扫描.META.表，计算得到当前还未分配的region，将他们放入待分配region列表。
问题一： 如何确定哪个master是真正的master
看谁获得到了active master的锁
问题二： master如何知道有哪些regionserver,
扫描zookeeper上的/hbase/rs节点
问题三:master 如何知道region与regionserver之间的对应关系
master和每个region server通信，regionserver反馈对应关系
问题四：master如何知道哪些region还未分配
master扫描.META.表，计算得到当前还未分配的region
Hmaster下线
master只维护表和region的元数据，不参与表数据IO的过程，所以master下线短时间内对整个hbase集群没有影响。
表的数据读写还可以正常进行。
Hmaster下线后的影响：
无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region 上下线，无法进行region的合并（region的split可以正常进行）
当hmaster下线后，启动Zookeeper的选举机制，选出新的Hmaster,新的Hmaster上线，执行上线流程。
HBase三个重要机制
1、flush机制
hbase.regionserver.global.memstore.size： 默认;堆大小的40%
regionServer的全局memstore的大小（多个CF的memstore-多个region），超过该大小会触发flush到磁盘的操作，会阻塞客户端读写
flush将所有的memstore全部flush.
hbase不建议配置过多列族：过多的列族会消耗大量的内存，同时数据在flush时消耗磁盘IO.
一个regionserver续写操作可用堆内存的80%，读取占用40% ，写入占用40%。这两个参数直接影响hbase读写性能。
什么时候触发flush
hbase.hregion.memstore.flush.size：默认：128M（单个region里memstore的缓存大小）
hbase.regionserver.optionalcacheflushinterval： 默认：1h
hbase.regionserver.global.memstore.size.lower.limit： 默认：堆大小 0.95倍
hbase.hregion.preclose.flush.size：默认为：5M 提前进行flush.(先flush一小部分，等后面数据达到阈值在flush后面的数据) 好处：比一次flush效率高
什么时候触发合并
hbase.hstore.compactionThreshold： 默认：3个 （flush文件的数量超过3个进行合并）
2、compact机制
默认3个
小的storeFile文件达到三个，合并成大的Storefile文件。
3、split机制
默认一个HFile达到10Gb的时候就会进行切分
hbase预分区
与分区的好处（优点）：
* 增加数据读写效率 : 数据分布在多台regionserver节点
* 负载均衡，防止数据倾斜 ： 当数据时离散的发送时，预分区可以解决数据倾斜
* 方便集群容灾调度region ： 分布在多个节点便于调度
* 优化Map数量 ：
原本数据分区（分region）的过程：
一个数据表原本只有一个region(分区)，随着数据量的增加，region慢慢变大，达到10G ，一个region变成两个region。当数据量还没有达到10G ，所有的数据全部写入一个region。一个region只能属于一个regionserver.
如何优化？方案： 将一个10G的数据打散，尽量多的，尽量均匀的分散到不同的regionserver上。
如何实现上述方案：预分区（region） 预先设置每个region 的startkey和endkey
命令分区：
create ‘staff’,‘info’,‘partition1’,SPLITS => [‘1000’,‘2000’,‘3000’,‘4000’]
API创建分区
后续讲API时创建
![ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ExsFOCCX-1576574636386)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576468136709.png)]](https://img-blog.csdnimg.cn/20191217172921247.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTc0OTAxMQ==,size_16,color_FFFFFF,t_70)
HBase的rowKey设计技巧
rowKey属性，最大64K,按照字典序排序，可以自定义
hbase数据的获取方式
1、通过rowkey直接查找
2、通过startkey endkey 范围查找
3、全表扫描
1 rowkey长度原则
最大64K,建议越短越好(在保证业务需求的前提下)，不要超过16个字节.
2 rowkey散列原则
建议将rowkey的高位(左边)作为散列字段， 低位（右边）放时间字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。
若不按照此原则：
让时间戳作为高位： 数据将按照时间的顺序进行存储。
热点问题：当有一点时间业务数据爆炸增长时，这个阶段的数据将存储在少数的节点上。
热点为题如何解决？？？？？
3 rowkey唯一原则
必须在设计上保证其唯一性，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。
热点问题如何解决？？？？？
原则：将分散的数据，放在rowkey的高位
1、哈希（随机数），将哈希值放在高位
2、反转：反转固定长度或者数字格式的数据（时间戳反转、手机号反转，订单号反转）
3、加盐：本质时是加随机数，并且放在高位。
2、通过startkey endkey 范围查找
3、全表扫描
1 rowkey长度原则
最大64K,建议越短越好(在保证业务需求的前提下)，不要超过16个字节.
2 rowkey散列原则
建议将rowkey的高位(左边)作为散列字段， 低位（右边）放时间字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。
若不按照此原则：
让时间戳作为高位： 数据将按照时间的顺序进行存储。
热点问题：当有一点时间业务数据爆炸增长时，这个阶段的数据将存储在少数的节点上。
热点为题如何解决？？？？？
3 rowkey唯一原则
必须在设计上保证其唯一性，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。
