6、apache-kylin-3.1.3-bin-hadoop3 cube优化方向及减少cuboids和降低膨胀率详细示例

apache-kylin-3.1.3-bin-hadoop3 系列文章

1、apache-kylin-3.1.3-bin-hadoop3介绍及部署、验证详解2、apache-kylin-3.1.3-bin-hadoop3集群部署
3、apache-kylin-3.1.3-bin-hadoop3基本操作(创建model和cube、数据查詢)
4、apache-kylin-3.1.3-bin-hadoop3增量构建、全量构建详细示例
5、apache-kylin-3.1.3-bin-hadoop3 segment管理及JDBC操作
6、apache-kylin-3.1.3-bin-hadoop3 cube优化方向及减少cuboids和降低膨胀率详细示例

---

文章目录

• apache-kylin-3.1.3-bin-hadoop3 系列文章
• 一、优化方向介绍

• 1、減少組合cuboids
• 2、輸出壓縮
• 3、壓縮HIve表
• 4、Hive表分區
• 5、用高 cardinality Dimensions 的 Cube
• 6、提升 cube 响应时间

• 二、示例一：減少組合（cuboids的数量）

• 1、Cuboid剪枝优化
• 2、检查Cuboid数量
• 3、检查Cube大小
• 4、使用衍生维度
• 5、聚合组Aggregation Group

• 1）、强制维度（Mandatory）
• 2）、层级维度（Hierarchy）
• 3）、联合维度（Joint）
• 4）、聚合组设置

• 三、示例2：降低膨脹率

• 1、數據准备
• 2、創建model
• 3、創建cube（優化前的cube）
• 4、構建
• 5、查看膨脹率
• 6、優化cube
• 7、比較膨脹率
• 8、比較cuboids的數量

---

本文简单的介绍了cube的优化方向，以及以减少cuboids和降低膨胀率为示例进行了详细的介绍。
本文依赖kylin环境好用。
本文分为3个部分，即优化方向、减少cuboids和降低膨胀率两个示例。

一、优化方向介绍

參考鏈接：https://kylin.apache.org/cn/docs31/tutorial/cube_build_performance.html

1、減少組合cuboids

即減少cuboids。在 Dimensions 上使用 Joint 和 Hierarchy 来减少组合 (cuboids 的数量)。

2、輸出壓縮

使用 Snappy 压缩 HBase Cube。

3、壓縮HIve表

在 Hive 输入表中使用 ORC 格式和压缩(Snappy)，大部分時間是有效的，需具體情況具體驗證。

4、Hive表分區

5、用高 cardinality Dimensions 的 Cube

• 解决方案 1：增加 RAM 给 YARN
• 解决方案 2：增加在 Mapper 步骤中使用的 vCores 数量来减少 RAM 使用
• 解决方案 3：可以通过 node 为 YARN 使用最大的 RAM（yarn.nodemanager.resource.memory-mb) 并为每一个 container 使用最小的 RAM 进行实验（yarn.scheduler.minimum-allocation-mb）。如果为每一个 container 增加了最小的 RAM，YARN 将会减少 Mappers 的数量。

6、提升 cube 响应时间

使用不同 aggregations groups 来提升一些非常重要 Dim 或有高 cardinality 的 Dim 的查询性能

二、示例一：減少組合（cuboids的数量）

1、Cuboid剪枝优化

将以减少Cuboid数量为目的的Cuboid优化统称为Cuboid剪枝。
在没有采取任何优化措施的情况下，Kylin会对每一种维度的组合进行预计算，每种维度的组合的预计算结果被称为Cuboid。
例如：

• 如果有4个维度，可能最终会有2^4 =16个Cuboid需要计算。但在实际开发中，用户的维度数量一般远远大于4个
• 如果有10个维度，那么没有经过任何优化的Cube就会存在2^10 =1024个Cuboid

Cuboid的数量太多会导致Cube对构建引擎、存储引擎压力非常大。因此，在构建维度数量较多的Cube时，尤其要注意Cube的剪枝优化。
Cube的剪枝优化是一种试图减少额外空间占用的方法，这种方法的前提是不会明显影响查询时间。在做剪枝优化的时候，
需要选择跳过那些“多余”的Cuboid

