Facebook數(shù)據(jù)倉庫揭秘之RCFile高效存儲結(jié)構(gòu)

1、Facebook數(shù)據(jù)倉庫揭秘：RCFile高效存儲結(jié)構(gòu)本文介紹了Facebook公司數(shù)據(jù)分析系統(tǒng)中的RCFile存儲結(jié)構(gòu)，該結(jié)構(gòu)集行存儲和列存儲的優(yōu)點于一身，在MapReduce環(huán)境下的大規(guī)模數(shù)據(jù)分析中扮演重要角色。Facebook曾在2010 ICDE（IEEE International Conference on Data Engineering）會議上介紹了數(shù)據(jù)倉庫Hive。Hive存儲海量數(shù)據(jù)在Hadoop系統(tǒng)中，提供了一套類數(shù)據(jù)庫的數(shù)據(jù)存儲和處理機制。它采用類 SQL語言對數(shù)據(jù)進行自動化管理和處理，經(jīng)過語句解析和轉(zhuǎn)換，最終生成基于Hadoop的MapReduce任務，通過執(zhí)行這些任

2、務完成數(shù)據(jù)處理。圖1顯 示了Hive數(shù)據(jù)倉庫的系統(tǒng)結(jié)構(gòu)。圖1 Hive數(shù)據(jù)倉庫的系統(tǒng)結(jié)構(gòu)基于MapReduce的數(shù)據(jù)倉庫在超大規(guī)模數(shù)據(jù)分析中扮演了重要角色，對于典型的Web服 務供應商，這些分析有助于它們快速理解動態(tài)的用戶行為及變化的用戶需求。數(shù)據(jù)存儲結(jié)構(gòu)是影響數(shù)據(jù)倉庫性能的關鍵因素之一。Hadoop系統(tǒng)中常用的文件存 儲格式有支持文本的TextFile和支持二進制的SequenceFile等，它們都屬于行存儲方式。Facebook工程師發(fā)表的RCFile: A Fast and Spaceefficient Data Placement Structure in MapReducebased

3、 Warehouse Systems一文，介紹了一種高效的數(shù)據(jù)存儲結(jié)構(gòu)RCFile（Record Columnar File），并將其應用于Facebook的數(shù)據(jù)倉庫Hive中。與傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)存儲結(jié)構(gòu)相比，RCFile更有效地滿足了基于MapReduce的 數(shù)據(jù)倉庫的四個關鍵需求，即Fast data loading、Fast query processing、Highly efficient storage space utilization和Strong adaptivity to highly dynamic workload patterns。數(shù)據(jù)倉庫的需求基于Facebook系統(tǒng)

4、特征和用戶數(shù)據(jù)的分析，在MapReduce計算環(huán)境下，數(shù)據(jù)倉庫對于數(shù)據(jù)存儲結(jié)構(gòu)有四個關鍵需求。Fast data loading對于Facebook的產(chǎn)品數(shù)據(jù)倉庫而言，快速加載數(shù)據(jù)（寫數(shù)據(jù)）是非常關鍵的。每天大約有超過20TB的數(shù)據(jù)上傳到Facebook的數(shù)據(jù)倉庫，由于數(shù)據(jù)加載期間網(wǎng)絡和磁盤流量會干擾正常的查詢執(zhí)行，因此縮短數(shù)據(jù)加載時間是非常必要的。Fast query processing為了滿足實時性的網(wǎng)站請求和支持高并發(fā)用戶提交查詢的大量讀負載，查詢響應時間是非常關鍵的，這要求底層存儲結(jié)構(gòu)能夠隨著查詢數(shù)量的增加而保持高速的查詢處理。Highly efficient storage spa

