聯(lián)機(jī)分析處理

　　聯(lián)機(jī)分析處理OLAP是一種軟件技術(shù)，它使分析人員能夠迅速、一致、交互地從各個方面觀察信息，以達(dá)到深入理解數(shù)據(jù)的目的。它具有FASMI（Fast Analysis of Shared Multidimensional Information），即共享多維信息的快速分析的特征。其中F是快速性（Fast），指系統(tǒng)能在數(shù)秒內(nèi)對用戶的多數(shù)分析要求做出反應(yīng)；A是可分析性（Analysis），指用戶無需編程就可以定義新的專門計算，將其作為分析的一部 分，并以用戶所希望的方式給出報告；M是多維性（Multi—dimensional），指提供對數(shù)據(jù)分析的多維視圖和分析；I是信息性（Information），指能及時獲得信息，并且管理大容量信息。

　　數(shù)據(jù)倉庫和聯(lián)機(jī)分析處理（OLAP）是決策支持基本要素，已經(jīng)日益成為數(shù)據(jù)庫行業(yè)的重點。許多商業(yè)產(chǎn)品和服務(wù)現(xiàn)已推出，并且所有主要的數(shù)據(jù)庫管理系統(tǒng)供應(yīng)商現(xiàn)在已經(jīng)在這些領(lǐng)域提供產(chǎn)品。決策支持，相比于傳統(tǒng)的聯(lián)機(jī)事務(wù)處理應(yīng)用程序，會有些不同的要求數(shù)據(jù)庫技術(shù)。本文提供的數(shù)據(jù)概述數(shù)據(jù)倉庫和OLAP技術(shù)，著眼于他們的新的要求。我們描述后端工具來提取，清潔和數(shù)據(jù)加載到數(shù)據(jù)倉庫;典型OLAP的多維數(shù)據(jù)模型;前端客戶端工具用于查詢和數(shù)據(jù)分析;服務(wù)器擴(kuò)展來高效的查詢處理;用來管理元數(shù)據(jù)和倉庫工具。此外，勘測技術(shù)現(xiàn)狀，本文還指出了一些有前景的研究問題，其中一些涉及數(shù)據(jù)庫研究界合作多年的研究的問題，但其他一些問題只是剛剛開始被解決。本概述是基于一個教程，有作者們在會議VLDB 1996年提出。

　　1. 介紹

　　數(shù)據(jù)倉庫是決策支持技術(shù)的集合，旨在使知識工作者（總裁，經(jīng)理，分析師）做出更快更好的決策。過去三年已經(jīng)看到的爆炸性的增長，無論是在所提供的產(chǎn)品和服務(wù)的數(shù)量，還是在采用這些技術(shù)的工業(yè)領(lǐng)域。按照META集團(tuán)說法，數(shù)據(jù)倉庫市場，包括硬件，數(shù)據(jù)庫軟件和工具，預(yù)計是由1995年的20億美金增長到1998年分80億美金。數(shù)據(jù)倉庫技術(shù)已經(jīng)成功部署在許多行業(yè)：制造業(yè)（訂單運輸和客戶支持），零售（用于用戶分析和庫存管理），金融服務(wù)（理賠分析，風(fēng)險分析，信用卡分析和欺詐檢測），交通（車隊管理），電信（呼叫分析和欺詐檢測），公用事業(yè)（電力使用分析）和醫(yī)療保?。▽τ诮Y(jié)果的分析）。本文介紹了數(shù)據(jù)倉庫技術(shù)的路線圖，著重于有特殊需求的數(shù)據(jù)倉庫數(shù)據(jù)庫管理系統(tǒng)（DBMS）。

　　數(shù)據(jù)倉庫是一個“面向主題的，集成的，隨時間變化的，非易失性的，主要用于組織決策的數(shù)據(jù)集合。 ”通常情況下，數(shù)據(jù)倉庫用來分別維護(hù)組織的不同業(yè)務(wù)的數(shù)據(jù)庫。有很多原因來這么做。數(shù)據(jù)倉庫支持在線分析處理（OLAP ），它的功能和性能要求完全不同于由業(yè)務(wù)數(shù)據(jù)庫所支持的聯(lián)機(jī)事務(wù)處理（ OLTP）應(yīng)用程序。

　　OLTP應(yīng)用程序通常使得文書數(shù)據(jù)處理任務(wù)自動化，如訂單錄入和銀行交易等一些組織的日常運作。這些任務(wù)是結(jié)構(gòu)化和重復(fù)性，以及由短的，原子，孤立的交易。該交易需要詳細(xì)，最新的數(shù)據(jù)，通常通常訪問他們的主鍵來讀取或更新少數(shù)（幾十）記錄。操作數(shù)據(jù)庫往往是百兆到千兆字節(jié)。數(shù)據(jù)庫的一致性和可恢復(fù)性是至關(guān)重要的，最大化事務(wù)吞吐量是關(guān)鍵性能指標(biāo)。因此，數(shù)據(jù)庫被設(shè)計為反映已知的應(yīng)用，特別是的操作語義，以盡量減少并發(fā)沖突。

