Apache Kylin查询性能优化

Apache Kylin查询性能优化

作者:周倚平

编辑:Sammi

Apache Kylin™是一个开源的分布式分析引擎,提供Hadoop之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由eBay Inc. 开发并贡献至开源社区,可在亚秒内查询巨大的Hive表。

在Apache Kylin的实际部署过程中,SQL查询有时并不能如预期在很短的时间内完成,需要开发人员进行有针对性的分析和优化。

在进行分析、优化之前,我们需要先了解Apache Kylin查询的整个生命周期。这一周期主要分为三个阶段:第一阶段的SQL解析阶段,第二阶段的SQL查询阶段,以及第三阶段的数据集中和聚合阶段。接下来,我们将分阶段为大家解析应如何分析和优化Apache Kylin的查询性能。


第一阶段:SQL解析

在收到SQL请求后,Kylin Query Server会调用Calcite对SQL语句进行解析,Calcite的工作流程如下图。



首先,Calcite会将SQL语句通过范式编译器解析为一颗抽象语义树(AST)。




然后Calcite对这棵AST树进行优化,将Project(select部分)和Filter(where部分)Push down至Hadoop集群。


接着定义implement plan,共有两种方式:HepPlanner(启发式优化)和VolcanoPlanner(基于代价的优化)。目前Kylin只启用了一些必要的HepPlanner规则,大部分使用的是VolcanoPlanner。

第二阶段:SQL查询

针对子查询,UNION等场景,Calcite将SQL分解为多个OLAPContext,同时执行Filter Pushdown和Limit Pushdown等优化手段,然后提交到HBase上执行。

第三阶段:数据集中和聚合

HBase上的查询任务执行完成后,数据返回至Kylin Query Server端,由Calcite聚合多个OLAP Context的查询结果后,最后返回给前端BI。在了解Apache Kylin的查询生命周期以后,碰到一些查询速度较慢的情况,就能够有针对性地进行分析和优化了。

1、从模型设计角度,需要合理调整RowKey中维度的排列顺序,原则是把过滤字段(例如PART_DT等日期型字段)和高基维(例如BUYER_ID,SELLER_ID等客户字段)放在Rowkey的前列,这样能够显著提升【第二阶段SQL查询】在HBase上数据扫描和I/O读取的效率。



2、Kylin遵循的是“Scatter and gather”模式,而有的时候在【第二阶段SQL查询】时无法实现Filter Pushdown和Limit Pushdown等优化手段,需要等待数据集中返回Kylin后再筛选数据,这样数据吞吐量会很大,影响查询性能。优化方法是重写SQL语句。

例如,该SQL查询的筛选条件(斜体加粗部分)放在子查询中,因此无法实现Filter Pushdown。

select KYLIN_SALES.PART_DT, sum(KYLIN_SALES.PRICE)
from KYLIN_SALES
inner join (select ACCOUNT_ID, ACCOUNT_BUYER_LEVEL from KYLIN_ACCOUNT whereACCOUNT_COUNTRY = 'US' ) as TT
on KYLIN_SALES.BUYER_ID = TT.ACCOUNT_ID
group by KYLIN_SALES.PART_DT

正确的写法应该是:

select KYLIN_SALES.PART_DT, sum(KYLIN_SALES.PRICE)
from KYLIN_SALES
inner join KYLIN_ACCOUNT as TT on KYLIN_SALES.BUYER_ID = TT.ACCOUNT_ID
where TT.ACCOUNT_COUNTRY = 'US'
group by KYLIN_SALES.PART_DT

如下图所示,可以在日志中查看Filter Pushdown是否成功。



3、查看后台日志,如果查询击中了Base Cuboid,则【第三阶段数据集中和聚合】将会花费大量时间,优化方法是调整模型中聚合组,联合维度,必要维度的设计。

相关优化方法可以参考以下技术文章:

Apache Kylin高级设置:聚合组(Aggregation Group)原理解析

Apache Kylin高级设置:联合维度(Joint Dimension)原理解析

Apache Kylin高级设置:必要维度 (Mandatory Dimension)原理解析

在日志中可以看到查询击中的Cuboid组合,如下图红框中的131071,将其转换为二进制数值是0x1 1111 1111 1111 1111,从右至左,共有17个1,表示该Cuboid中包含了17个维度(这里从右至左指代的维度的对应顺序是Cube模型中Rowkey中自下而上定义的维度),而Cube模型中所有维度的数量是17,说明击中了Base Cuboid。



4、从Kylin Query Server处理效率角度,需要实时监控Kylin节点的CPU占有率和内存消耗,如果两者很高的话可能导致【第一阶段SQL解析】的效率下降,优化方法是增加Kylin节点CPU和JVM配置。

具体方法是修改setenv.sh中的KYLIN_JVM_SETTINGS配置项。



5、监控BI前端,Kylin Query Server节点和Hadoop集群之间的网络通信状态,大数据集传输可能引起网络堵塞,尤其是在多并发查询的情况下更容易发生网络堵塞,进而对查询性能产生显著影响。优化方法是确保BI前端、Kylin节点、Hadoop集群之间的网络通畅,一个简单的方法是用PING命令查看网络之间的延迟。

6、对于一些复杂的SQL语句,如果包含子查询的话,尽量避免Left Join操作,尤其是Join的两个数据集都较大的情况下,会对查询性能有显著的影响。建议将SQL的数据处理逻辑放在ETL阶段,而前端SQL逻辑保持简单明了。

编辑于 2017-09-06