运营商大数据平台整体规划

1、运营商大数据平台整体规划1目录12背景及问题分析大数据平台规划方案架构演进历史及现状业务背景及驱动力现状问题分析相关规范及总部要求2经营分析系统架构演进系统现状完成数据仓库重构后到2016年底，数据仓库架构相对稳定JDBC接口经分系统访问门户指标应用报表应用主题分析专题分析临时需求MISBOSSCRM业务平台结构化数据主仓库专题库（历史库）报表库前台库OLAP集市层ETL报表库：省级业务部门报表和取数主仓库：基础数据模型和一经、KPI等关键应用专题库（历史库）：重入网、套餐分析等专题应用和仓库重要历史数据在线存储前台库：主要存放门户配置信息和KPI数据OLAP ：多维分析数据库，主题分析结果数

2、据3JDBC接口接口工具接口工具接口工具应急库经分系统访问门户指标应用报表应用主题分析专题分析临时需求MISBOSSCRM业务平台结构化数据主仓库专题库/历史库互联网半/非结构化数据DPI信令互联网日志Hadoop集群报表库ESOP前台库OLAP集市层ETLETL地市数据中心VGOP创新平台经营分析系统架构演进-业务驱动 为了支撑业务发展，在集团规范和本省业务需求驱动下，进行集市的建设和扩容VGOP：2009年根据集团规范要求建设，支撑数据业务发展ESOP：2011年根据集团规范要求建设，支撑政企业务发展数据挖掘平台：2016年建设，提供体系化数据挖掘专业能力，支撑数据挖掘应用，如一人多卡地市

3、数据分析中心2009年启动地市集中化建设项目，加强地市一线支撑创新平台：2014年建设，承载地市试点应用，如存量维系、校园市场分析等数据挖掘平台4经营分析系统架构演进-架构驱动 随着数据源的不断引入和业务自身的发展，数据仓库也在不断扩容，以满足业务发展需求JDBC接口接口工具接口工具接口工具应急库经分系统访问门户指标应用报表应用主题分析专题分析临时需求MISBOSSCRM业务平台结构化数据主仓库专题库/历史库互联网半/非结构化数据DPI信令互联网日志Hadoop集群报表库ESOP前台库OLAP集市层ETLETL地市数据中心VGOP创新平台数据挖掘平台主仓库：硬件从P690升级到P595、P78

4、0，其中石桥机房由P780承载的主仓正在建设中；历史库：历史数据拆分，专题库转型历史库；ETL：2013年从主仓拆分到接口机，减轻详单拆分合并带来的计算开销；应急库：因每日数据变化量大，主仓无法进行系统容灾，2014年开始建设应急库，实现应用级容灾，保障高可用；接口工具：2015年建设，加强仓库、集市间数据交互管理；互联网日志Hadoop集群：2016年引入网络数据，支撑流量经营重点应用落地；5各系统定位主仓库应急库历史库地市数据分析中心负责基础数据模型的处理并承载KPI、一经等及时性较高的应用数据仓库的应用级容灾，目前还临时承载流量经营相关基础模型数据仓库的历史数据存储、客服集市和重入网、套

5、餐分析等专题面向地市的自助报表、取数机器人、营销快点吧等自助应用创新应用孵化平台报表库VGOP省公司指导、地市试点、各集成商承建的各类创新应用，如存量维系、校园市场分析、流量经营等主要满足省级业务部门的报表和临时统计需求面向数据部的增值业务物理数据集市ESOP数据挖掘平台面向政企客户部的物理数据集市数据挖掘专业平台，如一人多卡、财务扩展平台、终端偏好分析等数据仓库数据集市数据仓库主要负责基础数据模型的处理，承载少量及时性较高应用，数据集市的基础数据来源于数据仓库，并在此基础上支撑端到端应用历史库是从时间维度上对数据仓库数据进行切割部分集市为部门集市，以服务部门为切割维度部分集市为专业集市，以专

6、业功能为切割维度经营分析系统各子系统可归纳为数据仓库和数据集市两大类，数据仓库根据存储数据的周期不同，分为主数据仓库和历史库，数据集市根据服务的部门不同和承载的专业能力不同，分为部门集市和专业集市本次项目重点调整范围厂商分布说明：亚联华为思特奇TD亚联、华为、思特奇、东信北邮6光纤交换机IBM2109-M48历史库2*P595主仓库2*P595应急库4*P570互联网日志Hadoop集群ETL/接口2*P595报表库2*P595VGOP新主仓2*P780ESOP2*P690Teradata光纤交换机ED-48000B千兆局域网交换机VGOP历史库2*DMX3主仓库DMX3ESOPDS8300应

7、急库DMX4ETL/接口DS8300报表库DS8300WEB服务器 PC Server新主仓DS8700地市数据分析中心6*1/2 P750+2*1/2 P595创新应用平台4*1/2 P595WEB服务器刀片地市数据分析中心1*DS8700+1*DMX4创新应用孵化平台DS8300枢纽楼机房石桥机房滨江机房DCN经营分析系统硬件架构 在建22台小机： P595主机11台、 P570主机4台、 P780主机2台、P750主机3台、P690主机2台，5000w tpmC11套存储： EMC DMX系列存储5套、IBM DS系列存储6套，裸容量1200T，可用容量900T7经营分析系统数据架构现状

