大数据学习之 HBase 原理学习（二）

最新推荐文章于 2021-07-15 23:14:51 发布

从北码到南

最新推荐文章于 2021-07-15 23:14:51 发布

阅读量161

点赞数

分类专栏：数据仓库 Java应用与设计大数据文章标签：数据收集云服务

本文链接：https://blog.csdn.net/weixin_36079865/article/details/102932063

版权

Java应用与设计同时被 3 个专栏收录

19 篇文章 0 订阅

订阅专栏

大数据

7 篇文章 0 订阅

订阅专栏

数据仓库

2 篇文章 0 订阅

订阅专栏

HBase 表介绍

1. 命名空间

Table：表，所有表都是命名空间的成员，即表必须属于某个命名空间，如果没有指定，则默认为default的默认空间
RegionServer group：一个命名空间包含了默认的RegionServer Group
Permission：权限，命名空间能够让我们来定义访问控制列表ACL(Access Control List)，例如：创建表，读取表，删除，更新
Quota：限额，可以强制一个命名空间包含的region数量（属性：hbase.quota.enabled）

2.命名空间使用

创建命名空间

hbase(main):001:0> create_namespace 'data_col'
0 row(s) in 1.0910 seconds

hbase(main):002:0> create 'data_col:student','cf'
0 row(s) in 1.3290 seconds

=> Hbase::Table - data_col:student

hbase(main):005:0> describe 'data_col:student'
Table data_col:student is ENABLED
data_col:student
COLUMN FAMILIES DESCRIPTION
{NAME => 'cf', BLOOMFILTER => 'ROW', VERSIONS => '1', 
IN_MEMORY => 'false', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', 
TTL => 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOCKCACHE => 'true', 
BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}
1 row(s) in 0.0240 seconds

属性介绍

1. NAME
    列族名称
2. BLOOMFILTER
    默认是NONE，是否使用布隆过滤器及使用何种方式，布隆过滤器可以每列族单独开启，使用HColumnDescriptor.setBloomFilterType(NONE|ROW|ROWCOL)对列族单独启用布隆，default=ROW对行进行布隆过滤，对ROW，行键的哈希在每次插入行时被添加到布隆，对ROWCOl，行键+列族+列族修饰的哈希将在每次插入时添加到布隆
    eg：create 'table',{BLOOMFILTER=>'ROW'}
    作用：用布隆过滤器可以节省读磁盘过程，可以有助于降低读取延迟
3. VERSION
    版本号，默认是 1，compact操作执行之后，至少要保留的版本
4. IN_MEMORY
    Block Cache 包含三个级别的队列优先级
        Single：如果一个Block被第一次访问则放在这一级的队列中
        Multi：如果是一个Block被多次访问，则从Single队列移动到Multi
        In Memory：它是静态指定的，不会像其他两种cache因为访问频率而发生变化，这就决定了它的独立性
     LRU(Least Recently Used)淘汰数据时Single会被先淘汰，其次是Mutil，最后是In Memory，这三个队列分别占用BlockCache的 25% 50% 25%
     
5. KEEP_DELETED_CELLS
    默认为false,删除的同时flush,数据就会被删除，hbase没有保留。原生扫描也查不到数据了
    当指定了true，delete的数据仍然在hbase中，即使flush,也没有删除。使用原生扫描，是可以查到的

6. TTL
    Time To Live 定义列族中单元格存活时间，过期自动删除
    a):单位是秒，默认是 FOREVEN
    b):当一行所有列都过期后，RowKey也会被删除
    c):若TTL设置为一周，那么时间戳为一周之前的数据不能插入
    也可在建表的时候指定或者通过alter修改表结构设置
7. COMPRESSION
    默认值是NONE，即不使用压缩，这个参数意思是该列族是否采用压缩，采用什么压缩算法，推荐SNAPPY,HBase在写入数据块到HDFS之前会首先对数据块进行压缩，再落盘，从而可以减少磁盘空间使用量，
读数据的时候首先从HDFS中加载出Block块之后进行解压缩，然后缓存到BlockCache,最后返回给用户
写：DataBlock-->Encoding KVs-->Compress DataBlock-->Flush
读: ReadBlock-->DeCompress DataBlock-->Cache DataBlock-->Decoding Scan KVs
    综合上述，分析数据压缩对资源的使用情况以及读写性能的影响
    a): 资源使用情况：压缩最直接最重要的作用是减少数据磁盘的容量，理论上snappy压缩率可以达到5：1，但是这些视测试而定，压缩/解压缩无疑是需要大量计算，需要大量CPU资源，从读的流程中分析数据被加载到缓存前block块会被先解压，因为和不压缩的情况相比，内存占比是一样的
    b): 读写性能：因为数据写入是先将kv数据值写到缓存，最后统一flush，而压缩是flush这个阶段执行的，因此会影响flush的操作，对写性能本身并不会有太大影响，而数据读取如果是HDFS中读取的话，需要先解压缩，因此读的性能会有所下降
    create 'table',{NAME=>'cf',COMPRESSION=>'SNAPPY'}
    建表之处没有压缩，后来想加入可以压缩算法，可以通过alter修改schema

3.表设计

1.Region的大小尽可能保持在10到50GB之间
2.单个cell大小不要超过10MB，如果使用mob则不要超过50MB，否则可以考虑将数据存在hdfs中，
  并将指向数据的指针存储在 hbase 中
3.每个表的列族个数保持1到3个，因为HBase的设计不能很好的支持两个或者三个以上的列族设计，因为
  flushing 和 compactions是作用在每个列族上，当一个列族的数据量达到阈值需要经进行刷新的时候，
  相邻的列族的数据量很小，也会被顺带着对它进行flushing操作，必然会引起大量不必要的IO操作
4.列名设计尽量要短，不然会浪费很大部分的磁盘和内存
5.基于时间的数据存储很容易引起数据倾斜，一些已经被split的region永远也不会被写入。这种也会造
  成少量的region活跃和大量的region会闲置，可以考虑在rowkey的设计加盐、散列、时间倒置，但是这些
  也必然给读带来很大的影响（从这点看HBase并不适合时序性数据存储业务设计）

4.RowKey设计

HBase 中 row 是按照rowkey的字典序进行排序的，不当的rowkey设计很容易引起热点问题，即大量的Clinet请求会定向到集群的单个节点
上或仅几个节点；而大量的请求负载到同一个或者几个节点很容易引起主机的负载过重，性能下降，region不可用，甚至宕机，
而且集群资源也不能很好的被利用。

盐
这里加盐跟加密无关，仅仅是考虑在rowkey的设计中开始部分加入一组随机数，然后在hbase集群对rowkey进行
hash(rowkey)/region nunmber 使数据会均匀的分布

hash
使用确定的哈希，使其按照我们预测的去分布

反转倒置
反转rowkey，可以有效的随机分布，但是会牺牲rowkey的有序性

注意：如果确实需要将时间序列数据上传到HBase，可以考虑OpenTSDB（官方推荐）