...

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

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

...

2. Cuboid Pruning Optimization with Cube Planner

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

...

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

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

...

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，而不是使用数据源中的原始数据，这也是说，如果源数据有变化，此时的 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。

...

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

...

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

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

...

Kylin 通过 System Cube 监控系统，System Cube 记录了查询和任务相关的指标，能够有效的帮助系统运维和发现问题。当用户开启 System Cube 后，就可以在 Kylin 的 Web 界面查看项目 KYLIN_SYSTEM，在这个项目下有 5 个 Cube，它们分别从不同的维度记录系统的监控数据。用户可以通过，它们分别从不同的维度记录系统的监控数据。System Cube 进行更多场景的分析，以便更好的运维监控 Kylin。System Cube 也服务于 DashBoard，你可以通过服务于 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。

...

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 第二阶段，相关C第二阶段，相关 Cuboid 的构建收益比会被相应地加权，因此系统可能会推荐用户删除 Cuboid (C)，并且新增构建 Cuboid (BC)。请注意这里是说可能会如此推荐，在实际的场景中，Cube Planner 第二阶段会根据数据特征和查询习惯重新计算构建收益比，并生成新的 Recommend Cuboid List 用于构建 Cube。

...

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

...

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

...