Hbase2 高级特性

Create a table with namespace=ns1 and table qualifier=t1

  hbase> create 'ns1:t1', {NAME => 'f1', VERSIONS => 5}

 

Create a table with namespace=default and table qualifier=t1

  hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}

  hbase> # The above in shorthand would be the following:

  hbase> create 't1', 'f1', 'f2', 'f3'

  hbase> create 't1', {NAME => 'f1', VERSIONS => 1, TTL => 2592000, BLOCKCACHE => true}

  hbase> create 't1', {NAME => 'f1', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '10'}}

  hbase> create 't1', {NAME => 'f1', IS_MOB => true, MOB_THRESHOLD => 1000000, MOB_COMPACT_PARTITION_POLICY => 'weekly'}

 

1.Hbase预分区

默认情况下，hbase回自动分配一个Region，如果创建很多表，都会集中在一个Region。如果一下导入大量数据。RegionServer的压力就会非常大

这就引出了预分区的概念：

 hbase> create 'ns1:t1', 'f1', SPLITS => ['10', '20', '30', '40']

上面这行代码的意思是ns1:t1这张表有一个列族，rowkey按照null-10,10-20,20-30,30-40事先分好区

 

2.实战：设计一个通话记录查询

rowKey：手机号_时间戳

前缀匹配：

辅助索引表的设计：

Hbase方式

rowKey：条件查询

列族：主表的rowKey

使用es solr

主表和辅助表可以在程序中一个事务中进行

也可以利用协处理器来处理

列族属性

 

{NAME => 'info',

VERSIONS => '1',版本号限制，Hbase中一个rowkey的最多存储版本号个，但是用get操作只会返回最新的，

EVICT_BLOCKS_ON_CLOSE => 'false',

NEW_VERSION_BEHAVIOR => 'false',

KEEP_DELETED_CELLS => 'FALSE',

CACHE_DATA_ON_WRITE => 'false', D

ATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER',

MIN_VERSIONS => '0', REPLICATION_SCOPE => '0',

BLOOMFILTER => 'ROW', 布隆过滤器

CACHE_INDEX_ON_WRITE => 'false', IN_ME
MORY => 'false',

CACHE_BLOOMS_ON_WRITE => 'false',

PREFETCH_BLOCKS_ON_OPEN => 'false',

COMPRESSION => 'NONE', 是否启动压缩

BLOCKCACHE => 'true', 是否启动blockcache

BLOCKSIZE => '65536'} 

0----------------------

用户读取数据数据

先读memstore

再读blockCache   一次请求之后会吧结果缓存在blockCache中

在读Hfile

最后merge返回数据集

 

Hbase中RegionServer的内存分成两部分，一部分是memstore，主要用来写，另一部分作为BlockCache，用于读。写请求先写入Memstore,RegionServer会给每个region提供一个memstore，当Memstore满64MB之后会自动flush到磁盘。当Menstore总大小超过限制。会强行启动flush进程，从最大的memstore开始flush到低于阀值

读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读取，并把读取的结果放在BlockCache中，BlockCache采用的是LRU策略。在注重读响应时间的应用场景下，可以将BlockCache设置大一点，Memstore设置小点。

一个RegionServer上有一个BlockCache和N个Memstore。下面我们从hbase的源码中展开阐述Blockcache的具体实现，并在讲解实现的中间补充阐述关于缓存的相关机制介绍。

lockCache基于客户端对数据的访问频率，定义了三个不同的优先级，如下所示：

SINGLE：如果一个Block被第一次访问，则该Block被放在这一优先级队列中；

MULTI：如果一个Block被多次访问，则从single移到Multi中；

MEMORY：memory优先级由用户指定，一般不推荐，只用系统表才使用memory优先级；

以上将cache分级的好处在于：

首先，通过Memory类型的cache，可以将重要的数据放到RegionServer内存中常驻，例如Meta或者namespace的元数据信息；

其次，通过区分single和multi类型cache，可以防止由于scan操作带来的cache频繁颠簸，将最少使用的block加入到淘汰算法中；

默认配置下，对于整个blockcache的内存，按照以下百分比分配给single、multi和inMemory使用：0.25、0.5和0.25；

 

淘汰策略也是优先淘汰single，然后muti，inMemeory一般不会清除

 

Hbase的compaction

随着memstore中的数据不断写入磁盘，会产生很多HFile文件，Hbase内部有一个合并机制，合并有两种类型，minor和major

minor合并是一个多路归并过程，将小HFile合并成一个HFile文件，minor merge合并速度很快，只受磁盘IO的性能影响。

major 合并会将一个region中一个列族的若干个HFile重写为一个新HFile，这里会删除超过版本号限制以及生存时间到期的数据以及打上删除标记的数据

---------

Hbase 数据迁移方式：

1.sqoop

2.利用mr生成HFile文件，然后在通过BulkLoad导入到hbase中 

https://www.cnblogs.com/smartloli/p/9501887.html

3.利用mr或者spark程序导入

4.api写入

-------------------

协处理器

 协处理器有两种： observer 和 endpoint

  (1) Observer 类似于传统数据库中的触发器，当发生某些事件的时候这类协处理器会被 Server 端调用。Observer Coprocessor 就是一些散布在 HBase Server 端代码中的 hook 钩子， 在固定的事件发生时被调用。比如： put 操作之前有钩子函数 prePut，该函数在 put 操作
