HBase产品|数据查询的玄铁剑：云HBase原生二级索引起布

HBase原生提供了主键索引，用户能够根据Rowkey进行高效的单行读、前缀匹配、范围查询操做。但若须要使用属性列进行查询时，则只能使用filter在查询范围内进行逐行过滤。在扫描范围较大时，会浪费大量的IO，请求RT也没法保证。为此，HBase加强版推出了原生二级索引来解决非Rowkey查询的性能问题。

云HBase加强版是基于阿里内部的HBase分支(亦称Lindorm)构建的，二级索引是其核心能力之一，历经多年双11大考，在性能、吞吐、稳定性等方面都具有核心竞争力。

下面，咱们从一组示例出发来了解索引的使用及其能力。

功能简介

从表设计和查询设计的角度看，HBase加强版二级索引的使用与RDBMS的二级索引基本一致。下面咱们看一个简单的示例：大学生信息表(Students)，该表的主键(即rowkey)是学号，非主键是学生姓名和所属的学院名称。学生与学院是多对一的关系。

经过HBase shell建表，建索引：

https://help.aliyun.com/document_detail/119572.html

# 建立主表student，列族名为f
create 'student', 'f'

# 建立索引表department，为department列建索引
# COVERED_ALL_COLUMNS是HBase加强版引入的新属性关键字，
# 意味冗余主表student中的全部列，以此来避免回查主表
create_index 'department', 'student', {INDEXED_COLUMNS => ['f:departement']}, {COVERED_COLUMNS => ['COVERED_ALL_COLUMNS']}

经过Java API进行数据访问

// 定义一些常量
String id = "11";   // 一个随机的学号
String studentName = "Harry";
String department = "CS";
byte[] f = Bytes.toBytes("f");
byte[] qStudent = Bytes.toBytes("name");
byte[] qDepartment = Bytes.toBytes("department");

// 写入一个学生的数据
Put put = new Put(Bytes.toBytes(id));
put.addColumn(f, qStudent, Bytes.toBytes(studentName));
put.addColumn(f, qDepartment, Bytes.toBytes(department));
Table t = conn.getTable("student");
t.put(put);         // put成功返回意味着主表和索引表都成功更新，变动当即可见

// 按department进行查询
Scan scan = new Scan();
SingleColumnValueFilter where = new SingleColumnValueFilter(
    f, qDepartment, EQUAL, Bytes.toBytes(department));
scan.setFilter(where);
ResultScanner rs = t.getScanner(scan);
// 处理查询结果...

从上例可见，用HBase API直接描述查询请求便可使用索引。HBase加强版会自动根据filter以及索引schema来匹配到最合适的索引进行查询，必要时，在查完索引后也会回查主表(上例中，若是不是全冗余索引，则会回查主表来补全列)。更多使用上的说明请参考二级索引开发手册：

https://help.aliyun.com/document_detail/144577.html

HBase加强版二级索引的主要特性有：

• 支持为单个主表建多个索引

• 支持单列和多列索引(组合索引)

• 支持冗余索引：可显式指定冗余列，或冗余全部列，避免回查主表的性能损耗

• 查询优化：根据scan和filter自动选择合适的索引表进行查询，必要时会自动回查主表

• online schema change：支持给已经在使用的表建索引，对主表读写无影响

• 支持TTL：索引表会自动继承主表的TTL，主表和索引表数据一块儿过时

• 支持自定义数据版本：用户自定义数据时间戳写入(暂未开放)

  
  

产品优点

• 高性能

HBase加强版二级索引直接内置于内核中，并作了深度优化，提供了强大的吞吐与性能。下图是HBase加强版二级索引与Apache Phoenix的全局索引的性能对比：

从上图可见，不管RT仍是吞吐，HBase加强版二级索引均远超Apache Phoenix。

• 写后可读

数据写入返回成功后，则索引数据可当即被读到，消除传统异步建索引方案中的数据延迟，提供具备必定程度的强一致性语义(主表和索引表的数据一致性)，具体语义以下：

• 返回客户端写入成功，以后可当即读到刚写入的数据(包括主表和索引数据)；写入过程当中不保证同时可见

• 返回超时或IO出错，则在一段时间内，该数据在主表和索引表中的可见性没法肯定，但保证最终一致，即要么全成功，要么全不成功

HBase加强版提供的”写成功后更新当即可见的语义“，可用于一些分布式协同的任务，好比spark，在某些节点更新数据，另一些节点读取上一轮计算写入的数据。此时，必定能够读到刚写入的数据。

• 全冗余索引

全冗余索引可完全避免回查主表，提高性能；同时也是语法糖，避免手工维护复杂的DDL。下面分别介绍。

若是查询中须要的列在索引表中没有，则查完索引后，还需回查主表。在分布式场景下，回表查询会使得查询RT大幅度升高，最差状况下可能会回查主表的所有region，访问集群中的全部机器。此时，索引带来的性能收益已经无关紧要。经过精良的查询设计和索引设计，咱们能够在设计阶段避免回查，但随着业务发展变化，这个约束很难维持。所以，仍然须要冗余索引(Covered Index)来解决。

HBase加强版创造性的引入了全冗余索引的概念，即冗余主表中的全部列，以此来完全避免回查主表。配合HBase的schema-free特性，主表中新增的任何列都会自动冗余到索引表中。不管业务模式如何变化，都不须要回查主表。

同时，全冗余也是可大幅度提高效率的语法糖，咱们能够对好比下两个SQL语句：

