HBase高性能复杂条件查询引擎

　　在这次的审稿过程中有幸得到了Ted Yu和梁堰波先生的反馈，大家就一些感兴趣的内容进行了讨论。该方案由一个智能交通解决方案演变而来，设计之初仅寄希望于通过二级索引提升查询性能，由于在前期架构时充分考虑了通用性以及对复杂条件的支持，在后来的演变中逐渐被剥离出来形成了一个通用的查询引擎。Ted Yu对“查询决策器”表示了关心，他指出类似的组件同时也是Phoenix, Impala用于支持SQL查询的核心组件，但是这类组件很难引入到HBase中，因为HBase专注于byte[]的操作。对此，方案在设计时避开了“SQL解析”和“在各种数据类型与byte[]之间进行转化”的棘手问题，而是使用了一组可以描述查询的Query API，这与Hibernate中提供Criteria接口的做法非常相似，在Hibernate中既支持HQL语句的查询又支持使用Criteria接口以编程方式描述的查询，对于我们来说选择类似后者的做法实现起来要快速和容易的多，而查询条件中的值在构造之初就以byte[]的形式传递，避免了决策器解析时的类型判定和转化问题。

题记

——索引的实质是另一种编排形式的数据冗余，高效的检索源自于面向查询特别设计的编排形式，如果再辅以分布式的计算框架，就可以支撑起高性能的大数据查询。

正文

Apache HBase™是一个分布式、可伸缩的NoSQL数据库，它构建在Hadoop基础设施之上，依托于Hadoop的迅猛发展，HBase在大数据领域的应用越来越广泛，成为目前NoSQL数据库中表现最耀眼，呼声最高的产品之一。像其他NoSQL数据库一样，HBase也有其适用范围，就应对复杂条件的查询来说，一般认为它并不是非常适合，熟悉HBase的开发人员对此应该有一定的体会，但是基于普遍的需求，开发者们希望HBase在保持高性能优势的同时能对复杂条件的查询给予一定的支持，而本文将要介绍的正是一种在HBase现行机制下以非侵入式实现的基于二级多列索引的高性能复杂条件查询引擎。

问题

　　目前HBase主要应用在结构化和半结构化的大数据存储上，其在插入和读取上都具有极高的性能表现，这与它的数据组织方式有着密切的关系，在逻辑上，HBase的表数据按RowKey进行字典排序， RowKey实际上是数据表的一级索引（Primary Index），由于HBase本身没有二级索引（Secondary Index）机制，基于索引检索数据只能单纯地依靠RowKey，为了能支持多条件查询，开发者需要将所有可能作为查询条件的字段一一拼接到RowKey中，这是HBase开发中极为常见的做法，但是无论怎样设计，单一RowKey固有的局限性决定了它不可能有效地支持多条件查询。通常来说，RowKey只能针对条件中含有其首字段的查询给予令人满意的性能支持，在查询其他字段时，表现就差强人意了，在极端情况下某些字段的查询性能可能会退化为全表扫描的水平，这是因为字段在RowKey中的地位是不等价的，它们在RowKey中的排位决定了它们被检索时的性能表现，排序越靠前的字段在查询中越具有优势，特别是首位字段具有特别的先发优势，如果查询中包含首位字段，检索时就可以通过首位字段的值确定RowKey的前缀部分，从而大幅度地收窄检索区间，如果不包含则只能在全体数据的RowKey上逐一查找，由此可以想见两者在性能上的差距。

　　受限于单一RowKey在复杂查询上的局限性，基于二级索引（Secondary Index）的解决方案成为最受关注的研究方向，并且开源社区已经在这方面已经取得了一定的成果，像ITHBase、IHBase以及华为的hindex项目，这些产品和框架都按照自己的方式实现了二级索引，各自具有不同的优势，同时也都有一定局限性，本文阐述的方案借鉴了它们的一些优点，在确保非侵入的前提下，以高性能为首要目标，通过建立二级多列索引实现了对复杂条件查询的支持，同时通过提供通用的查询API，以及完全基于配置的索引结构，完全封装了索引的创建和使用细节，使之成为一种通用的查询引擎。

原理

　　“二级多列索引”是针对目标记录的某个或某些列建立的“键-值”数据，以列的值为键，以记录的RowKey为值，当以这些列为条件进行查询时，引擎可以通过检索相应的“键-值”数据快速找到目标记录。由于HBase本身并没有索引机制，为了确保非侵入性，引擎将索引视为普通数据存放在数据表中，所以，如何解决索引与主数据的划分存储是引擎第一个需要处理的问题，为了能获得最佳的性能表现，我们并没有将主数据和索引分表储存，而是将它们存放在了同一张表里，通过给索引和主数据的RowKey添加特别设计的Hash前缀，实现了在Region切分时，索引能够跟随其主数据划归到同一Region上，即任意Region上的主数据其索引也必定驻留在同一Region上，这样我们就能把从索引抓取目标主数据的性能损失降低到最小。与此同时，特别设计的Hash前缀还在逻辑上把索引与主数据进行了自动的分离，当全体数据按RowKey排序时，排在前面的都是索引，我们称之为索引区，排在后面的均为主数据，我们称之为主数据区。最后，通过给索引和主数据分配不同的Column Family，又在物理存储上把它们隔离了起来。逻辑和物理上的双重隔离避免了将两类数据存放在同一张表里带来的副作用，防止了它们之间的相互干扰，降低了数据维护的复杂性，可以说这是在性能和可维护性上达到的最佳平衡。