我的笔记-hbase

最新推荐文章于 2024-06-13 11:24:43 发布

qiayyii

最新推荐文章于 2024-06-13 11:24:43 发布

阅读量44

点赞数

文章标签：笔记 hbase 数据库

本文链接：https://blog.csdn.net/qq_58073842/article/details/134030402

版权

hbase笔记

hbase数据库特点：

* HBase - Hadoop Database,是一个高可靠性，高性能，面向列，可伸缩（传统数据库很难实现横向扩展，纵向扩展的空间也比较有限，而hbase就是为了解决这些问题而开发的，能够轻易的通过再集群中增加或者减少硬件数量来实现性能的伸缩），实时读写的分布式NoSQL数据库
* 利用Hadoop HDFS 作为文件存储系统，利用Hadoop MapReduce来处理海量数据，利用zookeeper作为其分布式协同服务
* 主要用来存储非结构化和半结构化的松散数据
* 逻辑上，Hbase的数据模型同关系型数据库很类似，数据存储再一张表上，有行有列，但从hbase的底层物理存储结构（k-v）来看，hbase更像是一个multi-dimensional map

hbase名词概念

RowKey
- 唯一标识一行数据
- 可以通过rowkey获取一行数据
- rowkey按照字典顺序排序
- rowkey只能存储64k的字节数据 10-100byte
Column Family（列族）和 qualifier（列）
- hbase表中的每个列都归属某个列族，创建表时，至少给定一个列族信息，表创建好了之后可以继续增加列族
- 列名以列族作为前缀，每个‘列族’都可以有多个列成员，新的列成员可以按需添加
- 权限控制，存储以及调优都是在列族层面进行的
- hbase把同一列族里面的数据存储在同一目录下，由几个文件保存
timestamp
- 在HBase每个cell存储单元对同一份数据有多个版本，根据唯一的时间戳来区分每个版本之间的差异，不同版本的数据按照时间倒序排序，最新的数据版本排在最前面。
- 时间戳的类型是 64位整型。
- 时间戳可以由HBase(在数据写入时自动)赋值，此时时间戳是精确到毫秒的当前系统时间
- 时间戳也可以由客户显式赋值，如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。
cell单元格
- 由行和列的坐标交叉决定。
- 单元格是有版本的。
- 单元格的内容是未解析的字节数组。
- 每个cell都有各种版本的数据，所以当update一个cell中的数据的时候，其实是网cell的末尾追加一个版本的数据，而update之前的数据依然是存在的
- 每个family都可以设置每个cell要保留的版本数量，默认是3，由VERSIONS决定

HBase系统架构

在这里插入图片描述

主从架构
- 主节点为Hmaster
- 从节点为HRegionServer
web 访问端口 16010
master
- 为Region server分配region
- 负责Region server的负载均衡
- 发现失效的Region server并重新分配其上面的region
- 管理用户对table的增删改操作
  - 对元数据的管理，和hadoop非常相似，管理在Hlog中
RegionServer
- Region server是负责维护region的，处理对这些region的IO请求
- Region server负责切分在运行过程中变得过大的region
Region
- HBase自动把表水平划分成多个区域(region)，每个region会保存一个表里面某段连续的数据；每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，region就会等分会两个新的region（裂变）。
- 当table中的行不断增多，就会有越来越多的region。这样一张完整的表被保存在多个Regionserver 上。
Memstore 与 storefile
- 一个region由多个store组成，**一个store对应一个CF（列族)**store包括位于内存中的memstore和位于磁盘的storefile , 写操作先写入memstore，当memstore中的数据达到某个阈值，hregionserver会启动flashcache进程写入storefile，每次写入形成单独的一个storefile
- 当storefile文件的数量增长到一定阈值后，系统会进行合并（minor、major compaction），在合并过程中会进行版本合并和删除工作（majar），形成更大的storefile
- 当一个region所有storefile的大小和数量超过一定阈值后，会把当前的region分割为两个，并由hmaster分配到相应的regionserver服务器，实现负载均衡
- 客户端检索数据，先在memstore找，找不到再找storefile

