數據倉庫和OLAP技術在CRM投訴分析中的應用研究

岳鵬，劉淑娟

（1 重慶郵電大學通信學院 重慶 400065； 2 西南大學計算機學院 重慶 400715）

0 引言

目前的網絡業務運行監控還存在一些問題，精細化程度不夠，難以發現具體網元的運行隱患；后分析方式的被動監控多，主動監管少。出現上述問題的一個重要原因就是在日常網絡業務運行監控中，忽略了大量、多種網絡業務信息（例如非緊急/重要投訴信息）和沒有更可靠的支持主動監控技術。

因此，充分利用各種網絡業務運行信息，通過科學的主動監控技術發現網絡業務運行中的潛在問題，實現有效的主動監控預警分析，才可以及時預警改進，并進一步推進集中監控的精細化，提高網絡業務運行的安全性、穩定性。

其次，當前的網絡管理是基于各網元管理系統實現的，在功能上主要實現了網元管理層和各自網絡設備管理層的功能，沒有面向業務的管理功能。因此故障信息都是基于設備而無法與投訴等業務和客戶相關聯。在故障監控方面很難做到主動監控，目前主要還是接受申告的被動維護。

1 BI解決方案結構設計

鑒于上訴背景, 利用某運營商客服投訴系統近年來長期積累的某運營商客戶投訴數據，進行原始數據的分析，建立相應的數據倉庫, 根據投訴主題建立多維數據集，在此基礎上利用OLAP技術從多角度、多側面、多層次對某運營商CRM投訴數據進行分析，對某運營商客戶投訴進行了科學系統的分析評估。進而做針對性的改進，提高某運營商對廣大客戶的服務質量。CRM投訴主題監控的BI解決方案整體結構如圖1所示。

圖1 XX運營商CRM投訴主題監控的BI解決方案結構

2 CRM投訴原始數據分析

原始數據分析結果的可行性、有效性、透徹度等，將直接關系最終的多維分析的角度，直接影響某運營商網絡服務質量的真實反映的準度和深度，對最后服務質量的改進起著決定性的作用。

開始至今，積累了相當數量的客戶投訴數據，這些投訴數據包含了大量與某運營商服務質量相關的有用信息。通過對大量客戶投訴數據的研究，得到與某運營商網絡服務質量相關的主要觀察數據主題：(a)網絡投訴量；(b)各公司投訴量；(c)業務投訴類型統計； (d)不同用戶類型投訴統計分析。

3 數據倉庫模型設計

3.1 設計方法

數據倉庫(Data Warehouse)是支持管理決策過程的、面向主題的、集成的、隨時間變化持久的數據集合[1]。其設計方法有兩種：自下而上和自上而下。自上而下的設計方法強調應用決定數據，有什么應用就獲取什么數據，設計維度和多維數據集是項目的開始；自下而上的設計方法首先要依據系統文檔與需求分析來創建數據倉庫,然后根據不同的分析主題建立多維數據集[2]。

本文采用自下而上的設計方法,圍繞CRM投訴數據分析為主題來建立數據倉庫。

3.2 數據結構

目前最流行的數據倉庫多維數據結構有3種:星型結構、雪花型結構和混雜型結構[2]。

星型結構是一種典型的數據結構，它以事實表為中心，一組維度表在星型結構的頂尖，事實表和每個維度表通過主鍵連接在一起,組成一個星型結構。雪花型結構是用一組或多組數據表與某些維度表相互鏈接，進而有效地描述維度表的復雜程度和層次。混雜型結構是綜合了星型結構和雪花型結構的優點。

本文綜合考慮，介于某運營商CRM投訴綜合查詢對效率和準確度的追求，最終決定采用星型結構。

星型結構是非范式的、以查詢為中心的模型，這種模型的最大優點是能夠提供所謂的星連接，即通過一步連接就可以獲取大部分所需要的信息，并很快得到輸出結果，這在常規的事務處理數據庫結構中是很難做到的。在這種模型中信息分為兩大類：事實表和維度表。星型結構對本文主題數據查詢十分適合。

數據倉庫的模型設計是數據倉庫設計的一個重要方面。本文以某運營商客戶投訴分析主題來組織數據,以CRM投訴作為事實表,以用戶品牌，用戶級別，投訴區域，故障描述，時間為維度表。

3.3 事實表的粒度

數據越詳細,粒度就越小,數據級別也就越小;數據綜合度越高,粒度也就越大,級別也就越高。而事實粒度需求的不同,一方面將直接導致數據倉庫模型設計的差異,另一方面將直接影響存儲容量與分析效果,因此粒度的設計極其重要。

由于本文需求分析中,不僅需要對細節性數據進行分析,而且需要對綜合數據進行分析,因此采用了多重數據粒度的設計方法。這也是針對業務量大、分析要求比較高的情況采用的最理想的解決方法[2]。

