...

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

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

1.2 The Different stages of Cube Pruning Optimization

...

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

Recommend Cuboid List 记录在 Cube Desc 中的 cuboid_bytes 和 bytes 和 cuboid_bytes_recommend。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。null。接下来依然按照 cuboid_bytes 中记录的 List 构建 Cube。

2.2 Cube Planner Whole Process

...

• 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。

...

假设已经通过参数设定提交构建后会使用贪心算法。在 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。

...

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

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

...

用户在 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;

...

以下是表 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。

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

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

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

3. Tips about Cube Pruning optimization

...

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

图示

Image Added

4. An Example for Cube Planner

...