1 背景

1.1 實時業務監控背景

隨著資訊科技的飛速發展，在電力、電信、金融、大型製造等各個行業ERP、CRM、SCM、OA等越來越多的IT系統得以成功實施，這些分散建設的IT系統為各部門的運營效率提升發揮了很大的作用。同時，為了滿足業務管理和決策的報表系統（包括傳統報表、資料倉庫、OLAP等）也被創建出來，企業主管通過報表瞭解企業的總體執行狀態。

但是，隨著企業間競爭的加劇和市場節奏的進一步加快，企業的日常管理需要對關鍵業務指標的更加實時的監控和反饋。比如：製造業需要更及時的倉庫排程、金融業需要更實時的風險防範、電信業需要更及時的服務指標監控。於是，越來越多的企業提出實時企業的要求，傳統的ERP等資訊系統和報表系統無法滿足這些需求。實時業務監控解決方案旨在更好支撐客戶此類需求。

總體實現架構：

2 該領域的知識的概括綜述

2.1 解決的主要問題

聯機分析處理 (OLAP) 的概念最早是由關係資料庫之父E.F.Codd於1993年提出的，他同時提出了關於OLAP的12條準則。OLAP的提出引起了很大的反響，OLAP作為一類產品同聯機事務處理 (OLTP) 明顯區分開來。

當今的資料處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關係型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是資料倉庫系統的主要應用，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。

2.2 現有主要產品

•  商業OLAP產品：

IBM Cognos：IBM Cognos 8 商業智慧系列產品在服務導向架構（SOA）的基礎上，提供可定製的全方位的商業智慧服務。使用者可以利用 IBM Cognos 8 商業智慧系列軟體對您的商業進行監控，分析和預測，而且使用者可以輕鬆的在集中控制的平臺上部署相應的服務來滿足特定的需求。這種模組化部署的架構能使使用者方便的擴充套件或者修改系統功能來滿足不同的商業智慧需求。詳細：http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0903gaoxf/

Oracle OLAP：是Oracle企業版的一個可選件，由於將OLAP引擎完全整合進了Oracle資料庫，所以，所有資料和元資料都是從Oracle資料庫內部進行儲存和管理的，以提供高度可伸縮性、強健的管理環境及工業級可用性和安全性。Oracle OLAP主要包括以下元件：

 OLAP Analytic Engine：Oracle的OLAP分析引擎是一個基於多維模型的MOLAP引擎，執行在Oracle核心中，因此擁有良好的效能。
 Analytic Workspace：分析工作區中實際儲存多維模型的資料。一個Analytic Workspace儲存為一個關係表，分析工作區中的不同物件儲存為表中的一行(LOB格式)。分析工作區甚至可以儲存在分割槽表中，以提供更好的併發效能。
 OLAP DML：OLAP DML是Analytic Workspace的原始操作語言，包括關於Analytic Workspace的資料定義語言(DDL)和資料操作語言(DML)。對於Analytic Workspace的所有操作方式，比如GUI工具，java和SQL等方式，最終都要轉化為Oracle DML語言。
 SQL Interface to OLAP：提供使用SQL操作Analytic Workspace的介面，該介面使用PL/SQL實現。
 Analytic Workspace Java API：提供使用Java操作Analytic Workspace的介面。在GUI工具Analytic Workspace Manager中使用的就是該介面。
 OLAP API：Oracle OLAP的一個Java程式設計介面，支援OracleBI Bean。除了伺服器元件，Oracle OLAP還提供了兩個客戶端工具：
 Analytic Workspace Manager：這是Oracle提供的一個操作Analytic Workspace的一個圖形工具。使用該工具可以快速的完成諸如定義資料的邏輯多維模型、建立多維資料到關係資料的對映、裝載和聚合資料等任務。
 OLAP Worksheet：OLAP Worksheet提供了操作Analytic Workspace的一個互動式環境。有點類似於Oracle資料庫的SQLPLUS工具。

MS Analytic Services：微軟的 SQL Server OLAP 服務是一個新的中間層伺服器用於線上的分析處理(OLAP)。 

