尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️
商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
提到‘數據庫’，首先被想到的肯定是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的高易用性數據分析平台，可以讓業務人員像打遊戲一樣非常輕鬆的進行數據分析，並且可以免費下載哦。
