1.背景概述
近些年来，数据爆炸或者大数据成为 IT 行业发展的高频词汇，传统单机数据库 处理数据能力的瓶颈成为摆在 IT 工程师面前十分常见且亟待解决的问题。单机硬件存储容量和计算力的增长远远赶不上数据的增长。在单机软件中，数据库是数据相关处理技术的集大成者，集合了数据存储、数据实时读写、在线事务和数据分析等技术，并通过主备、多活等方案保证了可靠性。但是，在实际业务场景中，我们往往并没有同时用到所有数据库提供的能力，这也为我们解决业务中实际遇到的大数据难题提供了解决思路。
当前的大数据系统大多是通过分布式原理，重点解决某个方面或者某些方面的困境和难题，比如 HDFS 解决了大数据存储的问题，MapReduce 解决了大数据量复杂分析和计算的难题，HBase 解决了实时读写的问题。下面笔者将介绍 HBase 从解决实时读写问题出发，逐步进化，从 NoSQL 发展到 NewSQL 的过程和最新进展。
单纯从解决大数据实时读写问题角度，最初的 HBase 系统可以去掉很多传统数据库无关的功能，比如事务，SQL 表达与分析等，重点关注于分布式系统的扩展性，容错性，分布式缓存的设计，读写性能的优化以及毛刺的减少等方面。这也就是 NoSQL 最初的含义，解决大数据的实时存取的核心问题是第一位的，提供简单的 Get，Put，Scan 接口就可以解决用户的燃眉之急。通过第一阶段的努力，HBase 成为了优秀的大数据实时存取引擎，传统数据库的容量问题解决了，HDFS 实时性不够的问题也解决了。
走过了从无到有的第一阶段，我们需要让 HBase 更强大，更好用，门槛更低，让 HBase 帮助更多的用户解决他们遇到的实际问题。众所周知，SQL 是数据处理领 域的语言标准，简单，好用，表达力强，用户使用广泛。HBase 很有必要回过头来支持 SQL，包括语言表达的支持和相关的数据处理方式和能力的支持。当然， HBase SQL 的实现和发展跟传统单机数据库有很多不同，便于区别，我们称之为 NewSQL。这也是社区 Phoenix 项目的初衷，如果说 HBase 是功能强大的存储引擎，那么支持 NewSQL 之后，就变成了新一代的大飞机。
接下来，第二章将介绍 Phoenix 项目是如何让 HBase 从 NoSQL 成长为 NewSQL 的;第三章介绍 Phoenix 在阿里的实践，增强和典型案例;第四章总结全文以及展望 Phoenix 未来的发展。
2.方案与实现
系统整体架构如图 2 所示，其中黄色部分是 HBase 的组件，蓝色部分是 Phoenix，我们可以看出 Phoenix 跟 HBase 是紧密结合的。Phoenix 首先要能通过 SQL 暴露 HBase 的能力，然后再通过一系列功能和特性增强 HBase 能力，并且还要做到足 够易用。下面我分别从基于 HBase 的 SQL，SQL 执行与优化以使用接口三个方 面介绍 Phoenix 已经做到的事情。
2.1 基于 HBase 的 SQL
让 HBase 支持 SQL，我们首先能想到的是，把 SQL 语言翻译成 HBase API，并且 HBase 本身的功能特性必须得能通过 SQL 暴露出来。Phoenix SQL 语法即 SQL- 92 标准语法+方言。Phoenix 支持标准语法的绝大部分特性，包括:标准类型; 聚合，连接，in，排序以及子查询等查询语法;create，drop，delete 等数据操作 语法，这些操作在底层都会转变为 HBase API。
此外，HBase 的某些特性也能通过 SQL 方言的形式表达，比如:
- HBase 的列族，可以把相关的列放到一起，以减少 IO，优化读性能，在创建 Phoenix 表的时候直接写成”cf.col”即可，Phoenix 会自动创建 cf 列族， 如果不指定，则放在默认列族中;
- Phoenix 将 insert 和 update 合并成 upsert 关键字，来对应 HBase 的 Put 概 念;
- HBase 为了避免在表初始时只有一个 Region 带来数据热点，支持预分区， Phoenix 支持在建表的时候通过 split on 关键字来表达。
- HBase 支持动态列的特性在 Phoenix 中也得以保留，存入数据的时候直接声明新的字段即可使用。
由于充分结合，Phoenix 天然继承了 HBase 所拥有的高并发，大容量，实时存取等特性。
从图 3 中可以看出，有了 SQL，用户无需编写繁琐的 java 代码，大大简化了代码逻辑，传统数据库用户可以快速上手，原有基于传统数据库的代码逻辑，只需要少量修改即可运行起来。
在很多场景下仅拥有实时存取的特性是不够的，大数据在线原地分析也是自然而然的需求，Phoenix 基于 HBase 拥有的高效缓存和 LSM 索引，可以做到对 PB 级 数据做操作型分析的毫秒级或秒级返回。
Phoenix SQL 的整体执行流程如图 4 所示，用户输入的查询语句首先经过 SQLParser 解析为执行计划，然后经过 QueryOptimizer 的优化，选取最优的执行计划，执行计划最终会转变为 HBase 的 Scan，RegionServer 端的协处理器会作用于该 Scan，做本地过滤和聚合，然后把 结果返回到客户端做汇总聚合形成最终结果，并通过ResultSet 的形式返回给用户。其中主要使用到的策略有:无需数据传输的算子原地计算;实时同步的二级索引;热点数据自动打散;以及基于代价和规则的执行计划优化等。后面笔者介绍前三个最具有 Phoenix 特色的策略。
在没有 Phoenix 之前，用户如果需要分析 HBase 数据，只能从HBase 拖出去或者绕过 HBase 直接读取 HDFS 上面的 HFile 的方式进行，前者浪费了大量的网络 IO，后者用不到 HBase 本身做的大量缓存和索引优化。Phoenix 使用 HBase 的协处理器机制，直接在 RegionServer 上执行算子逻辑，然后将算子的结果返回即可，也就是大数据中的“Move Operator to Data”理念。比如，用户执行“select
count(*) from mytable where mytime > timestamp’2018-11-11 00:00:00’”，在实际执行中，会先找到符合过滤条件的 region，然后在 RegionServer 本地计算 count， 最后再对各个 Region 上的结果进行汇总。
索引是传统数据库中常见的技术，HBase 表中可以指定主键，对主键使用 LSM 算 法构建索引。Phoenix 中，用户在创建表的时候，可以指定索引列，可以是单列， 也可以是组合列。很多时候仅有主键索引是不够的，特别是对于列特别多的宽表， 为此，Phoenix 提供二级索引功能，用户能够对表中非主键的列添加索引，并可以加入其它相关列到索引表中，如果某个查询涉及到的列全部在索引表中，直接查询索引表即可，无需访问原数据表。索引表跟原表做到实时同步更新，以保证 数据一致性。
索引示例如图 5 所示，创建索引的时候通过“on”关键字指定索引表的主键，实际 HBase 表中会使用 BA 来作为联合主键;“include”关键字指定加入到索引表的其 他列。当执行“select c from data_table where b > xx ”时，Phoenix 直接查询索引 表即可，否者需要返回原表查找。
当数据的访问比较集中，比如物联网场景中需要对最新的的监控数据做查询分析， 而这部分数据往往会集中分布在某个 RegionServer 上，那么就会形成热点，性 能也会大大折扣。此时需要能够把数据打散到不同的 RegionServer 上来解决， 加盐就是这样一个技术。加盐的过程本质上是对原有的主键加上一个字节的前缀， 如下面公式所示:
其中，BUCKETS_NUMBER 为桶的个数。主键的分布决定了数据的分布，把主键 打散也就意味着数据打散。具体使用时，一般建议桶的数目等于 RegionServer 的数目。
2.3 使用接口
Phoenix 提供 JDBC 的方式访问，并支持重客户端和轻客户端两种方式，重客户 端的 JDBC 串前缀是“jdbc:phoenix:”，轻客户端的 JDBC 串前缀为 “jdbc:phoenix:thin:”。重客户端中，Phoenix 初执行在 HBase 协处理器之外的逻辑均运行在客户端，这样可以带来最优的性能，但也带来了客户端的复杂性。轻客 户端则将上诉逻辑运行在单独不熟的 QueryServer 中，客户端仅有很薄的 JDBC 协议转换。轻客户端除支持 Java 语言外，也支持 Python、Go、C#等多种语言。
3.实践案例
阿里云 HBase 产品中集成 Phoenix 功能已经有一年多的时间了，阿里云 HBase 团队对 Phoenix 在稳定性和性能方面做了一系列的改进优化，并积极反馈回社区， 团队的瑾谦同学也成长为了 Phoenix 社区的 commiter。Phoenix 的用户既有来自 于新型大数据业务，如物联网、互联网金融以及新零售等;也有来自传统行业， 比如游戏、养殖业和运输业等。Phoenix 数据既有来在线实时业务，也有从单机 数据库同步进来。下面，笔者以物联网场景为例，说明 Phoenix 如何在实际业务中解决用户难题。
在物联网场景下，大量传感器会把实时监测到的数据上传到云平台，经过一定的 预处理后实时写入到 Phoenix 中，管控平台从 Phoenix 中直接在线查询和分析数 据，如生成报表，监控异常等。该场景会用到 Phoenix 的一下特性:
- 对实时写入的并发和 TPS 要求很高，甚至可以达到百万级。
- 数据量比较大，一般在 TB 到 PB 级别，且需要根据业务增长动态扩容。
- 有动态列的需求，比如根据业务调整，动态添加监控指标。
- 在线查询，甚至是毫秒级查询要求。
- 维度比较多，需要用到二级索引，以加速在线查询。
- 频繁查询最近一段时间的数据，会造成热点，可以使用加盐的特性。
4.总结与展望
开源的 HDFS、MapReduce 和 HBase 来源于 Google 的三篇论文，但最终驱动的 还是大数据场景下的实际需求。Phoenix 的出现也是需求驱动的必然结果，它继 承了 HBase 的各种特性，如高并发，水平扩展，实时读写等，并在其基础上实现 了一套 SQL 引擎，增加了如语法解析、二级索引、查询优化以及 JDBC 等功能和 特性，完成了NoSQL 到 NewSQL 的转变。
阿里云 HBase 团队和社区对 Phoenix 后续还会根据实际需求做进一步的进化， 包括稳定性的进一步加强;执行计划和运行时的进一步优化;轻客户端在易用性 支持上的持续完善;实时交易场景中事务的支持以及跟 Spark 的深度集成等等。 笔者非常希望对 HBase 和 Phoenix 感兴趣的读者朋友可以参与到社区里面，共 同推动技术的发展，满足更多的场景需求。