OLAP 服務系統包括一個能構建用於分析的多維立體資料以及提供客戶端對這些立體資料快速訪問的強大的伺服器。 PivotTable(中樞表)服務，所含的 OLE DB 適應提供器，用於微軟的 Excel 和其他軟體銷售商的應用程式從伺服器查詢多維資料並呈遞給使用者。OLAP 服務是從資料倉庫組織資料到多維立體資料庫，這些資料資訊已預先由 OLAP 計算或彙總好，以對複雜的分析查詢提供快速的響應。關鍵特性如下：

1. 通過使用者介面和精靈，易於使用。

2. 提供了用於立體資料定義和儲存的靈活、強勁的資料模型。

3. 對“what if”情節分析的使寫(Write-enabled)立體資料支援。

4. 可伸縮的體系結構提供了多種多樣的儲存細節和對困饒傳統 OLAP 技術的“資料爆炸綜合症”的自動解決方案。

5. 集成了管理工具、安全、資料來源以及客戶／伺服器快取技術。

6. 廣泛支援的 APIs 以及開放的體系結構，用以支援各種客戶應用。

•  開源OLAP產品：

Mondrian:我們預研選型的OLAP引擎產品，http://mondrian.pentaho.org Mondrian是開源世界中最為有名的OLAP Server特點是功能強大,易學易用，被評價為“窮人最適合的OLAP產品”

JPivot : http://jpivot.sourceforge.net/ 一個OLAP的客戶端，使用XML+XSL來展現OLAP的資料，雖然我們總是說Mondrian + JPivot ，但是其實Mondrian官方都說他們是小心翼翼的分開Mondrian + JPivot的，所以你可以任意選擇OLAP Server 和 OLAP Client 的組合的，JPivot 也支援MSSQL Server的 OLAP 資料來源的.

Palo : http://www.imppalo.com/   一個MOLAP實現，已經有商業化公司運行了，產品相對成熟，如果你看過RoadMap 那一篇的話，你就應該已經知道spagoBI的roadmap裡面已經開始要支援Palo了.

JPalo : http://www.jpalo.com/  一個基於Palo的Java客戶端，基於eclipse的RCP 技術，並提供API訪問Palo的Server 。SpagoBI 在RoadMap中也計劃支援這對組合，Mondrian + JPivot 的競爭對手.

Cubulus OLAP : http://cubulus.sourceforge.net/  一個OLAP Server + Client ， Python寫的，目前支援mySQL,PostgreSQL , SQLite .看來還很不成熟。

3 OLAP引擎技術特點和常用實現方式

3.1 技術特點

OLAP技術非常多的特性，概括起來主要有如下幾點特性：OLAP技術是面向分析人員、管理人員的；OLAP技術對資料訪問通常是隻讀的，並且一次訪問大量資料；OLAP技術是面向主題的多維資料分析技術。

•  OLAP技術是面向分析人員、管理人員的
•  區別於OLTP面向操作人員，OLAP技術主要面向分析人員、管理人員，他是提供分析人員、管理人員快速又直觀的訪問資料的一種途徑。使分析人員、管理人員能直觀的從海量資料中獲得有用資訊以提供決策依據。
•  OLAP技術對資料訪問通常是隻讀的，並且一次訪問大量資料。
•  OLAP技術主要是針對海量資料的查詢，通常不對資料做修改。這種資料訪問有別於OLTP中不斷的對資料進行增刪改操作。同時這種查詢不是簡單的記錄屬性的檢索，而是為了從海量資料中獲取有用資訊的針對大量資料的查詢，通常一次需要查詢會涉及到上百萬條以上資料。
•  OLAP技術是面向主題的多維資料分析技術。

主題涉及業務流程的方方面面，是分析人員、管理人員進行決策分析所關心的角度。分析人員、管理人員使用OLAP技術，正是為了從多個角度觀察資料，從不同的主題分析資料，最終直觀的得到有效的資訊。

3.2 主要技術實現方式

