Kylin Cube设计优化

2/13/2017来源:SQL技巧人气:1119

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

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