HRegion是HBase中分布式存储和负载均衡的最小单元。最小单元就表示不同的HRegion可以分布在不同的 HRegion server上。
HRegion由一个或者多个Store组成，每个store保存一个columns family。
每个Strore又由一个memStore和0至多个StoreFile组成。如图：StoreFile以HFile格式保存在HDFS上。

在这里插入图片描述

读写流程

写流程

在这里插入图片描述

1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。 
2）访问对应的 Region Server，获取 hbase:meta 表，根据写请求的 namespace:table/rowkey，查询出目标数据所在的 Region Server的Region信息,并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。  
3）向Region Server发送写操作
4）将数据顺序写入（追加）到 WAL
5）将数据写入对应的 MemStore，数据会在 MemStore 进行排序
6）向客户端发送 ack响应信息
7）等达到 MemStore 的刷写时机后，将数据刷写到 HFile。

读流程

在这里插入图片描述

1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。
2）访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。
3）与目标 Region Server 进行通讯
4）分别在 Block Cache（读缓存），MemStore 和 Store File（HFile）中查询目标数据，并将查到的所有数据进行合并。 
5）将从文件中查询到的数据块（Block，HFile 数据存储单元，默认大小为 64KB）缓存到Block Cache。
6）将合并后的最终结果返回给客户端。

hbase查询快的原因

布隆过滤器

通过使用布隆过滤器来过滤出要查询的数据可能在哪些hfile中，虽然布隆过滤器存在一定的误差率，但是可以确定哪些hfile中一定没有要查询的数据，这样就可以过滤到大部分的hfile，达到减少需要扫描的block的数量
BloomFilter对于HBase的随机读性能至关重要，对于get操作以及部分scan操作可以剔除掉不会用到的HFile文件，减少实际IO次数，提高随机读性能。

布隆过滤器原理

假如此时有一个集合S = {x1, x2, … xn}，Bloom Filter使用k个独立的hash函数，分别将集合中的每一个元素映射到｛1,…,m｝的范围。对于任何一个元素，被映射到的数字作为对应的位数组的索引，该位会被置为1。比如元素x1被hash函数映射到数字8，那么位数组的第8位就会被置为1。下图中集合S只有两个元素x和y，分别被3个hash函数进行映射，映射到的位置分别为（0，3，6）和（4，7，10），对应的位会被置为1:

在这里插入图片描述

现在假如要判断另一个元素是否是在此集合中，只需要被这3个hash函数进行映射，查看对应的位置是否有0存在，如果有的话，表示此元素肯定不存在于这个集合，否则有可能存在。下图所示就表示z肯定不在集合｛x，y｝中：

在这里插入图片描述

布隆过滤器存在一定误差，可能会错误的判断该元素存在在当前集合中，但实际上并不存在，但是这种误差，在hbase过滤hfile中是可以接受的

hbase中RowKey的设计原则

唯一原则
- 必须在设计上保证其唯一性，rowkey是按照字典顺序排序存储的，因此，设计rowkey的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。
散列原则
- 如果rowkey按照时间戳的方式递增，不要将时间放在二进制码的前面，建议将rowkey的高位作为散列字段，由程序随机生成，低位放时间字段，这样将提高数据均衡分布在每个RegionServer，以提高负载均衡的几率。如果没有散列字段，首字段直接是时间信息，所有的数据都会集中在一个RegionServer上，这样在数据检索的时候负载会集中在个别的RegionServer上，造成热点问题，会降低查询效率。
长度原则
- rowkey是一个二进制码流，可以是任意字符串，最大长度 64kb ，实际应用中一般为10-100bytes原因如下：
  - 数据的持久化文件HFile中是按照KeyValue存储的，如果rowkey过长，比如超过100字节，1000w行数据，光rowkey就要占用100*1000w=10亿个字节，将近1G数据，这样会极大影响HFile的存储效率；
  - MemStore将缓存部分数据到内存，如果rowkey字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率。

