大數據時代運營商分析支撐域轉型的實踐與思考

劉南海，雷蕾，王睿

（中國移動通信集團廣西有限公司，廣西 南寧530022）

大數據時代運營商分析支撐域轉型的實踐與思考

劉南海，雷蕾，王睿

（中國移動通信集團廣西有限公司，廣西 南寧530022）

大數據時代，隨著業務和管理模式向“數據驅動型”轉變，運營商分析支撐域的支撐模型和支撐模式也發生了轉變。制定了分析支撐域規劃，如構建云化ETL、MPP數據庫、能力服務中心、大數據運營支撐平臺等IT基礎設施，實現轉型。同時，提出了分析支撐域在IT、管理和核心競爭力方面的實施思路。

分析支撐域；大數據；Hadoop；MPP

1 引言

伴隨著電子信息技術的飛速發展，計算機軟件硬件技術和網絡不斷更新換代，關系到以互聯網和數據信息處理為核心的行業信息化水平的日益提高。抽象表征人類個體及由個體組成的群體自身屬性和外部行為的各類數據呈爆炸式增長，推動人類社會進入大數據時代。以解決海量數據存儲、計算、挖掘分析為核心的大數據技術的發展，使得數據成為了一種全新的生產要素，帶動業務和管理模式的轉變，驅使工業經濟向數據經濟轉型。

（1）大數據技術的發展奠定了業務和管理模式轉變的基礎

“大數據”一般包含4個方面的意義：數據容量（volume）大、數據類型（variety）多、數據處理速度（velocity）快、數據價值（value）密度低。“大數據技術”通常也針對這4個方面：或解決數據存儲效率低的問題；或適應不同的數據類型（結構化／半結構化／非結構化）；或采用不同的處理框架，提升數據處理效率；或使用不同的分析挖掘模型促進數據價值的轉化。

大數據技術的不斷發展使得數據將逐步成為與勞動力、土地等并列的生產要素。一方面，數據作為對現實世界的抽象和度量記載了各類物體的屬性和之間的行為過程；另一方面，通過一定量的客觀數據描述記載了事務發展的普遍規律，在一定條件下可以發掘成知識以供使用。這兩個過程在實際業務和管理中的出現和發展，意味著業務和管理模式的轉變。

（2）外部競爭和內部降本增效驅動業務和管理模式向“數據驅動型”轉變

互聯網企業OTT（over the top）業務蠶食傳統語音、短信收入，營收“剪刀差”“營改增”對利潤產生的影響以及監管部門“大幅削減營銷費用”的要求，倒逼掌握數據流動通道的運營商“降本增效”。數據作為新的生產要素融入現代化大生產的過程，勢必促使業務和管理模式向“數據驅動型”轉變。對于業務，可通過歷史的銷售數據挖掘產品和客戶之間的潛在關系，用以指導產品銷售，提升銷售效率。對于管理，一方面精確衡量某個管理對象的靜態、動態過程；另一方面基于歷史預測未來，支持管理決策。

2 分析支撐域轉型的實踐

運營商業務和管理模式向“數據驅動型”轉變勢必將對IT基礎設施提出轉型要求。作為企業內部進行數據采集、存儲、分析、挖掘從而完成知識到價值轉化的核心，分析支撐域的轉型迫在眉睫。轉型將涉及IT基礎設施、管理、運營3個維度，其中，IT基礎設施的轉型最為關鍵。通過分析支撐模型和支撐模式的轉變，規劃IT基礎設施的演進并實施，支撐實際運營活動的開展，為大數據時代運營商分析支撐域持續轉型奠定基礎。具體如圖1所示。

圖1 分析支撐域轉型三維度

2.1 在公司IT架構中的位置

使用系統的3類角色（客戶、客服代表、內部員工）分別通過內外部門戶和接觸渠道與公司IT系統發生聯系。公司內部IT系統按照承擔的職責，將其劃分為如下四大域。

（1）業務支撐域

