1. Background

1.1 The Necessity of Cuboid pruning optimization

商务领域瞬息万变，每当需要作出商务决策时，数据分析师往往希望得到即时响应，然而大数据时代的到来使数据分析在大数据量级上面临挑战。面对此挑战，Apache Kylin 应运而生。

一般来说，企业有专职人员负责运维 Kylin，我们称之为 Kylin Administrator。还有专职的建模师，大多数情况下，建模师熟悉 Kylin 的使用方法，但对业务模式了解较少，他们负责创建模型并构建 Cube 供数据分析师使用。数据分析师是使用 Kylin 的另一种用户角色，他们可能不熟悉 Kylin 的运维及使用方法或建模方法论，但他们了解业务模式，他们希望通过查询 Kylin 获得快速的查询体验。事实上，在 Kylin 中构建 Cube，将分析师关心的维度组合对应的数据存储下来，查询时使用预计算数据代替原始数据，能够极大的加速查询。但是所有查询对应维度组合的数据都可以被存储下来，从而提升每个查询的响应时间吗？

答案是否定的。并不是每一种分析师关心的查询结果都能够被预计算并存储下来。这是一场计算与存储的博弈。我们当然希望所有查询结果都被存储下来，但实际场景中分析师关心的维度组合是不确定的，如果我们将所有关心的维度放入聚合组，生成所有维度的组合并存储对应的数据，将花费极大的存储资源。为了避免“维度灾难”，Kylin 中单个 Cube 默认可以生成 40960 个维度组合。由于这个限制和“维度灾难”问题，当面对极多的维度时，建模师可以通过 Cube 静态规则进行初步的 Cube 剪枝优化。但由于建模师可能不熟悉业务模式，经过剪枝的 Cube 中最终保留的维度组合可能与实际业务需求不相符。

进行 Cube 剪枝优化是非常有必要的。我们希望能够在降低存储空间的同时，依然获得符合预期的查询效率。理想状态为仅存储对业务查询有意义的维度组合或构建收益比（构建收益比是指预计算出某个 Cuboid，相比没有这个 Cuboid，对 Cube 的所有查询所能减少的查询成本与这个 Cuboid 的行数的比值，将在下文详细讲解）高的维度组合。

1.2 The Different stages of Cube Pruning Optimization

从 Cube 剪枝优化的角度来看，在 Kylin 中，一个 Cube 的演进过程是怎样的？Cube 剪枝分为两个阶段，静态规则阶段和动态调整阶段：

首先是静态规则阶段，在 Kylin 中，一般是指聚合组设置、强制 Cuboid 设置等。用户可以在创建 Cube 时在 Advanced Setting 中进行聚合组设置，这个阶段一般发生在构建 Cube 之前。在此阶段，用户可以根据业务模式和数据特征设置聚合组中的必需维度、层级维度、联合维度和最大维度组合数来对 Cube 进行剪枝优化。

接下来是动态调整阶段，也就是 Cube Planner 阶段。Cube Planner 分为两个阶段，第一阶段发生在初次构建 Cube 时，系统将根据预设的膨胀率目标，结合数据特征，选择构建收益比最高的 Cuboid 集合，然后仅存储构建收益比高的 Cuboid。接下来，当用户启用了 System Cube，并且使用了 Kylin 一段时候之后，就可以手动触发 Cube Planner 第二阶段，并且可以按照一定的时间间隔反复触发 Cube Planner 第二阶段，从而不断优化 Cube。在 Cube Planner 第二阶段，系统一般会推荐删除对业务没有意义的 Cuboid，并推荐增加业务查询常用的 Cuboid。

本文不介绍聚合组设置相关的内容，你可以查看 Apache Kyin 官方文档 http://kylin.apache.org/cn/docs/tutorial/create_cube.html 了解聚合组设置方法。下文将详细介绍 Cube Planner 相关的内容。

2. Cuboid Pruning Optimization with Cube Planner

用户可以通过静态规则设置（如聚合组设置）进行 Cuboid 剪枝优化，而 Cube Planner 则通过“学习”用户的查询习惯“自动” 剪枝优化 Cuboid。用户可以通过设置参数 kylin.cube.cubeplanner.enabled=true 开启 Cube Planner，该参数为 Cube 级。

2.1 Some Concepts

2.1.1 Benefit Per Unit Space (BPUS)

构建收益比（Benefit Per Unit Space）是指预计算出某个 Cuboid，相比没有这个 Cuboid，对 Cube 的所有查询所能减少的查询成本与这个 Cuboid 的行数的比值。

