Hbase的二级索引和RowKey的设计

Hbase查询简介

Hbase查询的时候，有如下几种方式：
• 经过 rowkey方式，指定 获取惟一记录
• 经过 scan方式，设置satrtRow 和stopRow 参数进行范围匹配(模糊查询)
• 全表扫描，即直接扫描整张表中全部行记录

HBase里面只有rowkey做为一级索引

Hbase的scan，不走主键索引，而是全表扫描，性能奇差。

为了HBase的数据查询更高效、适应更多的场景， 诸如使用非rowkey字段检索也能作到秒级响应，或者支持各个字段进行模糊查询和多字段组合查询等， 所以须要在HBase上面构建二级索引， 以知足现实中更复杂多样的业务需求。

 

二级索引方案

基于Coprocessor方案

原理：基于Coprocessor（0.92版本开始引入，达到支持相似传统RDBMS的触发器的行为）开发自定义数据处理逻辑，采用数据“双写”（dual-write）策略，在有数据写入同时同步到二级索引表

开源方案：

一、华为的hindex：当年刚出来的时候比较火，可是版本较旧，看GitHub项目地址最近这几年就没更新过

二、Apache的phoenix：在目前开源的方案中，是一个比较优的选择。主打SQL on HBase ， 基于SQL能完成HBase的CRUD操做，支持JDBC协议

优势： 基于Coprocessor的方案，从开发设计的角度看， 把不少对二级索引管理的细节都封装在的Coprocessor具体实现类里面， 这些细节对外面读写的人是无感知的，简化了数据访问者的使用。

缺点： 可是Coprocessor的方案***性比较强， 增长了在Regionserver内部须要运行和维护二级索引关系表的代码逻辑等，对Regionserver的性能会有必定影响 

非Coprocessor方案

常见的是采用底层基于Apache Lucene的Elasticsearch(下面简称ES)或Apache Solr ，来构建强大的索引能力、搜索能力， 例如支持模糊查询、全文检索、组合查询、排序等。

一、Lily HBase Indexer：
Lily HBase Indexer(也简称 HBase Indexer)是国外的NGDATA公司开源的基于solr的索引构建工具， 特点是其基于HBase的备份机制，开发了一个叫SEP工具， 经过监控HBase 的WAL日志（Put/Delete操做），来触发对solr集群索引的异步更新， 基本对HBase无侵入性（但必须开启WAL ）

二、CDHSearch

CDHSearch是Hadoop发行商Cloudera公司开发的基于solr的HBase检索方案，部分集成了Lily HBase Indexer的功能。

三、 DataStory

有本身的大数据团队的公司通常都会针对本身的业务场景进行优化，自行构建ES/Solr的搜索集群。 例如数说故事企业内部的百亿级数据全量库，就是基于ES构建海量索引和检索能力的案例。 主要优化点包括：

对企业的索引集群面向的业务场景和模式定制，对通用数据模型进行抽象和平台化复用须要针对多业务、多项目场景进行ES集群资源的合理划分和运维管理查询须要针对多索引集群、跨集群查询进行优化共用集群场景须要作好防御、监控、限流

增量索引： 平常持续接入的数据源，进行增量的索引更新

全量索引： 配套基于Spark/MR的批量索引建立/更新程序， 用于初次或重建已有HBase库表的索引

数据查询流程：

Datastory在作全量库的过程当中，仍是有更多遇到的问题要解决，诸如数据一致性、大量小索引、多版本ES集群共存等 

 

RowKey的设计

若是咱们RowKey设计为uid+phone+name，那么这种设计能够很好的支持一下的场景:

uid=873969725 AND phone=18900000000 AND name=zhangsan
uid= 873969725 AND phone=18900000000
uid= 873969725 AND phone=189?
uid= 873969725

难以支持的场景：

phone=18900000000 AND name = zhangsan
phone=18900000000 
name=zhangsan

RowKey设计案例剖析

1. 查询某用户在某应用中的操做记录

reverse(userid) + appid + timestamp

2. 查询某用户在某应用中的操做记录（优先展示最近的数据）

reverse(userid) + appid + (Long.Max_Value - timestamp)

3. 查询某用户在某段时间内全部应用的操做记录

reverse(userid) + timestamp + appid

4. 查询某用户的基本信息

reverse(userid)

5. 查询某eventid记录信息

salt + eventid + timestamp

若是 userid是按数字递增的，而且长度不一，能够先预估 userid 最大长度，而后将userid进行翻转，再在翻转以后的字符串后面补0（至最大长度）；若是长度固定，直接进行翻转便可（如手机号码）。

在第5个例子中，加盐的目的是为了增长查询的并发性，加入Slat的范围是0~n，能够将数据分为n个split同时作scan操做，有利于提升查询效率。

RowKey设计原则总结

在HBase的使用过程，设计RowKey是一个很重要的一个环节。咱们在进行RowKey设计的时候可参照以下步骤： 

1. 结合业务场景特色，选择合适的字段来作为RowKey，而且按照查询频次来放置字段顺序
2. 经过设计的RowKey能尽量的将数据打散到整个集群中，均衡负载，避免热点问题
3. 设计的RowKey应尽可能简短