5、ce utilization高速增長的用戶活動總是需要可擴展的存儲容量和計算能力，有限的磁盤空間需要合理管理海量數(shù)據(jù)的存儲。實際上，該問題的解決方案就是最大化磁盤空間利用率。Strong adaptivity to highly dynamic workload patterns同一份數(shù)據(jù)集會供給不同應用的用戶，通過各種方式來分析。某些數(shù)據(jù)分析是例行過程，按照某種固定模式周期性執(zhí)行；而另一些則是從中間平臺發(fā)起的查 詢。大多數(shù)負載不遵循任何規(guī)則模式，這需要底層系統(tǒng)在存儲空間有限的前提下，對數(shù)據(jù)處理中不可預知的動態(tài)數(shù)據(jù)具備高度的適應性，而不是專注于某種特殊的負 載模式。MapReduce存儲策略要

6、想設計并實現(xiàn)一種基于MapReduce數(shù)據(jù)倉庫的高效數(shù)據(jù)存儲結(jié)構(gòu)，關鍵挑戰(zhàn)是在MapReduce計算環(huán)境中滿足上述四個需求。在傳統(tǒng)數(shù)據(jù)庫 系統(tǒng)中，三種數(shù)據(jù)存儲結(jié)構(gòu)被廣泛研究，分別是行存儲結(jié)構(gòu)、列存儲結(jié)構(gòu)和PAX混合存儲結(jié)構(gòu)。上面這三種結(jié)構(gòu)都有其自身特點，不過簡單移植這些數(shù)據(jù)庫導向的 存儲結(jié)構(gòu)到基于MapReduce的數(shù)據(jù)倉庫系統(tǒng)并不能很好地滿足所有需求。行存儲如圖2所示，基于Hadoop系統(tǒng)行存儲結(jié)構(gòu)的優(yōu)點在于快速數(shù)據(jù)加載和動態(tài)負載的高適應能力，這是因為行存儲保證了相同記錄的所有域都在同一個集群 節(jié)點，即同一個HDFS塊。不過，行存儲的缺點也是顯而易見的，例如它不能支持快速查詢處理，因為當查詢

7、僅僅針對多列表中的少數(shù)幾列時，它不能跳過不必要 的列讀?。淮送?，由于混合著不同數(shù)據(jù)值的列，行存儲不易獲得一個極高的壓縮比，即空間利用率不易大幅提高。盡管通過熵編碼和利用列相關性能夠獲得一個較好 的壓縮比，但是復雜數(shù)據(jù)存儲實現(xiàn)會導致解壓開銷增大。圖2 HDFS塊內(nèi)行存儲的例子列存儲圖3顯示了在HDFS上按照列組存儲表格的例子。在這個例子中，列A和列B存儲在同一列組，而列C和列D分別存儲在單獨的列組。查詢時列存儲能夠避 免讀不必要的列，并且壓縮一個列中的相似數(shù)據(jù)能夠達到較高的壓縮比。然而，由于元組重構(gòu)的較高開銷，它并不能提供基于Hadoop系統(tǒng)的快速查詢處理。列 存儲不能保證同一記錄的所有域都存儲

8、在同一集群節(jié)點，例如圖2的例子中，記錄的4個域存儲在位于不同節(jié)點的3個HDFS塊中。因此，記錄的重構(gòu)將導致通過 集群節(jié)點網(wǎng)絡的大量數(shù)據(jù)傳輸。盡管預先分組后，多個列在一起能夠減少開銷，但是對于高度動態(tài)的負載模式，它并不具備很好的適應性。除非所有列組根據(jù)可能的 查詢預先創(chuàng)建，否則對于一個查詢需要一個不可預知的列組合，一個記錄的重構(gòu)或許需要2個或多個列組。再者由于多個組之間的列交疊，列組可能會創(chuàng)建多余的列 數(shù)據(jù)存儲，這導致存儲利用率的降低。圖3 HDFS塊內(nèi)列存儲的例子PAX混合存儲PAX存儲模型（用于Data Morphing存儲技術(shù)）使用混合存儲方式，目的在于提升CPU Cache性能。對于記錄