包含客戶關系管理（customer relationship management，CRM）子域和業務運營支撐系統（businessandoperationsupport system，BOSS）子域，面向產品、渠道、定價、促銷等方面。

（2）運營支撐域

主要面向通信網絡，既包含網絡運營的功能，也包含對設備的維護和管理。

（3）管理支撐域

面向企業核心資產——人、財、物的配置、管理和效能管理。

（4）分析支撐域

面向上述三域提供專業的數據分析、決策支持。大數據技術引入前的主要系統是經營分析系統，利用接入業務支撐域的客戶基礎數據和計費賬務數據提供定期數據分析報表和智能查詢服務。

運營商IT分域構成如圖2所示。

2.2 支撐模型和支撐模式的轉變

支撐模型指業務需求、支撐能力要求和支撐方式的集合，是IT能力對業務需求進行匹配的抽象。通過分析確定支撐模型，對IT系統規劃和實施具有指導意義，避免系統與業務目標的偏移；支撐模式指對一個具體需求內容的支撐過程的抽象，是IT人員使用IT能力實現業務目標的過程，更強調組織和管理。

業務和管理模式轉向“數據驅動型”，對分析支撐域的支撐模型和支撐模式提出了新的要求。

對于支撐模型，在傳統經營分析系統“報表展現”業務分析支撐模型的基礎上，增加了“數據驅動運營”“數據價值輸出”兩類支撐模型。“數據驅動運營”面向企業內部，強調通過對歷史數據的相關性進行挖掘形成知識，用知識實時分析當前數據，對后續未知進行預測，基于預測開展行動以體現知識和數據的價值。“數據價值輸出”強調面向企業外部的數據開放，形成跨行業、跨企業的“數據驅動運營”，如圖3所示。

對于支撐模式，由于“數據驅動型”的本質是從海量數據中挖掘知識并探索價值轉化和實施途徑，是一個持續“運行—評估—優化”過程。支撐模式也由傳統的“需求—模型—設計—開發—測試—維護”模式向 “問題—數據源—探索結果—識別模式—優化模型—假設—新問題”的螺旋式模式轉變，并且這種螺旋式支撐模式比起前者分界明顯的“業務人員提需求，技術人員實現”更強調業務人員和技術人員的深度共同協作，具體如圖4所示。

圖2 運營商IT分域構成

圖3 分析支撐域的支撐模型

2.3 面向“數據驅動”的轉型規劃

分析支撐域的IT基礎設施需適應支撐模型和支撐模式的轉變。基于此，制定分析支撐域規劃。支撐模型和支撐模式的分析經歷了兩個階段：首先認識到“大數據關聯分析”對數據存儲、分析、處理方面的能力要求；然后才是“場景運營”對基礎能力和應用整合形成的運營能力的要求。因此，分析支撐域規劃也是兩個階段的過程。

2.3.1 規劃演進一階段

大數據技術引入之前，傳統分析支撐域的范圍極其有限。分析支撐系統和能力分散在BSS（business support system）域、MSS（management support system）域、OSS（operation support system）域中。BSS域分析支撐相對集中，通過經營分析系統整合域內數據，形成統一客戶畫像，主要支撐域內業務分析；OSS域系統分析支撐能力相對分散，分專業建設，分析支撐能力相對較弱；MSS域同樣存在分析支撐能力分散的問題，主要根據各類管理需求建設對應的系統，部分分析需求由經營分析系統支撐。

這種分析支撐能力的情形并不適應不斷增長的數據存儲、分析、處理方面的能力要求，主要體現在小型機架構下高擴容成本、離線分析架構無法支撐高并發量大數據的處理、分散數據訪問、服務以及對四網協同、家庭寬帶流量經營等跨域分析專題支撐不力等方面。為此，同時從跨域綜合分析能力、大數據處理能力、需求和數據管理能力提升方面著手，引入適用的新技術，按低成本、高效益的原則對決策分析的整個體系進行改造，提升能力、提高效益。

圖4 分析支撐域的支撐模式轉變

