**
計算cube的儲存代價以及計算代價都是比較大的， 傳統olap的維度**的問題kylin也一樣會遇到。 kylin提供給使用者一些優化措施，在一定程度上能降低維度**的問題：
cube 優化：
hierachy dimension， 一系列具有層次關係的dimension組成乙個hierachy， 比如年、月、日組成了乙個hierachy， 在cube中，如果不設定hierarchy， 會有 年、月、日、年月、年日、月日 6個cuboid， 但是設定了hierarchy之後cuboid增加了乙個約束，希望低level的dimension一定要伴隨高level的dimension 一起出現。設定了hierachy dimension 能使得需要計算的維度組合減少一半。
derived dimension, 如果在某張維度表上有多個維度，那麼可以將其設定為derived dimension， 在kylin內部會將其統一用維度表的主鍵來替換，以此來達到降低維度組合的數目，當然在一定程度上derived dimension 會降低查詢效率，在查詢時，kylin使用維度表主鍵進行聚合後，再通過主鍵和真正維度列的對映關係做一次轉換，在kylin內部再對結果集做一次聚合後返回給使用者
aggregation group， 這是乙個將維度進行分組，以求達到降低維度組合數目的手段。不同分組的維度之間組成的cuboid數量會大大降低，維度組合從2的（k+m+n）次冪至多能降低到 2的k次冪加2的m次冪加2的n次冪。group的優化措施與查詢sql緊密依賴，可以說是為了查詢的定製優化。 如果查詢的維度是誇group的，那麼kylin需要以較大的代價從n－cuboid中聚合得到所需要的查詢結果，這需要cube構建人員在建模時仔細地斟酌。
資料壓縮：
distinct count聚合查詢優化：
apache kylin 採用了hypeloglog的方式來計算distinctcount。好處是速度快，缺點是結果是乙個近似值，會有一定的誤差。在非計費等通常的場景下distinctcount的統計誤差應用普遍可以接受。
1、大的事實表採用天分割槽增量構建，為了不影響查詢效能，可以定期做合併(merge)，週期可以根據實際情況確定，我們一周進行一次合併。
2、對於維表比較大的情況，或者查詢select部分存在複雜的邏輯判斷，存在apache kylin不支援的函式或語句時，可以將事實表和維表的關聯處理建立為hive檢視，之後根據檢視建立cube模型。
3、每次查詢必然帶有的條件建議在字典設定步驟將其設定為mandatory。這樣會最終 build出來cube的大小會減少一半。
4、cube的維度如果超過10個，建議將常用的聚合欄位做分組，我們對於最大的16個維度分了三個組，每組大概在5個維度左右。
5、cube定義中rowkey順序：mandatory維度，where過濾條件中出現頻率較多的維度，高基數維度，低基數維度。
7、部署層面，可以通過nginx在前端做負載均衡，後端啟動多個query server接收查詢請求處理。
kylin總結（一些重要概念以及基礎優化）
apache kylin 是hadoop大資料平台的乙個開源olap引擎。採用多位立方體預計算技術，可以將大資料sql查詢速度達到亞秒級別。其實就是資料立方的一種實現，可以參考韓家偉的 資料探勘 概念與技術 裡面對資料立方有詳細介紹。簡單來說資料立方就是以空間換時間，通過定義一系列的緯度，對每個緯度...
Kylin實戰 建立cube的優化
背景 kylin的維度組合優化 1 mandatory維度 2 hierarchy維度 3 derived維度 4 聯合維度 kylin的rowkey優化 1 編碼 2 順序 3 分片 了解olap cube的人都會知道，建立cube的過程中往往會出現 維度 問題。kylin是典型的multidim...
kylin的rowkey優化之按維度分片
我們知道，系統會對cuboid的資料進行分片處理。但是預設的分片策略是隨機的，如果group by a,b 的查詢命中了某個cuboid，但是a 1 and b 1 的兩條資料在不同的機器上儲存，那就要將這兩條資料返回到儲存引擎的driver hbase裡是coprocessor 再根據邏輯做聚合。...