构建收益比的计算方法：设新增构建某个 Cuboid 能够使 N 个未构建的 Cuboid 的查询开销降低，并且使这 N 个 Cuboid 的查询开销分别降低 B₁，B₂，…，B_N，新增构建的 Cuboid 行数为 C，则该新增的 Cuboid 的构建收益比为 (B₁，B₂，…，B_N) / C。

在参考文献中，构建收益比一般称为 BPUS(benefit per unit space)，以下公式即为 Cube Planner 的通过贪心算法选择 Cuboid 核心思想：

相关资料：

http://www.vldb.org/conf/1998/p488.pdf

https://cs.uwaterloo.ca/~kmsalem/courses/cs743/F14/slides/datacubes.pdf 

https://xueshu.baidu.com/usercenter/paper/show?paperid=cd8c1be988af6b371c2c6e6ee04566ba

https://www.google.com.hk/search?tbm=bks&hl=en&q=BPUS+Benefit+per+unit+space

2.1.2 Recommend Cuboid List

Recommend Cuboid List 是在 Cube Planner 第一阶段和第二阶段生成的，它包含了一组构建收益比相对较“高”的 Cuboids，Kylin 将根据 Recommend Cuboid List 构建 Cube。

Cube Planner 使用两种算法生成 Recommend Cuboid List，分别是贪心算法和基因算法。它是根据静态规则剪枝优化之后的 Cuboid 个数来选择算法的。

Recommend Cuboid List 记录在 Cube Desc 中的 cuboid_bytes 和 cuboid_bytes_recommend。

• 如果未使用 Cube Planner，cuboid_bytes 和 cuboid_bytes_recommend 都是 null，系统将根据静态规则剪枝之后的 Cuboid List 构建 Cube。
• 当开启 Cube Planner 并首次生成 Recommend Cuboid List 之后，将记录在 cuboid_bytes，之后系统将根据这个 List 构建 Cube。
• 当进行 Cube Planner 第二阶段优化时，将推荐出新的 Recommend Cuboid List 并记录在 cuboid_bytes_recommend。当完成第二阶段优化后，将更新 cuboid_bytes 为最新的 List，同时重置 cuboid_bytes_recommend 的值为 null。接下来依然按照 cuboid_bytes 中记录的 List 构建 Cube。

2.2 Cube Planner Whole Process

1. Cube Planner 第 1 阶段发生在首次构建 Cube 时。在进入 Cube Planner 第 1 阶段之前，系统将预估每个 Cuboid 的行数和存储大小，这些预估的行数与存储大小将应用于 Cube Planner 算法中。Cube Planner 的算法选择（贪心算法或基因算法）与静态规则剪枝后的 Cuboid 个数有关。
2. 假设提交构建时根据静态规则剪枝生成的 Cuboid 列表为 Recommend Cuboid List 0，在 Cube Planner 第 1 阶段，系统将根据数据特征计算 Recommend Cuboid List 0 中每个 Cuboid 的构建收益比，将构建收益比小的 Cuboid 从 Recommend Cuboid List 0 删除，生成 Recommend Cuboid List 1。
3. 根据 Recommend Cuboid List 1 构建 Cube 的第 1 个 Segment，并记录 Segment 1 中每个 Cuboid 的 HyperLogLog，记录的 HyperLogLog 在 Cube Planner 中用于计算 Cuboid 的行数和存储大小，这是在第一个 Build Job 中完成的。
4. 根据 Recommend Cuboid List 1 构建 Cube 的第 2 个 Segment，并记录 Segment 2 中每个 Cuboid 的 HyperLogLog，这是在第二个 Build Job 中完成的。
5. 根据 Recommend Cuboid List 1 构建 Cube 的第 3 个 Segment，并记录 Segment 3 中每个 Cuboid 的 HyperLogLog，这是在第三个 Build Job 中完成的。
6. 在构建第一个 Segment 之后，如果开启了 System Cube，系统就会收集查询相关的指标数据。经过一段时间使用 Kylin，Cube Planner 第 2 阶段将发挥作用，此阶段将根据系统收集的用户查询指标及原始数据特征重新计算构建收益比。Cube Planner 算法的选择依然与 Cuboid 个数有关。并且根据 Cuboid 的使用频率，在计算构建收益比时会增加 Cuboid 的权重，即查询越多的 Cuboid 权重越大，反之越少。
7. 重新计算每个 Cuboid 的构建收益比后会生成 Recommend Cuboid List 2。这里会使用到第三、四、五步中记录的 3 个 Segments 中每个 Cuboid 的 HyperLogLog，重新预估每个 Cuboid 的行数和存储大小。
8. 根据 Recommend Cuboid List 2 构建 Cube 的第 4、5、6 个 Segment，它们的时间范围分别对应 Segment 1、Segment 2 和 Segment 3 的时间范围，同时记录 Segment 4、Segment 5 和 Segment 6 中每个 Cuboid 的 HyperLogLog，这是分别在三个 Optimize Job中完成的。同时需要注意，系统将根据 Base Cuboid（包含 Cube 中所有维度的 Cuboid） 的数据重新构建 Cube，而不是使用数据源中的原始数据，也就是说，如果源数据有变化，此时的 Optimize Job 并不会刷新 Cube 数据。
9. 在进行 Cube Planner 第二阶段优化时，会同时生成一个 Optimize Checkpoint Job，这个任务会在新的 Cube 数据构建完成之后，删除旧的 Cube 数据，并且更新 Cube 元数据，从而保证数据一致性。在当前例子中将删除原有的 Segment 1，Segment 2 和 Segment 3，接下来的查询会使用优化后的 Segment 4，Segment 5 和 Segment 6。
10. 系统将持续收集用户的查询指标数据，用户可以一段时间后继续触发 Cube Planner第二阶段来优化 Cube，并且持续优化 Cube。