　　數(shù)據(jù)倉庫，相反的，是有針對性的決策支持。歷史，總結(jié)和整合的數(shù)據(jù)比詳細(xì)的，個人記錄更重要。由于數(shù)據(jù)倉庫包含合并數(shù)據(jù)，或許可以從幾個業(yè)務(wù)數(shù)據(jù)庫，在一段時間可能很長的時期，他們往往要比業(yè)務(wù)數(shù)據(jù)庫較大的訂單;企業(yè)數(shù)據(jù)倉庫預(yù)計為數(shù)百GB到TB級大小。工作負(fù)載大多是查詢密集型與臨時性的，復(fù)雜查詢可以訪問數(shù)以百萬計的記錄，并進(jìn)行了大量的掃描，聯(lián)接和聚合。查詢吞吐量和響應(yīng)時間比事務(wù)吞吐量更重要。

　　促進(jìn)復(fù)雜的分析和可視化、數(shù)據(jù)倉庫通常多維建模。例如，在一個銷售數(shù)據(jù)倉庫，銷售，銷售區(qū)域、銷售人員和產(chǎn)品可能是一些感興趣的維度。通常，這些維度是分層次的;銷售時間可能是組織為day-month-quarter-year的層次結(jié)構(gòu)，產(chǎn)品作為product-category-industry的層次結(jié)構(gòu)。典型的OLAP操作包括上鉆（增加聚合的水平）和下鉆（減少聚合的水平或增加細(xì)節(jié)）以及一個或多個維度層次結(jié)構(gòu)切割（選擇和投影），軸轉(zhuǎn)（調(diào)整的多維視圖的數(shù)據(jù)）。

　　由于已有的業(yè)務(wù)數(shù)據(jù)庫已經(jīng)很好的支持已知的OLTP工作負(fù)載，所以試圖對業(yè)務(wù)數(shù)據(jù)庫執(zhí)行復(fù)雜的OLAP查詢，將導(dǎo)致不可接受的性能。此外，決策支持需求的數(shù)據(jù)可能從業(yè)務(wù)數(shù)據(jù)庫中丟失;例如，了解趨勢或進(jìn)行預(yù)測所需要歷史數(shù)據(jù)，而業(yè)務(wù)數(shù)據(jù)庫只存儲當(dāng)前的數(shù)據(jù)。決策支持一般需要從多個不同來源的數(shù)據(jù)進(jìn)行整合：這可能包括外部資源，如股票的市場反饋需要額外的幾個業(yè)務(wù)數(shù)據(jù)庫。不同的來源可能含有不同質(zhì)量的數(shù)據(jù)，或使用不一致的陳述，代碼和格式，需要協(xié)調(diào)。最后，支持多維數(shù)據(jù)模型和操作的典型OLAP需要特殊的數(shù)據(jù)組織，訪問方式和實現(xiàn)方法，不是如一般的商業(yè)數(shù)據(jù)庫管理系統(tǒng)用來針對OLTP。由于這些原因，數(shù)據(jù)倉庫的實現(xiàn)有別于業(yè)務(wù)數(shù)據(jù)庫。

　　數(shù)據(jù)倉庫可能會實施在標(biāo)準(zhǔn)的或擴(kuò)展的關(guān)系DBMS 上，就是所謂關(guān)系型OLAP（ROLAP ）服務(wù)器。這些服務(wù)器假設(shè)數(shù)據(jù)存儲在關(guān)系數(shù)據(jù)庫，并且支持?jǐn)U展SQL和特殊訪問及實施方法來有效實現(xiàn)多維數(shù)據(jù)模型和操作。相比之下，多維OLAP （ MOLAP）服務(wù)器直接把多維數(shù)據(jù)存儲在特定的數(shù)據(jù)結(jié)構(gòu)（例如，數(shù)組），并實現(xiàn)了OLAP在這些特點的數(shù)據(jù)結(jié)構(gòu)的操作。

　　這不僅僅是建設(shè)和維護(hù)一個數(shù)據(jù)倉庫，還需要選擇一個OLAP服務(wù)器并為倉庫明確模式和一些復(fù)雜的查詢。存在著不同結(jié)構(gòu)的替代品。許多組織希望實施綜合性企業(yè)的倉庫，收集跨越整個組織的所有科目（例如，客戶，產(chǎn)品信息，銷售，資產(chǎn)，人員）。然而，構(gòu)建企業(yè)級數(shù)據(jù)倉庫是一個漫長而復(fù)雜的過程，需要廣泛的業(yè)務(wù)建模，可能需要多年才能成功。相反的，一些組織滿足于數(shù)據(jù)集市，它是針對選定的科目的子集（例如，營銷數(shù)據(jù)可能包括客戶，產(chǎn)品和銷售信息） 。這些數(shù)據(jù)集市實現(xiàn)更快的推算，因為它們不需要企業(yè)廣泛的共識，但如果一個完整的商業(yè)模式并不發(fā)達(dá)的話，從長遠(yuǎn)來看，它們可能會導(dǎo)致復(fù)雜的集成問題。