• 有的Cuboid因为查询样式的原因永远不会被查询到，因此显得多余
• 有的Cuboid的能力和其他Cuboid接近，因此显得多余

Kylin提供了一系列简单的工具来帮助完成Cube的剪枝优化

2、检查Cuboid数量

Apache Kylin提供了一个简单的工具，检查Cube中哪些Cuboid最终被预计算了，称这些Cuboid为被物化的Cuboid，该工具还能给出每个Cuboid所占空间的估计值。由于该工具需要在对数据进行一定阶段的处理之后才能估算Cuboid的大小，因此一般来说只能在Cube构建完毕之后再使用该工具。
使用如下的命令行工具去检查这个Cube中的Cuboid状态：

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

kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader cube_order_dim_date
....
============================================================================
Statistics of cube_order_dim_date[20191013000000_20191014000000]

Cube statistics hll precision: 14
Total cuboids: 3
Total estimated rows: 7
Total estimated size(MB): 3.5762786865234375E-5
Sampling percentage:  100
Mapper overlap ratio: 1.0
Mapper number: 1
Length of dimension TEST.FACT_ORDER.USER_ID is 1
Length of dimension TEST.FACT_ORDER.DT is 1
|---- Cuboid 11, est row: 3, est MB: 0
    |---- Cuboid 01, est row: 1, est MB: 0, shrink: 33.33%
    |---- Cuboid 10, est row: 3, est MB: 0, shrink: 100%
----------------------------------------------------------------------------
============================================================================
Statistics of cube_order_dim_date[20191014000000_20191015000000]

Cube statistics hll precision: 14
Total cuboids: 3
Total estimated rows: 9
Total estimated size(MB): 4.601478576660156E-5
Sampling percentage:  100
Mapper overlap ratio: 1.0
Mapper number: 1
Length of dimension TEST.FACT_ORDER.USER_ID is 1
Length of dimension TEST.FACT_ORDER.DT is 1
|---- Cuboid 11, est row: 4, est MB: 0
    |---- Cuboid 01, est row: 1, est MB: 0, shrink: 25%
    |---- Cuboid 10, est row: 4, est MB: 0, shrink: 100%
----------------------------------------------------------------------------

分析：
Cube statistics hll precision: 14  估计Cuboid大小的精度（Hll Precision）
Total cuboids: 3  总共的Cuboid数量
Total estimated rows: 9  Segment的总行数估计
Total estimated size(MB): 4.601478576660156E-5  Segment的大小估计，Segment的大小决定mapper、reducer的数量、数据分片数量等
Sampling percentage:  100
Mapper overlap ratio: 1.0
Mapper number: 1
Length of dimension TEST.FACT_ORDER.USER_ID is 1
Length of dimension TEST.FACT_ORDER.DT is 1
|---- Cuboid 11, est row: 4, est MB: 0
    |---- Cuboid 01, est row: 1, est MB: 0, shrink: 25%
    |---- Cuboid 10, est row: 4, est MB: 0, shrink: 100%

# 说明
# 所有的Cuboid及它的分析结果都以树状的形式打印了出来
# 在这棵树中，每个节点代表一个Cuboid，每个Cuboid都由一连串1或0的数字组成
# 数字串的长度等于有效维度的数量，从左到右的每个数字依次代表Rowkeys设置中的各个维度。如果数字为0，则代表这个Cuboid中不存在相应的维度；如果数字为1，则代表这个Cuboid中存在相应的维度
# 除了最顶端的Cuboid之外，每个Cuboid都有一个父亲Cuboid，且都比父亲Cuboid少了一个“1”。其意义是这个Cuboid就是由它的父亲节点减少一个维度聚合而来的（上卷）
# 最顶端的Cuboid称为Base Cuboid，它直接由源数据计算而来。Base Cuboid中包含所有的维度，因此它的数字串中所有的数字均为1
# 每行Cuboid的输出中除了0和1的数字串以外，后面还有每个Cuboid的具体信息，包括该Cuboid行数的估计值、该Cuboid大小的估计值，以及这个Cuboid的行数与父亲节点的对比（Shrink值）
# 所有Cuboid行数的估计值之和应该等于Segment的行数估计值，所有Cuboid的大小估计值应该等于该Segment的大小估计值。每个Cuboid都是在它的父亲节点的基础上进一步聚合而成的

