OLAP聯機分析處理介紹

　　聯機分析處理 (olap) 的概念最早是由關系資料庫之父e.f.codd于1993年提出的，他同時提出了關于olap的12條準則。olap的提出引起了很大的反響，olap作為一類産品同聯機事務處理 (oltp) 明顯區分開來。

　　codd提出olap的12條準則來描述olap系統：

　　準則1 olap模型必須提供多元概念視圖

　　準則2 透明性準則

　　準則3 存取能力準則

　　準則4 穩定的報表能力

　　準則5 客戶/伺服器體系結構

　　準則6 維的等同性準則

　　準則7 動态的稀疏矩陣處理準則

　　準則8 多使用者支援能力準則

　　準則9 非受限的跨維操作

　　準則10 直覺的資料操縱

　　準則11 靈活的報表生成

　　準則12 不受限的維與聚集層次

oltp

olap

使用者

操作人員，低層管理人員

決策人員，進階管理人員

功能

日常操作處理

分析決策

db 設計

面向應用

面向主題

資料

目前的， 最新的細節的， 二維的分立的

曆史的， 聚集的， 多元的內建的， 統一的

存取

讀/寫數十條記錄

讀上百萬條記錄

工作機關

簡單的事務

複雜的查詢

db 大小

100mb-gb

100gb-tb

　　在過去的二十年中，大量的企業利用關系型資料庫來存儲和管理業務資料，并建立相應的應用系統來支援日常業務運作。這種應用以支援業務處理為主要目的，被稱為聯機事務處理(oltp，on-line transaction processing)應用，它所存儲的資料被稱為操作資料或者業務資料。

　　随着市場競争的日趨激烈，企業更加強調決策的及時性和準确性，這使得以支援決策管理分析為主要目的的應用迅速崛起，這類應用被稱為聯機分析處理，它所存儲的資料被稱為資訊資料。

　　聯機分析處理的使用者是企業中的專業分析人員及管理決策人員，他們在分析業務經營的資料時，從不同的角度來審視業務的衡量名額是一種很自然的思考模式。例如分析銷售資料，可能會綜合時間周期、産品類别、分銷管道、地理分布、客戶群類等多種因素來考量。這些分析角度雖然可以通過報表來反映，但每一個分析的角度可以生成一張報表，各個分析角度的不同組合又可以生成不同的報表，使得it人員的工作量相當大，而且往往難以跟上管理決策人員思考的步伐。

　　事實上，随着資料倉庫理論的發展，資料倉庫系統已逐漸成為新型的決策管理資訊系統的解決方案。資料倉庫系統的核心是聯機分析處理，但資料倉庫包括更為廣泛的内容。

　　-概括來說，資料倉庫系統是指具有綜合企業資料的能力，能夠對大量企業資料進行快速和準确分析，輔助做出更好的商業決策的系統。它本身包括三部分内容：

　　1、資料層：實作對企業操作資料的抽取、轉換、清洗和彙總，形成資訊資料，并存儲在企業級的中心資訊資料庫中。

　　2、應用層：通過聯機分析處理，甚至是資料挖掘等應用處理，實作對資訊資料的分析。

　　3、表現層：通過前台分析工具，将查詢報表、統計分析、多元聯機分析和資料發掘的結論展現在使用者面前。

　　從應用角度來說，資料倉庫系統除了聯機分析處理外，還可以采用傳統的報表，或者采用數理統計和人工智能等資料挖掘手段，涵蓋的範圍更廣；就應用範圍而言，聯機分析處理往往根據使用者分析的主題進行應用分割，例如：銷售分析、市場推廣分析、客戶利潤率分析等等，每一個分析的主題形成一個olap應用，而所有的olap應用實際上隻是資料倉庫系統的一部分。

　　olap展現在使用者面前的是一幅幅多元視圖。維（dimension）：是人們觀察資料的特定角度，是考慮問題時的一類屬性，屬性集合構成一個維（時間維、地理維等）。

　　維的層次（level）：人們觀察資料的某個特定角度（即某個維）還可以存在細節程度不同的各個描述方面（時間維：日期、月份、季度、年）。

　　維的成員（member）：維的一個取值，是資料項在某維中位置的描述。（“某年某月某日”是在時間維上位置的描述）。

　　度量（measure）：多元數組的取值。（2000年1月，上海，筆記本電腦，0000）。

　　olap的基本多元分析操作有鑽取（drill-up和drill-down）、切片（slice）和切塊（dice）、以及旋轉（pivot）等。