在邏輯架構上進行分層，統一數據中心、企業數據中心、能力服務中心、分析應用中心各司其職。在統一數據中心，引入基于Hadoop架構的云化ETL，利用分布式文件存儲降低成本，利用分布式批處理計算提升對數據源ETL過程的執行效率，統一接入BSS／OSS／MSS三域數據；在企業數據中心，引入基于MPP的分布式數據庫，利用分布式計算提升高度匯總數據關聯計算的效率，利用無共享（share-nothing）架構提升擴容效率；在能力服務中心，面向上層應用抽象對底層數據操作和基礎功能組件能力，支撐多個應用開發商開發不同的應用，實現應用的“百花齊放”。具體如圖5所示。

2.3.2 規劃演進二階段

云化ETL、MPP數據庫一定程度上提升了數據存儲、分析、處理的基礎能力，使得數據轉化為知識成為可能，能力服務中心也為引入外部廠商開發應用提供了開放環境，促進了知識（各類應用的業務意義正是知識的體現）的“百花齊放”。

知識到價值的轉化離不開運營。數據蘊含的知識通常只是表征一個事物的屬性或者其活動過程的規律，需要通過運營才能轉化為價值。比如，“挖掘出滿足某些條件的客戶有極大可能購買某產品”是知識，可以以客戶標簽的應用形式存在，需要提取客戶清單，選擇合適時機對其開展營銷，產生了產品交易，收了客戶的錢才形成價值。這個過程就是一種運營。

于是，為了提升知識到價值的轉化效率，在一階段的應用中心上規劃了運營中心。運營中心一方面整合應用中心的知識；另一方面連接外部使能系統（如BSS域的銷售渠道、OSS域的控制用戶網絡服務策略的PCRF網元），打通知識到價值的轉換渠道，提供一站式的運營支撐。具體如圖6所示。

2.4 IT基礎設施構建

遵循兩階段的規劃演進，構建云化ETL、MPP數據庫、能力服務中心、大數據運營支撐平臺四大IT基礎設施，支持“數據驅動”轉型。

2.4.1 云化ETL

ETL（extract-transform-load）指數據抽取、轉換、裝載的過程。作為分析支撐域的基礎，能夠按照具體規則將分散于各業務系統的數據進行輕度匯總后集成入數據倉庫，為上層分析應用提供數據支撐。

大數據技術引入前，傳統的ETL過程基于 “小型機+盤陣”的架構，由于與數據倉庫中的高度匯總以及面向應用的數據計算共享計算和存儲能力，在數據量激增的大數據時代出現性能瓶頸。并且CPU和存儲的擴容與性能的提升已經出現強烈的非線性關系，如圖7所示。因此迫切需要引入MPP架構的ETL能力。

圖6 分析支撐域規劃演進二

圖7 SMP和MPP架構

云化ETL包含兩個層面，“云化”指的是采用MPP方式的硬件架構，并且在軟件框架上采用了“云計算”類相關的技術，適用于ETL的過程。云化ETL的核心是Hadoop，如圖8所示。

圖8 云化ETL相關組件結構

（1）Hadoop

是一個分布式存儲和計算的框架，廣泛用于海量數據的存儲和處理。包含HDFS（hadoop distributed file system）、YARN（yet another resource negotiator）、MapReduce、HBase、Hive等組件。

（2）HDFS

是一個適合運行在通用硬件之上的、具備高度容錯特性、支持高吞吐量數據訪問的分布式文件系統，適合大規模數據集應用。

（3）YARN

是一個分布式的資源管理系統，用以提高分布式集群環境下的資源利用率，這些資源包括內存、I／O、網絡、磁盤等。在它上面可以部署MapReduce等各種分布式計算框架。

（4）MapReduce

是分布式大型計算框架，支持MapReduce編程模型，高度適應數據處理的ETL過程。

（5）HBase

是面向列（column-oriented）、適合存儲海量非結構化數據或半結構化數據、高可靠、高性能、可靈活擴展伸縮、支持實時數據讀寫的分布式存儲系統。

（6）Hive

