【正文】 總計S1S2表31 數(shù)據(jù)量估算表從表31我們得到了DASD的最大最小估算數(shù)據(jù)和行數(shù)的最大最小估算值，緊接著就是確定數(shù)據(jù)粒度了。這時可以參照行業(yè)經(jīng)驗值來確定是否需要雙重或多重粒度，除非是輕量級的數(shù)據(jù)倉庫，一般均需要雙重粒度，大多數(shù)情況下數(shù)據(jù)倉庫需要多重粒度。表32是行業(yè)經(jīng)驗值。表32 數(shù)據(jù)粒度經(jīng)驗值一年期五年期10,000,000行雙重粒度級20,000,000行雙重粒度級1,000,000行雙重粒度10,000,000行雙重粒度100,000行都可以1,000,000行都可以10,000行都可以100,000行都可以如果數(shù)據(jù)倉庫只需要單一粒度，則數(shù)據(jù)粒度的級別就沒有重大的意義，所以數(shù)據(jù)粒度級別是針對多重粒度而言出現(xiàn)的一個概念。我們應(yīng)著重分析的對象是主題領(lǐng)域中某個確定的“維度”。對于雙重粒度和多重粒度的級別設(shè)計問題，唯一可行的辦法是采用猜測方法。在做數(shù)據(jù)倉庫設(shè)計時，無法得到精確的需求，只有拿出了具體的設(shè)計方案后，才能得到具體有用的信息，所以猜測法的出發(fā)點是項目的大概需求和實際開發(fā)經(jīng)驗。總的來說，針對特定的主題域、特定的維度到底在何種級別上建立匯總數(shù)據(jù)，要根據(jù)項目大小來做決定，在太低細節(jié)級數(shù)據(jù)上建立匯總會使該匯總沒有任何實際意義，處理數(shù)據(jù)時將消耗大量資源；在太高細節(jié)級上建立匯總數(shù)據(jù)將會使處理時過多依賴真實檔案。在設(shè)計通信行業(yè)數(shù)據(jù)倉庫時，粒度級別是這樣確定的：如果要對客戶交易行為分析，可以確定如下分析維度，交易方式（現(xiàn)場、非現(xiàn)場）、交易手段（互聯(lián)網(wǎng)、電話、熱鍵、刷卡）、交易時間等等。在設(shè)計數(shù)據(jù)倉庫時，多重粒度的設(shè)計是毫無疑問的了。數(shù)據(jù)粒度級別的確定，應(yīng)該首先考慮的是在詳細數(shù)據(jù)的基礎(chǔ)上以較低級別來匯總數(shù)據(jù)（如以交易日為單位），那么做年度數(shù)據(jù)分析時，系統(tǒng)必然要消耗很大資源；但如果在較高級別上匯總數(shù)據(jù)（以年為單位），則極有可能需要向下挖掘數(shù)據(jù)來分析其月或者日的數(shù)據(jù)。因此，你唯一可行的辦法是猜測，進而與DSS分析員交流來確定數(shù)據(jù)粒度級別。在這里，采用三重粒度設(shè)計方案，數(shù)據(jù)倉庫中包括詳細數(shù)據(jù)、按月匯總數(shù)據(jù)、按年匯總數(shù)據(jù)。經(jīng)過上述幾個步驟，基本符合要求的數(shù)據(jù)粒度已經(jīng)確立，在最終確定以前必須與用戶反復(fù)討論，確定數(shù)據(jù)粒度劃分是否符合所有主題域分析需求。第四章 數(shù)據(jù)倉庫詳細設(shè)計 邏輯模型設(shè)計實際數(shù)據(jù)倉庫項目建設(shè)中，往往存在用戶業(yè)務(wù)需求范圍難已確定、需求超前、需求的隨時應(yīng)變等情況，傳統(tǒng)的瀑布式系統(tǒng)開發(fā)方法適用于需求確定的開發(fā)，但難以適應(yīng)類似分析型系統(tǒng)的建設(shè)，許多項目也因此導(dǎo)致失敗，為此一種體現(xiàn)分而治之，分階段實施的螺旋式開發(fā)方法應(yīng)運而生。螺旋式開發(fā)方法將龐大的需求任務(wù)目標分成幾個階段，按照問題定義、系統(tǒng)分析、系統(tǒng)設(shè)計、開發(fā)、實現(xiàn)、維護和系統(tǒng)總結(jié)評估的流程來進行，通過不斷擴大開發(fā)范圍的方式逐步完善數(shù)據(jù)倉庫系統(tǒng)。邏輯數(shù)據(jù)模型建立一個統(tǒng)一的、共享的基礎(chǔ)數(shù)據(jù)平臺，為各個業(yè)務(wù)部門的不同業(yè)務(wù)需求提供一致的、規(guī)范的數(shù)據(jù)，其結(jié)構(gòu)是為了滿足各種不同的分析邏輯的要求而設(shè)計的。目前業(yè)界許多大公司如：IBM，NCR，ORACLE 等提出了各自的數(shù)據(jù)模型，隨分類視角不盡相同，但從不同側(cè)面反映了通信行業(yè)需求和發(fā)展的全景和特征。這些邏輯數(shù)據(jù)模型的組織規(guī)劃是圍繞通信業(yè)務(wù)活動的主要主題領(lǐng)域進行的，是多功能的和集成的，如客戶、產(chǎn)品、賬戶、機構(gòu)和渠道等。邏輯數(shù)據(jù)模型是一個可擴展的、動態(tài)的模型，是實際項目中的信息參考模型。結(jié)合通信行業(yè)現(xiàn)有分布數(shù)據(jù)中心的特點，提出基于邏輯數(shù)據(jù)模型的分布式數(shù)據(jù)倉庫結(jié)構(gòu)，上述結(jié)構(gòu)采用分步實施，自底向上的辦法，具體項目實施中可選擇數(shù)據(jù)質(zhì)量較好、系統(tǒng)相對集中的數(shù)據(jù)中心進行數(shù)據(jù)集市試點，等成功后再逐步推廣，最后構(gòu)建全局數(shù)據(jù)倉庫，這種方式較為符合通信行業(yè)的實際需求，可以快速見效，提高了系統(tǒng)成功率，且通過統(tǒng)一邏輯數(shù)據(jù)模型的映射基本能滿足單一數(shù)據(jù)視圖的要求。可以通過ETL 數(shù)據(jù)抽轉(zhuǎn)換加載提高數(shù)據(jù)質(zhì)量，并通過元數(shù)據(jù)管理來保證數(shù)據(jù)集市間，數(shù)據(jù)集市和數(shù)據(jù)倉庫間數(shù)據(jù)映射的唯一性。統(tǒng)一數(shù)據(jù)架構(gòu)是基于聯(lián)通全企業(yè)的整體數(shù)據(jù)規(guī)劃，本期計劃首先實現(xiàn)B域和M域的數(shù)據(jù)模型整合，構(gòu)建企業(yè)級的統(tǒng)一數(shù)據(jù)倉庫，并在后期考慮O域數(shù)據(jù)的整合。圖34 數(shù)據(jù)倉庫架構(gòu) 物理模型設(shè)計(1)DBDW 架構(gòu)，數(shù)據(jù)倉庫最典型的架構(gòu)是DBDW 結(jié)構(gòu)。數(shù)據(jù)倉庫典型的建設(shè)方法有兩種：一種是自頂向下，首先建立全局級的數(shù)據(jù)倉庫，然后從中抽取數(shù)據(jù)建立面向各個部門的數(shù)據(jù)集市這種方法，所有數(shù)據(jù)在進入數(shù)據(jù)倉庫前進行清洗和轉(zhuǎn)換，能夠保證數(shù)據(jù)的一致性，這種架構(gòu)一般適用于相對獨立集中或規(guī)模較小的企業(yè)；另一種是自底向上的建設(shè)方法，即首先建立一個或幾個數(shù)據(jù)集市，分布實施現(xiàn)解決企業(yè)面臨的局部問題，然后再從個數(shù)據(jù)集市中抽取數(shù)據(jù)構(gòu)建統(tǒng)一的數(shù)據(jù)倉庫。因此形成了兩種數(shù)據(jù)倉庫體系結(jié)構(gòu)DWDM 和DMDW，其中DM(Data Mart)是數(shù)據(jù)集市。(2)DBODSDW 架構(gòu)ODS(Operational Data Store)是用于支持企業(yè)日常的全局應(yīng)用的數(shù)據(jù)集合，ODS 解決企業(yè)日常性的問題，只存放當前或近期的數(shù)據(jù)，同操作型數(shù)據(jù)庫類似，其數(shù)據(jù)可進行聯(lián)機增加、刪除、更新等修改，這又有別于數(shù)據(jù)倉庫，數(shù)據(jù)倉庫中數(shù)據(jù)只是增加，沒有修改，因此這又形成了數(shù)據(jù)倉庫DBODSDW 的架構(gòu)。從技術(shù)角度看，集中式的數(shù)據(jù)倉庫為企業(yè)提供統(tǒng)一的數(shù)據(jù)視圖，數(shù)據(jù)一致性可以得到很好保證，因此許多廠商公司企業(yè)都采用集中的數(shù)據(jù)倉庫方案，然構(gòu)建一個集中數(shù)據(jù)倉庫，不僅耗時，而且費力，投入很大，產(chǎn)出效益很緩慢，集中式的數(shù)據(jù)倉庫的存取瓶頸和安全性總究是不容忽視的問題；同時許多大型企業(yè)或公司大多采用總分的組織管理模式，即總公司下設(shè)立了分布各地的下屬分公司，這種模式不僅是現(xiàn)代企業(yè)順應(yīng)業(yè)務(wù)發(fā)展和市場要求的選擇，而且也是實行區(qū)域差異化發(fā)展的基礎(chǔ)，再次網(wǎng)絡(luò)技術(shù)和并行處理技術(shù)的發(fā)展也為數(shù)據(jù)倉庫技術(shù)發(fā)展提供了空間，由此催生了分布式數(shù)據(jù)倉庫應(yīng)用架構(gòu)。分布式數(shù)據(jù)倉庫應(yīng)用架構(gòu)是由總分數(shù)據(jù)倉庫結(jié)構(gòu)組成，分部數(shù)據(jù)倉庫存儲對局部決策有意義的數(shù)據(jù)，總部數(shù)據(jù)倉庫存儲對全局有意義的數(shù)據(jù)。它將從局部數(shù)據(jù)倉庫和總部的操作環(huán)境中抽取數(shù)據(jù)。第五章 數(shù)據(jù)倉庫實現(xiàn) ODS層建設(shè)ODS層是一個面向主題的、集成的、可變的、當前的細節(jié)數(shù)據(jù)層,負責對接口進行抽取，該層更多的存在詳單，是動態(tài)實時變化的，數(shù)據(jù)整合層一般是指構(gòu)建ODS （Operational Data Store，操作性數(shù)據(jù)存儲區(qū)）的過程，有些構(gòu)建過程中可能會做成Stage+ODS； 數(shù)據(jù)整合層是整個系統(tǒng)中數(shù)據(jù)的統(tǒng)一入口，可以說是為數(shù)據(jù)倉庫提供數(shù)據(jù)準備的工作區(qū),經(jīng)常被作為數(shù)據(jù)倉庫的數(shù)據(jù)處理的過渡，以降低直接進行數(shù)據(jù)處理的復(fù)雜度。 接口數(shù)據(jù)抽取接口數(shù)據(jù)抽取就是根據(jù)數(shù)據(jù)倉庫系統(tǒng)數(shù)據(jù)模型的需求，從相應(yīng)的業(yè)務(wù)系統(tǒng)、外數(shù)據(jù)源等中抽取需要的數(shù)據(jù)。抽取出來的數(shù)據(jù)需要經(jīng)過轉(zhuǎn)換，采取同步或異步的方式加載到數(shù)據(jù)倉庫系統(tǒng)中，來滿足總部數(shù)據(jù)的統(tǒng)一規(guī)范。源數(shù)據(jù)接口主要分析數(shù)據(jù)倉庫的數(shù)據(jù)來源，包括源數(shù)據(jù)系統(tǒng)平臺、結(jié)構(gòu)等。典型的源數(shù)據(jù)接口包括數(shù)據(jù)庫接口(ODBC、 OLEDB、專用數(shù)據(jù)庫驅(qū)動接口)和文件接口。對于不同平臺、不同形式、不同業(yè)務(wù)以及不同數(shù)據(jù)量的源數(shù)據(jù)，將采取不同的數(shù)據(jù)抽取接口。在數(shù)據(jù)抽取時需要重點考慮數(shù)據(jù)抽取的效率。對數(shù)據(jù)抽取接口的選擇必須重點考慮數(shù)據(jù)平臺、源數(shù)據(jù)形式、業(yè)務(wù)系統(tǒng)的性能要求以及業(yè)務(wù)量和數(shù)據(jù)量大小。根據(jù)抽取的源數(shù)據(jù)形式，選擇數(shù)據(jù)抽取接口的原則建議為以下幾點：u 對于數(shù)據(jù)形式為關(guān)系型數(shù)據(jù)庫的系統(tǒng)，建議采用ODBC、OLEDB或?qū)Ｓ脭?shù)據(jù)庫驅(qū)動接口方式。u 對于數(shù)據(jù)形式是文件方式的源數(shù)據(jù)，一般直接進入轉(zhuǎn)換和加載流程。u 對于業(yè)務(wù)系統(tǒng)性能要求較高、業(yè)務(wù)量大、不能影響系統(tǒng)性能的系統(tǒng)，一般應(yīng)當采用高性能的數(shù)據(jù)抽取接口，比如：專用數(shù)據(jù)庫驅(qū)動接口、OLEDB接口等。u 對于數(shù)據(jù)量特別大的業(yè)務(wù)系統(tǒng)數(shù)據(jù)的抽取，必須采用高效率的數(shù)據(jù)接口，比如專用的API接口，進行編程。鑒于通信行業(yè)的源數(shù)據(jù)具有數(shù)據(jù)量特別大、業(yè)務(wù)系統(tǒng)工作負荷重和業(yè)務(wù)系統(tǒng)性能實時性的要求較高的特點，建議對于移動數(shù)據(jù)抽取接口一般情況下采用專用數(shù)據(jù)庫驅(qū)動接口，必要的時候采用API接口編程實現(xiàn)數(shù)據(jù)的抽取，以提高數(shù)據(jù)抽取效率同時減少對業(yè)務(wù)系統(tǒng)的性能的影響。下圖為ODS加工流程圖51 ODS加工流程 數(shù)據(jù)抽取策略數(shù)據(jù)的抽取必須能夠充分滿足數(shù)據(jù)倉庫系統(tǒng)分析及決策支持的需要，同時必須保證不能影響業(yè)務(wù)系統(tǒng)的性能，所以進行數(shù)據(jù)抽取時必須充分考慮這些因素，制定相應(yīng)的策略。就抽取數(shù)據(jù)的時效性而言，包括增量抽取、完全抽取等方式。增量抽取即每次只抽取自上次數(shù)據(jù)抽取以來產(chǎn)生的增量數(shù)據(jù)。增量抽取的優(yōu)點是抽取的數(shù)據(jù)量小，從而轉(zhuǎn)換和加載的數(shù)據(jù)量也小，能夠極大提高數(shù)據(jù)加載性能。完全抽取是抽取業(yè)務(wù)系統(tǒng)中指定業(yè)務(wù)的所有數(shù)據(jù)，建議在兩種情況下采用完全抽取方式：u 數(shù)據(jù)量很小，采用完全抽取方式性能更高時；u 無法分離出增量數(shù)據(jù)時。數(shù)據(jù)抽取的時機，必須盡可能避開業(yè)務(wù)系統(tǒng)的高峰時段，聯(lián)通通常在00:0003:00對數(shù)據(jù)進行抽取。對于通信業(yè)務(wù)系統(tǒng)的數(shù)據(jù)抽取，計費、賬務(wù)等數(shù)據(jù)采用增量抽??；對于營業(yè)系統(tǒng)，比如客戶信息的變動等，則提供增量信息，如果只能夠采用完全抽取，然后在數(shù)據(jù)倉庫系統(tǒng)中進行處理的辦法。對于其他的業(yè)務(wù)系統(tǒng)，由于數(shù)據(jù)量相對比較小，可以根據(jù)實際情況制定相應(yīng)的數(shù)據(jù)抽取策略。 ODS層的作用(1)快速接收數(shù)據(jù)采集過程傳過來的大量數(shù)據(jù)，縮短數(shù)據(jù)采集時間，減少數(shù)據(jù)采集對應(yīng)用系統(tǒng)的沖擊； (2)實現(xiàn)對跨系統(tǒng)、多數(shù)據(jù)源的統(tǒng)一數(shù)據(jù)采集，提高了采集數(shù)據(jù)的可靠性和一致性； (3)所有文本式的數(shù)據(jù)，應(yīng)先在整合層集中，再作后續(xù)處理； (4)所有的數(shù)據(jù)后續(xù)處理，因為數(shù)據(jù)整合層，而統(tǒng)一了接口，降低了技術(shù)復(fù)雜性和網(wǎng)絡(luò)不良等因素； (5)數(shù)據(jù)整合層保存了要加載的數(shù)據(jù)，避免了數(shù)據(jù)轉(zhuǎn)換過程對數(shù)據(jù)源的直接操作，減少了對數(shù)據(jù)源的影響； (6)當數(shù)據(jù)倉庫中的數(shù)據(jù)轉(zhuǎn)換出錯或失敗時，可以從數(shù)據(jù)整合層中再次抽取數(shù)據(jù)進行轉(zhuǎn)換，而不必從數(shù)據(jù)源系統(tǒng)中抽取，減少的數(shù)據(jù)源系統(tǒng)的負載，也提高了系統(tǒng)的效率。 DWD層建設(shè) DWD定義DWD是數(shù)據(jù)倉庫的細節(jié)數(shù)據(jù)層，為各種分析類應(yīng)用提供細節(jié)性數(shù)據(jù)支持，是數(shù)據(jù)倉庫的核心，同時為未來需求的擴展提供歷史數(shù)據(jù)支持。DWD層的模型設(shè)計，需要圍繞企業(yè)核心業(yè)務(wù)過程展開，關(guān)注業(yè)務(wù)過程中的核心業(yè)務(wù)事件和業(yè)務(wù)實體，以企業(yè)級數(shù)據(jù)模型規(guī)范為指導(dǎo)，其數(shù)據(jù)域的劃分遵從企業(yè)級數(shù)據(jù)模型域的劃分。 實體選取的原則原則1：業(yè)務(wù)過程中的核心事件實體及相關(guān)維度，長期沉淀，如：通話詳單、繳費等原則2：業(yè)務(wù)過程中的核心業(yè)務(wù)實體及相關(guān)維度，長期沉淀，如：客戶、產(chǎn)品、訂購實例、渠道等原則3：業(yè)務(wù)過程中產(chǎn)生的可度量實體及相關(guān)維度，長期沉淀，如：帳單、傭金等。原則4：面向處理流程的信息，不需要沉淀，如：出帳規(guī)則實體。原則5：控制流程類的信息，不需要沉淀，如：審批過程類信息。 字段選取的原則原則1：刪除與規(guī)則相關(guān)的字段。如：刪除 訂購實例信用額度 實體 中 信用評估規(guī)則標識 字段。原則2：增加和分析相關(guān)的屬性或集團統(tǒng)一編碼。如：用戶資料，增加用戶歸屬片區(qū)等屬性，渠道資料，增加集團統(tǒng)一渠道標識。原則3：增加時間戳或時間拉鏈字段：針對不同類型數(shù)據(jù)，考慮時間處理方式。對于增量數(shù)據(jù)，直接增加時間戳，如：通話詳單類數(shù)據(jù)。對于全量數(shù)據(jù)，即可采用時間拉鏈（生效時間和失效時間），也可時間戳方式，或者混合方式如：用戶資料類數(shù)據(jù)。 數(shù)據(jù)轉(zhuǎn)換(1)數(shù)據(jù)轉(zhuǎn)換的主要功能數(shù)據(jù)轉(zhuǎn)換是指對從業(yè)務(wù)系統(tǒng)中抽取的源數(shù)據(jù)根據(jù)數(shù)據(jù)倉庫系統(tǒng)模型的要求，進行數(shù)據(jù)的轉(zhuǎn)換、清洗、拆分、匯總等處理，保證數(shù)據(jù)按要求裝入數(shù)據(jù)倉庫。如果出現(xiàn)以下原因可能會使數(shù)據(jù)轉(zhuǎn)換工作變得復(fù)雜：u 源數(shù)據(jù)系統(tǒng)同數(shù)據(jù)倉庫系統(tǒng)在模型上的差異性。u 源數(shù)據(jù)系統(tǒng)平臺不一致：數(shù)據(jù)倉庫系統(tǒng)的數(shù)據(jù)源可能包括基于不同平臺的數(shù)據(jù)庫的數(shù)據(jù)。u 源數(shù)據(jù)結(jié)構(gòu)的不一致：有些數(shù)據(jù)源由于歷史的原因，導(dǎo)致同一個表 在不同的時期數(shù)據(jù)結(jié)構(gòu)不一致。u 源數(shù)據(jù)定義不規(guī)范導(dǎo)致錯誤數(shù)據(jù)。u 對數(shù)據(jù)的約束不嚴格，導(dǎo)致無意義數(shù)據(jù)。u 存在重復(fù)記錄。u 由于平臺系統(tǒng)的不同，可能會存在大量的轉(zhuǎn)碼工作。(2)數(shù)據(jù)轉(zhuǎn)換技術(shù)和策略根據(jù)實際情況，數(shù)據(jù)轉(zhuǎn)換工作一般會在以下幾個環(huán)節(jié)中具體實現(xiàn)：u 在抽取過程中進行數(shù)據(jù)處理。u 使用異步數(shù)據(jù)加載，以文件的方式處理。u 在數(shù)據(jù)加載過程中進行數(shù)據(jù)處理。u 進入數(shù)據(jù)倉庫以后再進行數(shù)據(jù)處理。采用在數(shù)據(jù)抽取過程中進行數(shù)據(jù)轉(zhuǎn)換時，必須考慮抽取的性能以及對業(yè)務(wù)系統(tǒng)性能的影響；采用異步數(shù)據(jù)加載需要以文件方式處理時，必須充分考慮中間磁盤的存儲量以及ETL 整個流程的協(xié)調(diào)性工作和大量的非SQL語句的編程；采用在數(shù)據(jù)加載過程中進行數(shù)據(jù)轉(zhuǎn)換時，必須考慮加載性能；采用先將數(shù)據(jù)裝載到數(shù)據(jù)倉庫后再處理時，必須考慮數(shù)據(jù)倉庫引擎的海量數(shù)據(jù)處理能力。(3)對于移動經(jīng)營分析系統(tǒng)數(shù)據(jù)倉庫的數(shù)據(jù)轉(zhuǎn)換工作，建議分別采取如下策略：u 對于數(shù)據(jù)量比較大的計費、賬務(wù)等數(shù)據(jù)，其特點是數(shù)據(jù)比較規(guī)范，域的合法性檢查工作不會太多，可能存在的工作就是不同字段的重新組合、匯總等工作?？梢圆扇?shù)據(jù)裝載到數(shù)據(jù)倉庫以后再進行數(shù)據(jù)的組合、匯總等處理工作。u 對于營業(yè)系統(tǒng)中的開戶等信息，由于歷史原因，各地方移動公司的該部分數(shù)據(jù)在關(guān)鍵信息上可能會存在信息不全或部分信息不符合規(guī)則的問題，比如早期開戶的開戶信息可能缺少個人的基本信息(性別、年齡、身份證號碼等)、出生年月不準確、字段值不符合字段類型要求等，而這些信息對于用戶的分析是極其重要的，尤其是在進行多維分析時。所以必須采用在抽取時以文件的方式進行數(shù)據(jù)的清洗、抽取、組合等轉(zhuǎn)換工作。u 對于其它如客戶服務(wù)數(shù)據(jù)等，根據(jù)實際情況采用相應(yīng)的轉(zhuǎn)換措施。 數(shù)據(jù)加載技術(shù)及策略主要加載技術(shù)：使用數(shù)據(jù)倉庫引擎廠商提供的數(shù)據(jù)加載工具進行數(shù)據(jù)加載和通過數(shù)據(jù)倉庫引擎廠商提供的API編程進行數(shù)據(jù)加載。在兩種數(shù)據(jù)加載技術(shù)中，前一種對于開發(fā)人員來講操作比較簡便；后一種方法需要部分程序編寫工作，但性能上可能會好一些。根據(jù)實際的系統(tǒng)及數(shù)據(jù)量情況進行權(quán)衡。數(shù)據(jù)加載策略主要包括兩