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_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 = USgroup 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邏輯保持簡單明了。