前言：資料分析領域自2010前後一直佔據了全球資訊科技的核心地位，OLAP的需求並未隨著Hadoop的流行而消亡，而是被越來越理智的認可——“資料再多也需要分析、分析的主要需求還是互動查詢”。本文概括了OLAP的本質原則、曾經的困境和當前的技術派系，希望能引起從業者的思考，共同促進行業進步與發展!

1. 剖析OLAP本質

OLAP(Online Analytical Processing)是一種資料處理技術，專門設計用於支援複雜的分析操作，側重對決策人員和高層管理人員的決策支援，可以根據分析人員的要求快速、靈活地進行大資料量的複雜查詢處理，並且以一種直觀而易懂的形式將查詢結果提供給決策人員，以便他們準確掌握企業(公司)的經營狀況

二十幾年前E.F. Codd提出OLAP時，也參照關係資料庫提出了12條規則，但後期沒有得到發展，其中有些規則在現在看來都已經不再完全適用，或者不是OLAP的特殊規則。因此我們從OLAP的本質定位上，重新確定三條原則，用以解析OLAP的歷史發展：

1) 提供多維的業務檢視(“維”是OLAP存在和核心概念)

2) 滿足靈活的互動分析(面向決策分析需要及時響應查詢需求的變更)

3) 提供高速的檢索效能(沒有人希望查詢資料等待太長時間)

無論從E.F. Codd提出的12條規則中，還是本文提煉的三大原則中，都可以明確出OLAP是滿足應用需求而研發的新技術，而且是以“維度”為核心概念的所有技術的統稱。

2. OLAP vs Reporting

從事BI/DW的專業人士們，對這張架構圖應該非常熟悉，其中同時出現了OLAP和Reporting兩個面向使用者的應用功能(資料探勘暫且忽略)。

兩者核心的區別在於OLAP可以讓終端使用者可隨意更改格式，以及進行維度鑽取，甚至自定義成員，而Reporting的終端使用者只能按照開發人員的預置做有限互動(比如重新整理引數等)。同時從後臺原理上，OLAP通過預計算(空間換時間的思想)做到高速響應，Reporting一般通過對關係型資料庫的模型和優化保證既定SQL的高速查詢。

為什麼提到Reporting，因為它是OLAP出現之前的唯一資料應用，也正是因為Reporting解決不了大規模資料的互動分析，才誕生了OLAP。

3. OLAP遇到的困難

OLAP核心三原則的“多維”通過星型/雪花模型得以保證(已經有OLTP能參考的經驗)、“靈活互動”和“高速響應”通過基於“預計算”資料的互動查詢而實現。這就順理成章的讓我們聯想起多維表示式——MDX(MultiDimensional eXpressions)，此技術在E.F.Codd提出OLAP四年後就被微軟定義並使用。

Multidimensional Expressions (MDX) is a query language for OLAP databases. Much like SQL, it is a query language for relational databases.

MDX是類似SQL的查詢語言，只不過查詢的是OLAP資料庫。

當微軟發明MDX後，眾多廠商都相繼跟進並應用了這個非公開標準的技術，比如Oracle、SAS、Teradata、Cognos、Business Objects等等，從而使得MDX成為了OLAP領域的必備技術。

熟悉OLAP的朋友都知道MOLAP、ROLAP、HOLAP，它們都是時間與空間平衡關係的產物，比如MOLAP犧牲了空間和時效性，過度滿足了查詢效能，ROLAP保證了空間和時效性，卻又容易喪失前端查詢的高效能，最後發展出混合型的HOLAP。無論後端如何變化，前端的MDX卻從來沒有改變過(2008年我曾參加的面試題，裡面就全部都是MDX語法)。

言歸正傳，為什麼說OLAP的發展遇到了苦難呢，有這麼幾點：

1、 OLAP產品的封閉性

雖然前端查詢的預設標準是MDX，但由於MDX的不夠普及和易用，實際得以商業應用的軟體中很多都自成一體(所謂成熟的商業軟體)，比如IBM Cognos等，造成前端功能的受限和不易整合。只有Microsoft SSAS、Oracle Essbase、Mondrian等少數幾個可以把服務端以XML for Analysis標準開放出來，提供比較好的開發和整合能力。

2、 OLAP的預建模瓶頸