9、中來自不同列的多個域，PAX將它們放在一個磁盤頁中。在每個磁盤頁中，PAX使用一個迷你頁來存儲屬于每個列的所有域，并使用 一個頁頭來存儲迷你頁的指針。類似于行存儲，PAX對多種動態(tài)查詢有很強的適應能力。然而，它并不能滿足大型分布式系統(tǒng)對于高存儲空間利用率和快速查詢處 理的需求，原因在于：首先，PAX沒有數(shù)據(jù)壓縮的相關工作，這部分與Cache優(yōu)化關系不大，但對于大規(guī)模數(shù)據(jù)處理系統(tǒng)是非常關鍵的，它提供了列維度數(shù)據(jù) 壓縮的可能性；其次，PAX不能提升I/O性能，因為它不能改變實際的頁內(nèi)容，該限制使得大規(guī)模數(shù)據(jù)掃描時不易實現(xiàn)快速查詢處理；再次，PAX用固定的頁 作為數(shù)據(jù)組織的基本單位，按照這個大小，在

10、海量數(shù)據(jù)處理系統(tǒng)中，PAX將不會有效存儲不同大小類型的數(shù)據(jù)域。本文介紹的是RCF i l e 數(shù)據(jù)存儲結(jié)構(gòu)在Hadoop系統(tǒng)上的實現(xiàn)。該結(jié)構(gòu)強調(diào)：第一，RCFile存儲的表是水平劃分的，分為多個行組， 每個行組再被垂直劃分， 以便每列單獨存儲；第二，RCFile在每個行組中利用一個列維度的數(shù)據(jù)壓縮，并提供一種Lazy解壓（decompression）技術(shù)來在查詢執(zhí)行時 避免不必要的列解壓；第三，RCFile支持彈性的行組大小，行組大小需要權(quán)衡數(shù)據(jù)壓縮性能和查詢性能兩方面。RCFile的設計與實現(xiàn)RCFile（Record Columnar File）存儲結(jié)構(gòu)遵循的是“先水平劃分，再垂直劃分”的

11、設計理念，這個想法來源于PAX。它結(jié)合了行存儲和列存儲的優(yōu)點：首先，RCFile保證同一行 的數(shù)據(jù)位于同一節(jié)點，因此元組重構(gòu)的開銷很低；其次，像列存儲一樣，RCFile能夠利用列維度的數(shù)據(jù)壓縮，并且能跳過不必要的列讀取。圖4是一個 HDFS塊內(nèi)RCFile方式存儲的例子。圖4 HDFS塊內(nèi)RCFile方式存儲的例子數(shù)據(jù)格式RCFile在HDFS分布式文件系統(tǒng)之上設計并實現(xiàn)，如圖4所示，RCFile按照下面的數(shù)據(jù)格式來存儲一張表。RCFile基于HDFS架構(gòu)，表格占用多個HDFS塊。每個HDFS塊中，RCFile以行組為基本單位來組織記錄。也就是說，存儲在一個HDFS塊中的所有記錄被劃分為多個行

12、組。對于一張表，所有行組大小都相同。一個HDFS塊會有一個或多個行組。一個行組包括三個部分。第一部分是行組頭部的同步標識，主要用于分隔HDFS塊中的兩個連續(xù)行組；第二部分是行組的元數(shù)據(jù)頭部，用于存儲行組單元的 信息，包括行組中的記錄數(shù)、每個列的字節(jié)數(shù)、列中每個域的字節(jié)數(shù)；第三部分是表格數(shù)據(jù)段，即實際的列存儲數(shù)據(jù)。在該部分中，同一列的所有域順序存儲。從圖 4可以看出，首先存儲了列A的所有域，然后存儲列B的所有域等。壓縮方式RCFile的每個行組中，元數(shù)據(jù)頭部和表格數(shù)據(jù)段分別進行壓縮。對于所有元數(shù)據(jù)頭部，RCFile使用RLE（Run Length Encoding）算法來壓縮數(shù)據(jù)。由于同一列中所

13、有域的長度值都順序存儲在該部分，RLE算法能夠找到重復值的長序列，尤其對于固定的域長度。表格數(shù)據(jù)段不會作為整個單元來壓縮；相反每個列被獨立壓縮，使用Gzip壓縮算法。RCFile使用重量級的Gzip壓縮算法，是為了獲得較好的壓 縮比，而不使用RLE算法的原因在于此時列數(shù)據(jù)非排序。此外，由于Lazy壓縮策略，當處理一個行組時，RCFile不需要解壓所有列。因此，相對較高的 Gzip解壓開銷可以減少。盡管RCFile對表格數(shù)據(jù)的所有列使用同樣的壓縮算法，不過如果使用不同的算法來壓縮不同列或許效果會更好。RCFile將來的工作之一可能就是根據(jù)每列的數(shù)據(jù)類型和數(shù)據(jù)分布來自適應選擇最好的壓縮算法。數(shù)據(jù)追