　　在第2節(jié)，我們描述了一個典型的數(shù)據(jù)倉庫體系結(jié)構(gòu)，和設(shè)計和操作數(shù)據(jù)倉庫的過程。在3-7節(jié)，我們回顧了在數(shù)據(jù)加載相關(guān)技術(shù)和刷新數(shù)據(jù)倉庫，倉庫服務(wù)器，前端工具和倉庫管理工具。在每一種情況下，我們指出什么是傳統(tǒng)的數(shù)據(jù)庫技術(shù)不同的，我們會提到有代表性的產(chǎn)品。在本文中，我們不打算提供每個類別的所有產(chǎn)品的綜合描述。我們鼓勵有興趣的讀者看看在最近的商業(yè)雜志，如Databased Advisor， Database Programming，Design， Datamation，DBMS Magazine， vendors’ Web sites來獲取商業(yè)產(chǎn)品，白皮書和案例研究的更多細(xì)節(jié)。OLAP Council是在整個行業(yè)的標(biāo)準(zhǔn)化工作上一個很好的信息源。還有科德等人的論文定義了OLAP產(chǎn)品的12條規(guī)則。還有，Data Warehousing Information Center是數(shù)據(jù)倉庫和OLAP良好的資源。

　　數(shù)據(jù)倉庫的研究是相當(dāng)新的，并一直專注的主要是查詢處理和視圖維護(hù)問題。還有很多開放性的研究問題，在第8節(jié)，我們會簡要提及的這些問題并得出結(jié)論。

　　2. 架構(gòu)與端到端流程

　　圖1是一個典型的數(shù)據(jù)倉庫架構(gòu)。

　　它包括一些工具。這些工具可以用來從多種操作數(shù)據(jù)庫和外部源中提取數(shù)據(jù)，并清洗、轉(zhuǎn)換和整合這些數(shù)據(jù)，然后把數(shù)據(jù)加載到數(shù)據(jù)倉庫;定期刷新倉庫來更新的源和清除倉庫的數(shù)據(jù)，或者是慢歸檔存儲。除了主倉庫，可能會有好幾個部門數(shù)據(jù)集市。存儲在數(shù)據(jù)倉庫和數(shù)據(jù)集市的數(shù)據(jù)，由一個或多個倉庫服務(wù)器管理，并呈現(xiàn)數(shù)據(jù)的多維視圖給不同的前端工具，如：查詢工具、報告作者、分析工具和數(shù)據(jù)挖掘工具。最后，還有一個存儲庫，用于存儲和管理元數(shù)據(jù)，并為監(jiān)測和管理倉儲系統(tǒng)。

　　倉庫可能被設(shè)計成分布式，以來得到負(fù)載均衡，可伸縮性和高可用性。在這樣一個分布式體系結(jié)構(gòu)，元數(shù)據(jù)存儲庫通常是在每個節(jié)點的倉庫都進(jìn)行備份的，整個倉庫集中管理的。另一個體系結(jié)構(gòu)，是倉庫或數(shù)據(jù)集市的聯(lián)合，每個倉庫或者數(shù)據(jù)集市都有自己的貯存和分級管理。該設(shè)計實現(xiàn)力求使用方便，所以可能花費過于昂貴的代價來構(gòu)造一個邏輯集成的企業(yè)倉庫。

　　設(shè)計和推出一個數(shù)據(jù)倉庫是一個復(fù)雜的過程，包括以下活動：

　　定義體系結(jié)構(gòu)，容量規(guī)劃，并選擇存儲服務(wù)器、數(shù)據(jù)庫和OLAP服務(wù)器和工具。

　　整合服務(wù)器、存儲和客戶端工具。

　　設(shè)計倉庫表和視圖。

　　定義物理倉庫組織，數(shù)據(jù)布局、分區(qū)和訪問方法。

　　使用網(wǎng)關(guān)、ODBC驅(qū)動程序，或其他的包裝器連接數(shù)據(jù)源，。

　　設(shè)計和實現(xiàn)數(shù)據(jù)提取、清洗、轉(zhuǎn)換、加載和刷新的腳本。

　　貯存表和視圖的定義、腳本和其他元數(shù)據(jù)。

　　設(shè)計和實現(xiàn)終端用戶應(yīng)用程序。

