返回顶部
扩大
缩小

Heaton

大数据篇:Hbase

大数据篇:Hbase

  • Hbase是什么

Hbase是一个分布式、可扩展、支持海量数据存储的NoSQL数据库,物理结构存储结构(K-V)。

  • 如果没有Hbase

如何在大数据场景中,做到上亿数据秒级返回。(有条件:单条数据,范围数据)

hbase.apache.org

1 Hbase结构及数据类型

  • 逻辑结构

  • 物理结构

整张表会按照水平方向按照Row Key切割(Region)。再按垂直方向按ColumnFamily切割(Store),

  • Name Space:命名空间

    • 类似于关系型数据库中的database概念,每个命名空间下可以放多个表,默认存在2个命名空间:hbase和default,hbase存放Hbase内置的表,default表是用户默认使用的命名空间。(例如给order表赋予命名空间test,可以写为test:order)
  • Row:行

    • Hbase中每行数据都由一个RowKey和多个列组成。
  • Column:列

    • Hbase中的每个列都由ColumnFamily(列族)和ColumnQualifier(列限定符)进行限定,(例如:personal_info:name,personal_info:city)
  • Cell:单元

    • 由{RowKey,ColumnFamily,ColumnQualifier,TimeStamp}唯一确定的单元,Cell中的数据是没有类型的,全部为字节码形式储存。
  • Row Key:行键

    • Row Key在表中必须是唯一的而且必须存在的。
    • Row Key是 按照字典序一位一位比较有序排列的(有值比没有值大)。例如row_key11 排列在row_key1和row_ley2之间。
    • 所有对表的访问都要通过Row Key 。(单个RowKey访问,或RowKey范围访问,或全表扫描)
  • ColumnFamily:列族

    • 创建Hbase表时,只需要给定CF即可,在插入数据时,列(字段)可以动态、按需增加。
    • 每个CF可以有一个或多个列成员(ColumnQualifier)。
    • 不同列族放在hdfs不同文件夹中存储。
  • TimeStamp:时间戳

    • 用于标识数据的不同版本,如果不指定时间戳,Hbase在写入数据时会自动加上当前系统时间戳为该字段值。

2 Hbase架构

下面从小到大解释上图中的各组件中的功能。

  • StoreFile

    • StoreFile为HBase真正存储的文件,最终通过HDFS客户端存入DataNode。(也就是linux磁盘中)
  • Store

    • 可以理解为一个切片Region中的一组列族。(如上图一个Region中有多个Store)
    • Store中包含Mem Store(内存存储),StoreFile(由内存刷入的数据,数量多了会合并,数据大了会切分)
  • Region

    • Region可以理解为一张表的切片,Region按照数据量大小阀值和Row key进行切分。
    • HBase自动把表水平(按行)划分成多个区域(region),每个region会保存一个表里面某段连续的数据。
    • 每个表一开始只有一个region,随着数据不断插入,region不断增大,当增大到一个阀值的时候,region就会根据Row key等分为两个新的region,以此类推。
    • Table中的行不断增多,就会有越来越多的region,一张表数据就被保存在多个Region 上。
  • HLog

    • Hbase的预写日志,防止特殊情况下的数据丢失。
  • RegionServer

    • 数据的操作(DML):get,put,delete
    • 管理Region:SplitRegion(切分),CompactRegion(合并)
  • Master

    • 表级别操作(DDL):create,delete,alter
    • 管理RegionServer:监控RegionServer状态,分配Regions到RegionServer,(如有机器rs1,rs2,rs3,数据写入rs1,rs2上的Region,r3空闲--->这时rs1被大量写入数据达到Region上限,rs1将Region等分后,就会通知Master将其中一份发往rs3管理。)

3 命令行操作

3.1 链接hbase

  • 链接hbase
hbase shell
  • 查看帮助命令或命令详细使用
help
help '命令'

3.2 命名空间操作

3.2.1 查询命名空间