是建立在Hadoop之上的數據倉庫解決方案，支持將結構化的數據文件映射為一張表，提供HQL（hive SQL）實現方便高效的數據查詢，底層數據存儲在HDFS上。Hive的本質是將HQL轉換為MapReduce程序去執行，使不熟悉MapReduce的用戶很方便地利用HQL進行數據ETL操作。

各組件按照圖9的方式以具體的進程實例分布在各種物理節點上，形成具有高度擴展型的IT基礎設施。BDI管理集群向外提供圖形化的集成管理界面，可以對ETL的數據處理流程進行管理和配置。管理階段中的3個主節點作為整個分布式集群管理的核心，維持資源調用的一致性和高可靠性，確保工作節點的工作。同時，HDFS、YARN、HBase、Hive的管理組件進程也部署在管理節點上，與部署在工作節點上的工作組件等一系列靜態進程構成統一的ETL處理工作環境。依靠這些進程，部署和分配ETL數據處理任務后，在工作節點產生一系列的動態進程 （由HDFS等組件的管理進程生成）完成具體的數據處理任務。

云化ETL的硬件部署情況如圖10所示。本期部署了72個節點的集群，包含4個BDI節點、4個管理節點和64個工作節點。節點內部使用萬兆網絡相連，外部管理控制使用吉比特網絡。特別地，云化ETL處理后的輕度匯總數據將通過萬兆交換機與MPP數據庫集群相連，由MPP數據庫集群完成面向分析應用的高度匯總過程。

2.4.2 MPP數據庫

如果說云化ETL解決的是傳統數據倉庫SMP共享存儲架構下，ETL和輕度匯總數據存儲和處理過程性能不足的問題。對應地，傳統數據倉庫的高度匯總和關聯分析需要依靠MPP架構的數據庫來解決。因為云化ETL使用的Hadoop的MapReduce過程更多偏向于離線數據處理，并不適用于多表關聯分析。

圖9 云化ETL組件進程部署

圖10 云化ETL硬件部署

實際中采用的是GBase 8a產品，如圖11所示，這是一個無管理節點的節點對等的架構，每個節點內的CPU不能直接訪問另一個節點的內存，節點之間的信息交互通過節點互聯網實現。這種無共享（share-nothing）架構，使得資源的水平擴展比較容易實現。

在各節點內部，通過GCluster組件管理元數據，對客戶端的SQL請求映射分布式地執行計劃并調度實施，各節點計算完成后，將各自部分的結果匯總在一起得到最終的結果，返回客戶端。GCluster僅能訪問節點內部的數據，跨節點數據關聯由GCluster之間通過高速網絡進行。具體如圖12所示。

MPP數據庫在各節點實現多表關聯計算的過程中，性能的核心在于選擇合適的數據分布鍵使得需要進行關聯的表數據能均勻分布在所有節點相同的數據分區中，這將減少擴節點跨分區的數據連接，極大發揮多節點并行處理的作用。

如圖13所示，對于cust表和sales表的數據，多需要根據cust_id進行關聯。那么將cust_id作為分布鍵對cust表和sales表的數據進行散列分布后，cust_id相同的數據將被分配至相同的節點或者是節點相同的數據分區。如此進行二表關聯時，僅需要在分區和節點內部進行關聯計算，如此極大降低了跨節點／分區的網絡數據消耗。

圖11 MPP數據庫架構

圖12 MPP數據庫對等節點內部組件

圖13 MPP數據庫數據分布和關聯計算

實際部署中，按照46個計算節點、2個數據分發節點的方式部署MPP數據庫集群。48個節點內部使用萬兆網絡相連，其中，2個數據分發節點與云化ETL相連，外部應用和監控管理平臺通過吉比特網絡接入，如圖14所示。

2.4.3 能力服務中心

云化ETL和MPP數據庫針對的是數據層面的問題，數據按照一定的規則面向業務領域進行了構建。為了實現數據到知識的轉化，需要開發各類分析應用，這個應用開發的過程通常是極其個性化和專業化的，也有不同的開發商專注于某個具體的分析應用領域。出于降本增效的考慮，引入開發商之間的競爭，實現應用的“百花齊放”，因此構建能力服務中心，向應用開發商提供統一的數據服務，如圖15所示。

