编者按：本文节选自华章科技大数据技术丛书《Apache Kylin权威指南(第2版)》一书中的部分章节。

Cuboid剪枝优化

维度的组合

由之前的章节可以知道，在没有采取任何优化措施的情况下，Kylin会对每一种维度的组合进行聚合预计算，维度的一种排列组合的预计算结果称为一个Cuboid。如果有4个维度，结合简单的数学知识可知，总共会有24=16种维度组合，即最终会有24=16个Cuboid需要计算，如图1所示。其中，最底端的包含所有维度的Cuboid称为Base Cuboid，它是生成其他Cuboid的基础。

图1　四维Cube

在现实应用中，用户的维度数量一般远远大于4个。假设用户有10个维度，那么没做任何优化的Cube总共会存在210=1024个Cuboid，而如果用户有20个维度，那么Cube中总共会存在220=1048576个Cuboid！虽然每个Cuboid的大小存在很大差异，但是仅Cuboid的数量就足以让人意识到这样的Cube对构建引擎、存储引擎来说会形成巨大的压力。因此，在构建维度数量较多的Cube时，尤其要注意进行Cube的剪枝优化。

检查Cuboid数量

Apache Kylin提供了一种简单的工具供用户检查Cube中哪些Cuboid最终被预计算了，将其称为被物化（materialized）的Cuboid。同时，这种工具还能给出每个Cuboid所占空间的估计值。该工具需要在Cube构建任务对数据进行一定的处理之后才能估算Cuboid的大小，具体来说，就是在构建任务完成“Save Cuboid Statistics”这一步骤后才可以使用该工具。

由于同一个Cube的不同Segment之间仅是输入数据不同，模型信息和优化策略都是共享的，所以不同的Segment中被物化的Cuboid是相同的。因此，只要Cube中至少有一个Segment完成了“Save Cuboid Statistics”这一步骤的构建，那么就能使用如下的命令行工具去检查这个Cube中的Cuboid的物化状态：

bin/kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader CUBE_NAME

CUBE_NAME 想要查看的Cube的名称

该命令的输出如图2所示。

图2　CubeStatsReader的输出

在该命令的输出中，会依次打印出每个Segment的分析结果，不同Segment的分析结果基本趋同。在上面的例子中Cube只有一个Segment，因此只有一份分析结果。对于该结果，自上而下来看，首先能看到Segment的一些整体信息，如估计Cuboid大小的精度（hll precision）、Cuboid的总数、Segment的总行数估计、Segment的大小估计等。

Segment的大小估算是构建引擎自身用来指导后续子步骤的，如决定mapper和 reducer数量、数据分片数量等的依据，虽然有的时候对Cuboid的大小的估计存在误差（因为存储引擎对最后的Cube数据进行了编码或压缩，所以无法精确预估数据大小），但是整体来说，对于不同Cuboid的大小估计可以给出一个比较直观的判断。由于没有编码或压缩时的不确定性因素，因此Segment中的行数估计会比大小估计来得更加精确一些。

在分析结果的下半部分可以看到，所有的Cuboid及其分析结果以树状的形式打印了出来。在这棵树中，每个节点代表一个Cuboid，每个Cuboid的ID都由一连串1或0的数字组成，数字串的长度等于有效维度的数量，从左到右的每个数字依次代表Cube的Rowkeys设置中的各个维度。如果数字为0，则代表这个Cuboid中不存在相应的维度，如果数字为1，则代表这个Cuboid中存在相应的维度。

除了最顶端的Cuboid之外，每个Cuboid都有一个父Cuboid，且都比父Cuboid少了一个“1”。其意义是这个Cuboid是由它的父节点减少一个维度聚合得来的（上卷，即roll up操作）。最顶端的Cuboid称为Base Cuboid，它直接由源数据计算而来。Base Cuboid中包含了所有的维度，因此它的数字串中所有的数字均为1。

每行Cuboid的输出除了0和1的数字串以外，后面还有每个Cuboid的具体信息，包括该Cuboid行数的估计值、该Cuboid大小的估计值，以及该Cuboid的行数与其父节点的对比（Shrink）。所有的Cuboid的行数的估计值之和应该等于Segment的行数估计值。同理，所有的Cuboid的大小估计值之和等于该Segment的大小估计值。

