通信線路狀態統計數據倉庫與OLAP應用范文
本站小編為你精心準備了通信線路狀態統計數據倉庫與OLAP應用參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。
1OLAP數據倉庫總體設計
數據倉庫(DataWarehouse，DW)是一個面向主題的、集成的、非易失的，隨時間變化的數據集合、支持管理部門的決策過程［1］。為了滿足企業的需求，首先要對關系型數據和其它外部數據源進行抽取、轉換、清洗，然后將處理過的數據裝載到數據倉庫中。聯機分析處理(OLAP)從數據倉庫中提取數據并建立多維數據集，使得用戶可以利用多維數據集多角度、多層次地觀察數據倉庫中的數據，從而選取有價值的信息。線路狀態統計系統的OLAP數據倉庫總體結構如圖1所示。圖1數據倉庫總體結構圖(1)通信源數據。源數據主要包括了通信運營企業的各種業務數據、外部數據以及與之相關規定的文檔資料等。(2)數據倉庫服務器。通信源數據通過ETL工具的數據清洗、轉換等操作后，把歷史數據集成到數據倉庫中。其中，還包含數據倉庫監控管理和數據倉庫的元數據管理。(3)OLAP及數據挖掘。數據倉庫搭建好之后，在其基礎之上建立多維數據集和進行數據挖掘工作。
2．1通信線路狀態統計系統數據分析近年來，通信行業的快速發展，累積了大量的業務數據，這些數據包含了大量與企業發展相關的信息。通過對通信線路狀態統計系統數據庫系統的研究，得到與之相關的主要源數據表有32個，如端口統計表、測試統計表、每小時統計表等。
2．2數據倉庫主題的確定數據倉庫中的數據是面向主題組織的。主題是在較高層次上將企業信息系統中的數據進行綜合、歸類和分析利用的一個抽象概念，每一個主題基本對應一個宏觀的分析領域［2］。針對需求分析，根據得到的分析型業務需求，結合應用系統及其數據的調研與數據分析的結果，按照通信公司數據庫的特點，通信線路狀態統計系統的主題可以分為端口統計主題、小時類統計主題、測試類統計主題。
2．3設計數據倉庫邏輯模型和物理模型目前，最流行的數據倉庫數據模型是多維模型［3］。多維模型大多以星型模式、雪花型模式或事實星座模式的形式存在。本文采用雪花型模式。雪花型模式雖不如星型模式流行，但雪花型模式減少了數據的冗余。在數據倉庫的邏輯結構中，數據表可以劃分為兩類:一類是事實數據表(簡稱為事實表)，用來存儲數據倉庫的實際數據，如通信線路狀態統計的端口統計表即是一個事實表;另一類是維度數據表(簡稱為維度表)，用來存儲數據倉庫的維度數據，如端口數目表、端口類別表、日期表、設備表等分析角度均為維度表等。事實表是數據倉庫的核心，也是數據倉庫中最大的表。事實表包含了通信線路狀態統計的基本情況等詳細信息，是對通信線路狀態統計進行分析的素材。事實表的設計包括對事實的選擇、量度的構造、粒度的設計和聚合的設計等。在本數據倉庫設計中，共有3個事實表:端口統計事實表、測試統計事實表、每小時統計事實表。維度表是商務智能的基本驅動力。通過維的切換，可以從不同的角度觀察客觀世界。基于不同的維度，可以看到各量度的匯總情況，也可以同時從多個不同的維度進行交叉分析。該數據倉庫設計中，主要有29個維度表。如時間表、日期表、設備表、端口表等。在確定了數據倉庫邏輯模型的事實表和維度表后，就要確定物理模型。數據倉庫的物理模型就是數據倉庫邏輯模型在物理系統中的實現模式，包括了邏輯模型中各種實體表的具體化，例如表的數據結構類型、索引策略、數據存放位置和數據存儲分配以及物理模型的優化操作等［4］。完成數據倉庫的邏輯模型和物理模型的設計后，就可以創建數據倉庫。數據倉庫也是一種數據庫，因此在邏輯結構設計完成之后可以跟普通的數據庫一樣創建、修改和刪除。
2．4數據抽取、轉換和加載完成數據倉庫的設計后，就需要通過ETL工具往數據倉庫中裝載數據。ETL，即數據抽取(Extract)、轉換(Transform)、裝載(Load)的過程，是負責完成數據從源數據向目標數據倉庫轉化的過程，是實施數據倉庫的重要步驟，是構建數據倉庫的重要一環［5］。用戶從數據源抽取出所需的數據，經過數據清洗，最終按照預先定義好的數據倉庫模型，將數據加載到數據倉庫中。目前，通信業務數據量越來越大，并且分布散亂、存儲形式多樣化，而原有的系統都是各公司根據自己的需求建立的小型系統，統計的標準多樣化，數據的存儲形式也不統一。如數據源可以是Oracle數據庫、關系型數據庫、純文本數據、XML文件等，這就給編碼增加了難度。因此首先要搜集通信企業各分公司的數據，然后將分公司的數據從Oracle數據庫或Excel表格等數據源中抽取到企業數據庫中，然后再進行ETL轉換。首先對以前的數據代碼進行統一規范，然后建立數據維表進行規范，最后按照清洗規范對數據進行ETL。ETL的設計和實施約占在整個項目中工作量的60%～80%，這是從眾多實踐中得到的普遍共識［6］。
2．5建立olap多維數據集根據通信線路狀態統計系統的需求分析，可以將數據倉庫劃分主題，根據不同的主題建立相應的多維數據集:由于在線路狀態統計過程中要統計分析的報表較多，因此數據倉庫按照要統計分析報表的類別來劃分多維數據集，大致劃分為以下3個:(1)端口統計模型分析，常用報表是使用頻率較高的報表，如端口類型、端口穩定性、端口狀態、端口在線時長等。在此多維數據集中有45個維度。如端口維度、日期維度、區域維度、設備維度、端口狀態維度、端口穩定性維度、終端類型維度、實際激活模式維度、端口黑名單維度、上行實際速率分段維度、下行實際速率分段維度等。(2)小時類統計模型分析，小時類報表是按小時統計分析的報表，如誤碼1小時統計、掉線1小時統計等。在此多維數據集中有3個維度，分別為:日期維度、設備維度、區域維度。小時類統計模型如圖2所示。圖2小時類統計模型主題分析(截圖)圖3測試統計模型主題分析(截圖)(3)測試統計模型分析，測試類報表時統計測試數據的報表，如線路測試故障統計、測試端口數統計、TOPn測試端口統計、測試策略統計等。在測試統計模型中有8個維度，分別為:測試線路維度、日期維度、區域維度、設備維度、測試結論維度、測試結論分段維度、測試項目維度和測試策略維度。測試統計模型如圖3所示。本文利用SSAS(MicrosoftSQLServer2008Analy-sisServices)建立多維數據集。首先建立數據源與數據源視圖，然后建立多維數據集模型，定義維度與事實度量，建立多維數據集。
3通信線路狀態統計系統的實例分析
商務智能的前端產品負責直接面向用戶，將用戶的請求轉發給服務器層、數據層，同時也向用戶展現所需信息。下面將對通信線路狀態統計系統進行實例分析。在實例中，分析結果采用重慶宏信軟件公司的極光商務智能工具(ABIS)進行前端展示，并利用表格和圖形等形式將分析的結果直觀地呈現給最終用戶，使用戶更容易理解。
3．1端口狀態統計分析端口穩定性統計趨勢報表用來顯示一段日期的一定范圍內的xDSL端口穩定性的統計變化趨勢如圖4所示。行元素選取“端口穩定性”，列元素選取“端口數”和“日期”，其中“日期”選取“日”為粒度。端口穩定性有“穩定”、“有風險的”、“不穩定的”和“未標明的”的4種狀態。圖表中選取2011．01．24-2011．04．30的數據。其中圖形還可以選擇用柱形、曲線、餅圖和密度圖等多種形式展現出來。由圖表所展示的統計信息可看出，在4種端口穩定性中，變化趨勢是比較清晰的，沒有交叉。“未標明的”端口數目明顯比其它幾種的多一些且呈逐漸上升的趨勢，說明端口數目在不斷地增加，客戶越來越多;“穩定的”端口呈先升后降的趨勢;“有風險的”端口和“不穩定的”端口是比較少的，說明整個端口穩定性是維持在一個相對理想的狀態。運營商可針對以上統計分析，對端口穩定性的運行和維護做有效的調整，以保證為廣大用戶提供更完善的服務。
3．2小時類統計模型分析掉線1小時統計趨勢報表用來顯示一天每小時的一定范圍內的xDSL端口的掉線端口數。結果如圖5所示，行元素選取“異常掉線端口數”、“異常掉線端口數(%)”和“設備”，列元素選取“年-月-日-小時”。圖表中所選為2011年4月30日的數據。由圖表所展現的統計信息可以看出，在一天內各時段的異常掉線端口數中，凌晨2點以前的掉線端口數幾乎可以忽略不計，從凌晨2點開始異常掉線端口數呈上升的趨勢，中午12時達到頂峰，然后呈下降的趨勢;而一天內各時段的異常掉線端口數(%)基本維持在0．5%以下。一天內各時段的異常掉線端口數變化趨勢可以提前讓運營商對運維人員做出相應的調整;而一天內各時段的異常掉線端口數(%)說明了掉線端口數整體上維持在相對合理的水平。
3．3測試端口數統計分析測試端口數統計趨勢報表顯示一段日期的線路測試次數的統計變化趨勢。如圖6所示，行元素選取“測試線路數”，列元素選取“日期-年-月-日”，圖表中所選為2010．8．1到2010．8．7的數據。分析這幾日的線路測試次數的變化，借助趨勢圖可以看出測試線路測試次數的統計變化趨勢。如此，可以根據趨勢圖來預測測試線路變化情況，及時做出相應的調整。
4結束語
本文的研究意義在于將數據倉庫與OLAP技術應用于通信線路狀態統計中。通過建立數據倉庫和多維數據集，為通信企業分析提供準確的信息，更為后續的數據挖掘等分析提供準確、更具有針對性的數據。下一步的工作重點除完善數據倉庫和OLAP模型，還將引入數據挖掘技術來分析通信線路狀態的潛在規律等。