作者：周倚平

編輯：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_SALESinner join (select ACCOUNT_ID, ACCOUNT_BUYER_LEVEL from KYLIN_ACCOUNT whereACCOUNT_COUNTRY = 'US' ) as TTon KYLIN_SALES.BUYER_ID = TT.ACCOUNT_IDgroup by KYLIN_SALES.PART_DT

正確的寫法應該是：

select KYLIN_SALES.PART_DT, sum(KYLIN_SALES.PRICE)from KYLIN_SALESinner join KYLIN_ACCOUNT as TT on KYLIN_SALES.BUYER_ID = TT.ACCOUNT_IDwhere 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邏輯保持簡單明了.