Apache Kylin™是一個開源的分佈式分析引擎，提供Hadoop/Spark之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規模數據，最初由eBay Inc. 開發並貢獻至開源社區。它能在亞秒內查詢巨大的Hive表。
下面是Kylin的架構圖：
其中數據源支持Hive，Kafka，RDBMS，經過Cube Build Engine構建後，將預結算結果存儲至HBase，查詢對外提供Rest接口、Jdbc、Odbc。
對於OLAP引擎來說，最重要的就是其查詢性能與構建性能。這篇文章以Hive爲例針對cube設計與優化提供一些建議。
-
Hive表按照日期列進行分區存儲， Cube按照同樣的日期列作爲分區列：
![在這裏插入圖片描述]()
這裏模型設置的日期類型和hive日期分區列的數據類型保持一致，建議模型的分區列和hive表的分區列保持一致，這樣在大量構建時，只需要從hive中讀取需要的分區。分區也需要設置定期合併，減少cuboid碎片，提高查詢性能 -
Rowkey設計：
Rowkey設計非常重要，維度在rowkey中的 次序設置得當，可以顯著提升查詢性能
a，通常建議將 mandantory 維度放在開頭, 然後是在過濾 ( where 條件)中起到很大作用的維度；
b，如果多個列都會被用於過濾，將高基數的維度放在低基數的維度前面，出現頻率高的放在頻率低的前面。
c，將常過濾條件的普通列放在前面 -
維度的設計
a， Cube 中的維度可以劃分到多個聚合組中。默認 kylin 會把所有維度放在一個聚合組，當維度較多時，產生的組合數可能是巨大的，會造成 Cube 爆炸，這個時候我們可以設計聚合組來初步解決這一問題。用戶根據自己關注的維度組合，將維度分爲幾個組合大類，如：A B C D四個維度，若用戶只是關注AB/CD兩個組合，那cube可以設計爲AB/CD兩個聚合組。這個時候cuboid數量就會從16個被降爲8個。
總結爲：某些維度肯定不會同時進行group by 或where查詢的情況下，可以將相關的這些維度放入一個聚合組中；高級維度單獨拿出來，和其他普通維度組成聚合組
b，Mandatory Dimensions，必需維度，查詢中總是會帶有 “ORDER_DATE” 做爲 group by 或 過濾條件, 那麼它可以被聲明爲必要維度。通常而言，時間維度會被設置爲Mandatory維度，因爲業務查詢時一般都會限定某個時間範圍內的查詢結果。
c，Hierarchy Dimensions: 層級維度，指的是維度之間有層級關係，不通常不會拋開傷及節點單獨查詢下級節點，例如 “國家” -> “省” -> “市” 是一個層級。這種一對多的層級關係，還有機構層級，渠道層級，產品層級等，需要根據業務場景自行判斷維度的關係。
d，Joint Dimensions:聯合維度，有些維度往往一起出現，可以將他們設置爲聯合維度。
維度經常同時在查詢where或group by條件中同時出現，將他們組成一個Joint維度；將一些低基數（建議維度基數不超過10，維度數量不超過4個）的維度合併組成一個Joint，可以大大減少Cuboid數目，在查詢時再重新聚合的時間耗費也不大；必要時可以將兩個有強關係的高基維度組成一個Joint維度，例如合同日期和入賬日期
；必要時可以將查詢時很少使用的若干維度組成一個Joint維度，聯合維度組內的基數乘機小於1000。
e，Derived Dimensions：推導維度，可以有選擇的將維表中的某些維度列設爲可推到維度，這些維度不會參與計算，不會出現在cuboid中，查詢的時候由主鍵推導，在線計算。（注意：當主鍵是高基維時，不推薦將低基維作爲Derived，因爲這樣會導致聚合查詢時，掃描很多行，查詢耗時很長。
- 度量的設計
待續…