Cube設(shè)計(jì)優(yōu)化

原文地址：http://kylin.apache.org/docs/howto/howto_optimize_cubes.html

層次結(jié)構(gòu)（Hierarchies）

理論上對(duì)于N個(gè)維度一有需要2^N個(gè)組合。然后對(duì)于某些維度之間是不需要?jiǎng)?chuàng)建如此多的組合的。例如，你有三個(gè)維度：continent、country和city（在層次結(jié)構(gòu)中，“較大的”維度總是先出現(xiàn)）。在你進(jìn)行下鉆操作的時(shí)候，你僅僅只需要下面三種組合： group by continent group by continent, country group by continent, country, city 在這種情況下，組合數(shù)從2^3=8減少到了3，這是一個(gè)巨大的優(yōu)化。對(duì)于YEAR、QUATER、MONTH、DATE，情況也是一樣。 如果我們將層級(jí)維度表示成H1、H2、H3，那么典型的場(chǎng)景就如下所示：

A.維度表上的層級(jí)結(jié)構(gòu)

B.事實(shí)表上的層級(jí)結(jié)構(gòu)

對(duì)于場(chǎng)景A來說是一種特殊的情況，位于維度上的PK意外地成為了層次結(jié)構(gòu)中的一部分。例如，我們有一個(gè)關(guān)于日歷的維度表，其中cal_dt是主鍵：

A*.維度表上的層級(jí)結(jié)構(gòu)包含主鍵

對(duì)于A*中的情況需要另外一個(gè)優(yōu)化方法，稱之為“派生列”。

派生列（Derived Columns）

當(dāng)一個(gè)或者多個(gè)維度（這些維度必須處于維度表上，稱之為“派生的”）可以由其他維度（通常該維度是對(duì)應(yīng)的FK，稱之為“主列”）推導(dǎo)得出的時(shí)候，使用派生列。 例如，假設(shè)我們有一個(gè)維度表連接至事實(shí)表，連接條件為“where DimA = DimX”。注意到在Kylin中，如果你選擇了一個(gè)FK作為維度，那么不需要任何代價(jià)，F(xiàn)K對(duì)應(yīng)的PK就會(huì)自動(dòng)的變成可查詢的狀態(tài)。奧秘就在于FK和PK總是獨(dú)一無二的，Kylin能夠首先對(duì)FK使用過濾或者組合，然后在你沒有察覺的情況下將它們替換為PK。這就表明，如果我們需要cube中的DimA(FK)，DimX(PK)，DimB和DimC，那么我們可以放心地只選擇DimA，DimB和DimC。

我們說DimA（代表FK/PK的維度）和DimB之間有一種特殊的映射：

在這種情況下，給定一個(gè)DimA的值，對(duì)應(yīng)的DimB的值也就確定了，所以我們可以說，dimB可以被dimA推導(dǎo)得出。當(dāng)我們構(gòu)建一個(gè)同時(shí)包含DimA和DimB的cube時(shí)，我們可以只包含DimA，把DimB作為派生列。派生列（DimB）不參與cuboid的產(chǎn)生： 初始組合： ABC, AB, AC, BC, A, B, C 由A推導(dǎo)出B時(shí)的組合： AC, A, C 在運(yùn)行時(shí)，如果出現(xiàn)“select count(*) from fact_table inner join looup1 group by looup1.dimB”這樣的查詢，它期望cuboid在查詢結(jié)果中能包含DimB。但是DimB因?yàn)榕缮膬?yōu)化而不會(huì)出現(xiàn)在cuboid中。為了應(yīng)對(duì)這種情況，我們修改執(zhí)行計(jì)劃，讓它先對(duì)DimA（它的主列）進(jìn)行分組操作，我們將會(huì)得到如下的中間結(jié)果：

接著，Kylin將會(huì)用DimB的值來替換DimA的值（因?yàn)樗鼈兊闹刀荚诰S度表中，Kylin可以把整個(gè)維度表加載到內(nèi)存中，然后構(gòu)建相應(yīng)的映射），中間結(jié)果就會(huì)變成如下所示：

在這之后，運(yùn)行時(shí)SQL引擎將會(huì)進(jìn)一步聚合中間結(jié)果：

這一步發(fā)生在查詢期間，這就是所謂的“在額外的運(yùn)行期間聚合的成本”。