Hbase笔记

架构角色

1）Region Server
Region Server 为 Region 的管理者，其实现类为HRegionServer，主要作用如下:
对于数据的操作：get, put, delete；
对于Region 的操作：splitRegion、compactRegion。
2）Master
Master 是所有Region Server 的管理者，其实现类为HMaster，主要作用如下：
对于表的操作：create, delete, alter
对于RegionServer 的操作：分配regions 到每个RegionServer，监控每个RegionServer
的状态，负载均衡和故障转移。
3）Zookeeper
HBase 通过Zookeeper 来做Master 的高可用、RegionServer 的监控、元数据的入口以及
集群配置的维护等工作。
4）HDFS
HDFS 为HBase 提供最终的底层数据存储服务，同时为HBase 提供高可用的支持。

数据模型

1）Name Space
命名空间，类似于关系型数据库的DatabBase 概念，每个命名空间下有多个表。HBase
有两个自带的命名空间，分别是hbase 和default，hbase 中存放的是HBase 内置的表，
default 表是用户默认使用的命名空间。
2）Region
类似于关系型数据库的表概念。不同的是，HBase 定义表时只需要声明列族即可，不需
要声明具体的列。这意味着，往HBase 写入数据时，字段可以动态、按需指定。因此，和关
系型数据库相比，HBase 能够轻松应对字段变更的场景。
3）Row
HBase 表中的每行数据都由一个RowKey 和多个Column（列）组成，数据是按照RowKey
的字典顺序存储的，并且查询数据时只能根据RowKey 进行检索，所以RowKey 的设计十分重
要。
4）Column
HBase 中的每个列都由Column Family(列族)和Column Qualifier（列限定符）进行限
定，例如info：name，info：age。建表时，只需指明列族，而列限定符无需预先定义。
5）Time Stamp
用于标识数据的不同版本（version），每条数据写入时，如果不指定时间戳，系统会
自动为其加上该字段，其值为写入HBase 的时间。

基本架构

  • Hlog是WAL
  • 一个Region Server可以有多个Region
  • Store是一个列族，一个Region可以有多个Store
  • Store存在内存（MemStore）或者磁盘
  • 来自Memstore的存储内容被flush到很多小文件，小文件合并成大文件，大文件再分裂
  • 储存的文件被称为StoreFile，格式是HFile(HFile的地位类似paquet，orc等存储格式)
  • 刷写过程调用HDFS客户端，写到DataNode
  • zk的作用：找master用

写数据流程

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。

（HBase 0.9.x以前的版本，会有第0步：先去zk找-ROOT-表，找到meta）

源码解读

HRegion.java
1. 请求锁 保证读写分离
2. 更新 LATEST_TIMESTAMP，（所以不用传时间戳会自动生成）
3. 构建WAL
4. 追加日志到WAL
5. 写入memstore
6. 释放锁
7. 同步WAL
8. 让写操作变得可见
如果同步失败，把keys从memstore里移除，从而保证事务
9.略，不用太关心了

MemStore Flush

MemStore 刷写时机：
1.当某个memstroe 的大小达到了hbase.hregion.memstore.flush.size（默认值128M），其所在region 的所有memstore 都会刷写。当memstore 的大小达到了hbase.hregion.memstore.flush.size（默认值128M）hbase.hregion.memstore.block.multiplier（默认值4）时，会阻止继续往该memstore 写数据。
2.当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 写数据。
  1. 到达自动刷写的时间，也会触发memstore flush。自动刷新的时间间隔由该属性进行，配置hbase.regionserver.optionalcacheflushinterval（默认1 小时）。
    4.当WAL 文件的数量超过hbase.regionserver.max.logs，region 会按照时间顺序依次进行刷写，直到WAL 文件数量减小到hbase.regionserver.max.log 以下（该属性名已经废弃，现无需手动设置，最大值为32）。

读数据流程

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）中查询目标数据，并将
查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不
同的类型（Put/Delete）。** 同时读磁盘和内存，会比较时间戳，给客户端返回时间戳最大的。 **
5） 将从文件中查询到的数据块（Block，HFile 数据存储单元，默认大小为64KB）缓存到
Block Cache。
6）将合并后的最终结果返回给客户端。

所以Hbase是一个读比写慢的框架，无论什么时候读，都要读磁盘。

StoreFile 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，并且会清理掉过期和删除的数据。

  • 默认设置是7天做一个Major Compaction，一般会关闭（设置为0），防止集群自动合并占用资源引发问题
  • conpactionThreshod 触发合并的HStoreFiles数量阈值，默认是3
  • 如果手动执行compact，可以把hdfs上的Hfile合并成一个

其他读写相关内容

  • 读写不需要Master
  • 数据什么时候删除？
    - flush
    - majorcompact

Region拆分

默认情况下，每个Table 起初只有一个Region，随着数据的不断写入，Region 会自动进
行拆分。刚拆分时，两个子Region 都位于当前的Region Server，但处于负载均衡的考虑，
HMaster 有可能会将某个Region 转移给其他的Region Server。
Region Split 时机：
1.当1 个region 中的某个Store 下所有StoreFile 的总大小超过hbase.hregion.max.filesize，
该Region 就会进行拆分（0.94 版本之前）。
2. 当1 个region 中的某个Store 下所有StoreFile 的总大小超过Min(R^2 *
"hbase.hregion.memstore.flush.size",hbase.hregion.max.filesize")，该Region 就会进行拆分，其
中R 为当前Region Server 中属于该Table 的个数（0.94 版本之后）。

Hbase API

  1. 新建项目后在pom.xml 中添加依赖：

    org.apache.hbase
    hbase-server
    1.3.1


    org.apache.hbase
    hbase-client
    1.3.1
  2. 获取Configuration 对象
    public static Configuration conf;
    static{
    //使用HBaseConfiguration 的单例方法实例化
    conf = HBaseConfiguration.create();
    conf.set("hbase.zookeeper.quorum", "192.166.9.102");
    conf.set("hbase.zookeeper.property.clientPort", "2181");
    }
  3. 创建表

    记得创建列族
  4. 删除表

    先disable再删除
  5. 获取指定列族:列的数据

API小结

DDL:Admin对象
DML:Table对象
他们都需要Connection对象来创建

优化

高可用

  1. 关闭HBase集群
    bin/stop-hbase.sh
  2. 在conf目录下创建backup-masters文件
    touch conf/backup-masters
  3. 在backup-masters文件中配置高可用HMaster节点
    echo hadoop103 > conf/backup-masters
  4. 整个目录scp到别的节点
    scp -r conf/xxx:/opt/module/hbase/
    5 打开页面查看
    http://xxxx:16010

预分区

1.手动设定
2. 生成16进制分区
3.按照文件设置分区
4.使用JavaAPI分区

分区原则：
未来的生产需要
机器集群规模

合理的Rowkey设计(随机散列)与预分区二者结合起来，是比较完美的。预分区一开始就预建好了一部分region，这些region都维护着自己的start-end keys，在配合上随机散列，写数据能均衡的命中这些预建的region，就能解决上面的那些缺点，大大提高性能

Row Key设计

1.生成随机数、hash、随机数
2.字符串反转
3.字符串拼接
例子：
查询通话记录：
xxx_13888888888_2019-02: xxx是13888888888_2019-12算出来的值
xxx_13888888888_2019-02| ：两者结合起来作为startkey和endkey

内存优化 及 配置优化

略

posted @ 2021-02-04 11:29  風酱  阅读(98)  评论(0)  编辑  收藏  举报