【转】Kylin的Hierarchies，Derived维度方面配置优化

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”。