Hbase基础

Posted Screenly

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Hbase基础相关的知识,希望对你有一定的参考价值。

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

Hbase基础

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
    如图:

  • 对应结构
    表 -> 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

    1. 保证集群中只有一个Master
    2. 存储所有Region的入口(ROOT)地址
    3. 实时监控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可以手动或者自动做

以上是关于Hbase基础的主要内容,如果未能解决你的问题,请参考以下文章

HBase框架基础

大数据存储- Hbase 基础

HBase框架基础

HBase框架基础

HBase框架基础

HBase框架基础