Kylin整理

Kylin整理

一，概述

1.1 Kylin定義

​ Apache Kylin是一個開源的分佈式分析引擎，提供Hadoop/Spark之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規模數據，最初由eBay Inc開發並貢獻至開源社區。它能在亞秒內查詢巨大的Hive表。

1.2 Kylin特點

Kylin的主要特點包括支持SQL接口、支持超大規模數據集、亞秒級響應、可伸縮性、高吞吐率、BI工具集成等。

• 標準SQL接口：Kylin是以標準的SQL作爲對外服務的接口。

• 支持超大數據集：Kylin對於大數據的支撐能力可能是目前所有技術中最爲領先的。早在2015年eBay的生產環境中就能支持百億記錄的秒級查詢，之後在移動的應用場景中又有了千億記錄秒級查詢的案例。

• 亞秒級響應：Kylin擁有優異的查詢相應速度，這點得益於預計算，很多複雜的計算，比如連接、聚合，在離線的預計算過程中就已經完成，這大大降低了查詢時刻所需的計算量，提高了響應速度。

• 可伸縮性和高吞吐率：單節點Kylin可實現每秒70個查詢，還可以搭建Kylin的集羣。

• BI工具集成

  Kylin可以與現有的BI工具集成，具體包括如下內容。

  ODBC：與Tableau、Excel、PowerBI等工具集成

  JDBC：與Saiku、BIRT等Java工具集成

  RestAPI：與JavaScript、Web網頁集成

  Kylin開發團隊還貢獻了Zepplin的插件，也可以使用Zepplin來訪問Kylin服務。

1.3 Kylin架構

1）REST Server

REST Server是一套面向應用程序開發的入口點，旨在實現針對Kylin平臺的應用開發工作。 此類應用程序可以提供查詢、獲取結果、觸發cube構建任務、獲取元數據以及獲取用戶權限等等。另外可以通過Restful接口實現SQL查詢。

2）查詢引擎（Query Engine）

當cube準備就緒後，查詢引擎就能夠獲取並解析用戶查詢。它隨後會與系統中的其它組件進行交互，從而向用戶返回對應的結果。

3）Routing

負責將解析的SQL生成的執行計劃轉換成cube緩存的查詢，cube是通過預計算緩存在hbase中，這部分查詢可以在秒級設置毫秒級完成，而且還有一些操作使用過的查詢原始數據（存儲在Hadoop的hdfs中通過hive查詢）。這部分查詢延遲較高。

4）元數據管理工具（Metadata）

Kylin是一款元數據驅動型應用程序。元數據管理工具是一大關鍵性組件，用於對保存在Kylin當中的所有元數據進行管理，其中包括最爲重要的cube元數據。其它全部組件的正常運作都需以元數據管理工具爲基礎。 Kylin的元數據存儲在hbase中。

5）任務引擎（Cube Build Engine）

這套引擎的設計目的在於處理所有離線任務，其中包括shell腳本、Java API以及Map Reduce任務等等。任務引擎對Kylin當中的全部任務加以管理與協調，從而確保每一項任務都能得到切實執行並解決其間出現的故障。

1.4 Kylin工作原理

​ Apache Kylin的工作原理本質上是MOLAP（Multidimension On-Line Analysis Processing）Cube，也就是多維立方體分析。是數據分析中非常經典的理論，下面對其做簡要介紹。

1.4.1 維度和度量

維度：**即觀察數據的角度。**比如員工數據，可以從性別角度來分析，也可以更加細化，從入職時間或者地區的維度來觀察。維度是一組離散的值，比如說性別中的男和女，或者時間維度上的每一個獨立的日期。因此在統計時可以將維度值相同的記錄聚合在一起，然後應用聚合函數做累加、平均、最大和最小值等聚合計算。

度量：即被聚合（觀察）的統計值，也就是聚合運算的結果。比如說員工數據中不同性別員工的人數，又或者說在同一年入職的員工有多少。

基數：某個維度的種類數。比如說性別維度，基數爲（男和女）。按照某個維度進行聚合，結果數據的大小主要取決於該維度的基數。

1.4.2 Cube和 Cuboid

​ 有了維度跟度量，一個數據表或者數據模型上的所有字段就可以分類了，它們要麼是維度，要麼是度量（可以被聚合）。於是就有了根據維度和度量做預計算的Cube理論。

