多維數(shù)據(jù)庫Oracle Essbase和IBM Cogons的底層原理

本篇內(nèi)容主要講解“多維數(shù)據(jù)庫Oracle Essbase和IBM Cogons的底層原理”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“多維數(shù)據(jù)庫Oracle Essbase和IBM Cogons的底層原理”吧!

多維數(shù)據(jù)庫（Multi Dimensional Database，MDD）使用Dimension（維度）和Cube（數(shù)據(jù)立方體、數(shù)據(jù)集市）模型描述數(shù)據(jù)。

多維數(shù)據(jù)模型

關(guān)系型數(shù)據(jù)庫（Relational Database，RDB）中的星型結(jié)構(gòu)或雪花型結(jié)構(gòu)就是模擬上述多維模型結(jié)構(gòu)的，但無法提供真正意義上的多維數(shù)據(jù)分析能力，這里不做過多解釋。

下文講解Oracle Essbase以及IBM Cogons這種真正的多維數(shù)據(jù)庫的原理。

多維數(shù)據(jù)庫中模型結(jié)構(gòu)與事實(shí)數(shù)據(jù)分別以概要文件（profile）和數(shù)據(jù)塊（data block）的形式存在。

profile和data block

概要文件用來描述以下信息：

1. 維度和維度成員信息

2. 與維度相關(guān)的層級(jí)（Hierarchy）和級(jí)別（Level）信息

3. Cube的描述性信息，以及Cube與維度的關(guān)聯(lián)性

4. 其他描述性的信息，如實(shí)體模型屬性

Cube中度量數(shù)據(jù)存放在data block中，data block可以被理解成為多維數(shù)組結(jié)構(gòu)，其大小與相關(guān)維度的明細(xì)成員數(shù)量有直接關(guān)系。

計(jì)算公式：data block size = 維度1明細(xì)成員總數(shù) * 維度2明細(xì)成員總數(shù) * …… * 維度N明細(xì)成員總數(shù)

數(shù)據(jù)塊容量等于相關(guān)維度明細(xì)成員數(shù)量的笛卡爾積。

數(shù)據(jù)塊大小

明細(xì)度量值一般采用double類型，按8bytes算，上圖所描述的Cube的數(shù)據(jù)塊大小為480bytes。

除了數(shù)據(jù)塊中的明細(xì)度量值外，其他非明細(xì)度量值并沒有直接存儲(chǔ)，因?yàn)槠淇梢酝ㄟ^對(duì)應(yīng)的明細(xì)度量值計(jì)算出來。

非明細(xì)度量值計(jì)算方式

一些不存在的度量值會(huì)造成數(shù)據(jù)空洞問題，假設(shè)2018年4季度河北省B品牌手機(jī)的銷售量是未知的，則會(huì)在數(shù)據(jù)塊中產(chǎn)生一個(gè)空洞。

注意：數(shù)據(jù)空洞表示不存在的值，與數(shù)值0的意義不同，數(shù)值0表示一個(gè)有意義的值。

如果數(shù)據(jù)空洞比較多，則數(shù)據(jù)塊的數(shù)據(jù)密度就會(huì)下降，將造成存儲(chǔ)空間的浪費(fèi)。

數(shù)據(jù)空洞

除了數(shù)據(jù)空洞問題，還存在數(shù)據(jù)爆炸問題。數(shù)據(jù)塊大小由全部維度明細(xì)成員數(shù)量的笛卡爾積決定，假如某個(gè)Cube關(guān)聯(lián)三個(gè)維度，每個(gè)維度明細(xì)成員數(shù)量均為100，則：data block size = 100 ^ 3 = 1000000，如果度量值按double類型存儲(chǔ)（8bytes），數(shù)據(jù)塊文件大約為7.62M。如果每個(gè)維度明細(xì)成員數(shù)量增加至150，則數(shù)據(jù)塊文件將膨脹到25.74M（data block size = 150 ^ 3 * 8bytes / 1024 / 1024）。

當(dāng)數(shù)據(jù)塊極度膨脹并且存在很多數(shù)據(jù)空洞的時(shí)候，會(huì)極大地浪費(fèi)存儲(chǔ)空間，并且可能導(dǎo)致數(shù)據(jù)存儲(chǔ)無法實(shí)現(xiàn)。

極度膨脹和存在大量空洞的多維數(shù)組

為了解決數(shù)據(jù)空洞和數(shù)據(jù)膨脹問題，引入了密集維度組合和稀疏維組合的概念。