圖14 MPP數據庫部署

圖15 能力服務中心的定位

能力服務中心具體的功能架構如圖16所示，分為展示層、業務層、服務層和數據層。

展示層、業務層主要負責展現能力服務資源管理、能力服務使用管理、能力服務管理中心的界面，控制頁面跳轉。

服務層提供統一的開發規范和數據服務，支持多種形式的能力服務組件；提供用戶權限、應用權限管理及鑒權機制，確保數據安全性及服務可靠性；引入負載均衡及基于內存的數據緩存機制，提高查詢效率，保障服務的及時響應。

圖16 能力服務中心的功能架構

數據層封裝底層數據倉庫，包括傳統Oracle數據倉庫、Hadoop集群和MPP數據庫，通過透明數據層訪問異構數據庫。

2.4.4 大數據運營支撐平臺

云化ETL和MPP數據庫解決基礎數據能力問題，各類應用揭示了數據所蘊含的知識。知識到價值的轉化需要通過運營來實現。事實上，甚至在未引入大數據技術前，就已經有基于傳統Oracle關系型數據庫的精準營銷運營場景，業務人員通過客戶畫像指定業務口徑，從經營分析系統中提取客戶號碼清單，給客戶群發推薦短信，客戶接到短信后去營業廳辦理業務完成銷售，實現了數據到價值的轉化。在這個過程中，客戶數據客觀存在，也通過客戶畫像（應用）形成知識，如果業務人員不指定業務口徑（系統知識與人的知識結合），不提取客戶號碼去群發短信，客戶沒有進行業務訂購，不形成價值。

大數據運營支撐平臺面向具體的運營場景，比如面向市場的大數據銷售模板運營、面向網絡的四網協同運營、面向外部的對外數據服務等。通過連接各應用的功能模塊將涉及的運營環節進行整合，提供一站式運營，如圖17所示。

由于目前僅大數據銷售模板運營較為成熟，所以大數據運營支撐平臺當前主要面向數據驅動營銷進行構建，后續擴展支撐其他方面的運營。

“以產品為抓手，以銷售任務為導向”的大數據銷售模板運營的業務模板包含客戶（customer）、產品（product）、渠道（channel）、時機（time）4 個要素。強調業務（產品）、客戶、場景（時間、空間）及營銷話術等要素協同一體，推動業務（產品）產生增量效益。

基于此業務模型，按照圖18所示的功能框架構建大數據運營支撐平臺。對產品／內容庫、客戶標簽庫、營銷平臺、事件庫、營銷渠道進行功能優化改造，并用大數據運營門戶將運營流程串聯起來，提供面向運營的一站式支撐，提升“數據—知識—價值”的轉化效率。

2.5 運營效果

在大數據運營支撐平臺整合支撐銷售模板運營之前，在沒有大數據技術支撐的傳統Oracle數據庫和大量定制化配置開發、手工數據傳遞等的支撐下，銷售模板運營取得了不錯的效果。見表1，從2013年7月到2014年7月底，累計營銷1.25億次，成功營銷客戶242.7萬人，累計銷售收入達3 348萬元。

有理由相信，隨著分析支撐域云化ETL、MPP數據庫、能力服務中心、大數據運營支撐平臺等IT基礎設施形成生產力，數據的存儲、分析、處理能力增強，知識的提煉、知識到價值的轉化過程將得到固化，更多的運營場景被發掘，結合組織和管理的配套，將有力地驅動運營商業務和管理模式向“數據驅動型”轉變。

3 分析支撐域轉型的思考

大數據技術的發展、企業外部競爭和內部管理的要求驅動著運營商業務和管理模式向“數據驅動型”轉變。相對應，分析支撐域的支撐模型和支撐模式也在發生轉變。基于這種轉變，制定分析支撐域轉型規劃，構建云化ETL、MPP數據庫、能力服務中心、大數據運營支撐平臺等IT基礎設施。這些平臺和功能已陸續上線，需要運營和使用才能發揮能力，形成生產力。系統和平臺的上線僅僅是整個分析支撐域轉型乃至業務和管理模式轉型的起點。