​ 給定一個數據模型，我們可以對其上的所有維度進行聚合，對於N個維度來說，組合的所有可能性共有2的N次方 種。對於每一種維度的組合，將度量值做聚合計算，然後將結果保存爲一個物化視圖，稱爲Cuboid。所有維度組合的Cuboid作爲一個整體，稱爲Cube。

下面舉一個簡單的例子說明，假設有一個電商的銷售數據集，其中維度包括時間[time]、商品[item]、地區[location]和供應商[supplier]，度量爲銷售額。那麼所有維度的組合就有 24 的16 次 方 種，如下圖所示：

一維度（1D）的組合有：[time]、[item]、[location]和[supplier]4種；

二維度（2D）的組合有：[time, item]、[time, location]、[time, supplier]、[item, location]、[item, supplier]、[location, supplier]3種；

三維度（3D）的組合也有4種；

最後還有零維度（0D）和四維度（4D）各有一種，總共16種。

注意：每一種維度組合就是一個Cuboid，16個Cuboid整體就是一個Cube。

1.4.3 核心算法

Kylin的工作原理就是對數據模型做Cube預計算，並利用計算的結果加速查詢：

1）指定數據模型，定義維度和度量；

2）預計算Cube，計算所有Cuboid並保存爲物化視圖；

預計算過程是Kylin從Hive中讀取原始數據，按照我們選定的維度進行計算，並將結果集保存到Hbase中，默認的計算引擎爲MapReduce，可以選擇Spark作爲計算引擎。一次build的結果，我們稱爲一個Segment。構建過程中會涉及多個Cuboid的創建，具體創建過程由 kylin.cube.algorithm 參數決定，參數值可選 auto，layer 和 inmem， 默認值爲 auto，即 Kylin 會通過採集數據動態地選擇一個算法 (layer or inmem)，如果用戶很瞭解 Kylin 和自身的數據、集羣，可以直接設置喜歡的算法。

3）執行查詢，讀取Cuboid，運行，產生查詢結果。

1.4.3.1 逐層構建算法(layer)

​ 我們知道，一個N維的Cube，是由1個N維子立方體、N個(N-1)維子立方體、N*(N-1)/2個(N-2)維子立方體、…、N個1維子立方體和1個0維子立方體構成，總共有2^N個子立方體組成，在逐層算法中，按維度數逐層減少來計算，每個層級的計算（除了第一層，它是從原始數據聚合而來），是基於它上一層級的結果來計算的。比如，[Group by A, B]的結果，可以基於[Group by A, B, C]的結果，通過去掉C後聚合得來的；這樣可以減少重複計算；當 0維度Cuboid計算出來的時候，整個Cube的計算也就完成了。

• 每一輪的計算都是一個MapReduce任務，且串行執行；一個N維的Cube，至少需要N+1次MapReduce Job。

算法優點：

1）此算法充分利用了MapReduce的能力，處理了中間複雜的排序和洗牌工作，故而算法代碼清晰簡單，易於維護；

2）受益於Hadoop的日趨成熟，此算法對集羣要求低，運行穩定；在內部維護Kylin的過程中，很少遇到在這幾步出錯的情況；即便是在Hadoop集羣比較繁忙的時候，任務也能完成。

算法缺點：

1）當Cube有比較多維度的時候，所需要的MapReduce任務也相應增加；由於Hadoop的任務調度需要耗費額外資源，特別是集羣較龐大的時候，反覆遞交任務造成的額外開銷會相當可觀；

2）此算法會對Hadoop MapReduce輸出較多數據; 雖然已經使用了Combiner來減少從Mapper端到Reducer端的數據傳輸，所有數據依然需要通過Hadoop MapReduce來排序和組合才能被聚合，無形之中增加了集羣的壓力;

3）對的讀寫操作較多：由於每一層計算的輸出會用做下一層計算的輸入，這些需要寫到上；當所有計算都完成後，還需要額外的一輪任務將這些文件轉成的格式，以導入到中去；

• 總體而言，該算法的效率較低，尤其是當Cube維度數較大的時候。

1.4.3.2 快速構建算法(inmem)

​ 也被稱作“逐段”(By Segment) 或“逐塊”(By Split) 算法，從1.5.x開始引入該算法，利用Mapper端計算先完成大部分聚合，再將聚合後的結果交給Reducer，從而降低對網絡瓶頸的壓力。該算法的主要思想是，對Mapper所分配的數據塊，將它計算成一個完整的小Cube 段（包含所有Cuboid）；每個Mapper將計算完的Cube段輸出給Reducer做合併，生成大Cube，也就是最終結果；如圖所示解釋了此流程。