判斷維度組合是密集還是稀疏的原則是看其所對(duì)應(yīng)的明細(xì)度量值的存在情況，例如：

1. 北京地區(qū)只有ABC三種手機(jī)的銷售額，天津地區(qū)只有BCD三種手機(jī)的銷售額，河北地區(qū)賣出的手機(jī)只有AE兩種，表明并不是每個(gè)地區(qū)對(duì)于每一種手機(jī)都有銷售額，所以地區(qū)與產(chǎn)品屬于稀疏的維度組合。

2. 2018年的四個(gè)季度都有手機(jī)銷售額，所以日期維度自身可以構(gòu)成密集的維度組合。

注意！在其他講解多維數(shù)據(jù)庫的文章中都把維度分為稀疏維與密集維，這是非常錯(cuò)誤的，對(duì)于維度本身來講沒有稀疏與密集之分，稀疏與密集表示的是維度之間的組合！對(duì)于有N個(gè)維度的Cube而言，如果其只有一個(gè)維度退化成索引，或者有N - 1個(gè)維度退化成索引，則此時(shí)稀疏與密集的維組合只包含一個(gè)維度，但這只是一種特例，并不代表維度本身是稀疏或密集的。

在引入稀疏與密集的維度組合之后，原本由于數(shù)據(jù)空洞和數(shù)據(jù)爆炸而失控的數(shù)據(jù)塊結(jié)構(gòu)將變成索引和密度相對(duì)較高的小數(shù)據(jù)塊結(jié)構(gòu)。

索引和小數(shù)據(jù)塊

之前數(shù)據(jù)文件大小為3 * 4 * 5 = 60，結(jié)構(gòu)變換之后每個(gè)小數(shù)據(jù)塊大小為4（共8個(gè)），在不計(jì)算索引所占存儲(chǔ)大小的情況下，存儲(chǔ)容量變?yōu)樵瓉淼囊话搿?/p>

度量值的變化可能引起稀疏維度組合和密集維度組合的改變，如下圖所示。

重構(gòu)

雖然解決了數(shù)據(jù)空洞和數(shù)據(jù)爆炸的問題，但稀疏與密集的維組合所帶來的負(fù)作用是一旦度量值的變化導(dǎo)致了數(shù)據(jù)塊密度中心的改變，相關(guān)的索引和子數(shù)據(jù)塊必須重構(gòu)，而這種重構(gòu)的性能代價(jià)與時(shí)間成本是極為昂貴的。Cogons、Essbase等傳統(tǒng)多維數(shù)據(jù)庫以及其他MOLAP都存在此問題。

基于矢量計(jì)算引擎（Vector Calculation Engine）的新型分布式多維數(shù)據(jù)庫很好的解決了數(shù)據(jù)重構(gòu)問題。

矢量計(jì)算引擎將海量數(shù)據(jù)的運(yùn)算從多維數(shù)據(jù)庫核心分離出來，進(jìn)而將多維分析時(shí)的邏輯運(yùn)算與聚集計(jì)算解耦。多維數(shù)據(jù)庫核心只負(fù)責(zé)邏輯運(yùn)算，完全不需要再考慮數(shù)據(jù)量的問題。矢量計(jì)算引擎采用極為簡單的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)TB、PB級(jí)數(shù)據(jù)，并且只負(fù)責(zé)進(jìn)行一種算法上極為簡單的聚集運(yùn)算，針對(duì)此種特性，適宜采用更加接近底層的編程語言進(jìn)行開發(fā)（如C語言），不僅得到了性能上的提升，也因?yàn)閿?shù)據(jù)存儲(chǔ)結(jié)構(gòu)的簡單而獲得了更加穩(wěn)定的運(yùn)行效果。

基于矢量計(jì)算引擎的多維數(shù)據(jù)庫

如上圖所示，在多維數(shù)據(jù)庫內(nèi)核角度來看，矢量計(jì)算引擎是更加底層的一種基礎(chǔ)服務(wù)，所以可以根據(jù)各種應(yīng)用場景切換不同的實(shí)現(xiàn)方式，而這一切對(duì)于多維數(shù)據(jù)庫內(nèi)核來說都是透明的，多維數(shù)據(jù)庫本身對(duì)更上層的應(yīng)用提供一致的數(shù)據(jù)查詢能力，從而更好的支持了100%面向業(yè)務(wù)的探索式數(shù)據(jù)分析能力。

到此，相信大家對(duì)“多維數(shù)據(jù)庫Oracle Essbase和IBM Cogons的底層原理”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！