前言：數據分析領域自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軟件工具!

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