14、加RCFile不支持任意方式的數(shù)據(jù)寫操作，僅提供一種追加接口，這是因為底層的HDFS當前僅僅支持數(shù)據(jù)追加寫文件尾部。數(shù)據(jù)追加方法描述如下。RCFile為每列創(chuàng)建并維護一個內(nèi)存column holder，當記錄追加時，所有域被分發(fā)，每個域追加到其對應的column holder。此外，RCFile在元數(shù)據(jù)頭部中記錄每個域?qū)脑獢?shù)據(jù)。RCFile提供兩個參數(shù)來控制在刷寫到磁盤之前，內(nèi)存中緩存多少個記錄。一個參數(shù)是記錄數(shù)的限制，另一個是內(nèi)存緩存的大小限制。RCFile首先壓縮元數(shù)據(jù)頭部并寫到磁盤，然后分別壓縮每個column holder，并將壓縮后的column holder刷寫到底層文件系統(tǒng)中

15、的一個行組中。數(shù)據(jù)讀取和Lazy解壓在MapReduce框架中，mapper將順序處理HDFS塊中的每個行組。當處理一個行組時，RCFile無需全部讀取行組的全部內(nèi)容到內(nèi)存。相反，它僅僅讀元數(shù)據(jù)頭部和給定查詢需要的列。因此，它可以跳過不必要的列以獲得列存儲的I/O優(yōu)勢。例如，表tbl(c1, c2, c3, c4)有4個列，做一次查詢“SELECT c1 FROM tbl WHERE c4 = 1”，對每個行組，RCFile僅僅讀取c1和c4列的內(nèi)容。在元數(shù)據(jù)頭部和需要的列數(shù)據(jù)加載到內(nèi)存中后，它們需要解壓。元數(shù)據(jù)頭部總會解壓并在內(nèi)存中維 護直到RCFile處理下一個行組。然而，RCFile不會

16、解壓所有加載的列，相反，它使用一種Lazy解壓技術(shù)。Lazy解壓意味著列將不會在內(nèi)存解壓，直到RCFile決定列中數(shù)據(jù)真正對查詢執(zhí)行有用。由于查詢使用各種WHERE條件，Lazy解壓非常有 用。如果一個WHERE條件不能被行組中的所有記錄滿足，那么RCFile將不會解壓WHERE條件中不滿足的列。例如，在上述查詢中，所有行組中的列 c4都解壓了。然而，對于一個行組，如果列c4中沒有值為1的域，那么就無需解壓列c1。行組大小I/O性能是RCFile關注的重點，因此RCFile需要行組夠大并且大小可變。行組大小和下面幾個因素相關。行組大的話，數(shù)據(jù)壓縮效率會比行組小時更有效。根據(jù)對Facebook日

17、常應用的觀察，當行組大小達到一個閾值后，增加行組大小并不能進一步增加Gzip算法下的壓縮比。行組變大能夠提升數(shù)據(jù)壓縮效率并減少存儲量。因此，如果對縮減存儲空間方面有強烈需求，則不建議選擇使用小行組。需要注意的是，當行組的大小超過4MB，數(shù)據(jù)的壓縮比將趨于一致。盡管行組變大有助于減少表格的存儲規(guī)模，但是可能會損害數(shù)據(jù)的讀性能，因為這樣減少了Lazy解壓帶來的性能提升。而且行組變大會占用更多的內(nèi)存， 這會影響并發(fā)執(zhí)行的其他MapReduce作業(yè)?？紤]到存儲空間和查詢效率兩個方面，F(xiàn)acebook選擇4MB作為默認的行組大小，當然也允許用戶自行 選擇參數(shù)進行配置。小結(jié)本文簡單介紹了RCFile存儲結(jié)

