1. 查看相關(guān)統(tǒng)計(jì)

1.1 查看cuboid物化狀態(tài)

• 命令：./kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader cube_name
  
  image.png

1.2 檢查cube大小

image.png

• 一般來說，膨脹率應(yīng)控制在0-1000%，
  • 膨脹率過高的原因分析：維度數(shù)量高且未進(jìn)行剪枝
  • 存在較高基維的維度，導(dǎo)致包含該維度的cuboid占用空間較大
  • 存在占用空間的度量，如count distinct

1.3 時(shí)間和空間的平衡

• 所有能用cuboid的查詢請(qǐng)求都可以通過base cuboid來處理，但是這樣帶來大量的聚合計(jì)算，kylin構(gòu)建這么多cuboid就是為了適應(yīng)不同的聚合計(jì)算。但是過多的cuboid又會(huì)導(dǎo)致構(gòu)建速度慢空間占用多，例如：shrink值接近100%的，及時(shí)丟棄這個(gè)cuboid而使用父cuboid計(jì)算也不會(huì)產(chǎn)生更多的開銷。

2. 剪枝優(yōu)化

image.png

2.1 衍生維度

• 適用范圍：使用維度表時(shí)，可以將維度表的字段設(shè)置為衍生維度。
• 原理：衍生維度不參加預(yù)計(jì)算，在底層記錄維度表主鍵與維度表其他維度之間的映射關(guān)系，在查詢的時(shí)候可以進(jìn)行動(dòng)態(tài)翻譯得到非主鍵id并進(jìn)行實(shí)時(shí)聚合
• 注意項(xiàng)：只在維表維度中可用，另外如果主鍵到某個(gè)維度所需要的聚合工作量非常大，也不建議用衍生維度。如日期主鍵映射到年份等
• 優(yōu)化效率：每個(gè)衍生維度可以減少一半的cuboid

2.2 聚合組

• 適用場(chǎng)景：根據(jù)業(yè)務(wù)場(chǎng)景，可以劃分出具有強(qiáng)依賴的組合。

• 原理

  
  
  image.png

• 根據(jù)業(yè)務(wù)的維度組合，劃分出具有強(qiáng)依賴的組合，這些組合稱之為聚合組，在聚合組內(nèi)，維度之間的組合會(huì)預(yù)計(jì)算，聚合組之間并不交叉預(yù)計(jì)算，從而減少Cuboid的數(shù)量

2.3 必需維度

• 適用場(chǎng)景：如果某個(gè)維度在所有查詢中都會(huì)作為group by或者where的條件，可以把他設(shè)置為必需維度，通常情況下會(huì)設(shè)置日期為必需維度。

2.4 層級(jí)維度

• 適用場(chǎng)景：維度之間有層級(jí)關(guān)系，比如 國家(A)->省份(B)->城市(C)

  
  
  image.png

• 優(yōu)化效率：2^n -> n+1

2.5 聯(lián)合維度

• 適用場(chǎng)景：同時(shí)查詢幾個(gè)維度的場(chǎng)景，即某種維度組合要么一起出現(xiàn)，要么一起不出現(xiàn)，如o_city,d_city; 不常出現(xiàn)的多個(gè)維度可以設(shè)置為聯(lián)合維度；基數(shù)比較小的多個(gè)維度可以設(shè)置為聯(lián)合維度。
• 優(yōu)化效率： 2^n ->2

3. 并發(fā)粒度優(yōu)化

3.1 讀并發(fā)優(yōu)化

• 原理：每個(gè)segment對(duì)應(yīng)一張hbase中的表，一張表可以對(duì)應(yīng)多個(gè)region,這是region的個(gè)數(shù)就對(duì)應(yīng)的是查詢時(shí)的并發(fā)粒度，region切分越細(xì)，并發(fā)度越高。
• 對(duì)應(yīng)參數(shù)：kylin.storage.hbase.region-cut-gb

3.2 寫并發(fā)優(yōu)化

• 原理：構(gòu)建cube時(shí)，最終是將文件寫入到hbase中，此時(shí)一個(gè)文件對(duì)應(yīng)一個(gè)并發(fā)度，文件劃分越小，并發(fā)度則越高。
• 對(duì)應(yīng)參數(shù)：kylin.storage.hbase.hfile-size-gb

