Hbase的二级索引和RowKey的设计

Hbase查询简介

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

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

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

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

 

二级索引方案

基于Coprocessor方案

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

开源方案：

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

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

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

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

非Coprocessor方案

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

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

2、CDHSearch

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

3、 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设计的时候可参照如下步骤： 

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

 

参考文章

https://blog.csdn.net/weixin_43892898/article/details/89249322

https://blog.csdn.net/WYpersist/article/details/79830811

https://zhuanlan.zhihu.com/p/69462736