执行前会被 Region Server 调用；在 put 操作之后则有 postPut 钩子函数

(2) Endpoint 协处理器类似传统数据库中的存储过程，客户端可以调用这些 Endpoint 协处 理器执行一段 Server 端代码，并将 Server 端代码的结果返回给客户端进一步处理，最常 见的用法就是进行聚集操作。如果没有协处理器，当用户需要找出一张表中的最大数据，即

max 聚合操作，就必须进行全表扫描，在客户端代码内遍历扫描结果，并执行求最大值的 操作。这样的方法无法利用底层集群的并发能力，而将所有计算都集中到 Client 端统一执 行，势必效率低下。利用 Coprocessor，用户可以将求最大值的代码部署到 HBase Server 端，
HBase 将利用底层 cluster 的多个节点并发执行求最大值的操作。即在每个 Region 范围内 执行求最大值的代码，将每个 Region 的最大值在 Region Server 端计算出，仅仅将该 max 值返回给客户端。在客户端进一步将多个 Region 的最大值进一步处理而找到其中的最大值。
这样整体的执行效率就会提高很多
下图是 EndPoint 的工作原理：

----------------------

hbase中的热点现象：

我们知道，检索habse的记录首先要通过row key来定位数据行。当大量的client访问hbase集群的一个或少数几个节点，造成少数region server的读/写请求过多、负载过大，而其他region server负载却很小，就造成了“热点”现象。

 

热点的危害：

大量访问会使热点region所在的单个主机负载过大，引起性能下降甚至region不可用。

 

热点产生原因：

有大量连续编号的row key  ==>  大量row key相近的记录集中在个别region

 ==>  client检索记录时,对个别region访问过多  ==>  此region所在的主机过载

 ==>  热点

明白了热点原因就可以从row key着手解决，下面几个方法可以使用，目的就一个：尽量均衡地把每一条记录分散到不同的region里去！

 

下面是一些常见的避免热点的方法以及它们的优缺点：

加盐

       这里所说的加盐不是密码学中的加盐，而是在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。给多少个前缀？这个数量应该和我们想要分散数据到不同的region的数量一致（类似hive里面的分桶）。加盐之后的rowkey就会根据随机生成的前缀分散到各个region上，以避免热点。

哈希

       哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使用get操作准确获取某一个行数据。

反转

       第三种防止热点的方法是反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。

反转rowkey的例子：以手机号为rowkey，可以将手机号反转后的字符串作为rowkey，从而避免诸如139、158之类的固定号码开头导致的热点问题。

时间戳反转

       一个常见的数据处理问题是快速获取数据的最近版本，使用反转的时间戳作为rowkey的一部分对这个问题十分有用，可以用Long.Max_Value - timestamp追加到key的末尾，例如[key][reverse_timestamp] ,[key] 的最新值可以通过scan [key]获得[key]的第一条记录，因为HBase中rowkey是有序的，第一条记录是最后录入的数据

----------

hbase的事务：

hbase仅仅支持行级事务

写写并发控制：

1.获取行级所

2.写wal动作

3.更新memstore，写入cell

4.释放所

 

批量写

两段所协议：

1.获取所有待写入（更新）行记录的行锁

2.开始执行写入更新

3.写完之后统一释放

主要是为了避免死锁

----

读写

采用的是mvcc机制，

在每一个RegionServer上维护了一个事务队列，事务编号从小到大排序，底部指向最近已经提交的数据，但读请求进来时候会返回最近已经提交事务的 时候的状态。这点和关系型数据库有点不同。；
 

 

布隆过滤器

1、主要功能

提高随机读的性能

2、存储开销

bloom filter的数据存在StoreFile的meta中，一旦写入无法更新，因为StoreFile是不可变的。Bloomfilter是一个列族（cf）级别的配置属性，如果你在表中设置了Bloomfilter，那么HBase会在生成StoreFile时包含一份bloomfilter结构的数据，称其为MetaBlock；MetaBlock与DataBlock（真实的KeyValue数据）一起由LRUBlockCache维护。所以，开启bloomfilter会有一定的存储及内存cache开销。 

3、控制粒度

a)ROW

根据KeyValue中的row来过滤storefile 

举例：假设有2个storefile文件sf1和sf2， 

sf1包含kv1（r1 cf:q1 v）、kv2（r2 cf:q1 v） 

sf2包含kv3（r3 cf:q1 v）、kv4（r4 cf:q1 v） 

如果设置了CF属性中的bloomfilter为ROW，那么get(r1)时就会过滤sf2，get(r3)就会过滤sf1 

b)ROWCOL

根据KeyValue中的row+qualifier来过滤storefile

举例：假设有2个storefile文件sf1和sf2， 

sf1包含kv1（r1 cf:q1 v）、kv2（r2 cf:q1 v） 

sf2包含kv3（r1 cf:q2 v）、kv4（r2 cf:q2 v） 

如果设置了CF属性中的bloomfilter为ROW，无论get(r1,q1)还是get(r1,q2)，都会读取sf1+sf2；而如果设置了CF属性中的bloomfilter为ROWCOL，那么get(r1,q1)就会过滤sf2，get(r1,q2)就会过滤sf1