Kylin Cube设计优化
Cube设计优化
原文地址：http://kylin.apache.org/docs/howto/howto_optimize_cubes.html
层次结构（Hierarchies）
理论上对于N个维度一有需要2^N个组合。然后对于某些维度之间是不需要创建如此多的组合的。例如，你有三个维度：continent、country和city（在层次结构中，“较大的”维度总是先出现）。在你进行下钻操作的时候，你仅仅只需要下面三种组合： group by continent group by continent, country group by continent, country, city 在这种情况下，组合数从2^3=8减少到了3，这是一个巨大的优化。对于YEAR、QUATER、MONTH、DATE，情况也是一样。 如果我们将层级维度表示成H1、H2、H3，那么典型的场景就如下所示：
A.维度表上的层级结构
Fact table | (joins) Lookup table |
|---|---|
column1, column2, …, FK | PK, H1, H2, H3, … |
B.事实表上的层级结构
Fact table |
|---|
column1, column2, …, H1, H2, H3, … |
对于场景A来说是一种特殊的情况，位于维度上的PK意外地成为了层次结构中的一部分。例如，我们有一个关于日历的维度表，其中cal_dt是主键：
A*.维度表上的层级结构包含主键
Lookup table(Calendar) |
|---|
cal_dt(PK), week_beg_dt, month_beg_dt, quarter_beg_dt, … |
对于A*中的情况需要另外一个优化方法，称之为“派生列”。
派生列（Derived Columns）
当一个或者多个维度（这些维度必须处于维度表上，称之为“派生的”）可以由其他维度（通常该维度是对应的FK，称之为“主列”）推导得出的时候，使用派生列。 例如，假设我们有一个维度表连接至事实表，连接条件为“where DimA = DimX”。注意到在Kylin中，如果你选择了一个FK作为维度，那么不需要任何代价，FK对应的PK就会自动的变成可查询的状态。奥秘就在于FK和PK总是独一无二的，Kylin能够首先对FK使用过滤或者组合，然后在你没有察觉的情况下将它们替换为PK。这就表明，如果我们需要cube中的DimA(FK)，DimX(PK)，DimB和DimC，那么我们可以放心地只选择DimA，DimB和DimC。
Fact table | (joins) Lookup table |
|---|---|
column1, column2, …, DimA(FK) | DimX(PK), DimB, DimC |
我们说DimA（代表FK/PK的维度）和DimB之间有一种特殊的映射：
dimA | dimB | dimC |
|---|---|---|
1 | a | ? |
2 | b | ? |
3 | c | ? |
4 | a | ? |
在这种情况下，给定一个DimA的值，对应的DimB的值也就确定了，所以我们可以说，dimB可以被dimA推导得出。当我们构建一个同时包含DimA和DimB的cube时，我们可以只包含DimA，把DimB作为派生列。派生列（DimB）不参与cuboid的产生： 初始组合： ABC, AB, AC, BC, A, B, C 由A推导出B时的组合： AC, A, C 在运行时，如果出现“select count(*) from fact_table inner join looup1 group by looup1.dimB”这样的查询，它期望cuboid在查询结果中能包含DimB。但是DimB因为派生的优化而不会出现在cuboid中。为了应对这种情况，我们修改执行计划，让它先对DimA（它的主列）进行分组操作，我们将会得到如下的中间结果：
DimA | count(*) |
|---|---|
1 | 1 |
2 | 1 |
3 | 1 |
4 | 1 |
接着，Kylin将会用DimB的值来替换DimA的值（因为它们的值都在维度表中，Kylin可以把整个维度表加载到内存中，然后构建相应的映射），中间结果就会变成如下所示：
DimB | count(*) |
|---|---|
a | 1 |
b | 1 |
c | 1 |
a | 1 |
在这之后，运行时SQL引擎将会进一步聚合中间结果：
DimB | count(*) |
|---|---|
a | 2 |
b | 1 |
c | 1 |
这一步发生在查询期间，这就是所谓的“在额外的运行期间聚合的成本”。