list_namespace

3.2.2 查询命名空间下的表

list_namespace_tables '命名空间名'

3.2.3 创建命名空间

create_namespace '命名空间名'

3.2.4 删除命名空间(需要namespace是空的)

drop_namespace '命名空间名'

3.3 DDL操作

3.3.1 查询所有用户表

list

3.3.2 创建表

create '命名空间:表', '列族1', '列族2', '列族3','列族4'...

如图发现有一串乱乱序文件夹,这串乱序就代表了Region号

3.3.3 查看表详情

describe '命名空间:表'

可以看出VERSIONS为1,代表这个表只能存放一个版本的数据。

3.3.4 变更表信息

主要用于修改表的版本保存信息,也可以创建表的时候指定,但是shell命令复杂,故一般使用变更命令。

alter '命名空间:表',{NAME=>'列族名',VERSIONS=>3}

3.3.5 修改表状态(删除前必须失效表)

  • 失效表
disable '表'
  • 启用表
enable '表'

3.3.6 删除表

delete '表'

3.4 DML操作

3.4.1 插入数据

put '命名空间:表','RowKey','列族:列','值'
put '命名空间:表','RowKey','列族:列','值',时间戳(版本控制)

如图发现并没有数据文件生成,因为数据在内存中,需要flush '表',而后就可以看见数据落地了。(flush一次就是生成一个StoreFile)

3.4.2 扫描表

#全表扫描
scan '命名空间:表'
#范围扫描(左闭右开)
scan '命名空间:表',{STARTROW => 'RowKey',STOPROW=>'RowKey'}
#扫描N个版本的数据
scan '命名空间:表',{RAW=>true,VERSIONS=>10}

3.4.3 Flush刷写

flush '命名空间:表'
  • 数据版本保留机制

从上面知道flush一次就是生成一个StoreFile,那么数据就会根据建表保留版本个数来存储最近个数的数据。

比如:保留版本个数为2,那么如果插入v1,v2,v3三条数据,flush后,就只剩下v2,v3两条数据,这时再插入v4,v5,v6三条数据,flush后,剩下的为v2,v3,v5,v6四个版本的数据(此时是2个StoreFile文件),如果发生Region合并或者分裂,那么StoreFile文件会被合并后在放入对应的Region中,这时数据就又会根据保留版本个数删除,v2,v3,v5,v6,就变成了v5,v6。(如果没有手动flush,或者到设置的自动flush时间,那么数据不会根据版本个数删除)(默认超过3个StoreFile文件则会进行大合并)

  • 一个列族对应一个MemStore
  • 每个MemStore在刷写到HDFS时,生成的StoreFile是独立的
  • RegionServer全局MemStore刷写时机:hbase.regionserver.global.memstore.size

  • 单个Memstore刷写时机:hbase.hregion.memstore.flush.size

3.4.3 查询数据

get '命名空间:表','RowKey'
get '命名空间:表','RowKey','列族'
get '命名空间:表','RowKey','列族:列'
#获取N个版本的数据
get '命名空间:表','RowKey',{COLUMN=>'列族:列',VERSIONS=>10}

3.4.4 清空表

truncate '命名空间:表'

3.4.5 删除数据

#delete '命名空间:表','RowKey','列族'(此命令行删除有问题,但是API可以)
delete '命名空间:表','RowKey','列族:列'
deleteall  '命名空间:表','RowKey'

4 读写流程

4.1 写流程

  1. 客户端通过ZK查询元数据存储表的所在RegionServer所在位置并返回

  1. 查询元数据,返回需要表的RegionServer

  1. 客户端缓存信息,方便下次使用

  2. 发送PUT请求到RegionServer,写操作日志(WAL),再写入内存,然后同步wal到HDFS,则结束。(此步骤由事务回滚保证日志、内存都写入成功)

4.2 读流程