OLAP系統按照其儲存器的資料儲存格式可以分為關係OLAP（RelationalOLAP，簡稱ROLAP）、多維OLAP（MultidimensionalOLAP，簡稱MOLAP）和混合型OLAP（HybridOLAP，簡稱HOLAP）三種類型。

•  ROLAP：ROLAP將分析用的多維資料儲存在關係資料庫中並根據應用的需要有選擇的定義一批實檢視作為表也儲存在關係資料庫中。不必要將每一個SQL查詢都作為實檢視儲存，只定義那些應用頻率比較高、計算工作量比較大的查詢作為實檢視。對每個針對OLAP伺服器的查詢，優先利用已經計算好的實檢視來生成查詢結果以提高查詢效率。同時用作ROLAP儲存器的RDBMS也針對OLAP作相應的優化，比如並行儲存、並行查詢、並行資料管理、基於成本的查詢優化、點陣圖索引、SQL的OLAP擴充套件(cube,rollup)等等。

•  MOLAP：MOLAP將OLAP分析所用到的多維資料物理上儲存為多維陣列的形式，形成“立方體”的結構。維的屬性值被對映成多維陣列的下標值或下標的範圍，而總結資料作為多維陣列的值儲存在陣列的單元中。由於MOLAP採用了新的儲存結構，從物理層實現起，因此又稱為物理OLAP（PhysicalOLAP）；而ROLAP主要通過一些軟體工具或中間軟體實現，物理層仍採用關係資料庫的儲存結構，因此稱為虛擬OLAP（VirtualOLAP）。

•  HOLAP：由於MOLAP和ROLAP有著各自的優點和缺點（如下表所示）,且它們的結構迥然不同，給分析人員設計OLAP結構提出了難題。為此一個新的OLAP結構——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP兩種結構的優點結合起來。迄今為止，對HOLAP還沒有一個正式的定義。但很明顯，HOLAP結構不應該是MOLAP與ROLAP結構的簡單組合，而是這兩種結構技術優點的有機結合，能滿足使用者各種複雜的分析請求。、

4 對Mondrian產品的預研和分析

4.1 產品簡介

Mondrian 是一個開源專案，是開源專案Pentaho的一部分，是一個用Java寫成的OLAP引擎。它實現了MDX語言、XML解析、JOLAP規範。它從SQL和其它資料來源讀取資料並把資料聚集在記憶體快取中，然後經過Java API用多維的方式對結果進行展示，同時可以不寫SQL就能分析儲存於SQL 資料庫的龐大資料集，可以封裝JDBC資料來源並把資料以多維的方式展現出來。

開源協議：EPL協議（商用友好的協議）

4.2 產品功能模組綜述

Mondrian專案邏輯模組分層結構圖：

上圖為整體的專案架構，圖中所示Mondrian分成了四個大部分Schema manager、Session Manager、Dimension Manager、Aggregate Manager，而實際上各個部分有著更為緊密的聯絡。對於Dimensional Layer、Star Layer和SQL Layer的劃分，更多是處於總體邏輯分層的考慮，具體在原始碼中，邏輯分層的概念比較模糊。

下面是四個Manager的簡介：

•  Session Manager：最為重要的一個部分。接受MDX查詢、解析MDX，返回結果。
•  Schema Manager：與初始化緊密相關。主要是一些重要的資料結構如快取池的構建以及多維模型的生成。
•  Aggregate Manager：實現了對聚集表的管理。主要是對OLAP快取的管理，屬於效能優化的部分。
•  Dimension Manager：維度的管理。實現多維模型中維度和關係資料庫表中列的對映，在Schema Manager也有部分功能處理這些對映。

4.3 產品特性列表

•  OLAP快取：Mondrian主要特點是對立方體進行了快取，眾所周知，快取龐大的立方體對效能有很大的影響，但是Mondrian利用java語言的特點對這一點進行了很好的控制。其次由於Mondrian基於java語言，所以它能執行在不同的平臺之上，這也是其流行的主要原因之一，例如花旗銀行就在其資料倉庫專案中用Mondrian作為它的OLAP引擎。

