Hbase基础

• Hbase基础
  • Hbase定义
  • 行存储 v s 列存储
  • Hbase数据模型
  • Hbase物理模型
  • Hbase系统架构
  • Hbase的容错
  • Hbase特殊的表
  • 合并
  • Hbase的Compaction和Split

Hbase定义

• HBase是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的BigTable建模，实现的编程语言为 Java。
• 是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统之上，因此可以容错地存储海量稀疏的数据

行存储 v s 列存储

• 行存储：

  – 优点：写入一次性完成，保持数据完整性

  – 缺点：数据读取过程中产生冗余数据，若有少量数据可以忽略

• 列存储

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

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

Hbase数据模型

• RowKey：是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要。
• Column Family：列族，拥有一个名称(string)，包含一个或者多个相关列
• Column：属于某一个columnfamily，familyName:columnName，每条记录可动态添加
• Version Number：类型为Long，默认值是系统时间戳，可由用户自定义
• Value(Cell)：Byte array

Hbase物理模型

• Hbase一张表由一个或多个Hregion(Region)组成
• 记录之间按照Row Key的字典序排列

  如图

  

• Region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。

  如图:

  

• Region配置，默认大小10GB，如果在没有自定义配置的情况下，超过10GB就会自动分裂
• 当对某一行进行修改时，会锁定一整行数据，也就是对这一样进行加锁，当对某一行的某一个字段进行读操作时，其他字段也不允许被操作，
• 一个RegionServer可以包含多个Region，内部管理了一系列的HRegion

  如图：

  

• saf

  表 -> HTable

  ? 按RowKey范围分的Region-> HRegion ->Region Servers

  ? HRegion按列族（Column Family） ->多个HStore

  ? HStore -> memstore(默认128M，超过128M就会自动往磁盘上split) + HFiles(均为有序的KV)

  ? HFiles -> HDFS

• HRegion是Hbase中分布式存储和负载均衡的最小单元，最小单元就表示不同的

  Hregion可以分布在不同的HRegion server上，但一个Hregion是不会拆分到

  多个server上的

  如图：

  

• HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元

  如图：

  

Hbase系统架构

• Client

  – 访问Hbase的接口，并维护Cache加速Region Server的访问

• Master(主)

  – 负载均衡，分配Region到RegionServer

  – DLL,增删查改 -> table,cf,namespace

  – 类似namenode,管理一些元数据

  – ACL权限控制

• HRegionServer(从)
  1. 维护Region，负责Region的IO请求
  2. 管理和存放本地的HRegion
  3. 读写HDFS，提供IO操作
  4. 本地化：HRegion的数据尽量和数据所属的DataNode在一起，但是这个本地化不能够总是满足和实现
• Zookeeper

  – 保证集群中只有一个Master

  – 存储所有Region的入口（ROOT）地址

  – 实时监控Region Server的上下线信息，并通知Master

Hbase的容错

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

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

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

• Master容错：
• Zookeeper重新选择一个新的Master
  1. 无Master过程中，数据读取仍照常进行；
  2. 无master过程中，region切分、负载均衡等无法进行
• Region Server容错：
• 定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer
• Zookeeper容错：
• Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例
• WAL(Write-Ahead-Log)预写

  日志

• 是Hbase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志
• 在每次Put、 Delete等一条记录时，首先将其数据写入到RegionServer对应的HLog文

  件的过程

• 客户端往RegionServer端提交数据的时候，会写WAL日志，只有当WAL日志写成功以后，客户端才会被告诉提交数据成功，如果写WAL失败会告知客户端提交失败
• 数据落地的过程
• 在一个RegionServer上的所有的Region都共享一个HLog，一次数据的提交是先写WAL，写入成功后，再写memstore。当memstore值到达一定阈值，就会形成一个个StoreFile（理解为HFile格式的封装，本质上还是以HFile的形式存储的）

Hbase特殊的表

• ROOT- 表和.META.表是两个比较特殊的表
• .META.记录了用户表的Region信息，.META.可以有多个regoin。
• -ROOT-记录了.META.表的Region信息，-ROOT-只有一个region，Zookeeper中记录了-ROOT-表的location
• Hbase 0.96之后去掉了-ROOT- 表，因为：

1. 三次请求才能直到用户Table真正所在的位置也是性能低下的
2. 即使去掉-ROOT- Table，也还可以支持2^17(131072)个Hregion，对于集群来说，存储空间也足够

• 所以目前流程为：

1. 从ZooKeeper(/hbase/meta-region-server)中获取hbase:meta的位置（HRegionServer的位置），缓存该位置信息【没有图中绿色的部分】
2. 从HRegionServer中查询用户Table对应请求的RowKey所在的HRegionServer，缓存该位置信息
3. 从查询到HRegionServer中读取Row。

合并

• region的合并：尽量把小的region合并到一个大的，理想情况下，每个region的请求量是一样的(不能保证数据量一样)
• storefile的合并
• 如果Hbase当做MapReduce的输入源的话，一个map对应一个region

Hbase的Compaction和Split

• 问题：随着写入不断增多，flush次数不断增多，Hfile文件越来越多,所以Hbase需要对这些文件进行合并
• Compaction会从一个region的一个store中选择一些hfile文件进行合并。合并说来原理很简单，先从这些待合并的数据文件中读出KeyValues，再按照由小到大排列后写入一个新的文件中。之后，这个新生成的文件就会取代之前待合并的所有文件对外提供服务
• Minor Compaction：是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次Minor Compaction的结果是更少并且更大的StoreFile
• Major Compaction：是指将所有的StoreFile合并成一个StoreFile，这个过程还会清理三类无意义数据：被删除的数据、 TTL过期数据、版本号超过设定版本号的数据
• Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响
• 因此线上业务都会将关闭自动触发Major Compaction功能，改为手动在业务低峰期触发
• Compaction本质：使用短时间的IO消耗以及带宽消耗换取后续查询的低延迟
• compact的速度远远跟不上HFile生成的速度，这样就会使HFile的数量会越来越多，导致读性能急剧下降。为了避免这种情况，在HFile的数量过多的时候会限制写请求的速度
• Split
• 当一个Region太大时，将其分裂成两个Region
• Split和Major Compaction可以手动或者自动做

此笔记仅用于作者记录复习使用，如有错误地方欢迎留言指正，作者感激不尽，如有转载请指明出处

原文地址：https://www.cnblogs.com/screen/p/9069606.html