　　切片和切塊：是在一部分維上標明值後，關心度量資料在剩餘維上的分布。如果剩餘的維隻有兩個，則是切片；如果有三個或以上，則是切塊。

　　旋轉：是變換維的方向，即在表格中重新安排維的放置（例如行列互換）。

　　資料倉庫與olap的關系是互補的，現代olap系統一般以資料倉庫作為基礎，即從資料倉庫中抽取詳細資料的一個子集并經過必要的聚集存儲到olap存儲器中供前端分析工具讀取。典型的olap系統體系結構如下圖所示：

　　olap系統按照其存儲器的資料存儲格式可以分為關系olap（relationalolap，簡稱rolap）、多元olap（multidimensionalolap，簡稱molap）和混合型olap（hybridolap，簡稱holap）三種類型。

　　molap将olap分析所用到的多元資料實體上存儲為多元數組的形式，形成“立方體”的結構。維的屬性值被映射成多元數組的下标值或下标的範圍，而總結資料作為多元數組的值存儲在數組的單元中。由于molap采用了新的存儲結構，從實體層實作起，是以又稱為實體olap（physicalolap）；而rolap主要通過一些軟體工具或中間軟體實作，實體層仍采用關系資料庫的存儲結構，是以稱為虛拟olap（virtualolap）。

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

　　rolap molap

　　沿用現有的關系資料庫的技術

　　專為olap所設計

　　響應速度比molap慢；

　　現有關系型資料庫已經對olap做了很多優化，包括并行存儲、并行查詢、并行資料管理、基于成本的查詢優化、位圖索引、sql 的olap擴充(cube,rollup)等，性能有所提高

　　性能好、響應速度快

　　資料裝載速度快

　　資料裝載速度慢

　　存儲空間耗費小，維數沒有限制

　　需要進行預計算,可能導緻資料爆炸，維數有限；無法支援維的動态變化

　　借用rdbms存儲資料，沒有檔案大小限制

　　受作業系統平台中檔案大小的限制，難以達到tb 級(隻能10~20g)

　　可以通過sql實作詳細資料與概要資料的存儲

　　缺乏資料模型和資料通路的标準

　　–不支援有關預計算的讀寫操作

　　–sql無法完成部分計算

　　–無法完成多行的計算

　　–無法完成維之間的計算

　　–支援高性能的決策支援計算

　　–複雜的跨維計算

　　–多使用者的讀寫操作

　　–行級的計算

　　維護困難

　　管理簡便

　　同樣是仿照使用者的多角度思考模式，聯機分析處理有三種不同的實作方法：

　　· 關系型聯機分析處理(rolap,relational olap)

　　· 多元聯機分析處理(molap,multi-dimensional olap)

　　· 前端展示聯機分析處理(desktop olap)

　　其中，前端展示聯機分析需要将所有資料下載下傳到客戶機上，然後在客戶機上進行資料結構/報表格式重組，使使用者能在本機實作動态分析。該方式比較靈活，然而它能夠支援的資料量非常有限，嚴重地影響了使用的範圍和效率。是以，随着時間的推移，這種方式已退居次要地位，在此不作讨論。

　　以下就rolap和molap的具體實施方法進行讨論：

　　顧名思義，關系型聯機分析處理是以關系型資料庫為基礎的。唯一特别之處在于聯機分析進行中的資料結構組織的方式。

　　讓我們考察一個例子，假設我們要進行産品銷售的财務分析，分析的角度包括時間、産品類别、市場分布、實際發生與預算四方面内容，分析的财務名額包括：銷售額、銷售支出、毛利(=銷售額-銷售支出)、費用、純利(=毛利-費用)等内容，則我們可以建立如下的資料結構：

　　該資料結構的中心是主表，裡面包含了所有分析次元的外鍵，以及所有的财務名額，可計算推導的财務名額不計在内，我們稱之為事實表(fact table)。周圍的表分别是對應于各個分析角度的維表(dimension table)，每個維表除了主鍵以外，還包含了描述和分類資訊。無論原來的業務資料的資料結構為何，隻要原業務資料能夠整理成為以上模式，則無論業務人員據此提出任何問題，都可以用sql語句進行表連接配接或彙總(table join and group by)實作資料查詢和解答。（當然，有一些現成的rolap前端分析工具是可以自動根據以上模型生成sql語句的）。這種模式被稱為星型模式(star-schema)，可應用于不同的聯機分析處理應用中。

