大家好，我是不溫卜火，是一名計算機學院大數據專業大二的學生，暱稱來源於成語—
不溫不火，本意是希望自己性情溫和。作爲一名互聯網行業的小白，博主寫博客一方面是爲了記錄自己的學習過程，另一方面是總結自己所犯的錯誤希望能夠幫助到很多和自己一樣處於起步階段的萌新。但由於水平有限，博客中難免會有一些錯誤出現，有紕漏之處懇請各位大佬不吝賜教！暫時只有csdn這一個平臺，博客主頁：https://buwenbuhuo.blog.csdn.net/
此篇爲大家帶來的是Cube構建原理。
一. Cube構建流程
- 1. 第一步：創建中間表
![1]()
- 2.將中間表的數據均勻分配到不同的文件
![3]()
- 3.創建維度字典表
![4]()
- 4. 構建cube
![5]()
- 5.HBase K-V
![6]()
- 6.將cube data 轉成GFile格式並導入HBase
![7]()
二. Cube構建算法
1. 逐層構建算法（layer）[默認]
我們知道，一個N維的Cube，是由1個N維子立方體、N個(N-1)維子立方體、N*(N-1)/2個(N-2)維子立方體、…、N個1維子立方體和1個0維子立方體構成，總共有2^N個子立方體組成，在逐層算法中，按維度數逐層減少來計算，每個層級的計算（除了第一層，它是從原始數據聚合而來），是基於它上一層級的結果來計算的。比如，[Group by A, B]的結果，可以基於[Group by A, B, C]的結果，通過去掉C後聚合得來的；這樣可以減少重複計算；當 0維度Cuboid計算出來的時候，整個Cube的計算也就完成了。
每一輪的計算都是一個MapReduce任務，且串行執行；一個N維的Cube，至少需要N次MapReduce Job。
過程如下：
算法優點：
- 1.此算法充分利用了MapReduce的優點，處理了中間複雜的排序和shuffle工作，故而算法代碼清晰簡單，易於維護；
- 2.受益於Hadoop的日趨成熟，此算法非常穩定，即便是集羣資源緊張時，也能保證最終能夠完成。
算法缺點：
- 1.當Cube有比較多維度的時候，所需要的MapReduce任務也相應增加；由於Hadoop的任務調度需要耗費額外資源，特別是集羣較龐大的時候，反覆遞交任務造成的額外開銷會相當可觀；
- 2.由於Mapper邏輯中並未進行聚合操作，所以每輪MR的shuffle工作量都很大，導致效率低下。
- 3.對HDFS的讀寫操作較多：由於每一層計算的輸出會用做下一層計算的輸入，這些Key-Value需要寫到HDFS上；當所有計算都完成後，Kylin還需要額外的一輪任務將這些文件轉成HBase的HFile格式，以導入到HBase中去；
總體而言，該算法的效率較低，尤其是當Cube維度數較大的時候。
2. 快速構建算法（inmem）[基於內存]
也被稱作“逐段”(By Segment) 或“逐塊”(By Split) 算法，從1.5.x開始引入該算法，該算法的主要思想是，每個Mapper將其所分配到的數據塊，計算成一個完整的小Cube 段（包含所有Cuboid）。每個Mapper將計算完的Cube段輸出給Reducer做合併，生成大Cube，也就是最終結果。如圖所示解釋了此流程。
過程如下：
與舊算法相比，快速算法主要有兩點不同：
- 1.Mapper會利用內存做預聚合，算出所有組合；Mapper輸出的每個Key都是不同的，這樣會減少輸出到Hadoop MapReduce的數據量，Combiner也不再需要；
- 2.一輪MapReduce便會完成所有層次的計算，減少Hadoop任務的調配。
本次的分享就到這裏了,
好書不厭讀百回，熟讀課思子自知。而我想要成爲全場最靚的仔，就必須堅持通過學習來獲取更多知識，用知識改變命運，用博客見證成長，用行動證明我在努力。
如果我的博客對你有幫助、如果你喜歡我的博客內容，請“點贊” “評論”“收藏”一鍵三連哦！聽說點讚的人運氣不會太差，每一天都會元氣滿滿呦！如果實在要白嫖的話，那祝你開心每一天，歡迎常來我博客看看。
碼字不易，大家的支持就是我堅持下去的動力。點贊後不要忘了關注我哦！