如上圖所示，這是由三個維度構成的一個OLAP立方體，立方體中包含了滿足條件的cell(子立方塊)值，這些cell裡面包含了要分析的資料，稱之為度量值。顯而易見，一組三維座標唯一確定了一個子立方。

多位模型的基本概念介紹：

•  立方體：由維度構建出來的多維空間，包含了所有要分析的基礎資料，所有的聚合資料操作都在立方體上進行。
•  維度：就是觀察資料的一種角度。在這個例子中，路線，源，時間都是維度，
•  這三個維度構成了一個立方體空間。維度可以理解為立方體的一個軸。要注意的是有一個特殊的維度，即度量值維度。
•  維度成員：構成維度的基本單位。對於時間維，它的成員分別是：第一季度、第二季度、第三季度、第四季度。
•  層次：維度的層次結構，要注意的是存在兩種層次：自然層次和使用者自定義層次。對於時間維而言，(年、月、日)是它的一個層次，(年、季度、月)是它的另一個層次，一個維可以有多個層次，層次可以理解為單位資料聚合的一種路徑。
•  級別：級別組成層次。對於時間維的一個層次(年、月、日)而言，年是一個級別，月是一個級別，日是一個級別，顯然這些級別是有父子關係的。
•  度量值：要分析展示的資料，即指標。如圖1中一個cell中包含了兩個度量值：裝箱數和截至時間，可以對其進行多維分析。
•  事實表：存放度量值的表，同時存放了維表的外來鍵。所有的分析用的資料最終都是來自與事實表。
•  維表：一個維度對應一個或者多個維表。一個維度對應一個維表時資料的組織方式就是採用的星型模式，對應多個維表時就是採用雪花模式。雪花模式是對星型模式的規範化。簡言之，維表是對維度的描述。
•  MDX查詢：多維模型的查詢語言MDX(MDX是微軟釋出的多維查詢語言標準),它的語法與SQL有很多相似之處：select {[Measures].[Salary]} on columns, {[Employee].[employeeId].members} on rows from CubeTest對於這條語句，COLUMNS 和 ROWS都代表查詢軸，其中COLUMNS代表列軸，ROWS代表行軸。COLUMNS又可以寫成0，ROWS又可以寫成1，當只有兩個查詢軸時，可以理解為結果的展現格式是一個平坦二維表。這條語句的含義就是查詢名字為CubeTest的立方體，列顯示Measures維度的salary，行顯示 Employee維度employeeId級別的所有成員，那麼得出的結果就是employeeId所有成員的salary，也就是所有員工的薪酬。具體語法規範和幫助文件可以參考微軟的使用者文件。

4.4 評價和分析

•  開源協議：EPL協議，是基於Eclipse的商用友好的協議，我們可以使用。協議詳細定義請參見：http://www.eclipse.org/legal/epl-v10.html
•  資料載入操作方式：Mondrian 並不像其他OLAP Server一樣會將聚合、彙總的資料儲存在磁碟中，它是直接在使用者配置好的關係資料庫中的資料上進行資料分析計算處理, 一旦讀取一塊資料,就將其儲存在快取中，這使得Mondrian的安裝、使用起來非常容易, 但這也影響了Mondrian處理海量資料時的效能。
•  效能和優化：雖然Mondrian自己不做彙總資料儲存的功能，但面對海量資料時也提供了效能優化的支援方式，如可以支援使用者為常用查詢維度基於事實表擴充套件資料聚合表，在執行查詢請求是Mondrian可以通過查詢聚合表進行查詢效能優化。下面是不同的資料量情況下Mondrian OLAP Server的效能表現和優化方案的介紹。

百萬級事實資料：按照Mondrian文件中所描述的內容可以看出，只基於作業系統環境和資料庫環境的優化，Mondrian Server在百萬行級別資料量的事實表（關係資料庫）仍能夠執行良好。當然這需要我們自己來評測和證實。