2.3 Greedy Algorithm

Cube Planner 通过两种算法计算构建收益比并推荐出 Recommend Cuboid List：贪心算法和基因算法，选择哪一种算法取决于静态规则设置之后的 Cuboid 个数。

• Cuboid Count <= 2^X ，跳过 Cube Planner，使用静态规则剪枝优化之后的 Cuboid List 构建 Cube
• 2^X < Cuboid Count < 2^Y ，使用贪心算法推荐 Recommend Cuboid List
• 2^Y <= Cuboid Count ，使用基因算法推荐 Recommend Cuboid List

下面通过一个例子详解贪心算法。

假设原始数据中有 4 列：ABCM，ABC 表示 3 个维度，M 表示度量，对于维度 ABC 来说，有 27 行不重复的数据，如下图所示：

接下来在 Kylin 中创建一个包含一个聚合组的 Cube，聚合组中包含三个维度 ABC，此时将生成 7 个 Cuboid。

步骤1：提交构建 Cube 时，仅构建 Base Cuboid

假设已经通过参数设定提交构建后会使用贪心算法。在 Kylin 中，Base Cuboid 和强制 Cuboid 一定会被构建，本例中我们假设没有强制 Cuboid，因此将 Base Cuboid 加入 Recommend Cuboid List。提交构建后，系统会预估每个 Cuboid 的行数和存储大小。查询开销为查询某一个 Cuboid 需要扫描的行数，本例中 Cuboid(ABC)（Base Cuboid） 的行数为 27，则 Cuboid(ABC) 的查询开销为 27。假设仅构建 Base Cuboid，那么构建之后，对 Base Cuboid 以外的 Cuboid 的查询都将通过 Base Cuboid 来回答，因此它们的查询开销与 Base Cuboid 的查询开销相等，都是 27。

步骤2：第一轮迭代，将构建收益比最高的 Cuboid 加入 Recommend Cuboid List

假设新增构建 Cuboid(AB)，Cuboid(AB) 的行数为 9，则它的查询开销为 9。同时查询 Cuboid(A) 和 Cuboid(B) 可以通过查询 Cuboid(AB) 回答，则 Cuboid(AB)、Cuboid(A) 和 Cuboid(B) 的查询开销都降低为 9。

再次回顾构建收益比的计算方法：设新增构建某个 Cuboid 能够使 N 个未构建的 Cuboid 的查询开销降低，并且使这 N 个 Cuboid 的查询开销分别降低 B₁，B₂，…，B_N，新增构建的 Cuboid 行数为 C，则该新增的 Cuboid 的构建收益比为 (B₁，B₂，…，B_N) / C。

因此 N=3，B₁=27-9=18，B₂=27-9=18，B₃=27-9=18，C=9。则 Cuboid(AB) 的构建收益比 = (18+18+18) / 9 = 6

接下来依次计算新增其他 Cuboid 的构建收益比，总结如下：

可见，新增 Cuboid(A)，Cuboid(B)，Cuboid (C) 的构建收益比最高且相等。

贪心算法每轮迭代仅加入 1 个 Cuboid 至 Recommend Cuboid List，如果存在构建效益比相同的 Cuboid，则随意选择一个 Cuboid 加入 Recommend Cuboid List。

