都是 HBase 上的 SQL 引擎，Kylin 和 Phoenix 有什么不一样？

做者 | 翟娜

大数据时代，数据的价值愈来愈被重视，企业从海量大数据中挖掘所须要的信息，用来驱动业务决策以得到更大的商业价值。

与此同时，出现了愈来愈多的大数据技术帮助企业进行大数据分析，例如 Apache Hadoop，Hive，Spark，Presto，Drill，以及今天咱们即将介绍的 Apache Kylin 和 Apache Phoenix 项目等，都是使用 SQL 语言就能够分析大数据，极大地下降了大数据的使用门槛。

这些大数据技术提供 SQL 查询接口，不仅是由于 SQL 学习成本低，同时也和 SQL 拥有丰富而强大的表达能力、能知足绝大多数的分析需求的特性有关系。

了解 Apache Kylin 和 Apache Phoenix 的同窗都知道，它们都是使用 Apache HBase 作数据存储和查询，那么，同为 HBase 上的 SQL 引擎，它们之间有什么不一样呢？下面咱们将从这两个项目的介绍开始为你们作个深度解读和比较。

一、Apache Kylin

1.1Apache Kylin 介绍

Kylin 是一个分布式的大数据分析引擎，提供在 Hadoop 之上的 SQL 接口和多维分析能力（OLAP），能够作到在 TB 级的数据量上实现亚秒级的查询响应。

图1 Kylin 架构

上图是 Kylin 的架构图，从图中能够看出，Kylin 利用 MapReduce/Spark 将原始数据进行聚合计算，转成了 OLAP Cube 并加载到 HBase 中，以 Key-Value 的形式存储。Cube 按照时间范围划分为多个 segment，每一个 segment 是一张 HBase 表，每张表会根据数据大小切分红多个 region。Kylin 选择 HBase 做为存储引擎，是由于 HBase 具备延迟低，容量大，使用普遍，API完备等特性，此外它的 Hadoop 接口完善，用户社区也十分活跃。

二、Apache Phoenix

2.1 Apache Phoenix 介绍

Phoenix 是一个 Hadoop 上的 OLTP 和业务数据分析引擎，为用户提供操做 HBase 的 SQL 接口，结合了具备完整 ACID 事务功能的标准 SQL 和 JDBC API，以及来自 NoSQL 的后期绑定，具备读取模式灵活的优势。

下图为 Phoenix 的架构图，从图中能够看出，Phoenix 分为 client 和 server，其中 client 又分为 thin（本质上是一个 JDBC 驱动，所依赖的第三方类较少）和非 thin （所依赖的第三方类较多）两种；server 是针对 thin client 而言的，为 standalone 模式，是由一台 Java 服务器组成，表明客户端管理 Phoenix 的链接，能够进行横向扩展，启动方式也很简单，经过 bin/queryserver.py start 便可。

图2 Phoenix 架构图

接下来咱们进行一个二者的对比。

三、Kylin 和 Phoenix 的对比

3.1 二者优缺点对比

咱们先来看看 Kylin 和 Phoenix 各自的优势是什么。Kylin 的优势主要有如下几点：

1. 支持雪花/星型模型；

2. 亚秒级查询响应；

3. 支持 ANSI-SQL，可经过 ODBC，JDBC 以及 RESTful API 进行访问；

4. 支持百亿、千亿甚至万亿级别交互式分析；

5. 无缝与 BI 工具集成；

6. 支持增量刷新；

7. 既支持历史数据也支持流式数据；

8. 易用的管理页面和 API。

Phoenix 的优势则主要是如下几点：

1. 支持明细和聚合查询；

2. 支持 insert，update，delete 操做，其使用 upsert 来代替 insert 和 update；

3. 较好的利用 HBase 的优势，如 row timestamp，将其与 HBase 原生的 row timestamp 映射起来，有助于 Phoenix 利用 HBase 针对存储文件的时间范围提供的多种优化和 Phoenix 内置的各式各样的查询优化；

4. 支持多种函数：聚合、String、时间和日期、数字、数组、数学和其它函数；

5. 支持具备完整 ACID 语义的跨行及跨表事务；

6. 支持多租户；

7. 支持索引（二级索引），游标。

固然，Kylin 和 Phoenix 也都有一些还有待提高的不足之处，Kylin 的不足主要是体如今首先因为 Kylin 是一个分析引擎，只读，不支持 insert, update, delete 等 SQL 操做，用户修改数据的话须要从新批量导入（构建）；其次，Kylin 用户须要预先创建模型后加载数据到 Cube 后才可进行查询；最后，使用 Kylin 的建模人员须要了解必定的数据仓库知识。

Phoenix 的不足则主要体如今：首先，其二级索引的使用有必定的限制，只有当查询中全部的列都在索引或覆盖索引中才生效且成本较高，在使用以前还需配置；其次，范围扫描的使用有必定的限制，只有当使用了很多于一个在主键约束中的先导列时才生效；最后，建立表时必须包含主键 ，对别名支持不友好。

3.2 HBase 表存储格式的对比

Kylin 将数据列区分红维度和度量：维度的顺序与 HBase 中的 Rowkey 创建关系从而将 Cube 数据存储，维度的值会被编码为字节，而后多个维度的值被拼接在一块儿组成 Rowkey，Rowkey 的格式为 Shard ID（2 字节）+ Cuboid ID（8 字节，标记有哪几个列）+ 维度值；度量的值会被序列化为字节数组，而后以 column 的方式存储；多个度量值能够放在同一个列簇中，也能够放在不一样列簇中。以下图所示：

图3 Kylin 的 HBase Table 格式