圖18 大數據運營支撐平臺功能框架

表1 大數據技術使用前銷售模板的運營效果

3.1 實時處理

傳統分析支撐域的數據源多以日為周期（每天可以從數據源系統獲得前一天的數據），基于歷史數據進行統計分析，對實時性要求不高，無法支撐如“實時／準實時事件驅動營銷”之類的場景。引入云化ETL和MPP數據庫后，一定程度上提升了數據提取、匯總和查詢的效率，仍無法支撐實時性要求高的場景。需要規劃引入流處理、內存數據庫等IT基礎設施，并且積極推動前端數據源系統向實時消息機制的轉型。

3.2 數據資產化

數據驅動的運營使得數據成為一種資產。需要考慮以資產的方式進行管理，協調考慮數據生命周期、數據價值評估、數據口徑、數據存儲、知識挖掘、數據使用、數據安全等各方面。

3.3 模型挖掘

數據需要通過挖掘才能成為知識，知識通常以一定模型算法的形式存在，這正是分析支撐域的核心競爭力。大數據技術使得對海量數據的挖掘處理成為可能，迫切需在組織機構、管理流程、人才培養方面統籌規劃，建立模型挖掘團隊，開展挖掘研究，提升核心掌控力。

4 結束語

大數據時代，業務和管理模式逐步向“數據驅動”轉型，對電信運營商的IT支撐提出了轉型要求。廣西移動在技術架構上采用“Hadoop”和“MPP”的混搭，實現數據生命周期各種能力的服務化改造以及 “數據驅動營銷”作為應用層的優先切入，確保IT支撐轉型與核心業務支撐的順利銜接，轉型實踐路徑具有推廣借鑒價值。

［1］鄭毅.證析——大數據與基于證據的決策［M］.北京：華夏出版社，2012.ZHENG Y.Analytics：on big data and evidence-based decision［M］.Beijing：Huaxia Publishing House，2012.

［2］BILL F.駕馭大數據［M］.北京：人民郵電出版社，2013.BILL F.Taming the big data tidal wave ［M］.Beijing：Postsamp;Telecom Press，2013.

［3］徐子沛.大數據：正在到來的數據革命 ［M］.桂林：廣西師范大學出版社，2013.XU Z P.The big data revolution ［M］.Guilin：Guangxi Normal University Press，2013.

［4］劉軍.Hadoop大數據處理［M］.北京：人民郵電出版社，2013.LIU J.Hadoop big data processing ［M］.Beijing：Postsamp;Telecom Press，2013.

Practice and thinking on the transition of telecom operator analysis support system in big data era

LIU Nanhai，LEI Lei，WANG Rui
China Mobile Group Guangxi Co.，Ltd.，Nanning 530022，China

In big data era，with business and management mode changing to “data driven”，the support model and support pattern of telecom operator analysis support system has changed.With the ASS planning，cloud ETL，MPP DB，ability service center and big data operation platform were constructed.Also，implementation thinking in aspects of IT，management and core competitiveness of ASS were proposed.

analysis support system，big data，Hadoop，MPP

TN915.07

A

10.11959／j.issn.1000-0801.2016226

2015-05-03；

2016-08-15

劉南海（1982-），男，中國移動通信集團廣西有限公司信息系統部IT專家、工程師，主要承擔BI／大數據系統的IT規劃實施建設及運營工作，主要研究方向為大數據DaaS、PaaS、SaaS的服務化和企業級數據治理。

雷蕾（1978-），女，中國移動通信集團廣西有限公司信息系統部規劃建設室經理、工程師，主要研究方向為云計算、大數據。

王睿（1980-），男，中國移動通信集團廣西有限公司信息系統部大數據開發支撐室經理、工程師，主要研究方向為大數據、IT架構、云計算、網絡安全管控。