3、检查Cube大小

在Web GUI的Model页面选择一个READY状态的Cube，把光标移到该Cube的Cube Size列时，Web GUI会提示Cube的源数据大小，以及当前Cube的大小除以源数据大小的比例，称为膨胀率（Expansion Rate）。如下图所示

一般来说，Cube的膨胀率应该在0%~1000%之间，如果一个Cube的膨胀率超过1000%，那么应当开始找出其中的原因。通常，膨胀率高有以下几个方面的原因：

• Cube中的维度数量较多，且没有进行很好的Cuboid剪枝优化，导致Cuboid数量多
• Cube中存在较高基数的维度，导致包含这类维度的每一个Cuboid占用的空间都很大，这些Cuboid累积造成整体Cube体积变大
• 存在比较占用空间的度量，例如Count Distinct，因此需要在Cuboid的每一行中都为其保存一个较大度量数据，最坏的情况将会导致Cuboid中每一行都有数十KB，从而造成整个Cube的体积变大

4、使用衍生维度

示例：有两张表 用户维度表（dim_user）、订单事实表（fact_order），要根据各个维度建立MOLAP立方体

生成Cube时，如果指定维度表中的：姓名、出生年份、政治面貌、职业、性别、民族、省份、市、区等维度生成Cube，这些维度相互组合，会造成较大的Cube膨胀率。使用衍生维度用于在有效维度内将维度表上的非主键维度排除掉，并使用维度表的主键（其实是事实表上相应的外键）来替代它们。Kylin会在底层记录维度表主键与维度表其他维度之间的映射关系，以便在查询时能够动态地将维度表的主键“翻译”成这些非主键维度，并进行实时聚合。

• 选择衍生维度



• 创建Cube的时候，维度如果指定为衍生维度，Kylin将会排除这些维度，而是使用维度表的主键来代替它们创建Cuboid。后续查询的时候，再基于主键的聚合结果，再进行一次聚合。
• 优化效果
  维度表的N个维度组合成的cuboid个数会从2的N次方降为2。
• 不适用的场景
  如果从维度表主键到某个维度表维度所需要的聚合工作量非常大，此时作为一个普通的维度聚合更合适，否则会影响Kylin的查询性能

5、聚合组Aggregation Group

聚合组（Aggregation Group）是一种更强大的剪枝工具

聚合组假设一个Cube的所有维度均可以根据业务需求划分成若干组

同一个组内的维度更可能同时被同一个查询用到，每个分组的维度集合均是Cube所有维度的一个子集

不同的分组各自拥有一套维度集合，它们可能与其他分组有相同的维度，也可能没有相同的维度

每个分组各自独立地根据自身的规则贡献出一批需要被物化的Cuboid，所有分组贡献的Cuboid的并集就成为了当前Cube中所有需要物化的Cuboid的集合

不同的分组有可能会贡献出相同的Cuboid，构建引擎会察觉到这点，并且保证每一个Cuboid无论在多少个分组中出现，它都只会被物化一次

对于每个分组内部的维度，用户可以使用如下三种可选的方式定义它们之间的关系，具体如下：

1）、强制维度（Mandatory）

如果一个维度被定义为强制维度，那么这个分组产生的所有Cuboid中每一个Cuboid都会包含该维度。所有cuboid必须包含的维度，不会计算不包含强制维度的cuboid
每个分组中都可以有0个、1个或多个强制维度
如果根据这个分组的业务逻辑，则相关的查询一定会在过滤条件或分组条件中，因此可以在该分组中把该维度设置为强制维度

• 适用场景：可以将确定在查询时一定会使用的维度设为强制维度。例如，时间维度。
• 优化效果：将一个维度设为强制维度，则cuboid个数直接减半