因此，本轮将 Cuboid(A) 加入 Recommend Cuboid List，此时 Cuboid(A) 的行数为 3，查询开销也为 3，其余未构建的 Cuboid 的查询开销依然为 Cuboid(ABC) 的查询开销，为 27。

步骤3：多轮迭代，得到最终的 Recommend Cuboid List

• 开始时：加入 Cuboid(ABC)（Base Cuboid）
• 第 1 轮迭代：新加 Cuboid(A)，共有 Cuboid(ABC)，Cuboid(A)
• 第 2 轮迭代：新加 Cuboid(B) ，共有 Cuboid(ABC)，Cuboid(A)，Cuboid(B)
• 第 2 轮迭代：新加 Cuboid(C) ，共有 Cuboid(ABC)，Cuboid(A)，Cuboid(B)，Cuboid(C)
• 第 4 轮迭代：新加 Cuboid(AB)，共有 Cuboid(ABC)，Cuboid(A)，Cuboid(B)，Cuboid(C)，Cuboid(AB)
• …

迭代何时停止？

• Recommend Cuboid List 里的 Cuboid 的总预估存储大小大于等于 Base Cuboid 的预估存储大小的 X 倍，X 默认值为 15，由参数 kylin.cube.cubeplanner.expansion-threshold 控制；
• 本轮选中的 Cuboid 的构建收益比小于 0.001。

最终得到完整的 Recommend Cuboid List，然后根据此 Recommend Cuboid List 构建 Cube。

2.4. Use System Cube to help Cube Planner

2.4.1 System Cube and Hive Tables

当构建 Cube 后，用户需要持续且稳定的使用一段时间 Kylin 系统，使 Kylin 尽量充分的“熟悉”用户的查询习惯，以便在 Cube Planner 第 2 阶段更合理的优化 Cube。

Kylin 通过 System Cube 监控系统，System Cube 记录了查询和任务相关的指标，能够有效的帮助系统运维和发现问题。当用户开启 System Cube 后，就可以在 Kylin 的 Web 界面查看项目 KYLIN_SYSTEM，在这个项目下有 5 个 Cube，它们分别从不同的维度记录系统的监控数据。System Cube 服务于 DashBoard，用户可以通过设置 kylin.web.dashboard-enabled=true 开启 DashBoard，或访问 Apache Kyin 官方文档 http://kylin.apache.org/cn/docs/tutorial/use_dashboard.html 了解更多。用户可以通过 System Cube 进行更多场景的分析，以便更好的运维监控 Kylin。

用户在 Kylin 中的每一个查询或构建操作，都会被记录在 Hive 表中，共有 5 张 Hive 表，它们分别对应了 5 个 System Cube 的事实表。而 Cube Planner 只与其中一张表相关，就是表 hive_metrics_query_cube_qa。

以下列出与 Hive 表相关的 5 个配置项：

• kylin.metrics.prefix：The system will automatically create the above 5 tables in database named 'kylin' by default. You can customize the database by modifying the configuration item kylin.metrics.prefix=<name>. <name> is also the prefix of the System Cube name;
• kylin.metric.subject-suffix：You can customize the suffix of the hive tables, the default is 'qa', so the table name is 'hive_metrics_query_qa';
• kylin.metrics.monitor-enabled：Whether to record metrics in Hive, control the above 5 tables, the default is false, which means not to record;
• kylin.metrics.reporter-query-enabled：Whether to record metrics in Hive, control the above 3 tables about query, the default is false, which means not to record;
• kylin.metrics.reporter-job-enabled：Whether to record metrics in Hive, control the above 2 tables about job, the default is false, which means not to record;

2.4.2 How to record user query metrics into Hive

Cube 中可以有多个 Segments，每个 Segment 的数据可能存储在不同的 RPC 服务器中，当用户发送一条查询时，查询可能击中多个 Cube，扫描每个 Cube 下的多个 Segments，扫描每个 Segment 下面多个 RPC 服务器中存储的数据。那么对于发送的一条查询，每击中一个 Cube，在表 hive_metrics_query_qa 中记录一行数据。当查询击中 Cube，每扫描 Cube 下的一个 Segment，在表 hive_metrics_query_cube_qa 中记录一行数据。当查询需要扫描 Cube 下的一个 Segment，每扫描一个 RPC 服务器下的数据，在表 hive_metrics_query_rpc_qa 中记录一行数据。

2.4.3 What has been recorded into hive

