本文详细介绍了HBase的一级索引和查询方式，包括通过rowkey和scan的查询，并探讨了HBase二级索引的必要性和实现方案，如基于Coprocessor和非Coprocessor的方法。在RowKey设计上，通过案例分析了不同设计思路的适用场景，强调了设计原则。此外，还提到了数据一致性、查询效率和负载均衡等问题。
目录
Hbase查询简介
Hbase查询的时候，有以下几种方式：
• 通过 rowkey方式，指定 获取唯一记录
• 通过 scan方式，设置satrtRow 和stopRow 参数进行范围匹配(模糊查询)
• 全表扫描，即直接扫描整张表中所有行记录
HBase里面只有rowkey作为一级索引
Hbase的scan，不走主键索引，而是全表扫描，性能奇差。
为了HBase的数据查询更高效、适应更多的场景， 诸如使用非rowkey字段检索也能做到秒级响应，或者支持各个字段进行模糊查询和多字段组合查询等， 因此需要在HBase上面构建二级索引， 以满足现实中更复杂多样的业务需求。
二级索引方案
基于Coprocessor方案
原理：基于Coprocessor（0.92版本开始引入，达到支持类似传统RDBMS的触发器的行为）开发自定义数据处理逻辑，采用数据“双写”（dual-write）策略，在有数据写入同时同步到二级索引表
关键部分来了， 既然Hbase并没有提供二级索引，那如何实现呢？先看下面这张图
我们的需求是找出满足cf1:col2=c22这条记录的cf1:col1的值，实现方法如图，首先根据cf1:col2=c22查找到该记录的行键，然后再通过行健找到对应的cf1:col1的值。其中第二步是很容易实现的，因为Hbase的行键是有索引的，那关键就是第一步，如何通过cf1:col2的值找到它对应的行键。很容易想到建立cf1:col2的映射关系，即将它们提取出来单独放在一张索引表中，原表的值作为索引表的行键，原表的行键作为索引表的值，这就是Hbase的倒排索引的思想。
开源方案：
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=zhangsanRowKey设计案例剖析
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能尽可能的将数据打散到整个集群中，不要让连续的数据集中在一个
region里面， 均衡负载，避免热点问题(加盐，哈希)- 设计的RowKey应尽量简短，太长影响Hfile和MemStore的存储
扫一扫
1409
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