8、面向业务的应用结果数据汇总，如DW层日新增用户通话信息汇总生成新增用户日通话报表，供前端直接读取；对DWD层进行主题内轻度汇总，根据业务需求舍弃部分维度，实现轻度汇总，如计费话单日汇总将话单中时间戳信息汇总生成时段信息；对轻度汇总的结果进行跨主题的关联，如服务域中的用户信息关联事件域中的计费语音话单汇总结果，生成日新增用户通话信息；仓库明细数据，对ODS数据进行清洗、转换、按业务归类形成集团规范要求的7大概念域；如将用户资料信息归类为服务域、将计费语音话单归类于事件域；ODS层存储的是从外围系统采集的接口数据，与外围系统的数据结构基本保持一致,如用户资料信息、计费语音话单；ST层DW层DWD层

9、ODS层参与人事件服务资源帐务营销财务KPI主题报表一经专题精确营销模型BOSSCRMVGOP财务网管参与人事件服务资源帐务营销财务个人客户统一视图集团客户统一视图 8主仓库：数据来源于BOSS、CRM等源系统，可用空间51.6T，已用空间46T；应急库：除包含主仓库全部数据外，还包含网络数据，可用空间87T，已用空间60T；历史库：主要存储主仓库处理后的历史数据，详单保留3+1月，其他数据6-12月不等，可用空间114.8T，已用空间90T。经营分析系统各子系统数据分布-仓库数据流向ETLMISBOSSCRM业务平台结构化数据互联网半/非结构化数据DPI信令信令/DPI/互联网STDWDWD

10、ODSSTDWDWDODSSTDWDWD互联网主仓库应急库历史库Hadoop集群9经营分析系统各子系统数据分布-数据仓库数据分布数据仓库数据分布数据分层业务标准分类子类数据量（G）周期ODS按数据源划分BOSS计费、账务、结算等大致是日数据三天、月数据三月的原则CRM营业、渠道资源、客服等其它业务平台、上网日志、DPI、信令等DWD按概念域划分参与人客户资料（个人、家庭、政企）、渠道、竞争对手等服务用户资料、用户订购、统一产品等事件语音、短信、GPRS等计费话单、客服、营业工单等账务账户、账单等资源卡号资源等DW按概念域划分参与人同DWD层服务事件账务资源统一视图用户统一视图等ST按应用划分一

11、经MISKPI片区化VGOP信息子层汇总模型报表精确营销模型其他合计10经营分析系统各子系统数据分布-历史库数据分布历史库数据分布数据分层分类原则分类子类数据量（G）周期（月）DWD按概念域划分参与人6服务6事件GPRS详单3+1语音详单3+1短信详单3+1其他详单3+1账务6资源6DW按概念域划分参与人6服务用户24个月，其余12个月事件6账务6资源12ST按应用划分信息子层汇总模型重入网套餐分析客户细分客服运营分析合计11接口工具/JDBC 经营分析系统各子系统数据分布-集市数据流向主仓库/应急库/历史库ETL MISBOSSCRM业务平台结构化数据互联网半/非结构化数据DPI信令互联网报

12、表库地市数据中心创新平台数据挖掘平台VGOPESOP前台库OLAP报表工具（Dblink方式） 地市数据分析中心、创新应用孵化平台在集中化的建设过程中为了地市已有应用的迁移，其数据来源除了数据仓库外，还允许从BOSS、CRM直接抽取数据报表库因先于数据仓库建设，也存在从BOSS、CRM直接抽取数据的情况数据挖掘平台等集市的数据来源是数据仓库，不存在从BOSS、CRM直接抽取数据的情况12经营分析系统各子系统数据分布-地市中心数据分布地市数据分析中心数据分布数据分类子类总分配空间（G）可用空间（G）已用空间（G）基础数据基础数据49,348 15,78933,559 地市应用数据杭州7,5263

13、,908 3,618 湖州1,311914397嘉兴4,521 1,406 3,115绍兴1,359 943 416台州2,048 1,244 803温州3,4541,149 2,305 丽水344324 19 舟山331147 184 衢州2,1001,306 794 宁波7,3202,313 5,006 金华1,278774 504 合计80,94030,217 50,720 基础数据包括从仓库和外围数据源直接抽取的数据，包括客户资料、产品、订购、工单、账单和详单等集市中产生的数据，主要是各地市开发的报表数据和临时取数数据13经营分析系统各子系统数据分布-创新平台创新应用孵化平台数据分类子

14、类共分配空间(G)可用空间（G)已用空间（G）基础数据原始数据16,040 3,818 12,222 各集成商应用数据存量维系5,882 787 5,096 校园1,800 1,293 507 流量提升4,522 291 4,231 IVR6,081 2,821 3,260 行为分析855 452 403 终端运营分析1,573 1,570 3 营销评估2,035 1,670 364 业务稽核1,400 1,321 79 集团产品分析786 785 1 片区化786 786 0 集团市场1,497 206 1,290 流量经营6,128 2,651 3,478 合计49,386 18,452

15、30,933 根据专题需要从仓库和源系统直接抽取的数据，主要包括客户资料、订购、产品和计费汇总数据，不包括计费详单集市产生的数据，主要是各专题产生的应用结果数据14经营分析系统各子系统数据分布-报表、挖掘平台数据挖掘平台数据分布数据分类库名可用空间(G)已用空间(G)周期基础数据PD_CBIC129 6,780 3个月清单数据PD_DLAB155 4,887 3个月挖掘应用PD_MINER148 1,163 3个月财务分析PD_FIN56 15 2年合计489 12,845 备注报表库数据分布数据分类可用空间已用空间（G）周期说明基础数据原始数据113,90122,800 来源于BOSS、CR