　　以下是另一個采用星型模式的例子，分析的角度和名額截然不同，但資料結構模式一樣。我們看到的不是表的資料，而是表的結構。在聯機分析處理的資料模型設計中，這種表達方式更為常見：

　　有時候，維表的定義會變得複雜，例如對産品維，既要按産品種類進行劃分，對某些特殊商品，又要另外進行品牌劃分，商品品牌和産品種類劃分方法并不一樣。是以，單張維表不是理想的解決方案，可以采用以下方式，這種資料模型實際上是星型結構的拓展，我們稱之為雪花型模式(snow-flake schema).

　　無論采用星型模式還是雪花型模式，關系型聯機分析處理都具有以下特點：

　　· 資料結構群組織模式需要預先設計和建立；

　　· 資料查詢需要進行表連接配接，在查詢性能測試中往往是影響速度的關鍵；

　　· 資料彙總查詢（例如查詢某個品牌的所有産品銷售額），需要進行group by 操作，雖然實際得出的資料量很少，但查詢時間變得更長；

　　· 為了改善資料彙總查詢的性能，可以建立彙總表，但彙總表的數量與使用者分析的角度數目和每個角度的層次數目密切相關。例如，使用者從8個角度進行分析，每個角度有3個彙總層次，則彙總表的數目高達3的8次方。

　　可以采取對常用彙總資料建立彙總表，對不常用的彙總資料進行group by 操作，這樣來取得性能和管理複雜度之間的均衡。

　　多元聯機分析處理實際上是用多元數組的方式對關系型資料表進行處理。下圖是rolap與molap的對比：

　　圖中左邊是rolap方式，右邊是molap方式，兩者對應的是同一個三維模型。molap首先對事實表中的所有外鍵進行排序，并将排序後的具體名額數值一一寫進虛拟的多元立方體中。當然，虛拟的多元立方體隻是為了便于了解而構想的，molap實際的資料存儲放在資料檔案(data file)中，其資料放置的順序與虛拟的多元立方體按x,y,z坐标展開的順序是一緻的(如上圖)。同時，為了資料查找的友善，molap需要預先建立次元的索引，這個索引被放置在molap的概要檔案(outline)中。

　　一旦概要檔案定義好，molap系統可以自動安排資料存儲的方式和進行資料查詢。從molap的資料檔案與rolap的事實表的對比可以看出，molap的資料檔案完全不需要紀錄次元的外鍵，在次元比較多的情況下，這種資料存儲方式大量地節省了空間。

　　但是，如果資料相當稀疏，虛拟的多元立方體中很多數值為空時，molap的資料檔案需要對相關的位置留白，而rolap的事實表卻不會存儲這些紀錄。為了有效地解決這種情況，molap采用了稀疏維和密集維相結合的處理方式，如下圖。

　　上圖的背景是某些客戶隻通過某些分銷管道才購買，但是隻要該客戶存在，他在各個月和各個地區内均有消費(例如，華南ibm隻通過熊貓國旅定購南航機票，但在華南四省在每個月均有機票訂購)。則時間和地區維是密集維，客戶和分銷管道是稀疏維，molap将稀疏維建成索引檔案(index file)，密集維所對應的數值仍然保留在資料檔案中，索引檔案不存儲空紀錄。這樣保持了對空間的合理利用。我們也可以看到，如果所有維都是稀疏維，則molap的索引檔案就退化成rolap的事實表， 兩者沒有差別了。

　　在實際應用中，不可能所有分析的次元都是密集的，也絕少存在所有分析的次元都是稀疏的，是以稀疏維和密集維并用的模式幾乎主導了所有的molap應用。而稀疏維和密集維的定義全部集中在概要檔案中，是以，隻要預先定義好概要檔案，所有的資料分布就自動确定了。

　　在這種模式中，密集維的組合組成了的資料塊(data block)，每個資料塊是i/o讀寫的基礎機關(如上圖)，所有的資料塊組成了資料檔案。稀疏維的組合組成了索引檔案，索引檔案的每一個資料紀錄的末尾都帶有一個指針，指向要讀寫的資料塊。是以，進行資料查詢時，系統先搜尋索引檔案紀錄，然後直接調用指針指向的資料塊進行i/o讀寫(如果該資料塊尚未駐留記憶體)，将相應資料塊調入記憶體後，根據密集維的資料放置順序直接計算出要查詢的資料距離資料塊頭的偏移量，直接提取資料下傳到用戶端。是以，molap 方式基本上是索引搜尋與直接尋址的查詢方式相結合，比起rolap的表/索引搜尋和表連接配接方式，速度要快得多。