18、構(gòu)，其廣泛應用于Facebook公司的數(shù)據(jù)分析系統(tǒng)Hive中。首先，RCFile具備相當于行存儲的數(shù)據(jù)加載 速度和負載適應能力；其次，RCFile的讀優(yōu)化可以在掃描表格時避免不必要的列讀取，測試顯示在多數(shù)情況下，它比其他結(jié)構(gòu)擁有更好的性能；再 次，RCFile使用列維度的壓縮，因此能夠有效提升存儲空間利用率。為了提高存儲空間利用率，F(xiàn)acebook各產(chǎn)品線應用產(chǎn)生的數(shù)據(jù)從2010年起均采用RCFile結(jié)構(gòu)存儲，按行存儲 （SequenceFile/TextFile）結(jié)構(gòu)保存的數(shù)據(jù)集也轉(zhuǎn)存為RCFile格式。此外，Yahoo公司也在Pig數(shù)據(jù)分析系統(tǒng)中集成了 RCFile，RCFile正在用于另

19、一個基于Hadoop的數(shù)據(jù)管理系統(tǒng)Howl（/pig /Howl）。而且，根據(jù)Hive開發(fā)社區(qū)的交流，RCFile也成功整合加入其他基于MapReduce的數(shù)據(jù)分析平臺。有理由相信，作為數(shù)據(jù)存儲標準 的RCFile，將繼續(xù)在MapReduce環(huán)境下的大規(guī)模數(shù)據(jù)分析中扮演重要角色。附錄資料：不需要的可以自行刪除如何構(gòu)建銀行數(shù)據(jù)倉庫數(shù)據(jù)倉庫技術(shù)作為一項數(shù)據(jù)管理領域的新技術(shù)，其精髓在于針對聯(lián)機分析處理(OLAP)提出了一種綜合的解決方案，與以往很多技術(shù)不同的是，它主要是一種概念，在此概念指導下完成系統(tǒng)的構(gòu)造。既沒有可以直接購買到的現(xiàn)成產(chǎn)品，也沒有具體的分析規(guī)范和實現(xiàn)方法，也就是說沒有成熟、可靠且被廣

20、泛接受的數(shù)據(jù)倉庫標準。在以往關系數(shù)據(jù)庫的設計和實現(xiàn)中，不僅有詳細的理論推導，還有無數(shù)的設計實例，無論你使用的是什么公司的數(shù)據(jù)庫產(chǎn)品、開發(fā)工具，只要按照規(guī)范做，那么實現(xiàn)同一業(yè)務需求的方案都會很相似。而現(xiàn)有數(shù)據(jù)倉庫的實現(xiàn)中，出現(xiàn)了MOLAP方案和ROLAP方案的區(qū)別，出現(xiàn)了形形色色的數(shù)據(jù)倉庫建模工具、表現(xiàn)工具，而設計人員的個人經(jīng)驗和素質(zhì)也會在其中扮演很重要的角色。 數(shù)據(jù)倉庫技術(shù)的實現(xiàn)方式 目前在數(shù)據(jù)倉庫技術(shù)的實際應用中主要包括如下幾種具體實現(xiàn)方式。 1、在關系數(shù)據(jù)庫上建立數(shù)據(jù)倉庫(ROLAP) 2、在多維數(shù)據(jù)庫上建立數(shù)據(jù)倉庫(MOLAP) MOLAP方案是以多維方式來組織數(shù)據(jù)，以多維方式來存儲數(shù)據(jù)