Phoenix 在列名与 HBase 列限定符之间引入了一个间接层，将 HBase 非关系型形式转换成关系型数据模型，在建立表时默认会将 PK 与 HBase 中表的 Rowkey 映射起来,PK 支持多字段组合，剩下的列能够根据需求进行选择，列簇若是未显式定义，则会被忽略，Qualifier 会转换成表的字段名。以下图所示：

图4 Phoenix 数据模型

3.3 查询方式对比

Kylin 查询时会将 SQL 经过 Apache Calcite 进行解析和优化，转化成对 HBase 的 RPC 访问。Kylin 会将计算逻辑下压到 HBase Region Server 中使用 Coprocessor 并行运行，每一个 RS 返回过滤聚合后的数据给 Kylin 节点，Kylin 作最后的处理后返回给客户端。由于大量的计算在 Cube 生成的时候已经完成，所以 Kylin 的查询效率很是高，一般在毫秒到秒级。

Kylin 在 Insight 页面提供 SQL 查询窗口；也可以经过 REST API 发送请求的方式进行查询；还可以快速的与其余 BI 工具集成并使用 BI 工具自带的方式进行查询。

Phoenix 直接使用 HBase API，以及协处理器和自定义过滤器，从而使得查询的效率更好。对于查询，Phoenix 能够根据 region 的边界进行分块并在客户端并行运行以减小延迟。聚合操做将在服务器端的协处理器中完成（这点与 Kylin 相似），返回到客户端的数据量是进行过压缩的，而不是所有返回。

Phoenix 是经过命令行的方式进行查询（既能够输入单条 SQL 语句，也能够执行 SQL 文件）；也能够经过界面进行查询，但需额外安装 Squirrel。

3.4 查询优化方式对比

Kylin 查询优化方法比较多样，既有逻辑层的维度减枝优化（层级，必须，联合，推导等），编码优化，rowkey 优化等，也有存储层的优化，如按某个维度切 shard，region 大小划分优化，segment 自动合并等，具体能够参考 Kylin 的文档。用户能够根据本身的数据特征、性能需求使用不一样的策略，从而在空间和时间之间找到一个平衡点。

为了使得查询效率更高，Phoenix 能够在表上加索引，不一样的索引有不一样的适用场景：全局索引适用于大量读取的场景，且要求查询中引用的全部列都包含在索引中；本地索引适用于大量写入，空间有限的场景。索引会将数据的值进行拷贝，额外增长了开销，且使用二级索引还需在 HBase 的配置文件中进行相应配置。数据总不会是完美分布的，HBase 顺序写入时（行键单调递增）可能会致使热点问题，这时能够经过加盐操做来解决，Phoenix 能够为 key 自动加盐。

从上述内容能够看出：

1）Kylin 和 Phoenix 虽然同为 Hadoop/HBase 上的 SQL 引擎，二者的定位不一样，一个是 OLAP，另外一个是 OLTP，服务于不一样的场景；

2）Phoenix 更多的是适用于以往关系型数据库的相关操做，当查询语句是点查找和小范围扫描时，Phoenix 能够比较好地知足，而它不太适合大量 scan 类型的 OLAP 查询，或查询的模式较为灵活的场景；

3）Kylin 是一个只读型的分析引擎，不适合细粒度修改数据，但适合作海量数据的交互式在线分析，一般跟数据仓库以及 BI 工具结合使用，目标用户为业务分析人员。

下面咱们作一个简单的性能测试，由于 Kylin 不支持数据写入，所以咱们不得不测试数据的查询性能，使用相同 HBase 集群和数据集。

3.5 性能对比

咱们准备的测试环境为 CDH 5.15.1，1个 Master，7个 Region Server，每一个节点 8 核心 58G 内存，使用 Star Schema Benchmark 数据进行测试。其中单表 Lineorder 表数据量为 3 千万，大小为 8.70 GB。Phoenix 导入时间: 7mins 9sec, Kylin 导入时间: 32mins 8sec。多表 Lineorder 数据量 750 万，大小为 10 GB。具体的 SQL 语句参见Github。

图5 单表对比图

图 5 是一个单表查询场景的分析，从上咱们能够看出， 针对于一张表的查询，Phoenix 查询的耗时是 Kylin 的几十甚至是几百倍，加入索引后，Phoenix 的查询速度有了较为显著的提高，但仍然是 Kylin 的十几倍甚至几十倍，所以单表查询 Kylin 具备明显优点。

图6 多表对比图

图6是一个多表 join 查询的场景，从上图能够看出，对于多表 join 的状况，Kylin 查询依旧很是快，由于 join 在 Cube 构建阶段已经完成了；Phoenix 加入索引后时间并无较为显著的减小，耗时仍然是 Kylin 的几十倍甚至几百倍。

所以，不管是单表仍是多表查询，Kylin 查询的时间都远远小于 Phoenix，固然这是由于有了预计算的缘由。

四、总结

简单来看，Apache Phoenix 与Apache Kylin 彷佛都是 Hadoop/HBase 上的 SQL 引擎，实际上它们服务于不一样的目的，Phoenix 适用于频繁写但读取少的事务型场景，Kylin 则适合写少读多的分析型场景；在 OLTP 的场景中，Phoenix 具备低延迟、高并发、事务性等优势；在 OLAP 的场景下，Kylin 更具备优点。用户应该根据自身的实际状况，选择合适的引擎。

五、参考

1. kylin.apache.org/

2. phoenix.apache.org

3. github.com/apache/phoe…

4.www.slidestalk.com/s/Track22_A…

5. www.jianshu.com/p/91decdd7f…