以下是表 hive_metrics_query_cube_qa 中与 Cube Planner 相关的部分信息：

因此，当用户构建 Cube 并平稳的使用一段时间后，系统将逐渐“熟悉”用户的查询习惯。如果用户从未查询已经构建出来的 Cuboid(C)，而且常常查询没有构建出来的 Cuboid(BC)，那么在 Cube Planner 第二阶段，相关 Cuboid 的构建收益比会被相应地加权，因此系统可能会推荐用户删除 Cuboid (C)，并且新增构建 Cuboid (BC)。请注意这里是说可能会如此推荐，在实际的场景中，Cube Planner 第二阶段会根据数据特征和查询习惯重新计算构建收益比，并生成新的 Recommend Cuboid List 用于构建 Cube。

提示：在 Cube Planner 第一阶段，由于 Kylin 尚不了解用户的查询习惯，在计算构建收益比时所有的 Cuboid 将被平等对待。而在 Cube Planner 第二阶段，Kylin 已经收集一些用户的查询习惯，在计算构建收益比时 Cuboid 会被相应的加权。

Hive 表及 System Cube 的更多介绍请查看 System Cube Introduction_CN。

3. Tips about Cuboid Pruning optimization

3.1 How to debug the calculation process of Cube Planner algorithm ？

简介

Cube Planner 通过算法自动计算 Cuboid 的构建收益比，并提供 Recommend Cuboid List，如果在调试或学习过程中，想了解 Cube Planner 算法进行 Cuboid 淘汰选择的全流程，可以查看下面的方法。

方法

• 编辑 conf/kylin-server-log4j.properties，添加配置项 logger.org.apache.kylin.cube.cuboid.algorithm=TRACE；

• 首次构建 Segment，或者点击 Optimize 优化 Cube 时，在终端 $KYLIN_HOME 目录下执行 cat logs/kylin.log | grep GreedyAlgorithm；

• 可以按照日期筛选，如增加 grep yyyy-MM-dd，例 cat logs/kylin.log | grep GreedyAlgorithm | grep 2020-12-01。

图示

3.2 How to check whether the user query metrics have been recorded in Hive ？

简介

Cube Planner 根据 System Cube 进行 Cuboid 剪枝优化，System Cube 中的数据来自于 Hive 表。确认查询后相关的指标已经插入到 Hive 中，从而确保构建 System Cube 时包含了需要的数据，确保 Cube Planer 能够合理的优化 Cube。

方法

• 进入 Hive，使用相应的表 hive_metrics_query_cube_qa；
• 查询表以确定所需数据已插入 Hive。

提示

查询后，数据插入 Hive 表中有一定的延迟，系统一般会“在一定时间后”或“将一个固定批量的数据”一次性插入到 Hive 表中。默认的“一定的时间”是 10 分钟，“一个固定批量的数据”是 10 条。如果希望快速验证，可以采用以下两种方法：

• 修改配置文件 $KYLIN_HOME/tomcat/webapps/kylin/WEB-INF/classes/kylinMetrics.xml 中的配置项，“index=1” 的配置项表示批量（累计多少条数据必然会插入 Hive），“index=2” 的配置项表示时间间隔（累计多长时间必然会插入 Hive，单位分钟）；
• 重启 Kylin 会立即记录所有需要被记录的数据；

图示

3.3 How to check the query cost of SQL ？

简介

查看某条查询的执行信息，如扫描行数、扫描字节数，从而了解 Cube Planner 是否降低了某一条查询的查询开销。

方法

• 在终端 $KYLIN_HOME 目录下执行 "tail -f logs/kylin.log”；
• 在 Kylin 中进行查询；
• 在终端查看查询的执行信息。

图示

3.4 How to make Cube Planner help Cuboid pruning optimization well ?

• 第 1 个 Segment 的数据很重要。Cube Planner 第一阶段会根据第 1 个 Segment 的数据计算 Cuboid 的构建收益比，如果第 1 个 Segment 的数据特征与之后的 Segment 的数据特征非常不一致，则可能不能很好的优化 Cube，这时你可以通过 Cube Planner 第二阶段再次优化 Cube；
• 初次构建 Cube 后，请让系统稳定运行一段时间，使系统能够很好的“熟悉”用户的查询习惯，以便更好的剪枝优化。

3.5 How to optimize Cuboid list by setting "parent_forward" in CubeDesc ？

简介

