HBase二级索引实战：从方案选型到构建维护的完整指南

做HBase索引这事，我见过太多团队从"加个索引不就完了"开始，到"查询是快了，但写入毛了、数据对不上了、重建索引跑了一整夜"收场。索引创建与维护远不是一条create index那么简单，它牵扯到方案选型、rowkey设计、存量构建、增量同步、一致性校验、热点治理一整套链路。这篇文章不聊虚的，我把这些年在大数据生产环境里折腾HBase索引的完整思路、落地步骤和踩坑记录一次性摊开，希望能帮正在做技术选型或者已经被索引问题缠住的同学省点时间。

1. 先搞清楚HBase的查询短板，才知道索引到底在解决什么问题

1.1 原生Get/Scan为什么撑不起业务查询

HBase的存储模型决定了它的查询逻辑。一张表的数据按rowkey的字典序排列，分布在多个Region上，每个Region内部又是一个有序的LSM结构。这个设计让它在海量写入和点查场景下表现非常好，但代价是查询能力非常单一：

• 按rowkey精确查询，走Get，一次RPC就能拿到数据，这是HBase最舒服的场景。
• 按rowkey范围扫描，走Scan，只要startRow和stopRow设计得合理，性能也还行。
• 一旦查询条件落在非rowkey的普通列上，比如"查所有状态为待处理的订单""查某个用户最近一周的登录记录"，原生HBase就必须全表扫描，或者设计多层Scan去凑结果。

问题就出在这。全表扫描在几千万行的小表上尚且可以容忍，到了几亿、几十亿行的大数据场景，一个Scan下去Region Server的CPU和IO直接被打满，GC也飙起来，整个集群的写入都会受影响。我遇到过最夸张的一次，一个业务方为了查一个普通字段，直接拖慢了同集群另外十几个在线业务。所以只要查询维度不是rowkey，索引就不是"可选项"，而是"必选项"。

1.2 二级索引到底在解决哪几类问题

与其说二级索引是一个功能，不如说它是一种"空间换时间"的存储策略：把"按列查rowkey"这个操作，提前在写入阶段算好，查询时直接走一次精确匹配。

从业务场景归类，HBase索引主要解决三类问题：

• 非主键等值查询：比如订单表按用户ID查，用户ID不是rowkey。这种场景最简单的索引方案就是"索引表"，rowkey反转为userId_orderId，value存完整订单信息或主表rowkey。
• 多条件组合过滤：比如"状态=成功且金额>1000"。这类场景单靠一张索引表很难cover所有组合，往往需要引入Phoenix全局索引或者外部索引引擎，通过多维组合生成不同的索引项。
• 排序与分页：HBase的Scan天然按rowkey有序，如果业务需要按时间倒序、按金额排序，索引的rowkey设计可以直接决定排序是否高效。

很多人在设计阶段没想清楚上面这三类问题，结果索引建到一半发现查不动，或者写放大严重，又推倒重来。先盘清业务查询模型，再决定索引方案，这个顺序绝对不能反。

2. 主流的索引方案选型：Phoenix、协处理器、外部索引引擎怎么挑

2.1 三种方案的实现原理

HBase生态里做二级索引，总结下来就三条路：基于Phoenix的全局索引/本地索引、基于协处理器自己实现索引表、引入Solr/Elasticsearch这样的外部索引引擎。三条路的底层逻辑完全不一样。

Phoenix方案是把SQL编译成HBase的Scan/Get操作，同时通过协处理器在Region Server端拦截写入，自动维护索引表。全局索引适合读多写少，本地索引适合写多读少，因为它把索引数据和主表数据放在同一个Region，避免了跨Region的写开销。

协处理器自研方案的本质是自己在写主表的时候，通过RegionObserver的prePut/preDelete钩子，同步往索引表里写一份数据。查询的时候先查索引表拿rowkey，再回主表拿完整数据。这个方案的好处是灵活，索引字段、索引表结构、同步逻辑全部可控；坏处是协处理器的Bug会直接影响主表写入，排查问题难度大。

外部索引引擎方案是把主表数据通过实时管道同步到Solr或ES，查询走搜索引擎，拿回rowkey或完整文档后再回HBase补全字段。这个方案把索引的存储和查询完全独立出去，读写互相干扰小，还能支持全文检索和复杂聚合。代价是要额外维护一套搜索引擎集群，数据链路变长，一致性保障也更难。

2.2 选型对比：从一致性、维护成本、查询灵活性看

我建议用下面这张表来帮助选型，这是我在多个项目里总结出来的判断维度：

这里有个很核心的权衡点：一致性和灵活性是互相打架的。Phoenix追求强一致，所以索引表必须在同一事务里提交，写放大和锁竞