OLAPCube是一種典型的多維數據分析技術，Cube本身可以認為是不同維度數據組成的dataset，一個OLAP Cube 可以擁有多個維度（Dimension），以及多個事實（Factor Measure）。用戶通過OLAP工具從多個角度來進行數據的多維分析。通常認為OLAP包括三種基本的分析操作：上卷（rollup）、下鑽（drilldown）、切片切塊（slicingand dicing），原始數據經過聚合以及整理后變成一個或多個維度的視圖。
ROLAP 以關系模型的方式存儲用作多維分析用的數據，優點在於存儲體積小，查詢方式靈活，然而缺點也顯而易見，每次查詢都需要對數據進行聚合計算，為了改善短板，ROLAP使用了列存、並行查詢、查詢優化、位圖索引等技術。
MOLAP 將分析用的數據物理上存儲為多維數組的形式，形成CUBE結構。維度的屬性值映射成多維數組的下標或者下標范圍，事實以多維數組的值存儲在數組單元中，優勢是查詢快速，缺點是數據量不容易控制，可能會出現維度爆炸的問題。
Apache Kylin 是一個Hadoop生態圈下的MOLAP系統，是eBay大數據部門從2014年開始研發並開源的支持TB到PB級別數據量的分布式OLAP分析引擎。
- 可擴展的超快的OLAP引擎
- 提供ANSI-SQL接口
- 交互式查詢能力
- MOLAP Cube 的概念
- 與BI工具可無縫整合
Apache Kylin的多維計算主要是體現在OLAPCube的計算。Cube由多個Cuboid組合而成，Cuboid上的數據是原始數據聚合的數據，因此創建Cube可以看作是在原始數據導入時做的一個預計算預處理的過程。Kylin的強大之處在於充分利用了Hadoop的MapReduce並行處理的能力，高效處理導入的數據。
Apache Kylin的數據來自於Hive，並作為一個Hive的加速器希望最終的查詢SQL類似於直接在Hive上查詢。因此Kylin在建立Cube的時候需要從Hive獲取Hive表的元數據。雖然有建立Cube的過程，但是並不想對普通的查詢用戶暴露Cube的存在。
Apache Kylin創建Cube的過程：
- 根據Cube定義的事實表以及維度表，利用Hive創建一張寬表
- 抽取事實表上的維度的distinct值，將事實表上的維度以字典樹方式壓縮編碼成目錄，將維度表以字典樹的方式編碼
- 利用MapReduce從第一步得到的寬表文件作為輸入，創建 N－Dimension cuboid，然后每次根據前一步的結果串行生成 N-1 cuboid, N-2 cuboid … 0-Cuboid
- 根據生成的Cuboid數據量計算HTable的Region分割策略，創建HTable，將HFile導入進來
計算Cube的存儲代價以及計算代價都是比較大的， 傳統OLAP的維度爆炸的問題Kylin也一樣會遇到。 Kylin提供給用戶一些優化措施，在一定程度上能降低維度爆炸的問題：
Hierachy Dimension， 一系列具有層次關系的Dimension組成一個Hierachy， 比如年、月、日組成了一個Hierachy， 在Cube中，如果不設置Hierarchy， 會有 年、月、日、年月、年日、月日 6個cuboid， 但是設置了Hierarchy之后Cuboid增加了一個約束，希望低Level的Dimension一定要伴隨高Level的Dimension 一起出現。設置了Hierachy Dimension 能使得需要計算的維度組合減少一半。
Derived Dimension, 如果在某張維度表上有多個維度，那么可以將其設置為Derived Dimension， 在Kylin內部會將其統一用維度表的主鍵來替換，以此來達到降低維度組合的數目，當然在一定程度上Derived Dimension 會降低查詢效率，在查詢時，Kylin使用維度表主鍵進行聚合后，再通過主鍵和真正維度列的映射關系做一次轉換，在Kylin內部再對結果集做一次聚合后返回給用戶
Aggregation Group， 這是一個將維度進行分組，以求達到降低維度組合數目的手段。不同分組的維度之間組成的Cuboid數量會大大降低，維度組合從2的（k+m+n）次冪至多能降低到 2的k次冪加2的m次冪加2的n次冪。Group的優化措施與查詢SQL緊密依賴，可以說是為了查詢的定制優化。 如果查詢的維度是誇Group的，那么Kylin需要以較大的代價從N－Cuboid中聚合得到所需要的查詢結果，這需要Cube構建人員在建模時仔細地斟酌。
Kylin目前的多維數據存儲引擎是HBase， Kylin利用了HBase的Coprocessor機制在HBase的RegionServer完成部分聚合以及全部過濾操作，在HbaseScan時提前進行計算，利用HBase多個Region Server的計算能力加速Kylin的SQL查詢。
ApacheKylin 可以說是與市面上流行的Presto、SparkSQL、Impala等直接在原始數據上查詢的系統（暫且歸於RTOLAP）走了一條完全不同的道路：
1、Kylin的版本會改進預計算引擎，優化預計算速度，使得Kylin可以變成一個近似實時的分析引擎，主要優化如何快速求得預計算結果，以及優化查詢解析使得更多的查詢能用上預計算結果方面。
2、像Presto，SparkSQL等是着重於優化查詢數據的過程環節，像一些其它的數據倉庫一樣，使用列存、壓縮、並行查詢等技術，優化查詢。