　　特點

　　· 需要預先定義概要檔案；

　　· 資料查詢采用索引搜尋與直接尋址的方式相結合，不需要進行表連接配接，在查詢性能測試中比起rolap有相當大的優勢；

　　· 在進行資料彙總查詢之前，molap需要預先按概要檔案中定義的資料彙總關系進行計算，這個計算通常以批處理方式運作。計算結果回存在資料檔案中，當使用者查詢時，直接調用計算結果，速度非常快。

　　· 無論是資料彙總還是計算衍生資料，預先計算的方式實際上是用空間來換時間。當然，使用者也可以選擇動态計算的方式，用查詢時間來換取存儲空間。molap可以靈活調整時空的取舍平衡。

　　· 使用者難以使用概要檔案中沒有定義的資料彙總關系和衍生名額。

　　· 在大資料量環境下，關系型資料庫可以達到tb級的資料量，現有的molap應用局限于基于檔案系統的處理和查詢方式，其性能會在100gb級别開始下降，需要進行資料分區處理，是以擴充性不如rolap。是以，molap多數用于部門級的主題分析應用。

　　聯機分析處理其他要素包括假設分析(what-if)，複雜計算，資料評估等等。這些因素對使用者的分析效用至關重要，但是與rolap和molap的核心工作原理的不一定有很緊密的關系，事實上，rolap和molap都可以在以上三方面有所建樹，隻不過實作的方法迥異。是以，這些因素更取決于各個廠商為他們的産品提供的外延功能。對于像ibm的db2 olap server這樣一個成熟的産品來說，這三方面均有獨特的優勢：

　　假設分析提出了類似于以下的問題："如果産品降價5%，而運費增加8%，對不同地區的分銷商的進貨成本會有什麼影響？"這些問題常用于銷售預測、費用預算配置設定、獎金制度确定等等。據此，使用者可以分析出哪些角度、哪些因素的變化将對企業産生重要影響；并且，使用者可以靈活調節自己手中掌握的資源(例如費用預算等)，将它用到最有效的地方中去。

　　分析人員往往需要分析複雜的衍生資料，諸如：同期對比、期初/期末餘額、百分比份額計算、資源配置設定(按從頂向下的結構圖逐級配置設定)、移動平均、均方差等等。對這些要求，db2 olap server提供豐富的功能函數以便使用者使用。因為隻有在無需程式設計的環境下，商業使用者才能更好地靈活利用這些功能進行複雜的真實世界模拟。

　　資料評估包括兩方面内容，有效性評估和商業意義評估。在有效性評估方面，資料抽取、清洗和轉換的規則的定義是至關重要的。而合理的資料模型設計能有效防止無效資料的進入。例如在rolap中，如果維表沒有采用範式設計(normalise design)，可能會接受如下的維表：

　　機構代碼 機構名稱 所屬區縣 所屬城市 所屬省份

　　001 越秀支行 越秀區 廣州 廣東

　　002 祖廟支行 佛山 廣州 廣東

　　003 翠屏支行 佛山 南海 廣東

　　004 。。。 。。。 。。。 。。。

　　顯然，002中顯示的佛山屬于廣州市，與003中顯示的佛山屬于南海市是沖突的。這顯示出資料源有問題，但是如果采用星型模式設計，rolap無法自動發現資料源的問題！

　　在類似情況下，molap的表現稍占優勢。因為molap需要預先定義概要檔案，而概要檔案會詳細分析次元的層次關系，是以生成概要檔案時會反映資料源的錯誤。是以，在db2 olap server中，記錄003會被拒收，并紀錄在出錯日志中，供it人員更正。

　　但是，olap對資料源有效性的驗證能力畢竟是有限的，是以，資料有效性必須從源資料一級和資料抽取/清洗/轉換處理一級來進行保障。

　　對使用者而言，資料的商業含義評估更有意義。在商業活動中，名額數值的取值範圍是比較穩定的，如果名額數值突然發生變化，或者在同期比較、同類比較中有特殊表現，意味着該名額代表的方方面面具有特别的分析意義。普通的olap往往需要使用者自己去觀察發現異常名額，而db2 olap server的olap minor(多元資料挖掘功能)能為使用者特别地指出哪些條件下的哪些名額偏離常值，進而引起使用者的注意和思考。例如：12月份南部的聖誕禮品銷售額不到同期類似區域（東部、中部、西部）的50%。