與舊算法相比，快速算法主要有兩點不同：

1） Mapper會利用內存做預聚合，算出所有組合；Mapper輸出的每個Key都是不同的，這樣會減少輸出到Hadoop MapReduce的數據量；

2）一輪便會完成所有層次的計算，減少任務的調配。

二，Kylin環境搭建

2.1 安裝地址

1）官網地址

http://kylin.apache.org/cn/

2）官方文檔

http://kylin.apache.org/cn/docs/

3）下載地址

http://kylin.apache.org/cn/download/

2.2 安裝部署

1）將apache-kylin-2.5.1-bin-hbase1x.tar.gz上傳到Linux

2）解壓apache-kylin-2.5.1-bin-hbase1x.tar.gz

[wcb@hadoop102 sorfware]$ tar -zxvf apache-kylin-2.5.1-bin-hbase1x.tar.gz -C /opt/module/

• 注意：需要在/etc/profile文件中配置HADOOP_HOME，HIVE_HOME，HBASE_HOME並將其對應的sbin（如果有這個目錄的話）和bin目錄配置到Path，最後需要source使其生效。

3. 啓動

[wcb@hadoop102 kylin]$ bin/kylin.sh start

啓動之後查看各個節點進程：

--------------------- hadoop102 ----------------
3360 JobHistoryServer(MR的歷史服務，必須啓動)
31425 HMaster
3282 NodeManager
3026 DataNode
53283 Jps
2886 NameNode
44007 RunJar
2728 QuorumPeerMain
31566 HRegionServer
--------------------- hadoop103 ----------------
5040 HMaster
2864 ResourceManager
9729 Jps
2657 QuorumPeerMain
4946 HRegionServer
2979 NodeManager
2727 DataNode
--------------------- hadoop104 ----------------
4688 HRegionServer
2900 NodeManager
9848 Jps
2636 QuorumPeerMain
2700 DataNode
2815 SecondaryNameNode

• 注意：啓動Kylin之前要保證HDFS，YARN，ZK，HBASE相關進程是正常運行的。

在http://hadoop102:7070/kylin查看Web頁面

• 用戶名爲：ADMIN，密碼爲：KYLIN（系統已填）

4）關閉

[wcb@hadoop102 kylin]$ bin/kylin.sh stop

三, 快速入門

需求：實現按照維度（工作地點）統計員工信息

3.1 數據準備

在Hive中創建數據，分別創建部門和員工外部表，並向表中導入數據。

1） 原始數據

dept.txt

10	ACCOUNTING	1700
20	RESEARCH	1800
30	SALES	1900
40	OPERATIONS	1700

emp.txt

7369	SMITH	CLERK	7902	1980-12-17	800.00		20
7499	ALLEN	SALESMAN	7698	1981-2-20	1600.00	300.00	30
7521	WARD	SALESMAN	7698	1981-2-22	1250.00	500.00	30
7566	JONES	MANAGER	7839	1981-4-2	2975.00		20
7654	MARTIN	SALESMAN	7698	1981-9-28	1250.00	1400.00	30
7698	BLAKE	MANAGER	7839	1981-5-1	2850.00		30
7782	CLARK	MANAGER	7839	1981-6-9	2450.00		10
7788	SCOTT	ANALYST	7566	1987-4-19	3000.00		20
7839	KING	PRESIDENT		1981-11-17	5000.00		10
7844	TURNER	SALESMAN	7698	1981-9-8	1500.00	0.00	30
7876	ADAMS	CLERK	7788	1987-5-23	1100.00		20
7900	JAMES	CLERK	7698	1981-12-3	950.00		30
7902	FORD	ANALYST	7566	1981-12-3	3000.00		20
7934	MILLER	CLERK	7782	1982-1-23	1300.00		10

2. 建表語句

創建部門表

create external table if not exists default.dept(
deptno int,
dname string,
loc int
)
row format delimited fields terminated by '\t';

創建員工表

create external table if not exists default.emp(
empno int,
ename string,
job string,
mgr int,
hiredate string, 
sal double, 
comm double,
deptno int)
row format delimited fields terminated by '\t';

3. 查看創建的表

hive (default)> show tables;
OK
tab_name
dept
emp

4. 向外部表中導入數據

