hbase 数据导出乱码_数据查询的玄铁剑：云HBase原生二级索引发布

本文主要是介绍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

通过Java API进行数据访问

// 定义一些常量

从上例可见，用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

对于大部分业务来说，表里有数十列是常态，个别表可能会有数百列。如果为了建冗余索引，而把这数百列的列名再写一遍，无疑是巨大的负担(只能写工具自动化做，人来做太容易出错)。全冗余索引的新语法给人工维护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)：

'department',

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

考虑如下查询：

-- 查找所有计算机学院(cs)的学生的姓名(name)

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

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

因此，在分布式场景，尤其是节点很多的大集群，回查主表带来的性能损耗是巨大的(RT可能会增长数倍)。这也是我们设计全冗余索引的初衷：避免回查，提高性能。