傳統的OLAP軟體，無論MOLAP/ROLAP/HOLAP，都會為使用者的使用提前設計一個星型模型，它的好處是便於使用者在一個存在相關關係的資料範圍內操作，避免出現查詢結果的錯誤。但帶來的問題就是，當業務需求變化快或者業務關聯更新時，模型就需要重構，而且必須由IT人員負責重構，較低的變更效率影響了使用感受。

3、 xOLAP都滿足不了大資料的分析

凡事都存在量變到質變，資料量一旦大到TB、PB的程度，無論是基於檔案的MOLAP，還是基於資料庫的ROLAP，就都不能滿足第三原則(高速響應)了。尤其很多客戶已經採用Hadoop的資料架構，傳統的OLAP技術就很難融入其中了!

4、 OLAP視覺化能力弱

熟悉OLAP產品前端操作的使用者都清楚，拖拽、下鑽、切片這些動作都是基於表格的，基本不能在圖形上完成同樣的操作，這就給OLAP帶來一個基因上的缺陷，就是視覺化能力不夠。還不要提現在時髦的玫瑰圖、網路圖、桑基圖等等視覺化圖形!

5、 MDX不如SQL普及

MDX在很多統計分析功能上得天獨厚，又比如協方差等計算函式，但80%的真正需求還是定位在簡單的分級彙總和鑽取切片排序上。無論在學習資源還是普及程度上，SQL還是擁有最多人群的資料查詢技術。SQL的接受程度從在Hadoop生態的迴歸就能知道!

技術從來就不能阻擋需求，這些問題存在了若干年後，最近OLAP出現了很多新的技術實現，從多個方向帶來了新的選擇。

4. OLAP的技術派系

OLAP作為一大類市場需求始終是存在的，需要發展的只是實現它的技術(OLTP所基於的RDBMS非常穩定)。現在OLAP技術發展了20多年，正處於群雄逐鹿階段，無論未來有沒有一統江湖的完美技術，至少從現在來看，我們有必要從OLAP本質三原則梳理技術派系，以便市場參考和個人選擇：

1. 傳統OLAP

尊重傳統是技術領域最缺少的品德，傳統OLAP中尤其是Mondrian和SSAS還是有不少使用者群的(前者是開源軟體)，反而選用Cognos、MSTR等的越來越少。

2. 視覺化OLAP

十幾年前，最火爆的BI產品是BO(2007年以68億美元被SAP收購)。BO裡最早的核心技術叫做“動態微立方”，就是把基於語義模型查詢的結果集資料以MOLAP的方式儲存在記憶體中，以加快後期互動分析的效率。現在同樣也有各種基於記憶體計算的軟體，但它們是以視覺化為主，比如Tableau和Qlikview等。單純定位在視覺化上的OLAP只有商業軟體，沒有開源也沒有免費的選擇，這是因為視覺化是個短期需求吧。

3. 大資料OLAP

Hadoop的生態系統誕生於網際網路公司，從一開始就有開放的基因，這個OLAP派系最有意思的是Kylin，而且是咱中國人在Apache上的定級專案。“Apache Kylin™是一個開源的分散式分析引擎，提供Hadoop之上的SQL查詢介面及多維分析(OLAP)能力以支援超大規模資料，最初由eBay Inc. 開發並貢獻至開源社群。”它與前2者最大不同點在於2個：使用SQL進行查詢和支援Hadoop(SQL、SQL、SQL，重要的事情說三遍J)!準確的說，Kylin只是一個OLAP server，它的前端可以選用Smartbi等免費或者商業的軟體，也可以選擇自己開發。

4. 辦公OLAP

最後一個派系也不可小視，那就是微軟Excel(WPS等電子表格軟體還難以匹敵)。雖然它也是自有的封閉技術，但它的友好性和相容性足夠強大，幾乎人人電腦上都能使用，而且也確實是每個資料分析人員都略會一二的工具軟體。而且它更重要的價值在於在Excel裡面可以維護和處理資料，這是其它3類OLAP都無法提供的。具體介紹網上有很多，大家可以關注中國電子表格應用大會、Excelhome等網路資源。

最後還是強調OLAP是除了報表Reporting和資料探勘Mining以外的一大類資料分析需求，在遵從“多維”、“靈活互動”和“高速響應”三個本質原則情況下，無論你是辦公一族還是軟體工程師、大資料專家，都有適合你的OLAP軟體工具!

資料的聯機分析處理，不會隨著時間淡出，只會隨著資料化運營的管理觀念普及而加強!