21、；ROLAP方案則以二維關系表為核心表達多維概念，通過將多維結(jié)構(gòu)劃分為兩類表:維表和事實表，使關系型結(jié)構(gòu)能較好地適應多維數(shù)據(jù)的表示和存儲。在多維數(shù)據(jù)模型的表達方面，多維矩陣比關系表更清晰且占用的存儲更少，而通過關系表間的連接來查詢數(shù)據(jù)的ROLAP系統(tǒng)，系統(tǒng)性能成為最大問題。MOLAP方案比ROLAP方案要簡明，索引及數(shù)據(jù)聚合可以自動進行并自動管理，但同時喪失了一定的靈活性。ROLAP方案的實現(xiàn)較為復雜，但靈活性較好，用戶可以動態(tài)定義統(tǒng)計和計算方式，另外能保護在已有關系數(shù)據(jù)庫上的投資。 由于兩種方案各有優(yōu)劣，因此在實際應用中，往往將MOLAP和ROLAP結(jié)合使用，即所謂的混合模型。利用關系數(shù)據(jù)庫

22、存儲歷史數(shù)據(jù)、細節(jié)數(shù)據(jù)或非數(shù)值型數(shù)據(jù)，發(fā)揮關系數(shù)據(jù)庫技術(shù)成熟的優(yōu)勢，減少花費，而在多維數(shù)據(jù)庫中存儲當前數(shù)據(jù)和常用統(tǒng)計數(shù)據(jù)，以提高操作性能。 3、在原有關系庫上建立邏輯上的數(shù)據(jù)倉庫 由于目前正在運行的OLTP系統(tǒng)中已經(jīng)積累了海量數(shù)據(jù)，如何從中提取出決策所需的有用信息就成為用戶最迫切的需要。新建數(shù)據(jù)倉庫固然能從功能、性能各方面給出一個完整的解決方案，但需要投入大量的人力、物力，并且數(shù)據(jù)倉庫的建設和分析數(shù)據(jù)的積累需要一段時間，無法及時滿足用戶對信息分析的迫切需要。因此在籌建數(shù)據(jù)倉庫的前期，可以采用一些合適的表現(xiàn)工具，在原有OLTP系統(tǒng)上建立起一個邏輯的數(shù)據(jù)倉庫系統(tǒng)。盡管由于原有OLTP系統(tǒng)設計上的局

23、限性，這樣的系統(tǒng)可能無法實現(xiàn)很多分析功能，但這樣一個系統(tǒng)中數(shù)據(jù)結(jié)構(gòu)固定、信息分析需求相對穩(wěn)定成熟，因此數(shù)據(jù)倉庫的建模、實現(xiàn)過程會相對容易、便捷；同時，這樣的系統(tǒng)也會成為將來真正數(shù)據(jù)倉庫建設的原型。 信息系統(tǒng)與數(shù)據(jù)倉庫的關系 由于數(shù)據(jù)量大、數(shù)據(jù)來源多樣化，在商業(yè)銀行構(gòu)建管理信息系統(tǒng)時，不可避免地會遇上如何管理這些浩如煙海的數(shù)據(jù)，以及如何從中提取有用的信息的問題；而數(shù)據(jù)倉庫的最大優(yōu)點在于它能把企業(yè)網(wǎng)絡中不同信息島上的商業(yè)數(shù)據(jù)集中到一起，存儲在一個單一的集成的數(shù)據(jù)庫中，并提供各種手段對數(shù)據(jù)進行統(tǒng)計、分析。因此可以說，在銀行使用數(shù)據(jù)倉庫構(gòu)建管理信息系統(tǒng)，既有壓力，又有數(shù)據(jù)基礎，它們之間的聯(lián)系是必然的，

24、難以割舍的。 數(shù)據(jù)倉庫在商業(yè)銀行的應用范圍包括存款分析、貸款分析、客戶市場分析、相關金融業(yè)分析決策(證券、外匯買賣)、風險預測、效益分析等。 在銀行信息系統(tǒng)構(gòu)建時，由于歷史情況和現(xiàn)實需求的不同，存在兩種途徑: 1、建設新系統(tǒng) 由于目前國內(nèi)商業(yè)銀行對銀行內(nèi)部運營的監(jiān)管，缺乏很好的數(shù)據(jù)搜集機制，因此可以在構(gòu)建管理信息系統(tǒng)時，分數(shù)據(jù)收集錄入和數(shù)據(jù)匯總分析兩部分來考慮。這樣的系統(tǒng)中由于不需考慮大量歷史數(shù)據(jù)的處理問題，同時考慮到搜集過程中可能存在多個數(shù)據(jù)來源，因此可以在系統(tǒng)建設的同時構(gòu)建數(shù)據(jù)倉庫，將搜集來的各種數(shù)據(jù)通過數(shù)據(jù)抽取整合到數(shù)據(jù)倉庫中。 2、完善原有系統(tǒng) 而對于已經(jīng)存在OLTP系統(tǒng)，其中沉淀了大