16、M等模型数据18,092 来源于数据仓库报表数据指标库2,252 市场运营监控报表数据36,359 合计79,505 备注1、指标表与市场运营监控无法区分故放在一起统计，统计规则为，JFRPT下除去来源于数据仓库的数据与TMP开头数据，其它全部统计在内；2、可用空间：无法按类型区分；3、模型数据：接口工具中从仓库引入的数据；4、报表库数据：TJUSER下除出原始数据、仓库数据、TMP开头的所有数据；基础数据包括仓库模型数据和源系统抽取的数据，包括除详单外的CRM、BOSS主要数据仓库同步的基础数据，主要是客户资料、订购关系等仓库同步的详单数据平台产生的专题应用结果数据报表库产生的数据，主要是报

17、表结果数据等15目录12背景及问题分析大数据平台规划方案架构演进历史及现状业务背景及驱动力现状问题分析相关规范及总部要求16流量经营时代带来的大数据挑战随着移动互联网的不断发展，智能终端迅速普及、移动数据流量迅猛增长，流量收入占比快速攀升，流量经营已是运营商战略转型的重点。而流量经营带来的大数据挑战是IT系统架构亟待解决的问题互联网日志 通过综合网关获得CMWAP/CMNET两类日志，日话单记录数达到40亿条，奠定用户内容偏好分析的基础；位置信息 通过网络A口全量引入位置变更信息，日话单记录数达到12亿条，奠定活动轨迹行为分析的基础；Gn口数据 通过DPI设备从Gn口全量获得用户的应用使用行为

18、信息，如QQ、微博、微信等，日话单记录达到70亿，奠定用户应用偏好分析的基础；1、为了支撑流量经营的发展，引入DPI、互联网日志和位置信令等多种网络数据源2、网络数据与传统数据相比有非结构化特征传统计费话单新增大数据3、与传统数据相比，网络数据在数据量上有质的变化，并且还在快速增长，根据思科2011-2016年度网络猜测陈述，预计到2016年网络数据流量平均年复合增长率为78%17大数据的特点和对IT系统的核心要求1. Volume2. Variety3. value4. Velocity结构化数据、半结构化数据和非结构化数据如今的数据类型早已不是单一的结构化数据，也包括音频、图片、视频等非结

19、构化数据，对数据处理能力提出了更高的要求沙里淘金，价值密度低以视频为例，一部一小时的视频，在连续不间断监控过程中，可能有用的数据仅仅只有一两秒。如何通过强大的机器算法更迅速地完成数据的价值提取是目前大数据汹涌背景下亟待解决的难题实时获取需要的信息实时性大数据区分于传统数据显著的特征。如今已是ZB时代，在如此海量的数据面前，处理数据的效率就是企业的生命大数据技术将被设计用于在成本可承受（economically）的条件下，通过非常快速（velocity）的采集、发现和分析，从大数据量（volumes）、多类别（variety）的数据中提取价值（value），将引起IT 领域新一轮的技术与架构的变

20、革。数据量巨大全球在2010 年正式进入ZB 时代，IDC预计到2020 年，全球将总共拥有35ZB 的数据量18传统IT架构应对大数据挑战存在的不足存储层： 1）数据量不断增加，带来的IO瓶颈；2）容易造成数据分布不均匀，导致IO热点。 网络层： IO传输带宽不足，无法快速传输大量数据到服务器。主机层：接收过多数据进行处理，CPU、内存成为瓶颈。传统数据库小型机+UNIX+中高端存储升级本机硬件资源来提升性能结构化数据解决方案X86 PC Server+本地存储分布式架构结构化、非结构化数据支持BIG DATAEconomicallyVelocityVolumeVariety=传统小型机+高

21、端存储的数据库架构存在性能、成本、扩展性上的瓶颈，无法满足大数据时代在低成本前提下在海量、多样的数据中实时地提取价值的要求。因此，大数据时代的IT架构需要有所转变：19目录12背景及问题分析大数据平台规划方案架构演进历史及现状业务背景及驱动力现状问题分析相关规范及总部要求20现状分析一：现有架构在处理海量数据时存在系统瓶颈，无法满足业务要求数据采集接口机采集Hadoop处理应急库DB2入库、处理48时0时24时宽广实时采集数据，次日4点完成前日完整数据采集，每日数据70亿Hadoop每小时从接口机加载数据，汇总后加载入应急库，次日12点完成前日完整数据处理，入库数据量5亿应急库对前日数据进行批

22、处理，次日21点完成DPI次日21点，看到前日完整数据处理结果宽连实时从东方通信采集数据并进行处理，处理后数据分发到接口机，次日17点完成数据分发互联网日志应急库次日17时发起入库，T+2日10点完成入库72时T+2日18点看到T+0日完整数据处理结果应急库T+2日11点开始处理数据，处理8-10小时，T+2日18时完成处理接口机每小时从宽广采集数据，次日7点完成前日完整数据采集DPI需要21小时后可以看到昨日数据，互联网日志需要42小时，位置信令需要16小时，业务部门要求9点钟前看到昨日业务指标21当日（T+0日）次日（T+1日）T+2日接口机实时接收宽连分发的数据，次日17时完成数据接收，

23、每日数据量40亿实时、准实时批处理现状分析一（续）：现有架构在处理海量数据时存在系统瓶颈，无法满足业务要求数据采集接口机采集Hadoop处理应急库DB2入库、处理48时0时24时中创实时采集数据，次日3点完成前日完整数据采集，每日数据库12亿接口机实时从中创采集数据，次日3点完成前日数据采集位置信令Hadoop次日3点开始从接口机加载前天全量数据，并进行批量处理，次日12点完成处理后加载入应急库，入库数据量2.5亿应急库次日12点开始处理，次日16点完成处理72时12次日16时看到前日完整数据应急库当日10点启动入库程序，实时入库，次日2点完成前日完整数据入库，入库数据量6.5亿GPRS详单次