hive (default)> load data local inpath '/opt/module/datas/dept.txt' into table default.dept;
hive (default)> load data local inpath '/opt/module/datas/emp.txt' into table default.emp;

查看數據

hive (default)> select * from emp;
hive (default)> select * from dept;

3.2 創建項目

3.2.1 登陸系統

3.2.2 創建工程

1）點擊圖上所示“+”號

2）填入項目名及描述點擊Submit

3.2.3 選擇數據源

1）選擇加載數據源方式

2）輸入要作爲數據源的表

3）查看數據源

3.3 創建Model

1）回到Models頁面

2）點擊New按鈕後點擊New Model

3）填寫Model名稱及描述後Next

4）選擇事實表

5）添加維度表

6）選擇添加的維度表及join字段

7）選擇維度信息

8）選擇度量信息

9）添加分區信息及過濾條件之後“Save”

10）創建Model完成

3.4 創建Cube

1）點擊New按鈕然後選擇New Cube

2）選擇Model及填寫Cube Name

3）添加維度

4）添加需要做預計算的內容

5）動態更新相關（默認）

6）高階模塊（默認）

7）需要修改的配置

8）Cube信息展示

9）Cube配置完成

10）觸發預計算

11）查看Build進度

12）構建Cube完成

3.5 Hive和Kylin性能對比

需求：根據部門名稱[dname]統計員工薪資總數[sum（sal）]

3.5.1 hive查詢

hive> select dname,sum(sal) from emp e join dept d on e.deptno = d.deptno group by dname;
Query ID = atguigu_20181210104140_4931b735-5bad-4a4f-bce6-67985b8fe30a
Total jobs = 1
SLF4J: Class path contains multiple SLF4J bindings.
… …
… …
Stage-Stage-2: Map: 1  Reduce: 1   Cumulative CPU: 3.95 sec   HDFS Read: 13195 HDFS Write: 48 SUCCESS
Total MapReduce CPU Time Spent: 3 seconds 950 msec
OK
ACCOUNTING      3750.0
RESEARCH        10875.0
SALES   9400.0
Time taken: 23.893 seconds, Fetched: 3 row(s)
hive>

3.5.2 Kylin查詢

1）進入Insight頁面

2）在New Query中輸入查詢語句並Submit

3）數據圖表展示及導出

4）圖表展示之條形圖

5）圖表展示之餅圖

四，可視化

可以與Kylin結合使用的可視化工具很多，例如：

ODBC：與Tableau、Excel、PowerBI等工具集成

JDBC：與Saiku、BIRT等Java工具集成

RestAPI：與JavaScript、Web網頁集成

Kylin開發團隊還貢獻了Zepplin的插件，也可以使用Zepplin來訪問Kylin服務。

4.1 JDBC

1）新建項目並導入依賴

<dependencies>
        <dependency>
            <groupId>org.apache.kylin</groupId>
            <artifactId>kylin-jdbc</artifactId>
            <version>2.5.1</version>
        </dependency>
    </dependencies>

2）編碼

package com.wcb;

import java.sql.*;

public class TestKylin {

    public static void main(String[] args) throws Exception {

        //Kylin_JDBC 驅動
        String KYLIN_DRIVER = "org.apache.kylin.jdbc.Driver";

        //Kylin_URL
        String KYLIN_URL = "jdbc:kylin://hadoop102:7070/FirstProject";

        //Kylin的用戶名
        String KYLIN_USER = "ADMIN";

        //Kylin的密碼
        String KYLIN_PASSWD = "KYLIN";

        //添加驅動信息
        Class.forName(KYLIN_DRIVER);

        //獲取連接
        Connection connection = DriverManager.getConnection(KYLIN_URL, KYLIN_USER, KYLIN_PASSWD);

        //預編譯SQL
        PreparedStatement ps = connection.prepareStatement("SELECT sum(sal) FROM emp group by deptno");

        //執行查詢
        ResultSet resultSet = ps.executeQuery();

        //遍歷打印
        while (resultSet.next()) {
            System.out.println(resultSet.getInt(1));
        }
    }
}

3）結果展示

4.2 Zepplin

4.2.1 Zepplin安裝和啓動

1）將zeppelin-0.8.0-bin-all.tgz上傳至Linux

2）解壓zeppelin-0.8.0-bin-all.tgz之/opt/module

[wcb@hadoop102 sorfware]$ tar -zxvf zeppelin-0.8.0-bin-all.tgz -C /opt/module/