CREATE INDEX idx ON dt (c1, c2) include(c3, c4, c5, c6, ....);
CREATE INDEX idx ON dt (c1, c2) include(ALL);

对于大部分业务来讲，表里有数十列是常态，个别表可能会有数百列。若是为了建冗余索引，而把这数百列的列名再写一遍，无疑是巨大的负担(只能写工具自动化作，人来作太容易出错)。全冗余索引的新语法给人工维护DDL提供了可能。

为了得到上述两点收益，全冗余索引的代价是会占用更多存储空间。配合HBase加强版深度优化的ZStandard压缩算法：

https://help.aliyun.com/document_detail/119549.html

可有效下降冗余带来存储开销。冷热分离特性亦可应用于索引表，进一步控制成本。

• 基于原生API的查询优化

对大部分场景来讲，业务一行代码不改就能用上索引。

从本文开头的示例代码中可见：

• 写：写主表便可，会自动同步到索引，强一致。用户无需担忧索引更新的问题

• 读：基于主表进行查询，直接按业务逻辑进行查询表达，系统自动选择合适的索引表进行查询

这样，用户只需为那些性能很差的查询设计并添加索引，便可从索引特性中受益，实际的数据读写代码通常不须要修改。同时，既有的HBase生态相关的产品，均可以无缝使用上索引。一些如Spring的框架软件也可帮助用户得到业务上的灵活性。

• 大表建索引

从一开始就设计好主表和所有索引几乎是不可能的。所以，在后续业务发展过程当中，索引表可能须要不断的删除和新增。为此，对一个已经有大量数据表添加、删除索引，将是一个关键的运维操做。HBase加强版二级索引针对此场景作了特别的优化：

• schema在线修改：索引的变动不影响主表的正常读写(就像一次普通的alter表操做)，不影响其余索引表

• 服务端rebuild：在服务端为主表的历史数据构建索引

• 支持对超大主表添加索引：支持TB级别的主表添加新索引

• 流控：大主表的索引rebuild会消耗大量的系统资源，所以，精准的流控便可在兼顾索引构建速度的前提下，保障系统总体性能不会被影响

在有上述特性的加持下，索引变动的运维成本和风险大大下降，从容的适应业务发展。

原理简介

HBase加强版二级索引是一种全局二级索引，每一个索引表都是一张独立的HBase表。每张表的主键(rowkey)设计决定了其能支持的查询模式。当同一份数据有多种rowkey组织时，就能支持多种查询模式。这里，主表和它的索引表，能够看作是同一份数据的不一样组织形式，各自可以高效的支持必定的查询模式。

考虑本文开始时给出的学生信息表的示例：

主表Student：以学号(id)为主键(rowkey)，每行有两列，学生姓名(name)和所属的学院(department)。该设计仅支持按id进行查询。若是用户要按department或者name来查询，须要全表扫描 + filter。在学生数较少时，这种暴力扫描彻底可行。但在数据量大时(数十万乃至上亿时)，这种操做是没法执行的。

为了高效的支持按department查询，可为其创建一个全冗余索引(使用HBase shell)：

create_index 'department', 'student', {INDEXED_COLUMNS => ['f:departement']}, {COVERED_COLUMNS => ['COVERED_ALL_COLUMNS']}

在建索引时，系统会自动为主表中的存量数据构建索引，写入索引表中。主表行和索引行是一一对应的。以后主表上发生的数据更新，也会自动同步给索引表。

考虑以下查询：

-- 查找全部计算机学院(cs)的学生的姓名(name)
select name from student where department = 'cs';

这个查询会直接命中索引表，按department列进行前缀匹配。从每个索引行中提取name字段，返回给客户端。

若是咱们没有创建冗余索引，则索引表中不会存在name列。此时，在从索引表中读取到学号(id)后，必须回查主表(三次按id的单行读)来读取name列。在分布式场景下，10/12/13这三个id的数据可能分布在三台机器上。所以，回查主表最差状况下须要3次RPC，加上查索引表的一次RPC，共需4次RPC。而若是是冗余索引，则只需查索引表的一次RPC便可。

所以，在分布式场景，尤为是节点不少的大集群，回查主表带来的性能损耗是巨大的(RT可能会增加数倍)。这也是咱们设计全冗余索引的初衷：避免回查，提升性能。

总结

数据只有被查询才能创造价值，HBase原生高性能二级索引为多维度查询提供了一种有效的解决方案。在表设计上，用户能够参考MySQL等关系型数据库的索引设计思路来进行HBase的索引设计。业务无需更改代码，查询优化可自动进行索引表的选择。强一致、全冗余索引等特性也有效下降了业务的使用门槛。

将来，咱们将对索引作进一步的优化和扩展，提供优质的用户体验。欢迎你们体验HBase加强版。如您有对HBase相关的任何问题，欢迎经过钉钉与咱们联系(钉钉搜索“云HBase值班”)。

相关连接

• HBase Java SDK

  
  

  https://help.aliyun.com/document_detail/119568.html

• HBase加强版Shell

  https://help.aliyun.com/document_detail/119572.html

• 二级索引帮助文档

  https://help.aliyun.com/document_detail/144577.html

HBase 官方社区推荐必读好文

HBase 原理|HBase 内存管理之 MemStore 进化论

HBase 抗战总结|阿里巴巴 HBase 高可用8年抗战回忆录

HBase 实践|说好不哭，但 HBase 2.0 真的好用到哭