25、量歷史數(shù)據(jù)，則可以先在原有系統(tǒng)上建立邏輯數(shù)據(jù)倉庫，即使用數(shù)據(jù)分析的表現(xiàn)工具，在關系模型上構(gòu)建一個虛擬的多維模型。當系統(tǒng)需求穩(wěn)定后，再建立物理數(shù)據(jù)倉庫，這樣既節(jié)省投資，又縮短開發(fā)工期。 實現(xiàn)中需要注意的問題 一、模型設計中的問題 模型設計(包括邏輯模型設計和物理模型設計)是系統(tǒng)的基礎和成敗的關鍵，在實際操作中，視實現(xiàn)技術(shù)的不同應分別對下列問題引起注意。 1、直接構(gòu)建數(shù)據(jù)倉庫 直接構(gòu)建數(shù)據(jù)倉庫時，必須按業(yè)務分析的要求重組OLTP系統(tǒng)中的數(shù)據(jù)，并要按不同側(cè)重點分別組織，使之便于使用。 *主題的確定 主題是一個邏輯概念，它應該能夠完整、統(tǒng)一地刻畫出分析對象所涉及的各項數(shù)據(jù)以及相互聯(lián)系。劃分主題的根據(jù)主

26、要來源于兩方面:對原有固定報表的分析和對業(yè)務人員的訪談。原有固定報表能較好地反映出以往工作對數(shù)據(jù)分析的需求，而且數(shù)據(jù)含義和格式相對成熟、穩(wěn)定，在模型設計中需要大量借鑒。但僅僅滿足于替代目前的手工報表還遠遠不應是構(gòu)建管理信息系統(tǒng)的目標，還應該通過業(yè)務訪談，進一步挖掘出日常工作中潛在的更廣、更深的分析需求。只有這樣，才能真正了解構(gòu)建數(shù)據(jù)倉庫模型所需的主題劃分。 *分析內(nèi)容的細化 主題的劃分實際上是與分析內(nèi)容的范圍直接相關的，一旦主題劃分清楚了，下一步就是細化分析的具體內(nèi)容以及根據(jù)分析內(nèi)容的性質(zhì)確定它在數(shù)據(jù)倉庫中的位置。通常維元素對應的是分析角度，而度量對應的是分析關心的具體指標。一個指標究竟是作為

27、維元素、度量還是維屬性，取決于具體的業(yè)務需求，但從實際操作中可以總結(jié)出如下的概念性經(jīng)驗:作為維元素或維屬性的通常是離散型的數(shù)據(jù)，只允許有限的取值；作為度量的是連續(xù)型數(shù)據(jù)，取值無限。如果一定要用連續(xù)型數(shù)據(jù)作為維元素，則必須對其按取值進行分段，以分段值作為實際的維元素。判斷分析指標是作為維元素還是維屬性時，則需要綜合考慮這個指標占用的存儲空間與相關查詢的使用頻度。 需要特別強調(diào)的是，在細化分析內(nèi)容的過程中，務必解決指標的歧義問題。在不同報表中以及在業(yè)務訪談中同一名稱的指標，是否是在同樣條件限定下，通過同樣方法提取或計算得到的，它們之間的相互關系是什么，這些問題都必須從熟悉業(yè)務的分析人員那里得到準確