4 數據整合

4.1 數據源

業務數據是數據倉庫的數據源，而對業務數據的了解是設計數據倉庫的基礎。只有通過對業務數據的分析，才可以清楚地知道原有數據系統中已有什么指標，再結合用戶的需求，才能明確當前數據倉庫的設計能提供需求中的哪些指標，還缺少哪些指標。總之，通過對歷史數據和需求的分析，可以明確用戶正在使用的數據現狀、他們如何使用這些數據以及將來利用這些數據干什么。

本數據倉庫的數據來源于某運營商客服服務系統所統計積累的客戶投訴的歷史數據，涉及到的數據主要有投訴工單號，投訴受理時間，投訴業務類型，投訴故障描述，投訴區域，投訴用戶品牌，投訴用戶級別，分公司等。

4.2 數據的抽取、轉換與裝載（ETL）

設計好數據倉庫的模型之后，就需要把歷史數據裝載到數據倉庫去。歷史數據中存在大量的錯誤的、不一致等問題，數據質量是分析結果可靠性的基礎，而ETL(數據抽取、轉換、清洗和加載)是數據質量的重要保障[3]。ETL包含以下3個過程:

(a)抽取：從多個異構的不同結構或者不同格式的文件中抽取數據到目標數據庫臨時表中。

(b)轉換：抽取出的數據可能存在異常值或者缺失值等情況，為了保證數據的完整性和一致性，需要對不同的原始數據進行清洗和加工，并最終轉換成目標數據所要求的格式。

(c)加載：將以上步驟處理后的數據裝載到目標數據倉庫的事實表，維度表和視圖表中去。

為了確保數據倉庫中的數據更加準確，首先對某運營商公司近半年的歷史客戶投訴數據進行分析，先將數據從數據源抽取到臨時數據表，并形成一套標準的CRM投訴的業務代碼對應表，然后建立CRM投訴業務代碼表清洗規范，最后采用SSIS(Microsoft SQL Server 2008 Integration Services)逐日對某運營商提供的客戶投訴原始數據進行抽取、轉換和清洗,并裝載到目標數據倉庫中。最終所完成的ETL流程如圖2所示。

圖2 ETL流程圖

ETL在整個數據倉庫系統中的位置處于數據源與目的數據倉庫之間，貫穿于整個解決方案的全過程，管理數據的質量，并且對整個系統的數據進行處理與調度。ETL涉及到大量的業務邏輯和異構環境，在一般的數據轉換項目中ETL部分成為了牽扯精力最多的部分，故而ETL規則設計和實施約占在整個項目中工作量的60%～80%，這是從眾多實踐中得到的普遍共識[4]。

5 建立OLAP多維數據集

在上文中，設計好數據倉庫,并且將業務數據經過ETL數據整合之后,需要進一步根據CRM投訴這一分析主題建立相應的多維數據集。OLAP多維分析以多維數據集為基礎。多維數據集是數據分析時用戶的數據視圖，是面向分析的數據型,可以給分析人員提供多種觀察的視角和面向分析的操作,即將數據看作多維的數據立方體[5]。利用SSAS(Microsoft SQL Server 2008 Analysis Services)建立多維數據集。設計出的CRM投訴分析多維數據集的數據星型模型如圖3所示。

圖3 CRM投訴分析多維數據集數據模型

圖3模型中,表頭顏色較暗的是維度表，有CRM用戶品牌維度表、CRM用戶級別維度表、CRM故障描述維度表、CRM投訴區域維度表、時間維度表；表頭顏色較亮的是CRM客戶投訴事實表。多維數據集的度量值是CRM投訴量。

多維數據集的存儲方式有3種： ROLAP、MOLAP和HOLAP[6]。本文采用MOLAP方式存儲 ,它將細節數值和合計數值都存放在立方體中,可將多維視圖直接映射到數據立方體數組結構。這種存儲方式的優點是可以對數據立方體的數據快速索引[7]。通過對多維數據集的切片、切塊、鉆取等多種操作，可以從多個角度分析CRM投訴數據，來分析網絡投訴量、各公司投訴量、業務投訴類型統計、不同用戶類型投訴統計、同地市VIP用戶投訴統計等投訴情況。

6 CRM投訴分析前端展現與結果實例分析

商業智能的前端產品負責直接面向用戶,將用戶的請求轉發給服務器層、數據層,同時也向用戶展現所需信息。商業智能前端產品極光商智（ABIS），以圖形等直觀形式，聯動的調整和展現分析結果。

首先，將CRM投訴分析多維數據集，添加到ABIS的數據源管理器中。利用ABIS的超級分析器，部署所關注的CRM投訴分析角度和層面，然后保存為共享報表，最后以圖形和圖表形式展現分析結果。

6.1 實例1：網絡投訴量分析