24、日7点完成前日数据处理应急库次日2点钟开始处理前日完整数据，次日7点完成处理16计费实时分发到接口机次日2点完成前日数据分发，数据量每日6.5亿DPI需要21小时后可以看到昨日数据，互联网日志需要42小时，位置信令需要16小时，业务部门要求9点钟前看到昨日业务指标22当日（T+0日）次日（T+1日）T+2日接口机实时接收计费分发的详单，次日2点完成前日完整数据接收实时、准实时批处理现状分析一（续）：系统瓶颈分析-接口机目前，外围数据源与数据仓库，数据仓库与各数据集市之间的交互都依靠接口机，面对百亿级数据，1G带宽的接口机成为数据传输瓶颈，影响数据传输的及时性。1、交互数据量大：Jfrdetl1

25、主机平均每日数据交互量约为5t,平均75MB/s，jfrdetl2主机平均每日数据交互量为4t，平均70M/S。2、业务流程相对集中：KPI、一经等业务对数据及时性要求高，大量业务运行时段相对集中，网络带宽压力进一步加剧，导致部分业务数据延迟 ，月初峰值能达到8595M/s。3、交换机带宽不足，现有设备扩容困难：应急库建设期间，现有交换机经过反复测试，只找到4个高速口，1台主机只能分配1个高速口，达不到高可用要求，接口机的扩容要求在现有条件也很难做到主机承载业务业务流程描述数量(个)空间(G)日月日月JFRDETL1计费入库计费主动通过FTP推送数据文件201000ETL经分通过C程序去BOS

26、S/CRM的正式或BC库抽取快照数据2744508003000对外接口导出精确营销模型、ESOP、VGOP等16919410090互联网位置信息经分FTP从中创获取数据文件，实时装载入DB2150接口工具实现内部数据的交互,ORADB2、仓库集市报表库数据交互(导出)130125300500实现内部数据的交互,ORADB2、仓库集市报表库数据交互(导入)9744100100JFRDETL2DPI数据经分FTP从宽广获取数据文件,FTP到大数据平台，经过处理再入DB2（压缩）550互联网内容数据经分FTP从中创获取数据文件，实时装载入DB2950接口工具实现内部数据的交互,ORADB2、仓库集市

27、报表库数据交互(导出)11370100150实现内部数据的交互,ORADB2、仓库集市报表库数据交互(导入)29021450050023现状分析一（续）：系统瓶颈分析-应急库3、网络：jfrddw11和jfrddw13的网卡收发容量峰值时达到了规划值的90%-95% ，jfrddw12和jfrddw14表现正常。其中1号机负责详单入库、DPI和位置信令数据入库，3号机负责传统数据入库（客户资料、订购等）和GPRS上网日志数据入库。2、存储：存在热点盘，部分磁盘IOPS较多，13%的磁盘（共80块）需要处理40%的主机IO。主要处理的是写集中的IO，后端磁盘的繁忙导致写数据在Cache中有堆积，

28、会导致写IO延迟增加。热点盘主要是数据库日志读写引起。目前综上所述，主机、网络、存储、数据库都表现为较为繁忙，均存在瓶颈，短期需要对关键瓶颈进行优化来缓解系统压力，但并不能彻底解决问题，从长期看需要考虑系统的扩容或者架构调整。性能分析结论4、主机： 每日7-13点，主机内存使用率较高，达到90%，CPU使用率也较高（usr+sys维持在90%-100%），其它时段内存、CPU使用正常。可以得出的结论是系统在上午7点到13点之间系统压力大5、数据库：通过分析数据，可以看到应急库存在较多的排序溢出，存在排序溢出问题，排序溢出率较高，超过3%的正常值，最高时超过80%，说明系统目前的排序参数设置不合

29、理，亟需调整。取Jfrddw11网卡流量情况存储总体性能报告24现状分析二：数据分布缺乏规则，造成数据冗余，数据交互缺乏统一管理，造成数据质量隐患和数据交互延迟数据分布缺乏规则，数据仓库、各数据集市等共有4份ODS数据，存在冗余，造成空间浪费；数据交互缺乏统一管理，仓库、集市存在多套ETL工具，接口形式存在文件接口、dblink等多种方式，同时集市违反统一数据源原则直接从源系统抽取数据的情况，不仅反复抽取对BC库造成压力，同时存在数据不一致的隐患，影响数据的准确性；现有ELT模式将数据在库内进行清洗转换工作，不仅增加了数据仓库的处理负荷，而且导入和导出的动作影响到仓库与集市数据交互的及时性。挖

30、掘应用数据挖掘(13T)DWDWD报表应用报表库(80T)DWODS地市个性化应用地市中心(50T)DWODS 创新应用创新平台(31T)DWVGOP应用VGOP数据ESOP应用ESOP数据一经、KPI、MIS应用数据仓库(46T)DWDWDODSODSCRM/BOSS123412T19T11T0.18T23T12T8TVGOP(50T)ESOP(7T)16T1.5T报表工具，实现方式为存储过程+dblink，共部署6套，报表库1套，地市中心四中心四套，创新平台1套，合计1982个接口仓库/应急ETL，实现方式C+程序+文件接口，合计1666个接口25接口工具，实现方式java程序+文件接口，

