【轉】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”。

【轉】Kylin的Hierarchies，Derived維度方面配置最佳化