作者：周倚平
編輯：Sammi
Apache Kylin?是一個(gè)開源的分布式分析引擎，提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規(guī)模數(shù)據(jù)，最初由eBay Inc. 開發(fā)并貢獻(xiàn)至開源社區(qū)颊咬，可在亞秒內(nèi)查詢巨大的Hive表霉囚。
在Apache Kylin的實(shí)際部署過程中，SQL查詢有時(shí)并不能如預(yù)期在很短的時(shí)間內(nèi)完成抛腕，需要開發(fā)人員進(jìn)行有針對(duì)性的分析和優(yōu)化堤尾。
在進(jìn)行分析肝劲、優(yōu)化之前，我們需要先了解Apache Kylin查詢的整個(gè)生命周期哀峻。這一周期主要分為三個(gè)階段：第一階段的SQL解析階段涡相，第二階段的SQL查詢階段，以及第三階段的數(shù)據(jù)集中和聚合階段剩蟀。接下來(lái)，我們將分階段為大家解析應(yīng)如何分析和優(yōu)化Apache Kylin的查詢性能切威。
第一階段：SQL解析
在收到SQL請(qǐng)求后育特，Kylin Query Server會(huì)調(diào)用Calcite對(duì)SQL語(yǔ)句進(jìn)行解析，Calcite的工作流程如下圖先朦。
首先缰冤，Calcite會(huì)將SQL語(yǔ)句通過范式編譯器解析為一顆抽象語(yǔ)義樹（AST）。
然后Calcite對(duì)這棵AST樹進(jìn)行優(yōu)化喳魏，將Project（select部分）和Filter（where部分）Push down至Hadoop集群棉浸。
接著定義implement plan，共有兩種方式：HepPlanner（啟發(fā)式優(yōu)化）和VolcanoPlanner（基于代價(jià)的優(yōu)化）刺彩。目前Kylin只啟用了一些必要的HepPlanner規(guī)則迷郑，大部分使用的是VolcanoPlanner。
第二階段：SQL查詢
針對(duì)子查詢创倔，UNION等場(chǎng)景嗡害，Calcite將SQL分解為多個(gè)OLAPContext，同時(shí)執(zhí)行Filter Pushdown和Limit Pushdown等優(yōu)化手段畦攘，然后提交到HBase上執(zhí)行。
第三階段：數(shù)據(jù)集中和聚合
HBase上的查詢?nèi)蝿?wù)執(zhí)行完成后知押，數(shù)據(jù)返回至Kylin Query Server端叹螟，由Calcite聚合多個(gè)OLAP Context的查詢結(jié)果后鹃骂，最后返回給前端BI。在了解Apache Kylin的查詢生命周期以后罢绽，碰到一些查詢速度較慢的情況畏线，就能夠有針對(duì)性地進(jìn)行分析和優(yōu)化了。
1有缆、從模型設(shè)計(jì)角度象踊，需要合理調(diào)整RowKey中維度的排列順序，原則是把過濾字段（例如PART_DT等日期型字段）和高基維（例如BUYER_ID棚壁，SELLER_ID等客戶字段）放在Rowkey的前列杯矩，這樣能夠顯著提升【第二階段SQL查詢】在HBase上數(shù)據(jù)掃描和I/O讀取的效率。
2袖外、Kylin遵循的是“Scatter and gather”模式史隆，而有的時(shí)候在【第二階段SQL查詢】時(shí)無(wú)法實(shí)現(xiàn)Filter Pushdown和Limit Pushdown等優(yōu)化手段，需要等待數(shù)據(jù)集中返回Kylin后再篩選數(shù)據(jù)曼验，這樣數(shù)據(jù)吞吐量會(huì)很大泌射，影響查詢性能。優(yōu)化方法是重寫SQL語(yǔ)句鬓照。
例如熔酷，該SQL查詢的篩選條件（斜體加粗部分）放在子查詢中，因此無(wú)法實(shí)現(xiàn)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
正確的寫法應(yīng)該是：
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臭猜、查看后臺(tái)日志躺酒，如果查詢擊中了Base Cuboid，則【第三階段數(shù)據(jù)集中和聚合】將會(huì)花費(fèi)大量時(shí)間蔑歌，優(yōu)化方法是調(diào)整模型中聚合組羹应，聯(lián)合維度，必要維度的設(shè)計(jì)次屠。
相關(guān)優(yōu)化方法可以參考以下技術(shù)文章：
Apache Kylin高級(jí)設(shè)置：聚合組（Aggregation Group）原理解析
Apache Kylin高級(jí)設(shè)置：聯(lián)合維度（Joint Dimension）原理解析
Apache Kylin高級(jí)設(shè)置：必要維度 （Mandatory Dimension）原理解析
在日志中可以看到查詢擊中的Cuboid組合园匹，如下圖紅框中的131071，將其轉(zhuǎn)換為二進(jìn)制數(shù)值是0x1 1111 1111 1111 1111帅矗，從右至左偎肃，共有17個(gè)1，表示該Cuboid中包含了17個(gè)維度（這里從右至左指代的維度的對(duì)應(yīng)順序是Cube模型中Rowkey中自下而上定義的維度）浑此，而Cube模型中所有維度的數(shù)量是17累颂，說(shuō)明擊中了Base Cuboid。
4、從Kylin Query Server處理效率角度紊馏，需要實(shí)時(shí)監(jiān)控Kylin節(jié)點(diǎn)的CPU占有率和內(nèi)存消耗料饥，如果兩者很高的話可能導(dǎo)致【第一階段SQL解析】的效率下降，優(yōu)化方法是增加Kylin節(jié)點(diǎn)CPU和JVM配置朱监。
具體方法是修改setenv.sh中的KYLIN_JVM_SETTINGS配置項(xiàng)岸啡。
5、監(jiān)控BI前端赫编，Kylin Query Server節(jié)點(diǎn)和Hadoop集群之間的網(wǎng)絡(luò)通信狀態(tài)巡蘸，大數(shù)據(jù)集傳輸可能引起網(wǎng)絡(luò)堵塞，尤其是在多并發(fā)查詢的情況下更容易發(fā)生網(wǎng)絡(luò)堵塞擂送，進(jìn)而對(duì)查詢性能產(chǎn)生顯著影響悦荒。優(yōu)化方法是確保BI前端、Kylin節(jié)點(diǎn)嘹吨、Hadoop集群之間的網(wǎng)絡(luò)通暢搬味，一個(gè)簡(jiǎn)單的方法是用PING命令查看網(wǎng)絡(luò)之間的延遲。
6蟀拷、對(duì)于一些復(fù)雜的SQL語(yǔ)句碰纬，如果包含子查詢的話，盡量避免Left Join操作问芬，尤其是Join的兩個(gè)數(shù)據(jù)集都較大的情況下悦析，會(huì)對(duì)查詢性能有顯著的影響。建議將SQL的數(shù)據(jù)處理邏輯放在ETL階段此衅，而前端SQL邏輯保持簡(jiǎn)單明了她按。
