提到‘資料庫’，首先被想到的肯定是Oracle、DB2、SQL Server、MySql這些傳統的關係型資料庫。資料庫的概念是非常寬泛的，除了上述的關聯式資料庫，還有NoSQL（Not Only SQL）資料庫，還有一些基於分散式技術框架（Hadoop、Spark）的大資料儲存和處理體系也被稱為資料庫，以及基於邏輯多維結構的多維資料庫（Multi Dimensional Database，MDD）。今天這裡要介紹的就是這個多維資料庫。
如果您做過資料分析相關的工作，那應該對多維結構和多維資料分析不陌生。
關聯式資料庫中的ROLAP星型表結構是較為常見的“資料分析模型”，但從嚴格意義上來講，它並不具備多維分析的能力，ROLAP之所以被廣泛認知，是因為它易於被理解，只要是接觸過關聯式資料庫，就能很快搞懂ROLAP的套路。
ROLAP有兩個比較明顯的問題，難以優化和模型抽象程度低。
難以優化。對關係型資料庫來說，如果一套表結構模型具有非常複雜的關聯關係，但是這些表的資料量並不大，那麼在進行復雜邏輯的查詢時並不需要過多考慮效能優化問題，把精力專注在查詢邏輯即可。另外一種情況，如果一個資料庫表有大量的資料，但是其結構和查詢邏輯很簡單，那麼是可以對其進行一些通用的優化，使其能夠滿足大部分查詢的效率要求。
對ROLAP體系來說，它的複雜邏輯查詢與對海量資料的運算是嚴重耦合的。
如果是對一套星型結構的查詢，要處理的情況相對還是簡單些的；如果是對多套星型結構進行跨業務的查詢，那麼情況會非常複雜。
即使是能對某一個複雜查詢進行很好的優化，而對於並不可預知的其他查詢邏輯，並沒有辦法進行通用的優化。
模型抽象程度低。由於ROLAP是基於關聯式資料庫表結構的，所以其描述的模型始終擺脫不了‘表、欄位、資料行’等概念，這些概念都是關係資料路中技術相關的概念，而真正的多維資料分析要求維度描述的是純粹的業務角度，不應該暴露任何技術細節。
這裡並不是說ROLAP跟多維資料分析完全不沾邊，只是如果沒有在其上進行更高階模型的抽象，ROLAP本身的資料分析能力是很弱的。
如何構建真正的多維資料模型？要真把這個事情的全部細節說清楚，小編也不知道需要多長時間，下圖是一本講解多維資料結構的書籍，800多頁，各位可以自己估算一下時間。
ROLAP本身是不能等同於多維資料模型的，而且其本身的資料分析能力也是很弱的。
小編幾年前曾經接觸過一個開源的ROLAP系統Mondrian，雖然它也是將資料以星型結構儲存，但在星型結構之上做了大量的模型對映工作，其提供給上層應用的資料模型已經是遮蔽了技術細節的邏輯維度模型。目前Mondrian與其屬主專案Pentaho貌似被收購併商業化了，對開源的支援也降低了。
對比一下傳統報表，ROLAP體系除了星型結構使資料更加規整和採用分散式等手段處理大體量資料之外，和傳統報表幾乎沒有本質的區別。
目前流行的Hadoop、Spark等開源大資料框架可以被視為ROLAP的延伸，但是這種資料分析體系同樣存在抽象程度低的問題，基於Hadoop和Spark等框架可以建立起解決某種特定需求的資料分析體系，這種面向特定需求的專案型系統的通用化和移植性並不會很好（BAT內部建立的很多類似系統就屬於這種情況），而且只能面向技術人員，想要在商業資訊等更高層面體現價值的話必須依賴IT部門的大力支援。
ROLAP說的夠多了，下面言歸正傳，講解真正的多維資料庫。
以Oracle Essbase和IBM Cogons為例，多維資料庫向上提供的是以維度（Dimension）和Cube（資料立方體）為基本結構的邏輯模型。維度類似於座標軸，Cube則相當於這個N維空間中的一個結構體。
- 在0維空間中，Cube沒有可關聯的維度，可以將Cube想象成一個點，確定一個度量值不需要任何維度資訊。
- 在1維空間中，Cube結構是一條線。
- 在2維空間中，Cube結構是一個平面。
- 在3維空間中，Cube是一個立方體結構。
- N（N > 3）維空間中的Cube則可以被想象成一個超立方體結構。
相當一部分BI行業從業者認為ROLAP的星型結構與邏輯多維結構是等同的，實際上這是對多維資料庫及多維資料模型的最大誤解。
從表面來看，星型結構與多維資料庫在資料持久化方面提供的能力是相當的，甚至基於關聯式資料庫的ROLAP會更方便一些，但一旦涉及對資料的多維分析，ROLAP相對於多維資料庫來說基本可以被視為傳統報表。
多維資料模型的標準查詢語言是多維表示式（MDX，Mutil Dimensional Expressions），MDX是微軟公司發明的面向多維資料模型的結構化查詢語言，在語法結構和長相上MDX和SQL是很類似的。
對於多維邏輯模型，可以使用MDX進行查詢；對於ROLAP，則使用SQL查詢。人們很容易將ROLAP星型結構等同於多維結構，同樣也容易將MDX想象成SQL的簡單變體。實際情況是這兩種資料分析套路的差別是非常大的，多維資料庫可以支援100%面向業務式的資料分析，而基於ROLAP則始終無法擺脫關聯式資料庫表與欄位的查詢思路。
現在我們來假設一個多維資料模型，以此為例來探究一下傳統多維資料庫的內部原理。
此模型是全國各個地區各種服裝的銷售資料集，有三個維度：地區、日期、服裝類別，兩個度量：銷售額和售賣數量。
多維資料庫從接收MDX到返回查詢結果大致要經過MDX解析、中間結構處理、度量聚集計算、返回結果等幾個步驟。
- MDX解析步驟負責對輸入的MDX語句進行詞法和語法分析，然後生成中間表示結構。
- 中間結構處理步驟的工作是對多維查詢的複雜邏輯和函式進行處理、確定查詢結果的結構和呼叫度量聚集計算對結構進行填充，這個步驟的工作非常複雜，是由多維資料庫核心呼叫各個元件來完成的。
- 度量聚集計算負責將明細級度量彙總成非明細度量，是多維資料庫底層的原子級運算。
- 返回結果將一個M維（M <= N）的結構進行填充並返回，0維Cube的查詢結果只能是標量值，1維Cube的查詢結果可以是一個標量也可以是一個1維結構，2維Cube可以返回標量值、1維結構和2維結構作為結果，大於等於3的N維Cube返回結果形態可以以此類推。
在大多數情況下，查詢Cube返回的結構都是2維的，因為這是最容易被人們直觀理解的。
多維資料庫的優點之一是查詢速度非常快，這就要著重說一下度量聚集計算這個步驟。
多維資料庫對資料的管理主要由兩部分組成，概要檔案（Profile）和資料塊（Data Blocks）。概要檔案負責對維度、維度成員、Cube與維度的關聯關係等資訊進行管理，把它想象成一個迷你的主資料管理系統即可。資料塊則負責管理度量資料。
以前文提到的那個服裝銷售Cube為例，它的度量資料可以被想象成是存放在一個 192×2 的二維陣列中。
一個N維Cube模型的資料可以直接被對映為N + 1維陣列，這個多出來的1代表的是度量，度量本身也可以被看做一個維度，後文會進行說明。此文中會將N + 1維陣列的N維展開成1維，這意味著N + 1維陣列將變成一個2維陣列，2維陣列看起來會比較直觀。2維陣列本身也是邏輯結構，它可以很清晰的將代表業務角度的維度和度量維區分開。實際上，在作業系統級別的儲存結構上，任意維數的陣列都是以一維陣列的形態存在的，您應該對此有清晰的瞭解。
計算規則：
二維陣列長度 = 全部非度量維度明細級成員數量的笛卡爾積
二維陣列中包含的一維陣列長度 = 度量值數量（銷售額和售賣數量）
如果Cube只包含一個度量，那麼二維陣列就變成了一維陣列，可以把這種情況看成一種特例。
這個二維陣列儲存的是各維度明細成員組合所指向的度量值，如：【10月份北京地區夾克的售賣數量為80000條】
另一些非明細維度成員指向的度量值並沒有直接存放在這個二維陣列裡，它們可以通過對上面二維陣列中的資料進行聚集運算而得出。
正是由於二維陣列中的資料是依照各個維度明細成員的順序排列而來的，所以在進行聚集計算的時候，只需要給定聚集資料範圍的首位座標即可，程式將以直接定址的方式進行彙總計算，相比於關係型資料庫的索引，速度明顯要快得多。
多維資料的度量完全可以被視為一個維度，同樣，維度也可以變換成度量，以下兩種Cube在邏輯上是完全等同的。
這種二維陣列的結構存在兩個比較嚴重的問題，資料膨脹和資料空洞。
資料膨脹，這個不難理解，由於二維陣列的長度是各維度明細成員數量的笛卡爾積，所以一旦維度的明細成員增加，就有可能導致二維陣列體積的幾何增長。
當前示例中地區、時間、服裝類別維度明細成員數量分別是 4、12、4，對應的二維陣列長度即為 4×12×4=192。如果每個維度明細成員數量增加一倍，二維陣列的長度就變為了1536，體積變成了原來的8倍。
資料空洞問題。不存在的度量值會產生資料空洞，假設在海南地區一件羽絨服都沒有賣出去（實際情況是在海南確實能將羽絨服賣出去），那麼在二維陣列中同時關聯海南和羽絨服的度量將都沒有意義。
如果資料空洞很多，將會使得二維陣列變得非常稀疏，造成儲存空間的極大浪費。
為了解決上述兩個問題，傳統多維資料庫引入了索引結構。
索引是由那些導致陣列變得稀疏的若干個維度變化而來的，地區維度和服裝類別維度就可以變化為索引。
當地區和服裝類別變為索引後，每個索引將指向一個小的資料塊。
可以計算出，每個小資料塊的容量是12×2=24，總共有8個小資料塊，在不計索引本身所佔儲存的情況下，整體資料儲存量降到了原來的 1/2。
另一種情況，如果只有某幾個月份的銷售資料，那麼日期維度本身也可以變成索引，如下圖所示。
在其他介紹多維資料庫的文章中經常會出現“稀疏維”這個概念，這非常容易對讀者產生誤導，按某個維度本身來說是不存在稀疏還是密集這種說法的，稀疏指的是某些維度組合產生了很多不存在的資料，產生的大量資料空洞將導致資料集整體有效資料密度的降低。
傳統多維資料庫的索引結構就是為了解決資料稀疏問題而引入的，但是帶來的問題是一旦Cube資料密度重心發生變化，那麼應該組成索引的維度也可能隨之改變，這種變化會導致整個索引以及資料塊結構的完全重新構建，計算代價非常昂貴，而且，到底應該由哪些維度組成索引並沒有非常明確的判定標準。
LookUpCube函式問題。
LookUpCube是MDX中用於進行多Cube關聯查詢的函式，不過目前貌似只有Microsoft SSAS支援此函式，小編並沒有在Essbase、Cogons、Mondrian中找到LookUpCube的痕跡。
LookUpCube可以非常方便的進行跨業務、跨領域分析，但是在微軟的官方文件中卻明確指出不建議使用此函式，因為它會導致嚴重的效能問題。如果把關聯多個Cube的查詢想象成在ROLAP中對多張事實資料表進行Join查詢，就不難理解了。
如果您理解了Essbase、Cogons等多維資料庫的索引和資料塊結構，以及為了得到非明細維度成員所對應度量值的原子性聚集計算，那麼應該能夠理解在這種資料架構上並不會存在類似於關係型資料庫中多表Join的查詢。由此我們可以進行一下推測，微軟SSAS和Oracle Essbase、IBM Cogons的底層架構並不一樣，SSAS採用的是像Mondrian一樣在ROLAP上進行高度抽象的方式來實現多維分析的（確切的說應該是Mondrian模仿了Microsoft SSAS）。Mondrian沒有實現LookUpCube函式可能是因為（在ROLAP架構中）這確實會造成很大的效能問題，而在Essbase和Cogons的稀疏維組合索引和資料塊的架構下實現LookUpCube應該不會造成很大的效能問題，但Oracle和IBM（Hyperion和Cogons）為何沒有實現此函式，小編也不知道。
Essbase是Hyperion公司的產品，Hyperion被Oracle收購了。Cogons是Cogons公司的產品，別疑惑，公司名和產品名是相同的，Cogons後被IBM收購。
NeuralCube
NeuralCube是邦格科技研發的具有自主智慧財產權的國產多維資料庫，在整體架構上看，它可以被視為傳統多維資料庫Essbase、Cogons的進化版本，它是一個基於分散式資料儲存的多維資料庫，也是一個開放的資料分析引擎。
NeuralCube主要包括三個部分：核心、模型管理服務和向量計算引擎。
- 核心是NeuralCube的核心邏輯處理程式，與傳統多維資料庫一樣，核心的工作是對多維查詢的複雜邏輯和函式進行處理、確定查詢結果的結構和呼叫度量聚集計算對結構進行填充，它會呼叫模型管理服務和向量計算引擎來完成這些工作。
- 模型管理服務類似於Essbase和Cogons的概要檔案，前邊已經說過傳統多維資料庫的概要檔案相當於一個迷你的主資料管理系統。在NeuralCube中，模型管理服務是一個獨立執行的真正的主資料管理系統。
- 向量計算引擎是用C實現的分散式資料儲存體系，類似於傳統多維資料庫的索引和資料塊，它的作用是儲存資料和對非明細維度成員對應的度量進行聚集計算。向量引擎的資料量非常龐大，但是資料結構非常簡單，而且其本身的聚集計算邏輯也非常簡單，所以其具有更高的穩定性和更快的運算效率。
NeuralCube的整體邏輯處理流程如下。
NeuralCube接收一個MDX，最後會返回一個多維結果集。NeuralCube對標準MDX進行了擴充套件，用以對上層應用可能提出的特定化需求提供最大的支援，同時增加了一些更直觀的函式。MDX是由美國人發明的，在思維方式上老外跟國人還是有些差異的，就拿常見的同比、環比分析來說，在標準MDX下只能通過巢狀好幾個函式以一種非常奇怪的方式實現，而NeuralCube中則增加了大量貼近中國人思維方式的函式。
多維查詢能力提升的必要條件之一是對邏輯模型處理能力的增強，這離不開模型管理服務的支援。
傳統多維資料庫概要檔案所管理的模型是Cube、Dimension、Member、Hierarchy、Level、Measure等，這在處理某個維度扮演多個角色的情況時會帶來麻煩，如：對中國全部省份的人口遷徙情況做一個統計，會涉及到戶籍遷出省和戶籍遷入省，按業務含義來說，戶籍遷出省和遷入省維度是100%相同的，如果無法以另外一種方式對省份維度進行識別，就會對分析造成混淆。
NeuralCube解決以上問題，是通過在模型管理服務中引入Role模型來解決的。在NeuralCube中，Cube和Dimension不會直接關聯，而是通過Dimension Role（維度角色）產生聯絡，顧名思義，維度角色就是維度所扮演的角色。由於Hierarchy、Level、Member物件都是掛靠在Dimension上的，所以其也自帶有角色屬性（Hierarchy Role、Level Role、Member Role）。前文已經講過，度量完全可以被視為一個普通的維度，但這裡並沒有將度量維的角色屬性進行過多的處理，因為在大多數Cube中，其度量基本都是獨佔的。
相對於Essbase、Cogons等傳統多維資料庫，NeuralCube在多維模型的關聯能力方面進行了增強。維度是多維資料模型的核心，在底層概念上它可以被看做是一個座標軸，在抽象程度更高的業務角度，維度代表的就是現實中存在的物件，現實中各種實體及概念往往存在錯綜複雜的關聯關係。例如表示客戶的維度，每個客戶都有其所屬的地區，那麼所屬地區就是客戶的屬性之一，在正常認知層面，這些作為屬性的地區和地區維度中的地區應該是完全相同的。在傳統多維資料庫中，只能將地區名稱或編碼以屬性的方式儲存，而在NeuralCube中地區維度成員本身就具備屬性的性質，完全可以將客戶維度和地區維度進行關聯，這種關聯的意義會體現在更加深層次的資料探勘能力。
NeuralCube中對大資料的儲存和運算是由向量計算引擎來完成的，它的核心思想非常簡單，就是將海量資料的聚集運算分而治之。
在前文中已經提到過傳統多維資料庫的原子性運算是通過明細維度成員對應的度量值去彙總計算非明細成員對應的度量值，如果將每個維度成員都視為維度座標軸的一個刻度的話，那麼度量值可以被直觀的理解為一個向量值。向量計算引擎的功能就是通過明細向量值彙總去計算非明細向量值。
Essbase、Cogons等產品將事實資料儲存在索引和資料塊結構中，ROLAP儲存事實資料的則是事實表，NeuralCube的向量計算引擎原理跟這兩者都有一些類似，但不完全一樣。
NeuralCube向量計算引擎的儲存結構類似於ROLAP的事實表，但採用分散式儲存。關聯式資料庫的表如果很大也會被進行分片、分庫處理，但會有分片欄位將這些子表在邏輯上整合成一張完整的大表，NeuralCube向量計算引擎採取的方式就不一樣了，它將一個大的資料塊簡單的切分成若干的小的資料塊，每個小資料塊彼此之間是完全孤立的，並不需要產生任何關聯。
向量引擎的運算方式類似於傳統多維資料庫的原子級運算，就是將明細級度量彙總成非明細度量。傳統多維資料庫和向量計算引擎中都有資料塊的概念，但區別在於前者對資料塊的規劃是在將稀疏維組合變換為索引的前提下實現的，索引和資料塊的結構關聯緊密，還有可能因為資料重構而產生較大變化，可以說是處於一種不穩定的狀態，後者的資料塊則是將一個大的資料集簡單進行切分，然後形成多個完全孤立的資料塊。
傳統多維資料庫的‘索引和資料塊結構’、‘ROLAP事實表’、‘向量計算引擎的資料儲存結構’經過變換是可以互通的。
多維資料庫索引有一種特殊情況，就是所有維度的組合都是稀疏的，那麼資料塊中就只存在度量值資訊了，維度全部變換成索引，這就與ROLAP事實表中的維度表外來鍵索引完全一樣了。
將ROLAP事實表切分成多個子表，會近似於向量計算引擎的分散式儲存結構。
向量計算引擎的資料塊雖然可以被想象成ROLAP事實表的分片表，但卻不像事實表那樣需要關聯維度表進行查詢，它更像傳統多維資料庫的原子運算，是基於每個小資料塊之上獨立執行的。
我們現在將傳統多維資料庫、ROLAP、NeuralCube的架構做一個整體的對比，系統的看一下這三者之間的關聯與區別。
- 傳統多維資料庫的概要檔案、ROLAP維度表、NeuralCube的模型管理服務負責的工作是對後設資料模型的管理，NeuralCube的模型管理服務更是一個完全獨立的後設資料圖譜。
- 傳統多維資料庫的索引和資料塊、ROLAP事實表、NeuralCube向量計算引擎的任務是儲存事實資料並進行運算。ROLAP事實表需要跟維度表進行關聯查詢，而傳統多維資料庫和NeuralCube則是基於被切分的資料塊進行原子性彙總運算。
- 傳統多維資料庫和NeuralCube都有核心處理邏輯，ROLAP沒有核心，但也可以將關聯式資料庫本身的SQL解析與處理想象成ROLAP的核心邏輯。
另外，NeuralCube很好的支援了LookUpCube函式，很大程度上增強了跨行業、跨領域資料分析能力，並且不會造成很大的效能問題。
由於分散式多維資料庫NeuralCube的邏輯運算和聚集運算是解耦的，所以可以很好的支援即席查詢能力，對於隨機的查詢無需做特定的優化便可獲得很高的查詢效率，這也是NeuralCube能支援“探索式分析”和“零試錯成本”的前提。
多維資料庫屬於底層基礎軟體，想要進行系統的資料分析當然不能缺少面向終端使用者的上層應用，Phoenix Analytics就是基於NeuralCube的高易用性資料分析平臺，可以讓業務人員像打遊戲一樣非常輕鬆的進行資料分析，並且可以免費下載哦。
瞭解更多，請訪問www.bgotech.cn