浅谈Phoenix在HBase中的应用

一、前言

业务使用HBase已经有一段时间了，期间也反馈了很多问题，其中反馈最多的是HBase是否支持SQL查询和二级索引，由于HBase在这两块上目前暂不支持，导致业务在使用时无法更好的利用现有的经验来查询HBase。虽然HBase本身不支持SQL，但业界还是有现成的方案来支持，如Hive、Impala、Phoenix等。众多方案各有各的优势，本文主要对Phoenix作一个大概的介绍。

Phoenix中文翻译为凤凰, 其最早是Salesforce的一个开源项目，Salesforce背景是一个搞ERP的，ERP软件一个很大的特点就是数据库操作，所以能搞出一个数据库中间件也是很正常的。而后，Phoenix成为Apache基金的顶级项目。

Phoenix具体是什么呢，其本质是用Java写的基于JDBC API操作HBase的开源SQL引擎。它有如下几个功能特性：

图1.phoenix功能特性

我觉得值得关注的几个特性主要有以下几块：

• 通过JDBC API实现了大部分的java.sql接口，包括元数据API
• DDL支持：通过CREATE TABLE、DROP TABLE及ALTER TABLE来添加/删除
• DML支持：用于逐行插入的UPSERT VALUES,用于相同或不同表之间大量数据传输的UPSERT SELECT,用于删除行的DELETE
• 事务支持：通过客户端的批处理实现的有限的事务支持(beta测试中)
• 二级索引支持：
• 遵循ANSI SQL标准

当前使用Phoenix的公司有很多，如下图所示：

![2] 图2.phoenix使用公司

对于我们公司来说，虽然HBase用得多，但用Phoenix的比较少。从自己测试来看，Phoenix确实还存在各种不稳定，如下面描述的几点问题：

• 最新版本对HBase、Hadoop等有严格版本控制，对于已经用上HBase的业务来说要升级HBase版本适配Phoenix代价太大
• 与HBase强相关，作为HBase中的一个组件启动，HBase元数据容易遭到破坏
• 官方提供的创建索引方法，容易导致插入失败，查询失败，程序崩溃等问题

我觉得Phoenix总体思路还是很不错的，但本身太冒进，急于集成新功能，但现有的功能所存在的问题却并未有很好的解决方案，导致版本很多，但没有一个版本能放心在生产环境使用。下面关注一下Phoenix的整体设计思路。

二、Phoenix架构

上面说到，Phoenix是以JDBC驱动方式嵌入到HBase中的，在部署时只有一个包，直接放HBase的lib目录，逻辑构架如下：

![3] 图3.phoenix_structure

从图中可看出，每个RS结点上，都会有一个Phoenix协处理器来处理每个表、每个region的数据，应用端通过Phoneix客户端与HBase客户端打交道，从而实现Sql化访问HBase数据。下面先来说下Coprocessor。

2.1 Coprocessor

HBase的协处理器主要受Google BigTable的影响，具体可参考Dean-Keynote-Ladis2009-page 66-67。 对于HBase来说，引入Coprocessor也是为了提供更好的并行计算能力，而无需依赖于Hadoop的MapReduce。同时，基于Coprocessor，可以更好的实现二级索引、复杂过滤规则、权限访问控制等更接地气的特性。Coprocessor有两种类型，Observer和EndPoint。

前者Observer，类似于RDBMS的触发器，主要作用于RegionServer服务端，通过重载Coprocessor框架的Upcall函数插入用户自己的逻辑，这些逻辑只有在固定的事件发生时才会被触发调用执行，主要有三类hook接口：RegionObserver、