Facebook數據倉庫揭秘之RCFile高效存儲結構

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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