2）、层级维度（Hierarchy）

每个层级包含两个或更多个维度
假设一个层级中包含D1，D2…Dn这n个维度，那么在该分组产生的任何Cuboid中，这n个维度只会以（），（D1），（D1，D2）…（D1，D2…Dn）这n+1种形式中的一种出现
每个分组中可以有0个、1个或多个层级，不同的层级之间不应当有共享的维度
如果根据这个分组的业务逻辑，则多个维度直接存在层级关系，因此可以在该分组中把这些维度设置为层级维度

• 使用场景：年，月，日；国家，省份，城市这类具有层次关系的维度
• 优化效果：将N个维度设置为层次维度，则这N个维度组合成的cuboid个数会从2的N次方减少到N+1

3）、联合维度（Joint）

每个联合中包含两个或更多个维度，如果某些列形成一个联合，那么在该分组产生的任何Cuboid中，这些联合维度要么一起出现，要么都不出现
每个分组中可以有0个或多个联合，但是不同的联合之间不应当有共享的维度（否则它们可以合并成一个联合）。如果根据这个分组的业务逻辑，多个维度在查询中总是同时出现，则可以在该分组中把这些维度设置为联合维度

• 适用场景：可以将确定在查询时一定会同时使用的几个维度设为一个联合维度
• 优化效果：将N个维度设置为联合维度，则这N个维度组合成的cuboid个数会从2的N次方减少到1

4）、聚合组设置

三、示例2：降低膨脹率

对Cube膨胀率进行调优

1、數據准备

-- 1. 地理维度表
create table `test`.`dim_address`(
    id int,         
    province string,    
    city string,        
    region string       
)
row format delimited fields terminated by ',' stored as TEXTFILE;

-- 2. 时间维度表
create table `test`.`dim_date`(
    year int,      
    quarter string,    
    month int,    
    day int        
)
row format delimited fields terminated by ',' stored as TEXTFILE;

-- 3. 订单数据
create table `test`.`fact_order2`(
    orderId int,    
    price int,
    province string,
    city string,
    region string,
    year int,
    month int,
    day int
)
row format delimited fields terminated by ',' stored as TEXTFILE;


-- 加载数据文件
load data local inpath '/usr/local/bigdata/testdata/data_address.csv' overwrite into table `test`.`dim_address`;
load data local inpath '/usr/local/bigdata/testdata/data_date.csv' overwrite into table `test`.`dim_date`;
load data local inpath '/usr/local/bigdata/testdata/data_order.csv' overwrite into table `test`.`fact_order2`;

-- 同步Hive表到kylin中

0: jdbc:hive2://server4:10000> show tables;
+--------------+
|   tab_name   |
+--------------+
| dim_address  |
| dim_channel  |
| dim_date     |
| dim_product  |
| dim_region   |
| dim_user     |
| dw_sales     |
| fact_order   |
| fact_order2  |
+--------------+

2、創建model

3、創建cube（優化前的cube）

4、構建

5、查看膨脹率

6、優化cube

这一步骤是为增量构建 cube 而设计的。关于增量构建参考文章：4、apache-kylin-3.1.3-bin-hadoop3增量构建、全量构建详细示例

• Auto Merge Thresholds: 自动合并小的 segments 到中等甚至更大的 segment。如果不想自动合并，删除默认2个选项
• Volatile Range: 默认为0，会自动合并所有可能的 cube segments，或者用 ‘Auto Merge’ 将不会合并最新的 [Volatile Range] 天的 cube segments
• Retention Threshold: 只会保存 cube 过去几天的 segment，旧的 segment 将会自动从头部删除；0表示不启用这个功能
• Partition Start Date: cube 的开始日期