31、合计815个内部接口目前历史库数据存储方式依然为传统的小型机+磁盘阵列的模式，这种模式下随着相关经分系统数据量的快速增长而需要不断的进行系统扩容，硬件投资和运维成本较高。硬件及运维成本分析目前经分历史库的数据存储周期缺乏统一管理，保持周期长短不一，同时容量已趋近极限，各类详单的存储周期满足不了长周期深度趋势分析的业务需求，其中GPRS计费详单还以年均60%的速度快速增长，网络侧的历史数据目前并没有放入历史库中，由于其数据特点（百亿级、增长快），采用传统数据库构建模式建设历史库，成本将过于昂贵。现状分析三：数据生命周期缺乏管理，历史数据存储不满足集团规范要求和业务长周期趋势分析需求1、数据存储周

32、期缺乏规划，容量趋于饱和，存储周期不满足业务长周期趋势分析需求：历史库各类详单要求存储至少6+1月，目前只保存3+1月，占总数据量的62%2、GPRS详单数据量占全部详单数据量51%，而数据还在快速增长，年增速60%：3、海量网络侧数据目前没有放入在历史库业务日记录条数（亿）日文件大小（G）DPI701900互联网内容40950用户位置12150历史库数据分布数据分层分类数据量（G）周期（月）DWD60246CDRGPRS261602+1CALL199673+1SMS81333+1其他18943+1DW123426至12ST154436至12合计8996326目录12背景及问题分析大数据平台规

33、划方案架构演进历史及现状业务背景及驱动力现状问题分析相关规范及总部要求27相关规范及总部要求李跃总裁:“着力培育新的竞争优势，要改善服务、提高流量经营水平、巩固移动通信市场优势” 中国移动2012年工作会议刘爱力副总裁:“持续提升CRM、BOSS和综合分析的协同能力，提高对流量经营的支撑水平。1、推动网络设备改造，实现对流量按网络、位置、时段、终端、业务等维度综合分析；2、提高对流量套餐评估和销售支撑能力；3、持续提高流量消费的服务保障能力” 2012年集团业务支撑工作会议 流量经营关系公司未来，面对当前存在的问题与挑战，集团公司对于流量经营工作提出了明确的要求。奚国华董事长:“在战略转型方面

34、，深化四网协同发展，有效促进从以语音经营为主向语音、流量经营并重; 加快积累基础设施资源，积极做好全业务运营的各项准备工作；发挥优势，有所作为，积极构建移动互联网主导地位“ 中国移动2012年工作会议28目录12背景及问题分析大数据平台规划方案大数据处理架构的总体目标国内外大数据分析案例大数据处理目标架构及定位大数据分析平台选型技术要求29现有经分系统优化方案存储热点盘，13%的磁盘（共80块）需要处理40%的主机IOPS网络主机数据库1、3号主机达到网络瓶颈，峰值是目标值的90-95%每天6-18点CPU使用率较高（90-100%）、1号机内存使用率较高（90%）排序溢出率较高，超出3%正常

35、值，最高达到80%短期优化方案：短期内通过对现有系统从存储、网络、主机、数据库和应用等层面进行优化，缓解系统面临的压力该热点盘主要是数据库重做日志读写引起1、3号机作为入库协调节点，负责数据到其它数据节点的分发该时间段是终端和网络数据处理等大作业运行的业务高峰期需要处理的数据量较大，单表记录在亿级别关闭数据库镜像日志，减少热点盘的数据库日志写压力，5月15日执行，热点盘IOPS最高下降50%，整体IOPS下降20%每个节点通过san直接load数据，将load分成拆分文件和加载文件两阶段，计划6月底进行可行性验证，验证通过后实施，预计可消除1、3号机的网络瓶颈优化劣质SQL，峰值从93%下降到

36、83%整合数据模型，减少系统相似处理步骤，降低仓库主机性能开销，计划7月底完成，效果待评估建议放大sortheap参数10倍，计划5月底前完成验证和实施，效果待评估问题分析优化措施网络接口机机达到网络瓶颈，峰值是目标值的90-95%承载内外部数据交换，业务流量大，交换机无闲置端口扩容交换机，主机实施双网卡绑定，增加带宽接口机应急库30经分系统扩容的方式无法满足长期规划需求，建议调整大数据处理架构扩容方式扩容成本主库：石桥新主库（2台P780，约1200w TPMC）需扩容约900w TPMC的计算能力，存储空间不需要扩容（主仓裸容量180TB，可用126TB，DB2 v9.7压缩比40%）；应

37、急库：应急库（4台P570，约900w TPMC）需扩容约1200w TPMC的计算能力，以及约20TB的有效存储空间（应急库可用空间87TB，DB2 v9.7压缩比40%）；历史库：历史库需扩容约500TB的有效存储空间（现有可用空间100TB，版本升级后压缩40%）.为满足至2014年底的需求，经分系统共需扩容2100w TPMC的计算能力，以及520TB的有效存储空间，扩容硬件总成本约2400万元现有经分系统（IBM小型机+磁盘阵列+DB2数据库）可以扩容，但是其水平扩展性差，虽然可以通过扩容满足短期的业务需求，考虑到数据的快速增长和非结构化数据的出现，难以满足长远的大数据分析需求;现有

38、经分系统的扩容成本高，若采用X86+本地盘的云架构，相同TPMC的X86平台价格是IBM小型机价格的1/10，相同容量的普通硬盘价格是高端存储+SAN网络价格的1/20；因此建议调整大数据处理架构，引入基于分布式技术的云架构，以满足流量经营大数据分析需求.评估结论需求评估：当前主库（2台P595，约600w TPMC）每日处理约2TB的资料和详单数据，基本能满足业务需求，但系统已没有富余的处理能力（CPU峰值达到80-90%，业务已经不允许上线）；若同时承载每日约3TB网络数据的处理，根据规模的估算，并考虑0.6的扩展系数，主库应具备600+600/0.6=1600w TPMC的计算能力；根据

