http://blog.csdn.net/jiangshouzhuang/article/details/51286150
Hierarchies:
理论上对于N维度,我们可以进行2的N次方的维度组合。然而对于一些维度的组合来说,有时是没有必要的。例如,如果我们有三个维度:continent, country, city,在hierarchies中,最大的维度排在最前面。当使用下钻分析时,我们仅仅需要下面的三个维度的组合:
group by continent
group by continent, country
group by continent, country, city
在这个例子中,维度的组合从2的3次方共8种减少到了3种,这是一个很好的优化,同样适合YEAR,QUATER,MONTH,DATE等场景。
如果我们设置hierarchy作为H1,H2,H3,那么典型的场景应该是:
A. Hierarchies on lookup table
Fact table (joins)Lookup Table
column1,column2,,,,,, FK PK,,H1,H2,H3,,,,
B. Hierarchies on fact table
Fact table
column1,column2,,,H1,H2,H3,,,,,,,
对于scenario A,这是一个特殊的案例,PK在lookup的表上,意外的成为了hierarchies的一部分。例如我们有一个日历的lookup表,cal_dt是PK(primary key):
A*. Hierarchies on lookup table over its primary key
Lookup Table(Calendar)
cal_dt(PK), week_beg_dt, month_beg_dt, quarter_beg_dt,,,
对于A*这种案例,你应该使用“Derived Columns”这种优化方案。
Derived Columns:
当一个或多个维度(必须是lookup表的维度,这些字段被称为“Derived”)能够从另一个中减少(通常是相关的FK,被称为“host column”),Derived column就可以被使用。
例如,假如我们有一个lookup的表,我们使用join关联fact表,并且使用“where DimA=DimX”。在Kylin中需要注意,如果你选择FK为一个维度,那么相关的PK将自动可查询的,没有任何额外的开销。这重要的原因是FK和PK总是相同的,Kylin能够首先在FK上使用filters/groupby,并且使用PK透明地替换。这个表明如果我们想用DimA(FK),DimX(PK),DimB,DimC在我们的Cube中,我们能够安全地仅仅选择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获得(Derived)。当我们build一个cube包含DimA和DimB,我们能够简单的包含DimA,并且标记DimB作为Derived。Derived column(DimB)不会参与cuboids的生成:
original combinations: --原始维度组合
ABC,AB,AC,BC,A,B,C
combinations when driving B from A: --使用Derived优化后的维度组合
AC,A,C
在运行时,例如“select count(*) from fact_table inner join looup1 group by looup1 .dimB”的案例中,它期待从包含DimB的cuboid中去获取查询结果。然而,DimB因为使用了Derived优化,在cuboids没有结果。在这种情况下,我们修改执行计划,首先按照DimA(its host column)进行group by操作,我们将获取中间的结果,比如:
DimA count(*)
1 1
2 1
3 1
4 1
然后,Kylin将使用DimB的值替换DimA的值(因为他们的值都在lookup表中,Kylin能够加载整个lookup表到内存中并且build一个他们的映射关系),因而中间的结果为:
DimB count(*)
a 1
b 1
c 1
a 1
紧接着,运行SQL的引擎(calcite)将进一步的聚合中间结果为最终结果:
DimB count(*)
a 2
b 1
c 1
这个步骤发生在SQL查询运行期间,也就是“at the cost of extra runtime aggregation”。