浅谈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

图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有两种类型,ObserverEndPoint

前者Observer,类似于RDBMS的触发器,主要作用于RegionServer服务端,通过重载Coprocessor框架的Upcall函数插入用户自己的逻辑,这些逻辑只有在固定的事件发生时才会被触发调用执行,主要有三类hook接口:RegionObserverWALObserverMasterObserver。RegionObserver提供了一些数据层操作事件的hook,如Put、Get、Delete和Scan等,在每个操作发生或结束时,会触发调用一些前置的Hook(pre+操作,如preGet)或后置的Hook(post+操作,如postGet);WALObserver提供了WAL相关的Hook;MasterObserver提供了HMaster相关的Hook。

后者EndPoint类似于RDBMS的存储过程,主要作用于客户端,客户端可以调用这些EndPoint执行一段Server端代码,并将Server端代码结果返回给客户端进一步处理,如常见聚合操作,找一张大表某个字段的最大值,如果不用Coprocesser则只能全表扫描,在客户端遍历所有结果找出最大值,且只能利用有限的客户端资源进行迭代计算,无法利用上HBase的并发计算能力;如果用了Coprocessor,则client端可在RegionServer端执行统计每个Region最大值的逻辑,并将Server端结果返回客户端,再找出所有Server端所返回的最大值中的最大值得到最终结果,很明显,这种方式尽量将统计执行下放到Server端,Client端只执行一些最后的聚合,大幅提高了统计效率;还有一个很常见的需求可能就是统计表的行数,其逻辑和上面一样,具体可参考Coprocessor Introduction,在这里就不展开了,后面有机会针对Coprocessor单独展开介绍。

2.2 Phoenix 实现原理

Phoenix的SQL实现原理主要也是基于一系列的Scan操作来完成,Scan是HBase的批量扫描过程。这一系列的Scan操作也是分散到各台RegionServer上通过Coprocessor来完成。主要用到的是RegionObserver,通过RegionObserver在postScannerOpen Hook中将RegionScanner替换成支持聚合操作的定制化Scanner,在真正执行聚合时,会通过自定的Scan属性传递给RegionScanner,在这个Scan中也可加入一些过滤规则,尽量减少返回Client的结果。

2.3 Phoenix 数据模型

Phoenix在数据模型上是将HBase非关系型形式转换成关系型数据模型 ,如下图所示

6

图4.Phoenix Data Model

对于Phoenix来说,HBase的rowkey会被转换成primary key,column family如果不指定则为0否则字段名会带上,qualifier转换成表的字段名,如下是创建一个Phoenix表的例子,以创建表test为例,主键为id即为HBase的rowkey, column family为i, qualifier为name和age。

create table "test" ("id" varchar(20) primary key,"i"."name" varchar(20) ,"i"."age" varchar(20));

Phoenix还支持组合primary key,即由多个字段联合组成主键,对于组合主键来说,在HBase底层会把主键的多个字段组合成rowkey显示,其它字段为HBase的qualifier显示。如上面test表,假设id和name为主键,创建表语句又变成:

create table "test" ("id" varchar(20), "name" varchar(20) ,"i"."age" varchar(20),constraint pk PRIMARY KEY("id","name"));

这样,假设插入一条数据:如下所示

upsert into "test" values ('1','a','23');

在HBase中,rowkey即为"1a", i:age 为 23。这里,可能大家对双引号有点疑问,对于Phoenix来说,加了引号的话,不管是表还是字段名,会变成大小写敏感,不加的话,会统一转换成大写字母。

2.4 Phoenix所支持的语法

目前Phoenix已经支持关系型数据库的大部分语法,如下图所示:

7

图4.Phoenix 语法

具体语法用法可参考Phoenix官网,写得比较详细。

三、 Phoenix二级索引

我相信,二级索引这个特性应该是大部分用户引入Phoenix主要考虑的因素之一。HBase因其历史原因只支持rowkey索引,当使用rowkey来查询数据时可以很快定位到数据位置。现实中,业务查询需求条件往往比较复杂,带有多个查询字段组合,如果用HBase查的话,只能全表扫描进行过滤,效率很低。而Phoenix支持除rowkey外的其它字段的索引创建,即二级索引,查询效率可大幅提升。

3.1 索引类别

3.1.1 Covered Indexes

