优化cube设计

分层结构(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

这一步发生在查询运行阶段,这也是"额外运行时聚合的成本"的意思