3）修改名稱

[wcb@hadoop102 module]$ mv zeppelin-0.8.0-bin-all/ zeppelin

4）啓動

[wcb@hadoop102 zeppelin]$ bin/zeppelin-daemon.sh start

• 可登錄網頁查看，web默認端口號爲8080 http://hadoop102:8080

4.2.2 配置Zepplin支持Kylin

1）點擊右上角anonymous選擇Interpreter

2）搜索Kylin插件並修改相應的配置

3）修改完成點擊Save完成

4.3.3 案例

需求：查詢員工詳細信息，並使用各種圖表進行展示

1）點擊Notebook創建新的note

2）填寫Note Name點擊Create

3）執行查詢

4）結果展示

5）其他圖表格式

五，Cube構建優化

從之前章節的介紹可以知道，在沒有采取任何優化措施的情況下，Kylin會對每一種維度的組合進行預計算，每種維度的組合的預計算結果被稱爲Cuboid。假設有4個維度，我們最終會有16個Cuboid需要計算。

但在現實情況中，用戶的維度數量一般遠遠大於4個。假設用戶有10 個維度，那麼沒有經過任何優化的Cube就會存在2^10 =1024個Cuboid；而如果用戶有20個維度，那麼Cube中總共會存在2^20 =1048576個Cuboid。雖然每個Cuboid的大小存在很大的差異，但是單單想到Cuboid的數量就足以讓人想象到這樣的Cube對構建引擎、存儲引擎來說壓力有多麼巨大。因此，在構建維度數量較多的Cube時，尤其要注意Cube的剪枝優化（即減少Cuboid的生成）。

5.1 找到問題Cube

5.1.1 檢查CuboId

​ Apache Kylin提供了一個簡單的工具，供用戶檢查Cube中哪些Cuboid 最終被預計算了，我們稱其爲被物化（Materialized）的Cuboid。同時，這種方法還能給出每個Cuboid所佔空間的估計值。由於該工具需要在對數據進行一定階段的處理之後才能估算Cuboid的大小，因此一般來說只能在Cube構建完畢之後再使用該工具。目前關於這一點也是該工具的一大不足，由於同一個Cube的不同Segment之間僅是輸入數據不同，模型信息和優化策略都是共享的，所以不同Segment中哪些Cuboid被物化哪些沒有被物化都是一樣的。因此只要Cube中至少有一個Segment，那麼就能使用如下的命令行工具去檢查這個Cube中的

Cuboid狀態：

bin/kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader CUBE_NAME
CUBE_NAME：想要查看的cube的名字

例如：

[wcb@hadoop102 kylin]$ bin/kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader FirstCube

… …
… …
Statistics of FirstCube[FULL_BUILD]

Cube statistics hll precision: 14
Total cuboids: 7
Total estimated rows: 51
Total estimated size(MB): 3.027915954589844E-4
Sampling percentage:  100
Mapper overlap ratio: 1.0
Mapper number: 1
Length of dimension DEFAULT.EMP.JOB is 1
Length of dimension DEFAULT.EMP.MGR is 1
Length of dimension DEFAULT.EMP.DEPTNO is 1
|---- Cuboid 111, est row: 10, est MB: 0
    |---- Cuboid 011, est row: 9, est MB: 0, shrink: 90%
        |---- Cuboid 001, est row: 3, est MB: 0, shrink: 33.33%
        |---- Cuboid 010, est row: 7, est MB: 0, shrink: 77.78%
    |---- Cuboid 101, est row: 9, est MB: 0, shrink: 90%
        |---- Cuboid 100, est row: 5, est MB: 0, shrink: 55.56%
|---- Cuboid 110, est row: 8, est MB: 0, shrink: 80%

​ 從分析結果的下半部分可以看到，所有的Cuboid及它的分析結果都以樹狀的形式打印了出來。在這棵樹中，每個節點代表一個Cuboid，每個Cuboid都由一連串1或0的數字組成，如果數字爲0，則代表這個Cuboid中不存在相應的維度；如果數字爲1，則代表這個Cuboid中存在相應的維度。除了最頂端的Cuboid之外，每個Cuboid都有一個父親Cuboid，且都比父親Cuboid少了一個“1”。其意義是這個Cuboid就是由它的父親節點減少一個維度聚合而來的（上卷）。最頂端的Cuboid稱爲Base Cuboid，它直接由源數據計算而來。