　　推出倉庫和應(yīng)用程序。

　　3. 后端工具和實用程序

　　數(shù)據(jù)倉庫系統(tǒng)使用各種數(shù)據(jù)提取和清洗工具，錄入倉庫的加載和更新的實用程序。通常外來源的數(shù)據(jù)提取的實現(xiàn)需要通過網(wǎng)關(guān)和標(biāo)準(zhǔn)接口（如Information Builders EDA/SQL， ODBC， Oracle Open Connect， Sybase Enterprise Connect， Informix Enterprise Gateway）。

　　數(shù)據(jù)清洗

　　由于數(shù)據(jù)倉庫是用于決策，數(shù)據(jù)倉庫中的數(shù)據(jù)正確性的非常重要的。然而，因為大量的數(shù)據(jù)來自多個參與的數(shù)據(jù)源，數(shù)據(jù)中出現(xiàn)錯誤和異常的概率很高。因此，幫助檢測數(shù)據(jù)的異常和對其改正的工具，可以帶來很高高效益。在一些情況下，數(shù)據(jù)清洗顯得非常有必要：字段長度不一致，不一致的描述，不一致的價值分配，缺失的條目和違背完整性約束。可想而知，數(shù)據(jù)錄入表中的可選字段是不一致數(shù)據(jù)的重要來源。

　　有三個相關(guān)，但不同的類數(shù)據(jù)清理工具。數(shù)據(jù)遷移工具可以制定簡單轉(zhuǎn)換規(guī)則，例如，用性別種類來替換性別字符串。Prism的Warehouse Manager是這種類型的工具中比較流行的一個。數(shù)據(jù)清理工具使用特定領(lǐng)域的知識（如郵政地址）來對數(shù)據(jù)進(jìn)行清理。他們經(jīng)常利用解析和模糊匹配技術(shù)來完成來著多個源的清洗。一些工具可以指定源的“相對清洗”。 Integrity和Trillum等工具屬于此類。數(shù)據(jù)審計工具可以通過掃描數(shù)據(jù)從而發(fā)現(xiàn)規(guī)則和關(guān)系（或提醒違背了規(guī)定的規(guī)則）。因此，這樣的工具可以認(rèn)為是數(shù)據(jù)挖掘工具的變體。這樣的工具可能會發(fā)現(xiàn)一個可疑的樣本（基于統(tǒng)計分析），例如，某汽車經(jīng)銷商從未收到任何投訴。

　　加載

　　提取、清洗和轉(zhuǎn)換后，數(shù)據(jù)必須被加載到倉庫。額外的預(yù)處理可能仍然被需要：檢查完整性約束;排序;通過總結(jié)、聚合和其他計算來建立存儲在倉庫中的派生表;創(chuàng)建目錄和其他訪問路徑;分區(qū)實現(xiàn)多個目標(biāo)存儲區(qū)域。通常情況下，批量裝載工具可以用來做這件事。除了填充倉庫，一個負(fù)載工具必須允許系統(tǒng)管理員監(jiān)控狀態(tài)，取消、掛起和恢復(fù)一個負(fù)載，失敗后重啟而沒有損失數(shù)據(jù)的完整性。

　　數(shù)據(jù)倉庫的加載工具必須處理比操作數(shù)據(jù)庫更大規(guī)模的數(shù)據(jù)量。只有一個小時間窗口中（通常在晚上），倉庫可以離線刷新它。連續(xù)加載會花費很長的時間，例如。，可以加載TB級的數(shù)據(jù)會花幾周和幾個月時間！因此，通常需要利用管線式和分區(qū)式的并行性。進(jìn)行一個滿載的優(yōu)勢在于它可以被視為一個長的批處理事務(wù)，來建立一個新的數(shù)據(jù)庫。雖然在運行中，但是當(dāng)前數(shù)據(jù)庫仍然可以支持查詢;當(dāng)負(fù)載事務(wù)提交時，當(dāng)前數(shù)據(jù)庫被新的數(shù)據(jù)庫所取代。使用周期檢查點保證，如果加載過程中發(fā)生了失敗，這個進(jìn)程可以從上個檢查點重啟。

　　然而，即使使用并行性，一個滿載可能仍然需要太長的時間。大多數(shù)商業(yè)工具（如，RedBrick Table Management Utility）在刷新過程中使用增量加載，來降低必須被納入倉庫的數(shù)據(jù)規(guī)模。只插入更新的元組。然而，這樣的加載過程更加難以管理了。增量加載會與正在進(jìn)行的查詢起沖突，所以它被作為一個短事務(wù)（定期提交，如，每隔1000個記錄或每隔幾秒），但這樣一來這個事務(wù)的序列必須被設(shè)計，來確保導(dǎo)出數(shù)據(jù)與基礎(chǔ)數(shù)據(jù)的索引的一致性。