28、、清晰的答案，否則將會影響到模型設計、數(shù)據(jù)提取、數(shù)據(jù)展現(xiàn)等多個方面。 *粒度的設計 數(shù)據(jù)倉庫模型中所存儲的數(shù)據(jù)的粒度將對信息系統(tǒng)的多方面產(chǎn)生影響。事實表中以各種維度的什么層次作為最細粒度，將決定存儲的數(shù)據(jù)能否滿足信息分析的功能需求，而粒度的層次劃分、以及聚合表中粒度的選擇將直接影響查詢的響應時間。 如果同一個信息系統(tǒng)要在大范圍、多層次上同時運行，如部門級和企業(yè)級，還應考慮不同層次的數(shù)據(jù)倉庫采用不同的粒度。 *模型設計中的技巧 復合指標尤其是比率類指標的定義，必須注意累加時是先加減后乘除，還是反之。戶數(shù)、筆數(shù)的計算，這類指標在分析或報表中經(jīng)常出現(xiàn)，但不需要作為單獨的指標物理存在于數(shù)據(jù)庫中，但定義

29、分析模型時一定應該準備。度量的時間特性，針對分析指標在時間維上的不同表現(xiàn)，可分為可累加指標、半可累加指標和不可累加指標。 2、在原有數(shù)據(jù)基礎上構(gòu)建邏輯數(shù)據(jù)倉庫 如果直接使用OLTP系統(tǒng)中的數(shù)據(jù)進行數(shù)據(jù)分析處理，會遇到許多麻煩，有時甚至是不可能實現(xiàn)的。這并不是說關系數(shù)據(jù)庫不好，而是因為其設計思路不適應較大規(guī)模數(shù)據(jù)分析。因此在使用這種方法時，需要注意下列問題的處理: *不同的時間單位 這是實現(xiàn)過程中最常遇到的問題，也往往是最難解決的問題。OLTP系統(tǒng)中存儲的時間往往采用與實際業(yè)務發(fā)生相同的時間單位，如帳務數(shù)據(jù)單位為日期，財務報表單位為月或半年。而面向分析時，往往要將不同時間單位的數(shù)據(jù)統(tǒng)一到同一個結(jié)

30、果中，這樣就必須存在適當?shù)霓D(zhuǎn)換機制才能實現(xiàn)。 *冗余信息 所謂冗余信息，就是指不同關系表中存在的同一含義的字段，而同一含義不僅指這些字段的取得或計算方式一樣，還指它們成立的條件一樣，例如截止某一時間同一地區(qū)的同一貸種的貸款余額。在OLTP系統(tǒng)中，這樣的字段往往是基于性能考慮而設計的，而在面向分析設計模型時，為了保證結(jié)果的唯一性和準確性，就必須用且只用其中之一的數(shù)據(jù)產(chǎn)生分析結(jié)果。 *表間連接 由于OLTP系統(tǒng)中表的設計面向業(yè)務處理，既要保證數(shù)據(jù)的完整性、一致性，又要考慮響應時間，因此表與表之間既相對獨立，又相互依賴。在設計數(shù)據(jù)倉庫邏輯模型時，對表間的連接必須做出相應取舍，既要保證分析數(shù)據(jù)能通過連

31、接取得或計算出，又要避免出現(xiàn)環(huán)路，造成分析數(shù)據(jù)的歧義。另外，不同的連接途徑還會出現(xiàn)不同的查詢速度，影響數(shù)據(jù)分析的響應性能。 *統(tǒng)計表的設計 如果上述問題不能在原有數(shù)據(jù)庫基礎上得到很好的解決，那么權(quán)益之計就是構(gòu)建統(tǒng)計表，即簡單化的數(shù)據(jù)倉庫，形式類似數(shù)據(jù)倉庫的事實表，定時計算統(tǒng)計數(shù)據(jù)放入，將時間、冗余、連接等問題擯除，進行簡單分析。 二、數(shù)據(jù)抽取中的問題 數(shù)據(jù)抽取是一件技術(shù)含量不高，但非常煩瑣的工作，必須有專人負責數(shù)據(jù)抽取的工作。在對其進行設計時，要注意的問題有: 1、數(shù)據(jù)抽取的規(guī)則要作為元數(shù)據(jù)進行規(guī)范和管理，抽取過程中的源表、源字段、目的表、目的字段、轉(zhuǎn)換規(guī)則以及轉(zhuǎn)換條件都要作好詳細記錄。這樣不僅便于編程人員實現(xiàn)，而且在抽取