hbase热点问题

   由于HBase中的行是按照rowkey的字典顺序排序的，如果大量的操作（读或写）指向少量节点，大量访问会使热点region所在的单个机器超出自身承受能力，引起性能下降甚至region不可用，这也会影响同一个RegionServer上的其他region
   为了避免写热点，设计rowkey使得不同行在同一个region，但是在更多数据情况下，数据应该被写入集群的多个region，而不是一个。

优化方法
- 加盐：在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。分配的前缀种类数量应该和你想使用数据分散到不同的region的数量一致。
- 哈希：哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使用get操作准确获取某一个行数据
- 反转：使得rowkey中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性
- **预分区：**可以通过指定SPLITS_FILE的值指定分区文件,如果分区信息比较少，也可以直接用SPLITS分区。create ‘split_table_test’, ‘cf’, {SPLITS_FILE => ‘region_split_info.txt’}

MemStore刷写时机

当某个 memstore 的大小达到了 hbase.hregion.memstore.flush.size （默认值128M），其所在region的所有memstore都会刷写。当memstore的大小达到了 hbase.hregion.memstore.flush.size（默认值128M）* hbase.hregion.memstore.block.multiplier （默认值4）时，会阻止继续往该 memstore 写数据。
当region server中memstore的总大小达到java_heapsize * hbase.regionserver.global.memstore.size（默认值0.4）* hbase.regionserver.global.memstore.size.lower.limit（默认值0.95），region会按照其所有memstore的大小顺序（由大到小）依次进行刷写。直到region server中所有memstore的总大小减小到上述值以下。

当region server中memstore的总大小达到java_heapsize * hbase.regionserver.global.memstore.size（默认值0.4）时，会阻止继续往所有的memstore写数据。
到达自动刷写的时间，也会触发 memstore flush。

自动刷新的时间间隔由该属性进行配置hbase.regionserver.optionalcacheflushinterval（默认1小时）。

Compaction

由于memstore每次刷写都会生成一个新的HFile，且同一个字段的不同版本（timestamp）和不同类型（Put/Delete）有可能会分布在不同的HFile中，因此查询时需要遍历所有的HFile。为了减少HFile的个数，以及清理掉过期和删除的数据，会进行StoreFile Compaction。
Compaction分为两种，分别是Minor Compaction和Major Compaction。Minor Compaction会将临近的若干个较小的HFile合并成一个较大的HFile，并清理掉部分过期和删除的数据。Major Compaction会将一个Store下的所有的HFile合并成一个大HFile，并且会清理掉所有过期和删除的数据。

RegionSplit

        默认情况下，每个Table起初只有一个Region，随着数据的不断写入，Region会自动进行拆分。刚拆分时，两个子Region都位于当前的Region Server，但处于负载均衡的考虑，HMaster有可能会将某个Region转移给其他的Region Server。

Region Split时机：
1.当1个region中的某个Store下所有StoreFile的总大小超过Min(initialSize*R^3 ,hbase.hregion.max.filesize")，该Region就会进行拆分。其中initialSize的默认值为2*hbase.hregion.memstore.flush.size，R为当前Region Server中属于该Table的Region个数（0.94版本之后）。
具体的切分策略为：
第一次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了。

2.Hbase 2.0引入了新的split策略：如果当前RegionServer上该表只有一个Region，按照2 * hbase.hregion.memstore.flush.size（128M）分裂，否则按照hbase.hregion.max.filesize(10G)分裂。

MB > 10GB，因此取较小的值10GB 后面每次split的size都是10GB了。

2.Hbase 2.0引入了新的split策略：如果当前RegionServer上该表只有一个Region，按照2 * hbase.hregion.memstore.flush.size（128M）分裂，否则按照hbase.hregion.max.filesize(10G)分裂。