• Aggregation Groups： Cube 中的维度可以划分到多个聚合组中。默认 kylin 会把所有维度放在一个聚合组，当维度较多时，产生的组合数可能是巨大的，会造成 Cube 爆炸；如果能了解查询模式，可以创建多个聚合组。在每个聚合组内，使用 “Mandatory Dimensions”, “Hierarchy Dimensions” 和 “Joint Dimensions” 来进一步优化维度组合
• Mandatory Dimensions：必要维度，用于总是出现的维度。例如，如果你的查询中总是会带有 “ORDER_DATE” 做为 group by 或 过滤条件，那么它可以被声明为必要维度。这样一来，所有不含此维度的 cuboid 就可以被跳过计算
• Hierarchy Dimensions- 层级维度，例如 “国家” -> “省” -> “市” 是一个层级；不符合此层级关系的 cuboid 可以被跳过计算，例如 [“省”], [“市”]. 定义层级维度时，将父级别维度放在子维度的左边
• Joint Dimensions：联合维度，有些维度往往一起出现，或者它们的基数非常接近（有1:1映射关系）。例如 “user_id” 和 “email”。把多个维度定义为组合关系后，所有不符合此关系的 cuboids 会被跳过计算
• Rowkeys：是由维度编码值组成。”Dictionary” （字典）是默认的编码方式；字典只能处理中低基数（少于一千万）的维度；如果维度基数很高（如大于1千万)， 选择 “false” 然后为维度输入合适的长度，通常是那列的最大长度值；如果超过最大值，会被截断。如果没有字典编码，cube 的大小可能会非常大
  可以拖拽维度列去调整其在 rowkey 中位置；位于rowkey前面的列，将可以用来大幅缩小查询的范围。通常建议将 mandantory 维度放在开头，然后是在过滤 ( where 条件)中起到很大作用的维度；如果多个列都会被用于过滤，将高基数的维度（如 user_id）放在低基数的维度（如 age）的前面
• Mandatory Cuboids：维度组合白名单。确保想要构建的 cuboid 能被构建
• Cube Engine： cube 构建引擎。有两种：MapReduce 和 Spark。如果cube 只有简单度量（SUM, MIN, MAX)，建议使用 Spark。如果 cube 中有复杂类型度量（COUNT DISTINCT, TOP_N），建议使用 MapReduce
• Advanced Dictionaries： “Global Dictionary” 是用于精确计算 COUNT DISTINCT 的字典，它会将一个非 integer的值转成 integer，以便于 bitmap 进行去重。如果你要计算 COUNT DISTINCT 的列本身已经是 integer 类型，那么不需要定义 Global Dictionary。 Global Dictionary 会被所有 segment 共享，因此支持在跨 segments 之间做上卷去重操作。Global Dictionary 随着数据的加载，可能会不断变大
  “Segment Dictionary” 是另一个用于精确计算 COUNT DISTINCT 的字典，与 Global Dictionary 不同的是，它是基于一个 segment 的值构建的，因此不支持跨 segments 的汇总计算。如果cube 不是分区的或者能保证所有 SQL 按照 partition_column 进行 group by， 那么应该使用 “Segment Dictionary” 而不是 “Global Dictionary”，这样可以避免单个字典过大的问题
  ”Global Dictionary” 和 “Segment Dictionary” 都是单向编码的字典，仅用于 COUNT DISTINCT 计算(将非 integer 类型转成 integer 用于 bitmap计算)，他们不支持解码，因此不能为普通维度编码
• Advanced Snapshot Table：为全局 lookup 表而设计，提供不同的存储类型
• Advanced ColumnFamily：如果有超过一个的COUNT DISTINCT 或 TopN 度量，可以将它们放在更多列簇中，以优化与HBase 的I/O
  
  
  
  
  
  進行構建。

7、比較膨脹率

通過下圖可以看出膨脹率有減少，可能是測試數據不准，變化率有限。

8、比較cuboids的數量

優化后cuboids數量有明顯的下降，優化前有63個，優化后有19個

kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader cube_optimize_test_before
 
 Statistics of cube_optimize_test_before[FULL_BUILD]