每个Cuboid都是在它的父节点的基础上进一步聚合产生的，因此理论上来说每个Cuboid无论是行数还是大小都应该小于它的父Cuboid。但是，由于这些数值都是估计值，因此偶尔能够看到有些Cuboid的行数反而还超过其父节点、Shrink值大于100%的情况。在这棵“树”中，可以观察每个节点的Shrink值，如果该值接近100%，说明这个Cuboid虽然比它的父Cuboid少了一个维度，但是并没有比它的父Cuboid少很多行数据。换言之，即使没有这个Cuboid，在查询时使用它的父Cuboid，也不会花费太大的代价。

关于这方面的详细内容将在后续3.1.4节中详细展开。

检查Cube大小

还有一种更为简单的方法可以帮助我们判断Cube是否已经足够优化。在Web GUI的“Model”页面中选择一个READY状态的Cube，当把光标移到该Cube的“Cube Size”列时，Web GUI会提示Cube的源数据大小，以及当前Cube的大小与源数据大小的比例，称之为膨胀率（Expansion Rate），如图3所示。

图3　查看Cube的膨胀率

一般来说，Cube的膨胀率应该为0%~1000%，如果一个Cube的膨胀率超过1000%，Cube管理员应当开始挖掘其中的原因。通常，膨胀率高有以下几个方面的原因：

Cube中的维度数量较多，且没有进行很好的Cuboid剪枝优化，导致Cuboid数量极多；
Cube中存在较高基数的维度，导致包含这类维度的每一个Cuboid占用的空间都很大，这些Cuboid累积造成整体Cube体积过大；
存在比较占用空间的度量，如Count Distinct这样的度量需要在Cuboid的每一行中都保存一个较大的寄存器，最坏的情况会导致Cuboid中每一行都有数十千字节，从而造成整个Cube的体积过大；

……

因此，遇到Cube的膨胀率居高不下的情况，管理员需要结合实际数据进行分析，可灵活地运用本章接下来介绍的优化方法对Cube进行优化。

空间与时间的平衡

理论上所有能用Cuboid处理的查询请求，都可以使用Base Cuboid来处理，就好像所有能用Base Cuboid处理的查询请求都能够通过直接读取源数据的方式来处理一样。但是Kylin之所以在Cube中物化这么多的Cuboid，就是因为不同的Cuboid有各自擅长的查询场景。

面对一个特定的查询，使用精确匹配的Cuboid就好像是走了一条捷径，能帮助Kylin最快地返回查询结果，因为这个精确匹配的Cuboid已经为此查询做了最大程度的预先聚合，查询引擎只需要做很少的运行时聚合就能返回结果。每个Cuboid在技术上代表着一种维度的排列组合，在业务上代表着一种查询的样式；为每种查询样式都做好精确匹配是理想状态，但那会导致很高的膨胀率，进而导致很长的构建时间。所以在实际的Cube设计中，我们会考虑牺牲一部分查询样式的精确匹配，让它们使用不是完全精确匹配的Cuboid，在查询进行时再进行后聚合。这个不精确匹配的Cuboid可能是3.1.2节中提到的Cuboid的父Cuboid，甚至如果它的父Cuboid也没有被物化，Kylin可能会一路追溯到使用Base Cuboid来回答查询请求。

使用不精确匹配的Cuboid比起使用精确匹配的Cuboid需要做更多查询时的后聚合计算，但是如果Cube优化得当，查询时的后聚合计算的开销也没有想象中的那么恐怖。以3.1.2节中Shrink值接近100%的Cuboid为例，假设排除了这样的Cuboid，那么只要它的父Cuboid被物化，从它的父Cuboid进行后聚合的开销也不大，因为父Cuboid没有比它多太多行的记录。

从这个角度来说，Kylin的核心优势在于使用额外的空间存储预计算的结果，来换取查询时间的缩减。而Cube的剪枝优化，则是一种试图减少额外空间的方法，使用这种方法的前提是不会明显影响查询时间的缩减。在做剪枝优化的时候，需要选择跳过那些“多余”的Cuboid：有的Cuboid因为查询样式永远不会被查询到，所以显得多余；有的Cuboid的能力和其他Cuboid接近，因此显得多余。但是Cube管理员不是上帝，无法提前甄别每一个Cuboid是否多余，因此Kylin提供了一系列简单工具来帮助完成Cube的剪枝优化。

图书简介：https://item.jd.com/12566389.html

相关阅读：

Apache Kylin权威指南（一）：背景历史和使命

Apache Kylin权威指南（二）：工作原理

Apache Kylin权威指南（三）：技术架构

Apache Kylin权威指南（四）：核心概念

Apache Kylin权威指南（五）：Getting Started

创作场景

Apache Kylin 权威指南（六）：Cuboid 剪枝优化