39、业务发展趋势，网络数据的年增长率约为50%，因此规划至2014年底，主库/应急库应具备600+600*1.5/0.6=2100w TPMC的计算能力和140TB的有效存储空间，历史库应具备约800TB的有效存储空间.31系统架构调整原则和思路目前经分历史库的数据存储周期缺乏统一管理，保持周期长短不一；历史库容量已趋近极限，各类详单的存储周期不满足集团规范要求和业务长周期深度趋势分析需求.历史数据存储3合理规划数据存储周期，完善数据的生命周期管理，历史数据存储网络数据3+1月、计费详单数据6+1月，满足集团规范要求和趋势性分析的业务需求流量数据处理2调整数据分布，将数据量大、系统资源消耗高的流量

40、数据处理过程从数据仓库中剥离出来，减轻主仓库的压力，提升数据处理的及时性；引入基于分布式技术的云架构，负责流量数据（包括网络数据、计费详单）的汇总处理，提升经分系统的大数据处理能力和数据处理的及时性.统一ETL流程及数据交换1建立统一的ETL流程，将ODS至DWD层的数据清洗、转换过程移至数据仓库外，减轻仓库压力，提升数据处理的及时性；参照ESB架构，建立统一的数据交换平台，负责各系统的数据统一交换和集中管理，提升数据交换的及时性和规范性；禁止数据集市抽取存储ODS数据，消除数据冗余，提高数据的准确性和数据分布的合理性.大数据处理架构数据生命周期缺乏管理网络数据和计费详单数据量大，现有架构在处

41、理海量数据时存在系统瓶颈，主机、网络、存储、数据库都较为繁忙，处理时延严重，无法满足业务要求.系统性能存在瓶颈，处理时延严重数据分布缺乏规则，数据仓库、各数据集市等共有4份ODS数据，造成数据冗余和空间浪费，也影响数据的一致性；目前网络数据仅在应急库上运行.数据分布缺乏规则数据交互缺乏统一管理，数据源与数据仓库、数据仓库与集市之间依靠接口机进行点对点数据交互，且存在文件、dblink等多种接口方式，接口机成为数据传输瓶颈，影响数据的及时性；部分集市存在直接从源系统抽取数据的情况，对BC库造成压力，同时存在数据不一致的隐患，影响数据的准确性；现有ELT模式在库内进行数据清洗转换工作，不仅增加了数

42、据仓库的处理负荷，而且导入和导出过程影响了仓库与集市数据交互的及时性。数据交互缺乏统一管理经分系统现状问题32目录12背景及问题分析大数据平台规划方案大数据处理架构的总体目标国内外大数据分析案例大数据处理目标架构及定位大数据分析平台选型技术要求33移动集团集中化经分案例：主数据仓库+深度分析云+非结构化数据云数据采集多渠道访问门户应用专区、专题分析、指标等非结构化数据云基于高性能平台，预计610TB低成本技术，3套，预计1983TB主数据仓库深度分析云基于X86平台，预计668TB电脑智能手机PAD从各省经采集语音、短信、GPRS和彩信等全量明细数据；采集互联网网页和日志搭建主数据仓库，满足集

43、中化经分数据存储及分析需求，主数据仓库数据压缩后存储需求预计：610TB；按照应用专区、专题分析和指标等构建前端应用技术验证：自助分析需求构建智能手机和平板电脑接入方式提高系统易用性历史存储&自助服务技术验证：深度分析云承担历史数据存储和查询技术验证搭建非结构化数据云，实现互联网内容分类和日志分析，存储需求为668TB自助分析准实时采集互联网网络日志非结构化数据A省经B省经X省经一级系统业务平台结构化数据批量采集重点建设内容摘自中国移动集团信息管理处 2012年工作总结及2013年工作计划34eBay大数据分析架构案例：EDW+深度分析+Hadoop深度分析- Singularity刷新 60

44、 个以上的数据分析数据集广泛清理和安全筛选EDWEDW/ADW/ODW“与去年的用户活动比较”趋势和预测分析（大量历史数据）运营分析交易分析大批量临时查询低端企业级系统区分上下文的复合分析季节性消费品纵深数据集生产数据仓库大型并发用户群发现和探索分析和报告+100+并发用户500+并发用户企业级系统5-10并发用户图像指纹处理图像分类图案识别检测假冒产品和虚假描述产品将非结构化数据结构化检测图案Hadoop商业硬件系统6+PB55PB20+PB摘自2011年Teradata University Extreme Analytics at eBay - Oliver Ratzesberger 3

45、5目录12背景及问题分析大数据平台规划方案大数据处理架构的总体目标国内外大数据分析案例大数据处理目标架构及定位大数据分析平台选型技术要求36大数据处理目标架构及定位构建云化数据交换平台，承担生产数据的清洗转换过程、互联网日志的预处理，以及各系统之间的数据交换功能，既能减轻数据仓库压力，提升数据处理的及时性，也能规范数据分布，统一数据的交换管理；新建大数据分析平台，负责网络数据和详单数据处理，支撑流量经营分析，提升数据处理的及时性和数据分布的合理性；低成本构建云化历史库，负责主仓库和大数据分析平台的历史数据存储，以及历史数据挖掘、趋势分析预测等，完善数据的生命周期管理.访问层应用层数据层经分系统