Cube statistics hll precision: 14
Total cuboids: 63
Total estimated rows: 4807
Total estimated size(MB): 0.02726459503173828
Sampling percentage:  100
Mapper overlap ratio: 1.0
Mapper number: 1
Length of dimension TEST.FACT_ORDER2.PROVINCE is 1
Length of dimension TEST.FACT_ORDER2.CITY is 1
Length of dimension TEST.FACT_ORDER2.REGION is 1
Length of dimension TEST.FACT_ORDER2.YEAR is 1
Length of dimension TEST.FACT_ORDER2.MONTH is 1
Length of dimension TEST.FACT_ORDER2.DAY is 1
|---- Cuboid 111111, est row: 227, est MB: 0
    |---- Cuboid 011111, est row: 226, est MB: 0, shrink: 99.56%
        |---- Cuboid 001111, est row: 227, est MB: 0, shrink: 100.44%
            |---- Cuboid 000111, est row: 25, est MB: 0, shrink: 11.01%
                |---- Cuboid 000011, est row: 25, est MB: 0, shrink: 100%
                    |---- Cuboid 000001, est row: 25, est MB: 0, shrink: 100%
                    |---- Cuboid 000010, est row: 1, est MB: 0, shrink: 4%
                |---- Cuboid 000101, est row: 25, est MB: 0, shrink: 100%
                    |---- Cuboid 000100, est row: 1, est MB: 0, shrink: 4%
                |---- Cuboid 000110, est row: 1, est MB: 0, shrink: 4%
            |---- Cuboid 001011, est row: 227, est MB: 0, shrink: 100%
                |---- Cuboid 001001, est row: 227, est MB: 0, shrink: 100%
                    |---- Cuboid 001000, est row: 9, est MB: 0, shrink: 3.96%
                |---- Cuboid 001010, est row: 9, est MB: 0, shrink: 3.96%
            |---- Cuboid 001101, est row: 227, est MB: 0, shrink: 100%
                |---- Cuboid 001100, est row: 9, est MB: 0, shrink: 3.96%
            |---- Cuboid 001110, est row: 9, est MB: 0, shrink: 3.96%
        |---- Cuboid 010111, est row: 75, est MB: 0, shrink: 33.19%
            |---- Cuboid 010011, est row: 75, est MB: 0, shrink: 100%
                |---- Cuboid 010001, est row: 75, est MB: 0, shrink: 100%
                    |---- Cuboid 010000, est row: 3, est MB: 0, shrink: 4%
                |---- Cuboid 010010, est row: 3, est MB: 0, shrink: 4%
            |---- Cuboid 010101, est row: 75, est MB: 0, shrink: 100%
                |---- Cuboid 010100, est row: 3, est MB: 0, shrink: 4%
            |---- Cuboid 010110, est row: 3, est MB: 0, shrink: 4%
        |---- Cuboid 011011, est row: 226, est MB: 0, shrink: 100%
            |---- Cuboid 011001, est row: 226, est MB: 0, shrink: 100%
                |---- Cuboid 011000, est row: 9, est MB: 0, shrink: 3.98%
            |---- Cuboid 011010, est row: 9, est MB: 0, shrink: 3.98%
        |---- Cuboid 011101, est row: 226, est MB: 0, shrink: 100%
            |---- Cuboid 011100, est row: 9, est MB: 0, shrink: 3.98%
        |---- Cuboid 011110, est row: 9, est MB: 0, shrink: 3.98%
    |---- Cuboid 101111, est row: 226, est MB: 0, shrink: 99.56%
        |---- Cuboid 100111, est row: 75, est MB: 0, shrink: 33.19%
            |---- Cuboid 100011, est row: 75, est MB: 0, shrink: 100%
                |---- Cuboid 100001, est row: 75, est MB: 0, shrink: 100%
                    |---- Cuboid 100000, est row: 3, est MB: 0, shrink: 4%
                |---- Cuboid 100010, est row: 3, est MB: 0, shrink: 4%
            |---- Cuboid 100101, est row: 75, est MB: 0, shrink: 100%
                |---- Cuboid 100100, est row: 3, est MB: 0, shrink: 4%
            |---- Cuboid 100110, est row: 3, est MB: 0, shrink: 4%
        |---- Cuboid 101011, est row: 226, est MB: 0, shrink: 100%
            |---- Cuboid 101001, est row: 226, est MB: 0, shrink: 100%
                |---- Cuboid 101000, est row: 9, est MB: 0, shrink: 3.98%
            |---- Cuboid 101010, est row: 9, est MB: 0, shrink: 3.98%
        |---- Cuboid 101101, est row: 226, est MB: 0, shrink: 100%
            |---- Cuboid 101100, est row: 9, est MB: 0, shrink: 3.98%
        |---- Cuboid 101110, est row: 9, est MB: 0, shrink: 3.98%
    |---- Cuboid 110111, est row: 75, est MB: 0, shrink: 33.04%
        |---- Cuboid 110011, est row: 75, est MB: 0, shrink: 100%
            |---- Cuboid 110001, est row: 75, est MB: 0, shrink: 100%
                |---- Cuboid 110000, est row: 3, est MB: 0, shrink: 4%
            |---- Cuboid 110010, est row: 3, est MB: 0, shrink: 4%
        |---- Cuboid 110101, est row: 75, est MB: 0, shrink: 100%
            |---- Cuboid 110100, est row: 3, est MB: 0, shrink: 4%
        |---- Cuboid 110110, est row: 3, est MB: 0, shrink: 4%
    |---- Cuboid 111011, est row: 227, est MB: 0, shrink: 100%
        |---- Cuboid 111001, est row: 227, est MB: 0, shrink: 100%
            |---- Cuboid 111000, est row: 9, est MB: 0, shrink: 3.96%
        |---- Cuboid 111010, est row: 9, est MB: 0, shrink: 3.96%
    |---- Cuboid 111101, est row: 227, est MB: 0, shrink: 100%
        |---- Cuboid 111100, est row: 9, est MB: 0, shrink: 3.96%
    |---- Cuboid 111110, est row: 9, est MB: 0, shrink: 3.96%