4. row_key優(yōu)化

4.1 row_key順序

• row_key中字段的順序?qū)τ诓樵兎浅Ｖ匾?，因?yàn)閔base的查詢最終依賴的是對(duì)row_key的scan,

4.1.1 row_key的順序遵循如下原則：

• 有可能作為查詢的過濾條件的維度放在前面

  • 多個(gè)可能作為過濾條件的維度，基數(shù)高的（作為過濾條件時(shí)可以過濾更多數(shù)據(jù)）更適合放前面
  • 公式： 得分 = 維度出現(xiàn)在過濾條件中的頻率 * 作為過濾條件時(shí)尅過濾的數(shù)據(jù)記錄數(shù)

• 經(jīng)常出現(xiàn)在查詢中的維度放在不經(jīng)常出現(xiàn)的維度前面，這樣在需要進(jìn)行后聚合的場(chǎng)景中查詢效率會(huì)更高

• 不會(huì)出現(xiàn)在查詢中的維度，按照其基數(shù)的高低，低基數(shù)的放在后面：在逐層構(gòu)建cuboid時(shí)，kylin會(huì)優(yōu)先選擇rowkey后面的維度所在的cuboid來生成子coboid，那么基數(shù)越低的維度包含他的父cuboid的行數(shù)就越少，生成子cuboid的代價(jià)就越低。 （例：101110 和101101 都可以構(gòu)建出 101100，按kylin的設(shè)計(jì)，會(huì)選擇101101來完成構(gòu)建）

4.2 合適的維度編碼

• 字典不適用于高基維的維度，主要原因是字典是在單節(jié)點(diǎn)內(nèi)存中創(chuàng)建，查詢時(shí)還需要加載到內(nèi)存中，大字典會(huì)導(dǎo)致構(gòu)建過慢，并且會(huì)占用太多內(nèi)存。

4.3 按維度分片

• 原理：默認(rèn)cuboid的分片策略時(shí)哈希計(jì)算后隨即分配的，按維度分片的意思是，當(dāng)選擇一個(gè)維度作為維度分片(如od_city)時(shí)，如果cuboid中的兩行在該維度上相等，name這兩行數(shù)據(jù)始終在一個(gè)分片中。這樣在查詢時(shí)，hbase為每個(gè)分片（region）開啟一個(gè)coprocessor，coprocessor就能夠在讀取自身的分片數(shù)據(jù)做一定的預(yù)聚合，那么所有按照od_city分組的查詢都會(huì)變得更加高效，因?yàn)槊總€(gè)分片都做了預(yù)聚合，分片返回的結(jié)果更少，查詢引擎需要做的聚合操作也更少。
• 適用范圍： 高基圍維度，并且數(shù)據(jù)分布相對(duì)均勻的，在大多數(shù)cuboid中都會(huì)出現(xiàn)的維度

4.4 top_N度量?jī)?yōu)化

• 原理：對(duì)特定維度（較高基維）的topN做預(yù)先計(jì)算topN的結(jié)果，當(dāng)查詢到來時(shí)，只用各個(gè)單元格中存儲(chǔ)的topN個(gè)數(shù)據(jù)進(jìn)行聚合得到結(jié)果返回。

  
  
  image.png

image.png

• 適用范圍：分析場(chǎng)景主要集中在某個(gè)維度的topN時(shí)。

5. cube planner

• 這是自kylin2.3提供的一個(gè)自動(dòng)優(yōu)化工具，在用戶自定義的基礎(chǔ)上進(jìn)行進(jìn)一步的自動(dòng)優(yōu)化，主要是兩個(gè)階段：
  • 階段1. 初次構(gòu)建時(shí)，cube planner根據(jù)cube構(gòu)建過程中的extract fact table distinct columns步驟中的采樣數(shù)據(jù)，計(jì)算效益比（查詢成本/物化該維度組合后對(duì)整個(gè)cube減少的的查詢成本）
  • 階段2： 對(duì)于已經(jīng)運(yùn)行一段時(shí)間的cube，根據(jù)歷史統(tǒng)計(jì)的查詢信息，幾乎不被查詢的cuboid會(huì)被刪除（需要依賴于system cube）