「从零单排HBase 12」HBase二级索引Phoenix使用与最佳实践

Phoenix是构建在HBase上的一个SQL层，能让咱们用标准的JDBC APIs对HBase数据进行增删改查，构建二级索引。固然，开源产品嘛，天然须要注意“避坑”啦，阿丸会把使用方式和最佳实践都告诉你。 1.什么是Phoenix

Phoenix彻底使用Java编写，将SQL查询转换为一个或多个HBase扫描，并编排执行以生成标准的JDBC结果集。Phoenix主要能作如下这些事情：

• 将SQL查询编译为HBase扫描scan

• 肯定scan的开始和中止位置

• 将scan并行执行

• 将where子句中的谓词推送到服务器端进行过滤

• 经过服务器端挂钩（称为协处理器co-processors）执行聚合查询

除了这些以外，phoenix还进行了一些有趣的加强，以进一步优化性能：

• 二级索引，以提升非行键查询的性能（这也是咱们引入phoenix的主要缘由）

• 跳过扫描过滤器来优化IN，LIKE和OR查询

• 可选的对行键进行加盐以实现负载均衡，避免热点

2.Phoniex架构

Phoenix结构上划分为客户端和服务端两部分：

• 客户端包括应用程序开发，将SQL进行解析优化生成QueryPlan，进而转化为HBase Scans，调用HBase API下发查询计算请求，并接收返回结果；

• 服务端主要是利用HBase的协处理器，处理二级索引、聚合及JOIN计算等。

Phoiex的旧版架构采用重客户端的模式，在客户端执行一系列的parser、query plan的过程，以下图所示。

 

这种架构存在使用上的缺陷：

• 应用程序与Phoenix core绑定使用，须要引入Phoenix内核依赖，一个单独Phoenix重客户端集成包已达120多M；

• 运维不便，Phoenix仍在不断优化和发展，一旦Phoenix版本更新，那么应用程序也须要对应升级版本并从新发布；

• 仅支持Java API，其余语言开发者不能使用Phoenix。

所以，社区进行改造，引入了新的“轻客户端”模式。

 

 

轻客户端架构将Phoenix分为两部分：

• 客户端是用户最小依赖的JDBC驱动程序，与Phoenix依赖进行解耦，支持Java、Python、Go等多种语言客户端；

• 将QueryServer部署为一个独立的的HTTP服务，接收轻客户端的请求，对SQL进行解析、优化、产生执行计划；

3.基本使用

传送门：https://phoenix.apache.org/language/index.html（平时多参考官方的语法）

3.1 建表

在phoenix shell上建的表默认只有一个region，建表时要注意预分区

// step1: 【phoenix shell】若是没有建立过namespace的话，须要这一步
create schema "MDW_NS";
或者
create schema mdw_ns;


// step2: 【hbase shell】在原生HBase上建立一个表，为何须要这一步（可使用预分区的功能，phoenix的建表语句在分区上的支持比较弱）
create 'MDW_NS:TABLE_DEMO', 'F1', {NUMREGIONS => 16, SPLITALGO => 'HexStringSplit'}


// step3: 【phoenix shell】建立一个同步的phoenix表
craete table if not exists mdw_ns.table_demo (
    id varchar not null primary key,
    f1.a varchar,
    f1.b varchar,
    f1.c varchar,
    f1.d varchar,
    f1.e varchar,
    f1.f varchar,
    f1.g varchar,
    f1.h varchar
)
TTL=86400,
UPDATE_CACHE_FREQUENCY=900000;

3.2 建索引

须要关注索引表的散列问题

// 方式1：split分区（适用于索引列知足散列条件）
create index table_demo_a on mdw_ns.table_demo(f1.a) split on ('10000000','20000000','30000000','40000000','50000000','60000000','70000000','80000000','90000000','a0000000','b0000000','c0000000','d0000000','e0000000','f0000000');


// 方式2：salt分区（适用于索引列不知足散列条件）
create index table_demo_a on mdw_ns.table_demo(f1.a) salt_buckets = 16;


// 注意：索引列DESC的使用是不支持的，但对原表的主键是支持desc的
[x] create index table_demo_a on mdw_ns.table_demo(f1.a desc)
[√] craete table if not exists mdw_ns.table_demo (
    f1.a varchar,
    f1.b varchar,
    f1.c varchar,
    f1.d varchar,
    f1.e varchar,
    f1.f varchar,
    f1.g varchar,
    f1.h varchar,
    constraint pk primary key(a, b desc)
    );

3.3 select查询

[√] select * from mdw_ns.table_demo limit 10;
// 主键查询
[√] select * from mdw_ns.table_demo where id = '0000000000';
// 二级索引查询必须指定列名
[x] select * from mdw_ns.table_demo where a = '0000000000';
[√] select id, a, b, c, d, e from mdw_ns.table_demo where a = '0000000000'

 

4.最佳实践 4.1 大小写问题

注意点：phoenix对于（表名，列名，namespace，cf）是区分大小写，默认都会转为成大写。若是要屏蔽转换，须要在对应的字符上用双引号（"）。数据类型是字符串的话，要用单引号（'）包含。