​ 每行Cuboid的輸出中除了0和1的數字串以外，後面還有每個Cuboid 的的行數與父親節點的對比（Shrink值）。所有Cuboid行數的估計值之和應該等於Segment的行數估計值，每個Cuboid都是在它的父親節點的基礎上進一步聚合而成的，因此從理論上說每個Cuboid無論是行數還是大小都應該小於它的父親。在這棵樹中，我們可以觀察每個節點的Shrink值，如果該值接近100%，則說明這個Cuboid雖然比它的父親Cuboid少了一個維度，但是並沒有比它的父親Cuboid少很多行數據。換而言之，即使沒有這個Cuboid， 我們在查詢時使用它的父親Cuboid，也不會有太大的代價。那麼我們就可以對這個Cuboid進行剪枝操作。

5.1.2 檢查Cube大小

​ 還有一種更爲簡單的方法可以幫助我們判斷Cube是否已經足夠優化。在Web GUI的Model頁面選擇一個READY狀態的Cube，當我們把光標移到該Cube的Cube Size列時，Web GUI會提示Cube的源數據大小，以及當前Cube的大小除以源數據大小的比例，稱爲膨脹率（Expansion Rate），如圖所示。

一般來說，Cube的膨脹率應該在0%~1000%之間，如果一個Cube的膨脹率超過1000%，那麼Cube管理員應當開始挖掘其中的原因。通常，膨脹率高有以下幾個方面的原因。

1）Cube中的維度數量較多，且沒有進行很好的Cuboid剪枝優化，導致Cuboid數量極多;

2）Cube中存在較高基數的維度，導致包含這類維度的每一個Cuboid佔用的空間都很大，這些Cuboid累積造成整體Cube體積變大;

因此，對於Cube膨脹率居高不下的情況，管理員需要結合實際數據進行分析，可靈活地運用接下來介紹的優化方法對Cube進行優化。

5.2 優化構建

5.2.1 使用聚合組

​ 聚合組（Aggregation Group）是一種強大的剪枝工具。聚合組假設一個Cube的所有維度均可以根據業務需求劃分成若干組（當然也可以是一個組），由於同一個組內的維度更可能同時被同一個查詢用到，因此會表現出更加緊密的內在關聯。每個分組的維度集合均是Cube所有維度的一個子集，不同的分組各自擁有一套維度集合，它們可能與其他分組有相同的維度，也可能沒有相同的維度。每個分組各自獨立地根據自身的規則貢獻出一批需要被物化的Cuboid，所有分組貢獻的Cuboid的並集就成爲了當前Cube中所有需要物化的Cuboid的集合。不同的分組有可能會貢獻出相同的Cuboid，構建引擎會察覺到這點，並且保證每一個Cuboid無論在多少個分組中出現，它都只會被物化一次。

​ 對於每個分組內部的維度，用戶可以使用如下三種可選的方式定義，它們之間的關係，具體如下。

​ 1）強制維度（Mandatory），如果一個維度被定義爲強制維度，那麼這個分組產生的所有Cuboid中每一個Cuboid都會包含該維度。每個分組中都可以有0個、1個或多個強制維度。如果根據這個分組的業務邏輯，則相關的查詢一定會在過濾條件或分組條件中，因此可以在該分組中把該維度設置爲強制維度。

​ 2）層級維度（Hierarchy），每個層級包含兩個或更多個維度。假設一個層級中包含D1，D2…Dn這n個維度，那麼在該分組產生的任何Cuboid中， 這n個維度只會以（），（D1），（D1，D2）…（D1，D2…Dn）這n+1種形式中的一種出現。每個分組中可以有0個、1個或多個層級，不同的層級之間不應當有共享的維度。如果根據這個分組的業務邏輯，則多個維度直接存在層級關係，因此可以在該分組中把這些維度設置爲層級維度。

​ 3）聯合維度（Joint），每個聯合中包含兩個或更多個維度，如果某些列形成一個聯合，那麼在該分組產生的任何Cuboid中，這些聯合維度要麼一起出現，要麼都不出現。每個分組中可以有0個或多個聯合，但是不同的聯合之間不應當有共享的維度（否則它們可以合併成一個聯合）。如果根據這個分組的業務邏輯，多個維度在查詢中總是同時出現，則可以在該分組中把這些維度設置爲聯合維度。

出現，它都只會被物化一次。

​