分层结构(Hierarchies)
理论上,N个维度将得到2^N 个维度组合;
但是对一组维度,没必要创建这么多维度组合;
例如,如果有3个维度: continent, country, city (从层级来说,更大的维度在更前面),
当下钻分析时只需要支持3个group by的组合:
- group by continent
- group by continent,country
- group by continent,country,city
这个例子中,维度组合从2^3 = 8个下降到 3个;
8个维度组合为:
(continent,country,city),
(continent,country),(continent,city),(country,city),
(continent),(country),(city),
()
这是非常大的性能优化;这也似用于YEAR,QUATER,MONTH,DATE的例子;
将层级维度记为H1,H2,H3,典型的场景为:
A. lookup表的层级
Fact表 | (joins) | Lookup表 |
---|---|---|
column1,column2, FK | PK,H1,H2,H3, |
B. fact表的层级
Fact表 |
---|
column1,column2,H1,H2,H3, |
场景A是特殊的例子,lookup表的PK(外键)刚好是层级的一部分;
例如,有一个日历lookup表, cal_dt是主键:
A* lookup表的主键是层级的一部分
lookup表(Calendar) |
---|
cal_dt(PK), week_beg_dt, month_beg_dt, quarter_beg_dt, |
场景A* 需要另一种优化,称为"Derived Columns"
衍生字段(Derived Columns)
衍生字段: 一个或多个维度可以从别的维度推断出来;
主维度: 一般为FK;
衍生维度: lookup表的维度;
例如,在Kylin里有lookup表join 事实表: where DimA = DimX, 当选择维度FK时,相应的PK会自动可查询;
这是因为,当FK和PK确定时, kylin会先在FK应用filter/groupby,然后替换成PK;
如果想要让DimA(FK), DimX(PK), DimB, DimC都可使用cube,可以安全地选择DimA,DimB,DimC维度
Fact表 | (joins) | Lookup表 |
---|---|---|
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推断出;
当构建的cube包含DimA和DimB,只会包含DimA,将DimB标记为衍生(derived);
衍生字段(DimB)不会参于cuboid的生成;
原始的组合: ABC,AB,AC,BC,A,B,C
当B可由A衍生时的组合: AC,A,C
当查询"select count(*) from fact_table inner join looup1 group by looup1 ,dimB"时,预期会有包含DimB的cuboid来应答; 但是因为衍生优化, DimB的cuboid显示为NONE;在这个案例中,会修改执行计划先group by DimA,会得到中间应答:
dimA | count(*) |
---|---|
1 | 1 |
2 | 1 |
3 | 1 |
4 | 1 |
然后,kylin会用DimB的值替换DimA的值(当DimA和DimB的值都在lookup表时,kylin会加载表到内存,并构建映射),中间结果变为:
dimB | count(*) |
---|---|
a | 1 |
b | 1 |
c | 1 |
a | 1 |
之后, SQL引擎(calcite)进一步聚合中间结果为:
dimB | count(*) |
---|---|
a | 2 |
b | 1 |
c | 1 |
这一步发生在查询运行阶段,这也是"额外运行时聚合的成本"的意思