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

这一步发生在查询期间，这就是所谓的“在额外的运行期间聚合的成本”。