46、访问门户指标应用报表应用主题分析专题分析临时需求互联网DPI半/非结构化数据ERPBOSSCRM客服网元设备信令终端配置信息业务平台结构化数据主数据仓库云化历史库海量多结构化数据的分布式处理分析大数据分析平台地市数据中心创新平台报表库数据挖掘平台VGOPESOP前台库OLAP集市层云化数据交换平台云化数据交换平台云化数据交换平台云化数据交换平台历史数据存储趋势分析预测企业运营智能结构化数据分析获取层数据源37大数据处理目标架构及定位（续）数据迁移：目前DPI数据、GPRS上网日志、位置信令和详单数据的处理分析过程部署在DB2系统中，建议迁移至云化数据交换平台和大数据分析平台；新增数据：WLAN

47、上网日志、宽带上网日志数据为今年计划从网络侧新引入到大数据分析平台的数据.大数据分析平台定位：大数据分析：负责非结构化和海量数据处理，包括（DPI 数据、GPRS上网日志、位置信令、WLAN上网日志、宽带上网日志）和详单数据的处理分析，形成DW汇总层模型，以及基于大数据的深度行为分析，如进行路径分析、社交网络分析等.云化数据交换平台（含ETL）定位：日志预处理：负责GPRS、WLAN、宽带等互联网日志的预处理，生成结构化数据；ETL处理：负责数据抽取、校验等预处理工作；负责对ODS原始生产数据进行清洗、转换，形成遵循第三范式、面向主题的DWD基础层数据模型；并负责数据加载入库.数据交换：负责各

48、系统之间的数据交换.主数据仓库定位：传统结构化数据处理：负责传统的结构化、轻量级数据处理和及时性较高的KPI、一经等传统经营分析应用.历史库定位：历史数据存储：存储长周期历史数据，包括主数据仓库和大数据分析平台的历史数据；长周期趋势分析：开展海量历史数据挖掘、趋势分析预测等.38大数据处理架构的总体性能量化目标云化数据交换平台加载性能：12小时完成11TB的数据加载，峰值数据加载速度 1TB/小时清洗转换能力：12小时清洗转换数据量 7T，峰值数据清洗转换能力 600GB/小时数据导出能力： 12小时完成26TB的数据导出，峰值数据导出速度 2.2TB/小时扩展能力:200台规模内，增加节点后

49、，系统的性能扩展系数 0.8大数据分析平台云化历史库加载性能：12小时完成6TB明细数据加载进入大数据分析平台，峰值数据加载速度 500G/小时处理性能：6小时内完成流量、计费200亿条记录、12TB数据的处理，数据处理能力 2TB/小时存储能力：流量数据、详单数据的存储周期 7天，数据存储总量 80 TB扩展能力：100台规模内，增加节点后，系统的性能扩展系数 0.8加载性能：12小时内完成云化数据交换平台、大数据分析平台和主仓库当日产生的模型数据11TB，数据加载峰值速度 1TB/小时压缩能力：数据压缩比 1:6存储能力：历史库数据存储计费6+1月，网络3+1月，资料12+1月，总量 83

50、0 TB扩展能力： 100台规模内，增加节点后，系统的性能扩展系数 0.8具备支撑14年底网络、计费详单数据处理的计算能力具备支撑14年底网络数据3+1月、计费详单数据6+1月的数据存储的能力满足业务核心数据每日8点前查看T-1数据的需求（核心业务包括集团考核和发送管理层KPI彩信）39大数据处理目标架构数据分布参与人事件服务资源帐务营销财务BOSSCRMVGOP财务网管DPI信令互联网主数据仓库历史库云化数据交换平台ST层面向应用主题计算结果数据DW层（轻度汇总）面向分析主题汇总数据模型在DWD层基础上汇总而得DWD明细层面向业务主题的明细数据遵循第三范式ODS接口层按系统划分结构与源系统相

51、同DWD明细层由云化数据交换平台同步而来，事件域进大数据分析平台，其余进主仓大数据分析平台完成网络、详单数据的轻度汇总后，再同步给主数据仓库进行跨主题域交叉关联，生成ST共享数据层，供集市应用使用.参与人服务资源帐务营销财务KPI主题报表一经专题精确营销参与人事件服务资源帐务营销财务个人客户统一视图集团客户统一视图 参与人事件服务资源帐务营销财务KPI主题报表一经专题精确营销流量经营参与人事件服务资源帐务营销财务个人客户统一视图集团客户统一视图 大数据分析平台流量经营事件网络详单事件网络详单DW层（关联汇总）面向集市应用的共享数据跨主题域的汇总40云化数据交换平台主数据仓库8：大数据分析平台将

52、DW层数据导入主库，由主数据仓库进行横向跨主题交叉关联，生成共享数据层，供集市应用使用6：主仓库负责DWD层数据向DW层、ST层的汇总，并将主仓库DW层、ST层数据同步给云化历史库；7：大数据分析平台负责网络数据和详单数据从DWD层向DW层、ST层的汇总过程，并将其DW层、ST层数据同步给云化历史库1、2：生产系统数据导入云化数据交换平台，在云化数据交换平台上进行数据的清洗和转换，完成ODS到DWD的数据模型转换除网络/详单外的DWD数据加载网络/详单类DWD数据加载大数据处理目标架构数据流向大数据分析平台3、4、5：DWD层数据通过多加载方式进入主数据仓库、历史库和大数据分析平台，其中网络数