千萬級事實資料：當事實表資料立方體的資料量達到千萬行以上時，Mondrian建議採用“彙總表”或者是由資料庫支援的類似Oracle資料庫的“物化檢視”功能來優化OLAP查詢的效能。

Mondrian快取設定：由於Mondrian會將查詢過的資料快取起來，所以Mondrian建議快取的大小根據具體專案的實際情況判斷，當然是快取越大越好。

•  Mondrian生成SQL分析

MDX語句： 2011年所有員工的薪資統計

select {[Measures].[Salary]} on 0,{[Emp].[EmpID].Members} on 1 from Cube where {[Time].[2011]}

查詢生成的SQL語句:

1. select `tb_time`.`the_year` as `c0` from `tb_time` as `tb_time` where `tb_time`.`the_year` = 2011 group by `tb_time`.`the_year` order by ISNULL(`tb_time`.`the_year`), `tb_time`.`the_year` ASC

2. select `tb_employee`.`employee_id` as `c0` from `tb_employee` as `tb_employee` group by `tb_employee`.`employee_id` order by ISNULL(`tb_employee`.`employee_id`), `tb_employee`.`employee_id` ASC

3. select count(distinct `tb_employee`.`employee_id`) as `c0` from `tb_employee` as `tb_employee`

4. select `tb_time`.`the_year` as `c0`, `tb_employee`.`employee_id` as `c1`, sum(`tb_salary`.`salary`) as `m0` from `tb_time` as `tb_time`, `tb_salary` as `tb_salary`, `tb_employee` as `tb_employee` where `tb_salary`.`time_id` = `tb_time`.`time_id` and `tb_time`.`the_year` = 2011 and `tb_salary`.`employee_id` = `tb_employee`.`employee_id` group by `tb_time`.`the_year`, `tb_employee`.`employee_id`

SQL分析：Mondrian收到MDX查詢請求後，如果快取中沒有對應的內容，則會生產上面的SQL從資料庫載入資料，然後再加入快取中，這樣的場景也是我們做實時監控是最常遇到的場景。如上面的簡單例子，Mondrian所生成的SQL語句同我們期望的基本一致。就Mondrian生成的SQL語句本身不會有效能瓶頸，這樣也使我們可以著力於其他方面的設計和優化。

•  Mondrian快取控制

為了提高海量資料下的查詢響應速度，Mondrian自動將首次查詢的結果快取到記憶體中，之後的查詢如果命中快取內容，則不再訪問資料庫。這種實現方式有點自不必說，但是在實現實時OLAP時會存在問題，實時OLAP中資料變化頻繁導致快取中的資料不是最新的。

快取控制介面：為了做到不重啟OLAP Server也能更新快取，Mondrian提供了一系列的重新整理快取的介面，支援指定清除指定schema的元資料快取、查詢結果快取；清除動作可以是全部清除 也可以是 部分清除（可以指定清除某個維度下某級別成員的相關內容）。

資料變化監聽： Mondrian提供了快取控制介面（被動響應），但對於實現我們的目標“實時OLAP”來說我們就需要自己實現一個數據變更監聽的模組，來監聽資料變化，一旦資料有變化就發起變更事件，更新Mondrian引擎的快取。

目前初步考慮實現方案為ETL工具在資料處理結束後通知OLAP引擎。引擎收到資料變更通知後做清理快取的動作。

5 相關開源產品整合說明

5.1 依賴的JAR包

•  Mondrian示例測試需要的最少JAR列表:

commons-dbcp-1.2.1.jar

commons-logging-1.0.4.jar

commons-pool-1.2.jar

dom4j.jar

log4j-1.2.8.jar

mondrian.jar

olap4j.jar

commons-math-1.0.jar

commons-collections-3.1.jar

commons-beanutils-1.6.jar

commons-vfs-1.0.jar

eigenbase-xom.jar

eigenbase-properties.jar

eigenbase-resgen.jar

javacup.jar

•  擴充套件功能引入JAR:

mysql-connector-java-3.1.12-bin.jar

xstream-1.2.2.jar