多維分析預匯總的存儲容量

發布時間:2019-02-26 分類:數據蔣堂 Tag:,,,

多維分析一般是交互式操作的,也就要求有極高的響應速度,而多維分析涉及的數據量常常很大,幾千萬上億行甚至更大都有,臨時統計很可能跟不上界面的操作。為了保證性能,一些多維分析產品采用了預匯總方案,也就是把需要看到的統計結果事先計算好,這樣計算復雜度就從O(n)變成O(1),在常數時間(秒級甚至毫秒級)內就可以返回結果,滿足了交互分析的需求。

我們都知道,預匯總的基本邏輯就是用空間換時間,將會額外占用許多存儲空間,但很多人對它到底會占用多大空間卻沒有什么感性認識。我們現在就來算一算看。


假設一個原始的CUBE有50個獨立維度(所謂獨立維度是指互相不依賴的維度,象年/月/日這種是不獨立的,可以算成一個),如果我們把所有可能的維度組合都預先匯總出來的話,會有多少個中間CUBE(更精確的術語是CUBOID)呢?很容易算,2^50個!1

意這是中間CUBE的個數,而不是數據的行數,每個CUBE還會有很多數據,就算每個CUBE只占用1K字節(顯然不可能這么少),2^50個CUBE將占用的存儲空間也是個天文數字,超過1MT,也就是要上百萬塊1T的硬件才能放得下:)。

好吧,我們沒必要預匯總所有的維度組合,一般人同時看的匯總維度也沒有那么多。我們按20個來算,只匯總所有不超過20個維度的組合,那是多少個中間CUBE呢?C(50,1)+C(50,2)+…+C(50,20)。我們只看最后一項C(50,20),大概是4.7E13,如果每個中間CUBE按1萬行算(其實太保守了,20個維度很容易乘出上百萬甚至上億行出來2),這樣就會有4.7E17以上的數據行。維度信息因為有不少重復值,就認為有什么高效壓縮手段給徹底忽略掉算了,我們僅僅考慮一個測度的統計值,一行數據也要占1-4個字節,就算只有1字節,實在沒有辦法再壓縮了,這也要有470000T以上的容量,還是要幾十萬塊硬盤:)。

50個獨立維度是不是太多了?還是20個維度組合數量太多了?熟悉金融、通信等行業的同學會知道,這些數量還是比較常規的,并不算過份。


我們繼續來縮小任務空間。

一般來講我們查詢多維分析的結果是用一個交叉表,交叉表層數太多顯然看著不方便了,我們就假定左3層上3層,也就是總共最多6層。50個維度中取6個的組合數為C(50,6),大概是1589萬,我們仍然按每個中間CUBE有1萬行數據來算,這樣算下來不到160G行。每行數據有十幾個測度統計值,一般不會超過1K,總容量差不多能在100T左右了。這個數量似乎可以接受,只要100塊硬盤了:)。

且慢,這只是我們看到的交叉表部分。我們在多維分析時還常常要提一些切片條件,比如針對某個月、某個地區、某個產品來看其它維度的交叉表。預匯總的數據,不僅要考慮到交叉表本身的維度,還要加上切片用到的維度。6這個組合數量只夠交叉表的,我們把它湊成10再來計算容量,也就是留4個維度用來切片。

還是按上面的估算方法,C(50,10)大概是100億,每個中間CUBE按一萬行算,就是100T行??雌饋磉€行,但這只是數據的行數,如果我們事先匯總上10幾個測度,那又是幾千T空間了,硬盤數還得上千:)。


預匯總占用的空間實在太大,看起來沒什么實用性了。而且,我們的計算已經很保守了,比如CUBE數量只算了最大項,中間CUBE容量只算成一萬行,維度用的空間沒有算,一個測度匯總值也只算了一個字節。實際情況遠沒有這么理想了,占用空間比估算數值再大幾倍到幾十倍也是很正常的。

那么,預匯總到底還能不能做?

當然還是能的。維度比較少的時候沒問題,比如只有10幾個維度時,中間CUBE的數量也就是幾千到幾萬的量級,空間占用會在百十塊硬盤的范圍內。一般來說,如果獨立維度數超過30個時,就不要再指望能夠把可能查詢到的維度組合都事先匯總出來了,也就不可能把計算復雜度降成O(1)了。當然具體數值也要根據維度和測度統計需求的情況來定,可以用上面的辦法自己估算。

那是不是維度較多時不能做預匯總了?也不是,在有限的空間內雖然沒辦法把計算復雜度降到O(1),但能降上幾十幾百倍也很有意義。我們后續會再討論這個話題。


1:如果把年/月/日這種分層維度考慮進去,就不是2^n,會比這個數更大,應當是(L1+1)*(L2+1)*…*(Ln+1),n是維度數,Li是第i個維度的層數,比如年/月/日這種維度的層數是3,沒有層的維度可以看成是1層情況。

2:CUBE的行數,理論上是各維度取值可能性數量的乘積,即使每個維度只有2種取值,20個維度的CUBE行數就可能2^20=100萬行,遠遠超過1萬。每個維度有5種取值可能時,6個維度的CUBE就會有上萬行了。

更多《數據蔣堂》文章
广西快乐十分