53、据和详单数据仅加载进入大数据分析平台，其余数据进入主数据仓库，全量数据加载进入云化历史库，数据之间关系为3+5=4DPI半/非结构化数据互联网ERPBOSSCRM客服网元设备信令终端配置信息业务平台结构化数据地市数据中心创新平台报表库数据挖掘平台VGOPESOP前台库数据集市云化数据交换平台DWDDWSTDWDDWSTODSDWDODSDWD主库DW数据主库ST数据云化历史库全量的DWD数据加载DWDDWSTDW数据ST数据123546789：通过云化数据交换平台向各数据集市同步所需数据941大数据处理目标架构数据流向（续）客户资料、订购关系类数据分布及流向云化数据交换平台主数据仓库D1：通过

54、云化数据交换平台向各数据集市同步所需数据C1：主仓库负责数据从DWD层向DW层的汇总过程，生成DW层数据模型C1；C2：将主库DW层数据C1通过云化数据交换平台同步给云化历史库C2A1：客户资料、订购关系类的生产系统数据导入云化数据交换平台，在云化数据交换平台上进行数据的清洗和转换，完成ODS到DWD的数据模型转换大数据分析平台B1、B2：云化数据交换平台处理后的DWD层数据文件通过多加载进入主数据仓库和云化历史库DPI半/非结构化数据互联网ERPBOSSCRM客服网元设备信令终端配置信息业务平台结构化数据地市数据中心创新平台报表库数据挖掘平台VGOPESOP前台库数据集市云化数据交换平台DW

55、DDWSTDWDDWSTODSDWDODSDWD云化历史库DWDDWSTA1B1B2D1C1C2除网络/详单外的DWD数据加载网络/详单类DWD数据加载全量的DWD数据加载42大数据处理目标架构数据流向（续）网络流量、计费详单类数据分布及流向云化数据交换平台主数据仓库D1：通过云化数据交换平台向各数据集市同步所需数据C1：大数据分析平台负责计费详单、网络数据从DWD层向DW层的汇总过程，生成DW层数据模型C1；C2：将大数据分析平台的DW层数据通过云化数据交换平台同步给云化历史库C2；C3：将大数据分析平台的DW层数据通过云化数据交换平台同步给主数据仓库C3，后续再进行跨主题域交叉关联生成DW

56、/ST共享数据层，供集市应用使用A1：网络流量、计费详单类的生产系统数据导入云化数据交换平台，在云化数据交换平台上进行数据的清洗和转换，完成ODS到DWD的数据模型转换大数据分析平台B1、B2：云化数据交换平台处理后的DWD层数据通过多加载进入大数据分析平台和云化历史库DPI半/非结构化数据互联网ERPBOSSCRM客服网元设备信令终端配置信息业务平台结构化数据地市数据中心创新平台报表库数据挖掘平台VGOPESOP前台库数据集市云化数据交换平台DWDDWSTDWDDWSTODSDWDDWDDWSTA1B1B2D1C2C1C3云化历史库除网络/详单外的DWD数据加载网络/详单类DWD数据加载全量

57、的DWD数据加载43各平台数据存储周期及数据量需求（单位：TB）平台名称云化数据交换平台主数据仓库大数据分析平台历史库数据类型类型描述现有量增长率周期数据量周期数据量周期数据量周期数据量资料数据日明细0.7/天10%3天2.33天2.3No03天2.3月明细2.3/月10%3月7.63月7.6No012月30.4日汇总3/月10%No01+1月6.6No03+1月13.2月汇总3/月10%No03月9.9No012+1月42.9详单数据明细数据0.8/天30%3天3.1No07天7.36+1月218.4日汇总DS0.05/天30%No03天0.27天0.53+1月7.8日汇总DT1.5/天30

58、%No01天21天21天2日汇总DM0.25/月30%No01+1月0.71+1月0.73+1月1.3月汇总MS1.5/月30%No03月5.93月5.912+1月25.4月汇总MM0.05/月30%No03月0.23月0.212+1月0.9网络数据明细数据3/天50%3天13.5No07天31.53月405日汇总DS0.2/天50%No03天0.97天2.13+1月36日汇总DT0.7/天50%No01天1.11天1.11天1.1日汇总DM1/月50%No01+1月31+1月33+1月6月汇总MS0.7/月50%No03月3.23月3.212+1月13.7月汇总MM0.2/月50%No03月

59、0.93月0.912+1月3.9应用区0102020总计26.5 * 2 = 5354.578.483044大数据处理目标架构关键点分布访问层应用层数据层经分系统访问门户指标应用报表应用主题分析专题分析临时需求互联网DPI半/非结构化数据ERPBOSSCRM客服网元设备信令终端配置信息业务平台结构化数据主数据仓库云化历史库海量多结构化数据的分布式处理分析大数据分析平台地市数据中心创新平台报表库数据挖掘平台VGOPESOP前台库OLAP集市层云化数据交换平台云化数据交换平台云化数据交换平台云化数据交换平台历史数据存储趋势分析预测企业运营智能结构化数据分析获取层数据源3. 构建云化历史库2. 构建

60、大数据分析平台1. 构建云化数据交换平台4. 现有系统配合改造45大数据处理目标架构关键点详解-云化数据交换平台云化数据交换平台具备文件级校验、数据级校验、清洗、转换、关联、合并等多种操作功能，实现计算逻辑的前移，形成统一的DWD层，并具备多加载能力替换现有接口工具和多套ETL工具（主仓库、报表库、地市数据分析中心、创新平台等），并实现云化部署现有CRM、BOSS接口数据抽取以全表抽取为主，占用了大量网络资源开销，本次建设在保证抽取数据质量的前提下，将评估增量抽取的可行性，以降低网络资源开销参考集团规范制定适用于本省的接口规范， 进行接口的定义，实现接口统一管理接口形式统一为文件接口接口开发、