从字面上可理解为覆盖索引,什么意思呢,即索引表中就包含你想要的全部字段数据,这样就只需要通过访问索引表而无需访问主表就能得到数据。创建方式如下:

create index my_index on test (v1) include(v2);

当执行select v2 from test where v1='...'时,就只会查找索引表数据,不会去主表扫描。

3.1.2 Global Indexes

全局索引适用于读多写少的场景。全局索引在写数据时会消耗大量资源,所有对数据的增删改操作都会更新索引表,而索引表是分布在各个结点上的,性能会受到影响。好处就是,在读多的场景下如果查询的字段用到索引,效率会很快,因为可以很快定位到数据所在具体结点region上,对于写性能就很慢了,因为每写一次,需要更新所有结点上的索引表数据。创建方式如下:

create index my_index on test (v1);

如果执行`select v2 from test where v1='...', 实际是用不上索引的,因为v2不在索引字段中,对于全局索引来说,如果查询的字段不包含在索引表中,则还是会去全表扫描主表。

3.1.3 Local Indexes

局部索引适用于写多读少场景,和全局索引类似,Phoenix会在查询时自动选择是否使用索引。如果定义为局部索引,索引表数据和主表数据会放在同一regionserver上,避免写操作时跨节点写索引表带来的额外开销(如Global Indexes)。当使用局部索引查询时,即使查询字段不是索引字段,索引表也会正常使用,这和Global Indexes是有区别的。在4.8版本之前,所有局部索引数据存放在一个单独的共享表中,4.8之后是存储在主表的一个独立的列族中。因为是局部索引,所以在client端查询使用索引时,需要扫描每个结点上的索引表以得到数据所在具体region位置,当region多时,查询时耗会很高,所以查询性能比较低,适合读少写多场景。创建局部索引方式:

create local index my_index on test (v1);

3.2 Mutable Indexing 和Immutable Indexing

3.2.1 IMMutable Indexing

不可变索引主要创建在不可变表上,适用于数据只写一次不会有Update等操作,在什么场景下会用到不可变索引呢,很经典的时序数据:write once read many times。在这种场景下,所有索引数据(primary和index)要么全部写成功,要么一个失败全都失败返回错误给客户端。不可变索引用到场景比较少,下面是创建不可变索引的方式:

create table test (pk VARCHAR primary key,v1 VARCHAR, v2 VARCHAR) IMMUTABLE_ROWS=true;

即在创建表时指定IMMUTABLE_ROWS参数为true,默认这个参数为false。如果想把不可变索引改为可变索引,可用alter修改:

alter table test set IMMUTABLE_ROWS=false;

3.2.2 Mutable Indexing

可变索引意思是在修改数据如Insert、Update或Delete数据时会同时更新索引。这里的索引更新涉及WAL,即主表数据更新时,会把索引数据也同步更新到WAL,只有当WAL同步到磁盘时才会去更新实际的primary/index数据,以保证当中间任何一个环节异常时可通过WAL来恢复主表和索引表数据。

四、性能

在官网,有作一个性能测试,主要是将Phoenix和Hive、Impala作一个对比。
先来看下和Hive的性能对比,测试基准如下:

 select count(1) from table over 10M and 100M rows. Data is 5 narrow columns. Number of Region Servers: 4 (HBase heap: 10GB, Processor: 6 cores @ 3.3GHz Xeon)

测试结果:

9

图6.Phoenix性能对比

从图中可看出,带有Key过滤的Phoenix耗时最少,不带Key过滤的Phoenix和基于HDFS的Hive性能差不多,直接基于HBase的Hive性能最差。

再来看下和Impala的对比,测试基准如下:

select count(1) from table over 1M and 5M rows. Data is 3 narrow columns. Number of Region Server: 1 (Virtual Machine, HBase heap: 2GB, Processor: 2 cores @ 3.3GHz Xeon)

测试结果:

10

图7.Phoenix性能对比Impala

从图中可看出,Impala执行时间比Phoenix长很多,原因大概有几点:Impala基于内存进行并行计算,容易内存吃紧,对HBase和HDFS的支持也还远远不够,性能比较差。

我在自己的HBase测试集群也作了下测试,主要测试数据插入和一些SQL操作的查询时耗。测试集群如下:

![11]
图8.测试集群

先来测试下插入100万记录的测试基准,如下所示:

  • 1.创建基本表,表主键由4个字段组成,HOST字段称为First PK,DOMAIN为Second PK, 依此类推,SPLIT ON指定8个分区。
CREATE TABLE IF NOT EXISTS %s (HOST CHAR(2) NOT NULL,
DOMAIN VARCHAR NOT NULL, 
FEATURE VARCHAR NOT NULL,
DATE DATE NOT NULL,
USAGE.CORE BIGINT,
USAGE.DB BIGINT,
STATS.ACTIVE_VISITOR INTEGER
CONSTRAINT PK PRIMARY KEY (HOST, DOMAIN, FEATURE, DATE))  
SPLIT ON   ('CSGoogle','CSSalesforce','EUApple','EUGoogle','EUSalesforce','NAApple','NAGoogle','NASalesforce')
  • 2.插入100万行记录
  • 3.执行如下查询条件测试
Query # 1 - Count - SELECT COUNT(1) FROM PERFORMANCE_1000000;
Query # 2 - Group By First PK - SELECT HOST FROM PERFORMANCE_1000000 GROUP BY HOST;
Query # 3 - Group By Second PK - SELECT DOMAIN FROM PERFORMANCE_1000000 GROUP BY DOMAIN;
Query # 4 - Truncate + Group By - SELECT TRUNC(DATE,'DAY') DAY FROM PERFORMANCE_1000000 GROUP BY TRUNC(DATE,'DAY');
Query # 5 - Filter + Count - SELECT COUNT(1) FROM PERFORMANCE_1000000 WHERE CORE<10;

测试结果如下:

    1. 插入100万条记录耗时70s
    1. Query #1 耗时1.032s
    1. Query #2 耗时0.025s
    1. Query #3 耗时0.615s
    1. Query #4 耗时0.608s
    1. Query #5 耗时1.026s

具体结果如下:

csv columns from database.
CSV Upsert complete. 1000000 rows upserted
Time: 69.672 sec(s)

                                COUNT(1) 
---------------------------------------- 
                                 1000000 
Time: 1.032 sec(s)

HO 
-- 
CS 
EU 
NA 
Time: 0.025 sec(s)

DOMAIN                                   
---------------------------------------- 
Apple.com                                
Google.com                               
Salesforce.com                           
Time: 0.615 sec(s)

DAY                     
----------------------- 
2018-01-28 00:00:00.000 
2018-01-29 00:00:00.000 
2018-01-30 00:00:00.000 
2018-01-31 00:00:00.000 
2018-02-01 00:00:00.000 
2018-02-02 00:00:00.000 
2018-02-03 00:00:00.000 
2018-02-04 00:00:00.000 
2018-02-05 00:00:00.000 
2018-02-06 00:00:00.000 
2018-02-07 00:00:00.000 
2018-02-08 00:00:00.000 
2018-02-09 00:00:00.000 
Time: 0.608 sec(s)

                                COUNT(1) 
---------------------------------------- 
                                   20209 
Time: 1.026 sec(s)

还作了下三种不同数量级下的性能对比,作了5种SQL查询操作对比,如上测试基准第3条所描述的查询条件,结果如下:

12

图9.Phoenix不同数据量级测试对比

从结果看,随着数量级的增加,查询时耗也随之增加,有一个例外,就是当用First PK索引字段作聚合查询时,用时相差不大。总的来说,Phoenix在用到索引时查询性能会比较好。那对于Count来说,如果不用Phoenix,用HBase自带的Count耗时是怎样的呢,测了一下,HBase Count 100万需要33s, 500万需要139s,1000万需要284s,性能还是很差的。对于大表来说基本不能用Count来统计行数,还得依赖于基于Coprocessor机制来统计。

从上面测试来看下,Phoenix的性能不能说最好,也存在各种问题,就如开篇说的,版本不稳定,BUG过多,容易影响集群稳定性。

五、总结

总的来说,目前并没有一种很完美的方案来解决SQL查询、二级索引问题,都或多或少存在各种问题。不过HBase的Coprocessor是个好东西,很多功能可以基于此特性进行二次开发,后续可以深入研究一下。

六、参考

[1] https://community.hortonworks.com/articles/61705/art-of-phoenix-secondary-indexes.html

[2] https://github.com/forcedotcom/phoenix/wiki/Secondary-Indexing

[3] http://phoenix.apache.org/secondary_indexing.html

posted @ 2018-01-28 15:16  ballwql  阅读(...)  评论(... 编辑 收藏