網絡投訴量統計結果如圖4，時間切片選取粒度“月”，圖表中所選為某年某月數據，切片還可選擇周為粒度。圖形還可以選擇疊加柱形、曲線、折線等多種圖形形式來展示。

圖4 網絡投訴量柱形圖數據表

由圖表所展示的統計信息可看出，該公司的各大片區的網絡投訴量中，主城區的投訴量明顯高出各片區公司近9～10倍，而各片區之間投訴量相差不遠。這種結果可能由幾種情況導致：(a)主城區用戶數量高于各片區用戶數量; (b)主城區用戶密集程度高于各片區地區，對設備的使用頻率較高，導致設備出現故障幾率增大；(c)主城區用戶所用網絡業務較于各片區種類繁多，類型復雜，導致軟硬件服務設備更容易產生故障；(d)主城區用戶對網絡質量要求指數較高，對網絡狀況出現的問題較為敏感。以上分析中，(b)、(c)點應該是主要因素，運營商可據此統計，對主城區的軟硬件設備做更頻繁的安全檢修。以保障為廣大用戶提供更完善的服務。

6.2 實例二： 各公司投訴量分析

如圖5所示，各公司投訴量統計結果中，時間切片選取粒度“周”，圖表中顯示的是某年第某周的數據，及切片還可選擇“月”為粒度。度量值除了投訴量，還增加了計算列：投訴量占比，可醒目的顯示，各片區公司投訴量的所占比重。圖形還可以選擇疊加柱形、曲線，折線等多種圖形形式來展示。

圖5 各公司投訴量柱形圖數據表

因主城區公司的投訴量明顯高于各片區公司，故將主城區展開到下一層（行政區層）。有圖可得知，主城區各行政區中，南岸區、九龍坡區和沙坪壩區的投訴量居高，這3個區均屬老城區，所以這3個區的通信設備可能使用年限較久，應注意安全檢查，設備維修，必要時要更換新設備。

6.3 實例三業務投訴類型統計分析

如圖6所示，業務投訴類型統計結果中，時間切片選取粒度“周”，及切片還可選擇“月”為粒度。圖形還可以選擇疊加柱形，曲線，折線等多種圖形形式來展示。不同的業務類型以不同的色彩標志，各業務類型還可以往下層鉆取。

圖6 業務投訴類型統計柱形圖數據表

圖6將投訴總量最大的話音基本業務下鉆到次層，再將次層的網絡覆蓋類型下鉆至第三層。可透徹詳細地看到每個投訴的具體問題是什么。由圖可知，話音基本業務中的室內覆蓋問題是投訴的主要問題。室內是用戶每天所停留時間最長的場所，所以，此方面的投訴要格外重視。運營商可想辦法把用戶密集的地區的居民住宅的語音信號覆蓋率進一步加大，來給用戶提供更為優質的服務。

7 總結與展望

本文利用某運營商客戶服務中心積累的豐富的客戶投訴信息資源，經過數據的ETL預處理到聯機分析的數據倉庫中，并建立CRM投訴分析多維數據集，最后對這些數據進行多維分析并將結果用工具“極光商智”以圖形、報表的形式進行展現。本文的分析結果，對某運營商客戶服務質量的提升具有一定的指導意義。下一步的工作重點是借助數據挖掘技術，利用已經建立好的數據倉庫和多維數據集，進一步揭示出隱含在投訴數據中的規律和信息，從而為投訴問題的預測分析進行科學導向。

[1]Inmon W H.數據倉庫[M].3版.王志海,林友芳 譯.北京:機械工業出版社,2003.

[2]朱德利.SQL Server 2005 數據挖掘與商業智能完全解決方案[M].北京:電子工業出版社,2007:189-191.

[3]Brian K, Erik V.SQL Server 2005 Integration Services 專家教程[M].馮飛 譯.北京:清華大學出版社,2008:20-29.

[4]Vassiliadis Panos,Simitsis Alkis,Skiadopoulos Spiros.Conceptual Modeling for ETL Processes[M]. Virginia USA.14-21.

[5]Andreas S. Maniatis,Panos Vassiliadis.Advanced Visualization for OLAP//Proceedings of the 6th ACM International Workshop on Data Warehousing and OLAP. New Orleans: Louisiana, 2003: 9-16.

[6]Melome E,et al.SQL Server 2005 Analysis Services 標準指南[M].武桂香 譯.北京:電子工業出版社出版社,2008:56-61.

[7]柳進,胡政,唐降龍.OLAP數據倉庫在電網調度決策中的研究與應用[J].計算機工程與設計,2005,26(2):296-311.

[8]鐘建強.IP核心網的BGP增量規劃[J].電子測試,2011(07):54-57.

[9]愈大國.綠色通信網的設計分析[J].電子測試,2010 (12):87-93.