----------------------------------------------------------------------------

kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader cube_optimize_test_after

Statistics of cube_optimize_test_after[FULL_BUILD]

Cube statistics hll precision: 14
Total cuboids: 15
Total estimated rows: 449
Total estimated size(MB): 0.002681732177734375
Sampling percentage:  100
Mapper overlap ratio: 1.0
Mapper number: 1
Length of dimension TEST.FACT_ORDER2.PROVINCE is 1
Length of dimension TEST.FACT_ORDER2.CITY is 1
Length of dimension TEST.FACT_ORDER2.REGION is 1
Length of dimension TEST.FACT_ORDER2.YEAR is 1
Length of dimension TEST.FACT_ORDER2.MONTH is 1
Length of dimension TEST.FACT_ORDER2.DAY is 1
|---- Cuboid 111111, est row: 227, est MB: 0
    |---- Cuboid 110111, est row: 75, est MB: 0, shrink: 33.04%
        |---- Cuboid 100111, est row: 75, est MB: 0, shrink: 100%
            |---- Cuboid 000111, est row: 25, est MB: 0, shrink: 33.33%
                |---- Cuboid 000110, est row: 1, est MB: 0, shrink: 4%
                    |---- Cuboid 000100, est row: 1, est MB: 0, shrink: 100%
            |---- Cuboid 100110, est row: 3, est MB: 0, shrink: 4%
                |---- Cuboid 100100, est row: 3, est MB: 0, shrink: 100%
                    |---- Cuboid 100000, est row: 3, est MB: 0, shrink: 100%
        |---- Cuboid 110110, est row: 3, est MB: 0, shrink: 4%
            |---- Cuboid 110100, est row: 3, est MB: 0, shrink: 100%
                |---- Cuboid 110000, est row: 3, est MB: 0, shrink: 100%
    |---- Cuboid 111110, est row: 9, est MB: 0, shrink: 3.96%
        |---- Cuboid 111100, est row: 9, est MB: 0, shrink: 100%
            |---- Cuboid 111000, est row: 9, est MB: 0, shrink: 100%

以上，简单的介绍了cube的优化方向，以及以减少cuboids和降低膨胀率为示例进行了详细的介绍。