在读取数据时候,MemStore和StoreFile一起读取,将StoreFile中的数据放入BlockCache,然后在将内存数据和BlockCache比较时间戳做Merge,取最新的数据返回。

5 合并切分

  • 合并Compaction

由于Memstore每次刷写都会生成一个新的HFile,且同一个字段的不同版本和不同类型有可能会分布在不同的HFile中,因此查询时需要遍历所有的HFile。为了减少HFile的个数,以及清理掉过期和删除的数据,会进行StoreFile合并。

Compaction分为Minor Compaction和Major Compaction。

Minor Compaction会将临近的若干个较小的HFile合并成一个较大的HFile,但不会清理过期和删除的数据。

Major Compaction会将一个Store下的所有HFile合并成一个大的HFile,并且会清理掉过期和删除的数据。

参数设置:

hbase.hregion.majorcompaction=0

hbase.hregion.majorcompaction.jitter=0

hbase.hstore.compactionThreshold=3

  • 切分

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

参数设置:

hbase.hregion.max.filesize=5G (如下公式中为Max1)(可以减小该值,提高并发)

hbase.hregion.memstore.flush.size=258M (如下公式中为Max2)

每次切分将会比较Max1和Max2的值,取小的。[min(Max1,Max2 * Region个数 * 2)],其中Region个数为当前Region Server中数据该Table的Region个数。

由于自动切分无法避免热点问题,所以在生产中我们常常使用预分区和设计RowKey避免出现热点问题

6 优化

6.1 尽量不要使用多个列族

为了避免flush时产生多个小文件。

6.2 内存优化

主要作用来缓存Table数据,但是flush时会GC,不要太大,根据集群资源,一般分配整个Hbase集群内存的70%,16->48G就可以了

6.3 允许在HDFS中追加内容

dfs.support.append=true (hdfs-site.xml、hbase-site.xml)

6.4 优化DataNode允许最大文件打开数

dfs.datanode.max.transfer.threads=4096 (HDFS配置)

在Region Server级别的合并操作中,Region Server不可用,可以根据集群资源调整该值,增加并发。

6.5 调高RPC监听数量

hbase.regionserver.handler.count=30

根据集群情况,可以适当增加该值,主要决定是客户端的请求数。

6.6 优化客户端缓存

hbase.client.write.buffer=100M (写缓存)

调高该值,可以减少RPC调用次数,单数会消耗更多内存,根据集群资源情况设定。

6.7 合并切分优化

参考5合并切分

6.8 预分区

  • 创建表时候加入参数SPLITS
create '命名空间:表', '列族1', '列族2', '列族3','列族4'...,SPLITS=>['分区号','分区号','分区号','分区号']

根据数据量预估半年到一年的数据量,和Region最大值来选择预分区数。

6.9 RowKey

  • 散列性:均匀分部到不同的Region里
  • 唯一性:不会重复
  • 长度:70-100位

方案一:随机数,hash值,但是这种不能范围查询,没有数据的集中性。

方案二:字符串反转,比如时间戳反转后就达到了散列性,但是在查看的时候集中性只是优于第一种。

  • 生产方案推荐:
#设计预分区键(如比如200个区) | ASCLL码为124只有 } 和 ~ 比它大,那么不管以后的RowKey使用什么字符,都是小于这个字符的,所以可以有效的得到RowKey规律
000|
001|
......
199|


# 1 设计RowKey键_ASCLL码为95
000_
001_
......
199_
# 2 根据业务唯一标识(如用户ID,手机号,身份证)和时间维度(比如按月:202004)计算后根据分区数取余(13408657784^202004)%199=分区号
# 想以什么时间进行查询就把什么往前提,如下数据需要查1月数据范围就是 000_13408657784_2020-04  -> 000_13408657784_2020-04|
000_13408657784_2020-04-01 12:12:12
......
199_13408657784_2020-04-01 24:12:12

posted on 2020-04-12 16:14  咘雷扎克  阅读(1263)  评论(0编辑  收藏  举报

导航