设想一个场景：通过设置最大维度组合数使 Cube 中除了 Base Cuboid，其余 Cuboids 中最多包含两个维度，Base Cuboid 中包含 20 个维度，那么当查询中包含某三个维度时，只能通过 Base Cuboid 回答，此时将花费相对较大的后计算时间。由此可以发现，如果我们设置子 Cuboid 最多相隔多少代会有一个父 Cuboid，从而确保未被已构建的 Cuboid 精确匹配到的查询不会总是通过 Base Cuboid 回答，而是能够通过中间某个父 Cuboid 回答。如果我们设置这个值为 3，那么对于任意查询，都不会使用超过 3 代的父 Cuboid 回答，这样对于查询模式难以预测的场景比较有利。

方法

• 在 Kylin Web GUI 编辑 CubeDesc；
• 找到 parent_forward 并修改为期望的值，如 "parent_forward": 2

提示

• parent_forward 的默认值为 3，表示子 Cuboid 与父 Cuboid 中间相隔 3 代，例如 A 和 ABCDE；
• 当某个子 Cuboid 有多个父 Cuboid 可以选择时，系统将根据 Rowkey 的顺序选择排序靠后的父 Cuboid，从而获得最小的 Cuboid 行数。例如 BC 的父 Cuboid 可以是 ABCDE，也可以是 BCDEF，Rowkey 顺序为 ABCDEF，那么最终选择的父 Cuboid 为 BCDEF。

图示

4. An Example for Cube Planner

使用 Kylin 自带的数据集 kylin_sales 应用 Cube Planner。

第一阶段：准备一个 Cube

• 在 learn_kylin 项目中，通过 kylin_sales_model 模型创建一个 Cube；
• 在该 Cube 中，添加维度：kylin_sales.part_dt、KYLIN_CATEGORY_GROUPINGS.meta_categ_name、KYLIN_CATEGORY_GROUPINGS.categ_lvl2_name、KYLIN_CATEGORY_GROUPINGS.categ_lvl3_name；
• 将所有维度设置为 normal dimension；
• 添加 1 个聚合组包含上述所有维度；
• 添加如下 Cube 级参数：kylin.cube.cubeplanner.algorithm-threshold-greedy=2；
• 保存该 Cube。

保存后 Cube 中包含 15 个 Cuboid。

第二阶段：构建第一个 Segment

• 构建 Segment，时间范围为 2012-01-01 至 2013-01-01

构建时 Cube 将进行 Cube Planner 第 1 阶段优化，构建后 Cube 中包含 12 个 Cuboid。

提示：由于提交构建时的 Cuboid 个数 = 15，根据第一阶段的参数设定（kylin.cube.cubeplanner.algorithm-threshold-greedy=2），将使用贪心算法。

第三阶段：查询 Cube

• 查询如下 SQL 语句：

select part_dt, categ_lvl2_name, count(*)
from kylin_sales inner join KYLIN_CATEGORY_GROUPINGS on
KYLIN_SALES.LEAF_CATEG_ID=KYLIN_CATEGORY_GROUPINGS.LEAF_CATEG_ID
AND KYLIN_SALES.LSTG_SITE_ID=KYLIN_CATEGORY_GROUPINGS.SITE_ID
group by part_dt, categ_lvl2_name

由于缺少仅包含 part_dt, categ_lvl2_name 的 Cuboid，则通过包含 part_dt, meta_categ_name, categ_lvl2_name 的 Cuboid 回答查询。

第四阶段：构建 System Cube 

• 进入 KYLIN_SYSTEM 项目，将 System Cube：hive_metrics_query_cube_qa 增量构建至最新的时间

提示：请确保第三阶段的查询指标数据已经记录在 Hive 表中，否则 Cube Planner 无法进行合理优化。

第五阶段：查看 Cube 优化意见

• 查看 Cube 详情页 Planner 标签下的信息，点击 Recommend 按钮，查看 Cube Planner 第 2 阶段的优化意见：系统推荐新增包含 part_dt, categ_lvl2_name 的 Cuboid，并且根据算法推荐删除 5 个构建收益比低的 Cuboid。

第六阶段：优化 Cube

• 如果接受 Cube Planner 的建议，则点击 Optimize 按钮应用建议，进行 Cube 优化构建。

构建时 Cube 将进行 Cube Planner 第 2 阶段优化，构建后 Cube 中包含 8 个 Cuboid。

结论：构建后 Cube Size 明显减小，合理释放了存储空间；同样查询的扫描字节数减小，有效提升了查询效率。

5. Materials

bilibili 讲解视频请访问 https://b23.tv/NEwdYF

相关 PPT：