// case1: 查询「mdw_ns」（namespace）下「table_demo」（table），其中「f1」（列簇）+ 「A」（列名）为字符串「'0000000000'」 的记录
select id, a, b, c from "mdw_ns"."table_demo" where "f1".a = '0000000000'


// case2: 查询PS_NS（namespace）下「MODULE_REVISION」（table）的记录
select * from ps_ns.module_revision;

 

4.2 加盐注意事项

加盐一般用来解决数据热点和范围查询同时存在的场景，原理介绍能够参考社区文档。

通常咱们只在同时知足如下需求的时候，才使用加盐：

• 写热点或写不均衡

• 须要范围查询

有热点就要打散，但打散就难以作范围查询。所以，要同时知足这对相互矛盾的需求，必须有一种折中的方案：既能在必定程度上打散，又能保证必定程度的有序。这个解决方案就是加盐，其实叫分桶(salt buckets)更准确。数据在桶内保序，桶之间随机。写入时按桶个数取模，数据随机落在某个桶里，保证写请求在桶之间是均衡的。查询时读取全部的桶来保证结果集的有序和完备。

反作用：

写瓶颈：因为桶内保序，因此即便region不断split变多，全表实际上仍是只有数量为buckets的region用于承担写入。当业务体量不断增加时，由于没法调整bucket数量，不能有更多的region帮助分担写，会致使写入吞吐没法随集群扩容而线性增长。致使写瓶颈，从而限制业务发展。

读扩散：select会按buckets数量进行拆分和并发，每一个并发都会在执行时占用一个线程。select自己一旦并发过多会致使线程池迅速耗尽或致使QueryServer因太高的并发而FGC。同时，本应一个RPC完成的简单查询，如今也会拆分红多个，使得查询RT大大增长。

这两个反作用会制约业务的发展，尤为对于大致量的、发展快速的业务。由于桶个数不能修改，写瓶颈会影响业务的扩张。读扩散带来的RT增长也大大下降了资源使用效率。

 

必定不要为了预分区而使用加盐特性，要结合业务的读写模式来进行表设计。

Buckets个数跟机型配置和数据量有关系，能够参考下列方式计算，其中 N 为 Core/RS 节点数量：

单节点内存 8G: 2*N

单节点内存 16G: 3*N

单节点内存 32G: 4*N

单节点内存 64G: 5*N

单节点内存 128G: 6*N

注意：索引表默认会继承主表的盐值；bucket的数目不能超过256；一个空的Region在内存中的数据结构大概2MB，用户能够评估下单个RegionServer承载的总Region数目，有用户发生过在低配置节点上，建大量加盐表直接把集群内存耗光的问题。

 

4.3 慎用扫全表、OR、Join和子查询

虽然Phoenix支持各类Join操做，可是Phoenix主要仍是定位为在线数据库，复杂Join，好比子查询返回数据量特别大或者大表Join大表，在实际计算过程当中十分消耗系统资源，会严重影响在线业务，甚至致使OutOfMemory异常。对在线稳定性和实时性要求高的用户，建议只使用Phoenix的简单查询，且查询都命中主表或者索引表的主键。另外，建议用户在运行SQL前都执行下explain，确认是否命中索引，或者主键，参考explain社区文档。

4.4 Phoenix不支持复杂查询

Phoenix 的二级索引本质仍是前缀匹配，用户能够建多个二级索引来增长对数据的查询模式，二级索引的一致性是经过协处理器实现的，索引数据能够实时可见，但也会影响写性能，特别是建多个索引的状况下。对于复杂查询，好比任意条件的and/or组合，模糊查找，分词检索等Phoenix不支持，建议使用搜索引擎（如solr、es等）。固然，搜索引擎采用后台异步索引，必然会影响实时性，须要仔细权衡。

4.5 Phoenix不支持复杂分析

Phoenix定位为操做型分析（operational analytics），对于复杂分析，好比前面提到的复杂join则不适合，这种建议用Spark这种专门的大数据计算引擎来实现。

4.6 Phoenix支持映射已经存在的HBase表

用户能够经过Phoenix建立视图或者表映射已经存在的HBase表，注意若是使用表的方式映射HBase表，在Phoenix中执行DROP TABLE语句一样也会删除HBase表。另外，因为column family和列名是大小写敏感的，必须一一对应才能映射成功。另外，Phoenix的字段编码方式大部分跟HBase的Bytes工具类不同，通常建议若是只有varchar类型，才进行映射，包含其余类型字段时不要使用映射。

 

5.使用规范建议

• 大小写约定：因为phoenix对大小写敏感，默认又会转换成大写，咱们建表的时候都以大写做为规范，避免没必要要的麻烦。

• 索引名命名：每一个索引都会在hbase集群建一张索引表，便于识别索引的归属，建议索引名按 {表名}_{索引标识} 的规范命名（如表名TABLE_DEMO，索引名能够为TABLE_DEMO_C）。

• 原表分区原则：建议使用原生HBase的预分区方式。

• 索引表分区原则：建议使用salt_buckets的分区方式。

• select使用原则：建议不要使用select * 方式。

• 建表注意点：不要使用默认的UPDATE_CACHE_FREQUENCY策略（ALWAYS），改为UPDATE_CACHE_FREQUENCY = 60000。

 

                                                                      

 

 

本文分享自微信公众号 - 阿丸笔记（aone_note）。若有侵权，请删除。