移动集团大数据平台规划

移动集团大数据平台规划,1,目录,1,2,背景及问题分析,大数据平台规划方案,架构演进历史及现状业务背景及驱动力现状问题分析相关规范及总部要求,2,经营分析系统架构演进08年之前的系统现状,2005年完成数据仓库重构后到2008年底，数据仓库架构相对稳定,报表库：省级业务部门报表和取数,主仓库：基础数据模型和一经、KPI等关键应用,专题库（历史库）：重入网、套餐分析等专题应用和仓库重要历史数据在线存储,前台库：主要存放门户配置信息和KPI数据,OLAP ：多维分析数据库，主题分析结果数据,3,经营分析系统架构演进-业务驱动,为了支撑业务发展，在集团规范和本省业务需求驱动下，进行集市的建设和扩容,VGOP：2009年根据集团规范要求建设，支撑数据业务发展,ESOP：2010年根据集团规范要求建设，支撑政企业务发展,数据挖掘平台：2011年建设，提供体系化数据挖掘专业能力，支撑数据挖掘应用，如一人多卡,地市数据分析中心2009年启动地市集中化建设项目，加强地市一线支撑,创新平台：2010年建设，承载地市试点应用，如存量维系、校园市场分析等,数据挖掘平台,4,经营分析系统架构演进-架构驱动,随着数据源的不断引入和业务自身的发展，数据仓库也在不断扩容，以满足业务发展需求,主仓库：硬件从P690升级到P595、P780，其中石桥机房由P780承载的主仓正在建设中；,历史库：历史数据拆分，专题库转型历史库；,ETL：2011年从主仓拆分到接口机，减轻详单拆分合并带来的计算开销；,应急库：因每日数据变化量大，主仓无法进行系统容灾，2012年开始建设应急库，实现应用级容灾，保障高可用；,接口工具：2011年建设，加强仓库、集市间数据交互管理；,互联网日志Hadoop集群：2012年引入网络数据，支撑流量经营重点应用落地；,5,各系统定位,主仓库,应急库,历史库,地市数据分析中心,负责基础数据模型的处理并承载KPI、一经等及时性较高的应用,数据仓库的应用级容灾，目前还临时承载流量经营相关基础模型,数据仓库的历史数据存储、客服集市和重入网、套餐分析等专题,面向地市的自助报表、取数机器人、营销快点吧等自助应用,创新应用孵化平台,报表库,VGOP,省公司指导、地市试点、各集成商承建的各类创新应用，如存量维系、校园市场分析、流量经营等,主要满足省级业务部门的报表和临时统计需求,面向数据部的增值业务物理数据集市,ESOP,数据挖掘平台,面向政企客户部的物理数据集市,数据挖掘专业平台，如一人多卡、财务扩展平台、终端偏好分析等,数据仓库,数据集市,数据仓库主要负责基础数据模型的处理，承载少量及时性较高应用，数据集市的基础数据来源于数据仓库，并在此基础上支撑端到端应用,历史库是从时间维度上对数据仓库数据进行切割,部分集市为部门集市，以服务部门为切割维度,部分集市为专业集市，以专业功能为切割维度,经营分析系统各子系统可归纳为数据仓库和数据集市两大类，数据仓库根据存储数据的周期不同，分为主数据仓库和历史库，数据集市根据服务的部门不同和承载的专业能力不同，分为部门集市和专业集市,本次项目重点调整范围,厂商分布说明：,亚联,华为,思特奇,TD,亚联、华为、思特奇、东信北邮,6,光纤交换机IBM2109-M48,历史库2*P595,主仓库2*P595,应急库4*P570,互联网日志Hadoop集群,ETL/接口2*P595,报表库2*P595,VGOP,新主仓2*P780,ESOP2*P690,Teradata,光纤交换机ED-48000B,千兆局域网交换机,VGOP,历史库2*DMX3,主仓库DMX3,ESOPDS8300,应急库DMX4,ETL/接口DS8300,报表库DS8300,WEB服务器 PC Server,新主仓DS8700,地市数据分析中心6*1/2 P750+2*1/2 P595,创新应用平台4*1/2 P595,WEB服务器刀片,地市数据分析中心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，可用容量900T,7,经营分析系统数据架构现状,面向业务的应用结果数据汇总，如DW层日新增用户通话信息汇总生成新增用户日通话报表，供前端直接读取；,对DWD层进行主题内轻度汇总，根据业务需求舍弃部分维度，实现轻度汇总，如计费话单日汇总将话单中时间戳信息汇总生成时段信息；对轻度汇总的结果进行跨主题的关联，如服务域中的用户信息关联事件域中的计费语音话单汇总结果，生成日新增用户通话信息；,仓库明细数据，对ODS数据进行清洗、转换、按业务归类形成集团规范要求的7大概念域；如将用户资料信息归类为服务域、将计费语音话单归类于事件域；,ODS层存储的是从外围系统采集的接口数据，与外围系统的数据结构基本保持一致,如用户资料信息、计费语音话单；,ST层,DW层,DWD层,ODS层,参与人,事件,服务,资源,帐务,营销,财务,KPI,主题,报表,一经,专题,精确营销模型,BOSS,CRM,VGOP,财务,网管,参与人,事件,服务,资源,帐务,营销,财务,个人客户统一视图,集团客户统一视图, ,8,主仓库：数据来源于BOSS、CRM等源系统，可用空间51.6T，已用空间46T；应急库：除包含主仓库全部数据外，还包含网络数据，可用空间87T，已用空间60T；历史库：主要存储主仓库处理后的历史数据，详单保留3+1月，其他数据6-12月不等，可用空间114.8T，已用空间90T。,经营分析系统各子系统数据分布-仓库数据流向,ETL,MIS,BOSS,CRM,业务平台,结构化数据,互联网,半/非结构化数据,DPI,信令,信令/DPI/互联网,ST,DW,DWD,ODS,ST,DW,DWD,ODS,ST,DW,DWD,互联网,主仓库,应急库,历史库,Hadoop集群,9,经营分析系统各子系统数据分布-数据仓库数据分布,10,经营分析系统各子系统数据分布-历史库数据分布,11,接口工具/JDBC,经营分析系统各子系统数据分布-集市数据流向,主仓库/应急库/历史库,ETL,MIS,BOSS,CRM,业务平台,结构化数据,互联网,半/非结构化数据,DPI,信令,互联网,报表库,地市数据中心,创新平台,数据挖掘平台,VGOP,ESOP,前台库,OLAP,报表工具（Dblink方式）,地市数据分析中心、创新应用孵化平台在集中化的建设过程中为了地市已有应用的迁移，其数据来源除了数据仓库外，还允许从BOSS、CRM直接抽取数据报表库因先于数据仓库建设，也存在从BOSS、CRM直接抽取数据的情况数据挖掘平台等集市的数据来源是数据仓库，不存在从BOSS、CRM直接抽取数据的情况,12,经营分析系统各子系统数据分布-地市中心数据分布,基础数据包括从仓库和外围数据源直接抽取的数据，包括客户资料、产品、订购、工单、账单和详单等,集市中产生的数据，主要是各地市开发的报表数据和临时取数数据,13,经营分析系统各子系统数据分布-创新平台,根据专题需要从仓库和源系统直接抽取的数据，主要包括客户资料、订购、产品和计费汇总数据，不包括计费详单,集市产生的数据，主要是各专题产生的应用结果数据,14,经营分析系统各子系统数据分布-报表、挖掘平台,基础数据包括仓库模型数据和源系统抽取的数据，包括除详单外的CRM、BOSS主要数据,仓库同步的基础数据，主要是客户资料、订购关系等,仓库同步的详单数据,平台产生的专题应用结果数据,报表库产生的数据，主要是报表结果数据等,15,目录,1,2,背景及问题分析,大数据平台规划方案,架构演进历史及现状业务背景及驱动力现状问题分析相关规范及总部要求,16,流量经营时代带来的大数据挑战,随着移动互联网的不断发展，智能终端迅速普及、移动数据流量迅猛增长，流量收入占比快速攀升，流量经营已是运营商战略转型的重点。而流量经营带来的大数据挑战是IT系统架构亟待解决的问题,互联网日志 通过综合网关获得CMWAP/CMNET两类日志，日话单记录数达到40亿条，奠定用户内容偏好分析的基础；,位置信息 通过网络A口全量引入位置变更信息，日话单记录数达到12亿条，奠定活动轨迹行为分析的基础；,Gn口数据 通过DPI设备从Gn口全量获得用户的应用使用行为信息，如QQ、微博、微信等，日话单记录达到70亿，奠定用户应用偏好分析的基础；,1、为了支撑流量经营的发展，引入DPI、互联网日志和位置信令等多种网络数据源,2、网络数据与传统数据相比有非结构化特征,传统计费话单,新增大数据,3、与传统数据相比，网络数据在数据量上有质的变化，并且还在快速增长，根据思科2011-2016年度网络猜测陈述，预计到2016年网络数据流量平均年复合增长率为78%,17,大数据的特点和对IT系统的核心要求,大数据技术将被设计用于在成本可承受（economically）的条件下，通过非常快速（velocity）的采集、发现和分析，从大数据量（volumes）、多类别（variety）的数据中提取价值（value），将引起IT 领域新一轮的技术与架构的变革。,数据量巨大全球在2010 年正式进入ZB 时代，IDC预计到2020 年，全球将总共拥有35ZB 的数据量,18,传统IT架构应对大数据挑战存在的不足,存储层： 1）数据量不断增加，带来的IO瓶颈；2）容易造成数据分布不均匀，导致IO热点。 网络层： IO传输带宽不足，无法快速传输大量数据到服务器。主机层：接收过多数据进行处理，CPU、内存成为瓶颈。,=,=,=,传统小型机+高端存储的数据库架构存在性能、成本、扩展性上的瓶颈，无法满足大数据时代在低成本前提下在海量、多样的数据中实时地提取价值的要求。因此，大数据时代的IT架构需要有所转变：,19,目录,1,2,背景及问题分析,大数据平台规划方案,架构演进历史及现状业务背景及驱动力现状问题分析相关规范及总部要求,20,现状分析一：现有架构在处理海量数据时存在系统瓶颈，无法满足业务要求,数据采集,接口机采集,Hadoop处理,应急库DB2入库、处理,48时,0时,24时,宽广实时采集数据，次日4点完成前日完整数据采集，每日数据70亿,Hadoop每小时从接口机加载数据，汇总后加载入应急库，次日12点完成前日完整数据处理，入库数据量5亿,应急库对前日数据进行批处理，次日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时完成数据接收，每日数据量40亿,实时、准实时,批处理,现状分析一（续）：现有架构在处理海量数据时存在系统瓶颈，无法满足业务要求,数据采集,接口机采集,Hadoop处理,应急库DB2入库、处理,48时,0时,24时,中创实时采集数据，次日3点完成前日完整数据采集，每日数据库12亿,接口机实时从中创采集数据，次日3点完成前日数据采集,位置信令,Hadoop次日3点开始从接口机加载前天全量数据，并进行批量处理，次日12点完成处理后加载入应急库，入库数据量2.5亿,应急库次日12点开始处理，次日16点完成处理,72时,12,次日16时看到前日完整数据,应急库当日10点启动入库程序，实时入库，次日2点完成前日完整数据入库，入库数据量6.5亿,GPRS详单,次日7点完成前日数据处理,应急库次日2点钟开始处理前日完整数据，次日7点完成处理,16,计费实时分发到接口机次日2点完成前日数据分发，数据量每日6.5亿,DPI需要21小时后可以看到昨日数据，互联网日志需要42小时，位置信令需要16小时，业务部门要求9点钟前看到昨日业务指标,22,当日（T+0日）,次日（T+1日）,T+2日,接口机实时接收计费分发的详单，次日2点完成前日完整数据接收,实时、准实时,批处理,现状分析一（续）：系统瓶颈分析-接口机,目前，外围数据源与数据仓库，数据仓库与各数据集市之间的交互都依靠接口机，面对百亿级数据，1G带宽的接口机成为数据传输瓶颈，影响数据传输的及时性。,1、交互数据量大：Jfrdetl1主机平均每日数据交互量约为5t,平均75MB/s，jfrdetl2主机平均每日数据交互量为4t，平均70M/S。2、业务流程相对集中：KPI、一经等业务对数据及时性要求高，大量业务运行时段相对集中，网络带宽压力进一步加剧，导致部分业务数据延迟 ，月初峰值能达到8595M/s。3、交换机带宽不足，现有设备扩容困难：应急库建设期间，现有交换机经过反复测试，只找到4个高速口，1台主机只能分配1个高速口，达不到高可用要求，接口机的扩容要求在现有条件也很难做到,23,现状分析一（续）：系统瓶颈分析-应急库,3、网络：jfrddw11和jfrddw13的网卡收发容量峰值时达到了规划值的90%-95% ，jfrddw12和jfrddw14表现正常。其中1号机负责详单入库、DPI和位置信令数据入库，3号机负责传统数据入库（客户资料、订购等）和GPRS上网日志数据入库。,2、存储：存在热点盘，部分磁盘IOPS较多，13%的磁盘（共80块）需要处理40%的主机IO。主要处理的是写集中的IO，后端磁盘的繁忙导致写数据在Cache中有堆积，会导致写IO延迟增加。热点盘主要是数据库日志读写引起。,目前综上所述，主机、网络、存储、数据库都表现为较为繁忙，均存在瓶颈，短期需要对关键瓶颈进行优化来缓解系统压力，但并不能彻底解决问题，从长期看需要考虑系统的扩容或者架构调整。,性能分析结论,4、主机： 每日7-13点，主机内存使用率较高，达到90%，CPU使用率也较高（usr+sys维持在90%-100%），其它时段内存、CPU使用正常。可以得出的结论是系统在上午7点到13点之间系统压力大,5、数据库：通过分析数据，可以看到应急库存在较多的排序溢出，存在排序溢出问题，排序溢出率较高，超过3%的正常值，最高时超过80%，说明系统目前的排序参数设置不合理，亟需调整。,24,现状分析二：数据分布缺乏规则，造成数据冗余，数据交互缺乏统一管理，造成数据质量隐患和数据交互延迟,数据分布缺乏规则，数据仓库、各数据集市等共有4份ODS数据，存在冗余，造成空间浪费；数据交互缺乏统一管理，仓库、集市存在多套ETL工具，接口形式存在文件接口、dblink等多种方式，同时集市违反统一数据源原则直接从源系统抽取数据的情况，不仅反复抽取对BC库造成压力，同时存在数据不一致的隐患，影响数据的准确性；现有ELT模式将数据在库内进行清洗转换工作，不仅增加了数据仓库的处理负荷，而且导入和导出的动作影响到仓库与集市数据交互的及时性。,挖掘应用,数据挖掘(13T),DW,DWD,报表应用,报表库(80T),DW,ODS,地市个性化应用,地市中心(50T),DW,ODS,创新应用,创新平台(31T),DW,VGOP应用,VGOP数据,ESOP应用,ESOP数据,一经、KPI、MIS应用,数据仓库(46T),DW,DWD,ODS,ODS,CRM/BOSS,1,2,3,4,12T,19T,11T,0.18T,23T,12T,8T,VGOP(50T),ESOP(7T),16T,1.5T,报表工具，实现方式为存储过程+dblink，共部署6套，报表库1套，地市中心四中心四套，创新平台1套，合计1982个接口,仓库/应急ETL，实现方式C+程序+文件接口，合计1666个接口,25,接口工具，实现方式java程序+文件接口，合计815个内部接口,目前历史库数据存储方式依然为传统的小型机+磁盘阵列的模式，这种模式下随着相关经分系统数据量的快速增长而需要不断的进行系统扩容，硬件投资和运维成本较高。,硬件及运维成本分析,目前经分历史库的数据存储周期缺乏统一管理，保持周期长短不一，同时容量已趋近极限，各类详单的存储周期满足不了长周期深度趋势分析的业务需求，其中GPRS计费详单还以年均60%的速度快速增长，网络侧的历史数据目前并没有放入历史库中，由于其数据特点（百亿级、增长快），采用传统数据库构建模式建设历史库，成本将过于昂贵。,现状分析三：数据生命周期缺乏管理，历史数据存储不满足集团规范要求和业务长周期趋势分析需求,1、数据存储周期缺乏规划，容量趋于饱和，存储周期不满足业务长周期趋势分析需求：历史库各类详单要求存储至少6+1月，目前只保存3+1月，占总数据量的62%,2、GPRS详单数据量占全部详单数据量51%，而数据还在快速增长，年增速60%：,3、海量网络侧数据目前没有放入在历史库,26,目录,1,2,背景及问题分析,大数据平台规划方案,架构演进历史及现状业务背景及驱动力现状问题分析相关规范及总部要求,27,相关规范及总部要求,李跃总裁:“着力培育新的竞争优势，要改善服务、提高流量经营水平、巩固移动通信市场优势” 中国移动2012年工作会议,刘爱力副总裁:“持续提升CRM、BOSS和综合分析的协同能力，提高对流量经营的支撑水平。1、推动网络设备改造，实现对流量按网络、位置、时段、终端、业务等维度综合分析；2、提高对流量套餐评估和销售支撑能力；3、持续提高流量消费的服务保障能力” 2012年集团业务支撑工作会议,流量经营关系公司未来，面对当前存在的问题与挑战，集团公司对于流量经营工作提出了明确的要求。,奚国华董事长:“在战略转型方面，深化四网协同发展，有效促进从以语音经营为主向语音、流量经营并重; 加快积累基础设施资源，积极做好全业务运营的各项准备工作；发挥优势，有所作为，积极构建移动互联网主导地位“ 中国移动2012年工作会议,28,目录,1,2,背景及问题分析,大数据平台规划方案,大数据处理架构的总体目标国内外大数据分析案例大数据处理目标架构及定位大数据分析平台选型技术要求,29,现有经分系统优化方案,存储,热点盘，13%的磁盘（共80块）需要处理40%的主机IOPS,网络,主机,数据库,1、3号主机达到网络瓶颈，峰值是目标值的90-95%,每天6-18点CPU使用率较高（90-100%）、1号机内存使用率较高（90%）,排序溢出率较高，超出3%正常值，最高达到80%,短期优化方案：短期内通过对现有系统从存储、网络、主机、数据库和应用等层面进行优化，缓解系统面临的压力,该热点盘主要是数据库重做日志读写引起,1、3号机作为入库协调节点，负责数据到其它数据节点的分发,该时间段是终端和网络数据处理等大作业运行的业务高峰期,需要处理的数据量较大，单表记录在亿级别,关闭数据库镜像日志，减少热点盘的数据库日志写压力，5月15日执行，热点盘IOPS最高下降50%，整体IOPS下降20%,每个节点通过san直接load数据，将load分成拆分文件和加载文件两阶段，计划6月底进行可行性验证，验证通过后实施，预计可消除1、3号机的网络瓶颈,优化劣质SQL，峰值从93%下降到83%整合数据模型，减少系统相似处理步骤，降低仓库主机性能开销，计划7月底完成，效果待评估,建议放大sortheap参数10倍，计划5月底前完成验证和实施，效果待评估,问题,分析,优化措施,网络,接口机机达到网络瓶颈，峰值是目标值的90-95%,承载内外部数据交换，业务流量大，交换机无闲置端口,扩容交换机，主机实施双网卡绑定，增加带宽,接口机,应急库,30,经分系统扩容的方式无法满足长期规划需求，建议调整大数据处理架构,扩容方式,扩容成本,主库：石桥新主库（2台P780，约1200w TPMC）需扩容约900w TPMC的计算能力，存储空间不需要扩容（主仓裸容量180TB，可用126TB，DB2 v9.7压缩比40%）；应急库：应急库（4台P570，约900w TPMC）需扩容约1200w TPMC的计算能力，以及约20TB的有效存储空间（应急库可用空间87TB，DB2 v9.7压缩比40%）；历史库：历史库需扩容约500TB的有效存储空间（现有可用空间100TB，版本升级后压缩40%）.,为满足至2014年底的需求，经分系统共需扩容2100w TPMC的计算能力，以及520TB的有效存储空间，扩容硬件总成本约2400万元,现有经分系统（IBM小型机+磁盘阵列+DB2数据库）可以扩容，但是其水平扩展性差，虽然可以通过扩容满足短期的业务需求，考虑到数据的快速增长和非结构化数据的出现，难以满足长远的大数据分析需求;现有经分系统的扩容成本高，若采用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的计算能力；根据业务发展趋势，网络数据的年增长率约为50%，因此规划至2014年底，主库/应急库应具备600+600*1.5/0.6=2100w TPMC的计算能力和140TB的有效存储空间，历史库应具备约800TB的有效存储空间.,31,系统架构调整原则和思路,目前经分历史库的数据存储周期缺乏统一管理，保持周期长短不一；历史库容量已趋近极限，各类详单的存储周期不满足集团规范要求和业务长周期深度趋势分析需求.,历史数据存储,3,合理规划数据存储周期，完善数据的生命周期管理，历史数据存储网络数据3+1月、计费详单数据6+1月，满足集团规范要求和趋势性分析的业务需求,流量数据处理,2,调整数据分布，将数据量大、系统资源消耗高的流量数据处理过程从数据仓库中剥离出来，减轻主仓库的压力，提升数据处理的及时性；引入基于分布式技术的云架构，负责流量数据（包括网络数据、计费详单）的汇总处理，提升经分系统的大数据处理能力和数据处理的及时性.,统一ETL流程及数据交换,1,建立统一的ETL流程，将ODS至DWD层的数据清洗、转换过程移至数据仓库外，减轻仓库压力，提升数据处理的及时性；参照ESB架构，建立统一的数据交换平台，负责各系统的数据统一交换和集中管理，提升数据交换的及时性和规范性；禁止数据集市抽取存储ODS数据，消除数据冗余，提高数据的准确性和数据分布的合理性.,大数据处理架构,数据生命周期缺乏管理,网络数据和计费详单数据量大，现有架构在处理海量数据时存在系统瓶颈，主机、网络、存储、数据库都较为繁忙，处理时延严重，无法满足业务要求.,系统性能存在瓶颈，处理时延严重,数据分布缺乏规则，数据仓库、各数据集市等共有4份ODS数据，造成数据冗余和空间浪费，也影响数据的一致性；目前网络数据仅在应急库上运行.,数据分布缺乏规则,数据交互缺乏统一管理，数据源与数据仓库、数据仓库与集市之间依靠接口机进行点对点数据交互，且存在文件、dblink等多种接口方式，接口机成为数据传输瓶颈，影响数据的及时性；部分集市存在直接从源系统抽取数据的情况，对BC库造成压力，同时存在数据不一致的隐患，影响数据的准确性；现有ELT模式在库内进行数据清洗转换工作，不仅增加了数据仓库的处理负荷，而且导入和导出过程影响了仓库与集市数据交互的及时性。,数据交互缺乏统一管理,经分系统现状问题,32,目录,1,2,背景及问题分析,大数据平台规划方案,大数据处理架构的总体目标国内外大数据分析案例大数据处理目标架构及定位大数据分析平台选型技术要求,33,移动集团集中化经分案例：主数据仓库+深度分析云+非结构化数据云,数据采集,多渠道访问门户,应用专区、专题分析、指标等,非结构化数据云,基于高性能平台，预计610TB,低成本技术，3套，预计1983TB,主数据仓库,深度分析云,基于X86平台，预计668TB,电脑,智能手机,PAD,从各省经采集语音、短信、GPRS和彩信等全量明细数据；采集互联网网页和日志,搭建主数据仓库，满足集中化经分数据存储及分析需求，主数据仓库数据压缩后存储需求预计：610TB；,按照应用专区、专题分析和指标等构建前端应用技术验证：自助分析需求,构建智能手机和平板电脑接入方式提高系统易用性,历史存储&自助服务技术验证：深度分析云承担历史数据存储和查询,技术验证,搭建非结构化数据云，实现互联网内容分类和日志分析，存储需求为668TB,自助分析,准实时采集,互联网,网络日志,非结构化数据,A省经,B省经,X省经,一级系统,业务平台,结构化数据,批量采集,重点建设内容,摘自中国移动集团信息管理处 2012年工作总结及2013年工作计划,34,eBay大数据分析架构案例：EDW+深度分析+Hadoop,深度分析- Singularity,刷新 60 个以上的数据分析数据集,广泛清理和安全筛选,EDW,EDW/ADW/ODW,“与去年的用户活动比较”趋势和预测分析（大量历史数据）,运营分析交易分析大批量临时查询,低端企业级系统,发现和探索,分析和报告,+,+,100+并发用户,500+并发用户,企业级系统,5-10并发用户,图像指纹处理图像分类图案识别检测假冒产品和虚假描述产品,将非结构化数据结构化检测图案,Hadoop,商业硬件系统,6+PB,55PB,20+PB,摘自2011年Teradata University Extreme Analytics at eBay - Oliver Ratzesberger ,35,目录,1,2,背景及问题分析,大数据平台规划方案,大数据处理架构的总体目标国内外大数据分析案例大数据处理目标架构及定位大数据分析平台选型技术要求,36,大数据处理目标架构及定位,构建云化数据交换平台，承担生产数据的清洗转换过程、互联网日志的预处理，以及各系统之间的数据交换功能，既能减轻数据仓库压力，提升数据处理的及时性，也能规范数据分布，统一数据的交换管理；新建大数据分析平台，负责网络数据和详单数据处理，支撑流量经营分析，提升数据处理的及时性和数据分布的合理性；低成本构建云化历史库，负责主仓库和大数据分析平台的历史数据存储，以及历史数据挖掘、趋势分析预测等，完善数据的生命周期管理.,37,大数据处理目标架构及定位（续）,数据迁移：目前DPI数据、GPRS上网日志、位置信令和详单数据的处理分析过程部署在DB2系统中，建议迁移至云化数据交换平台和大数据分析平台；新增数据：WLAN上网日志、宽带上网日志数据为今年计划从网络侧新引入到大数据分析平台的数据.,大数据分析平台定位：大数据分析：负责非结构化和海量数据处理，包括（DPI 数据、GPRS上网日志、位置信令、WLAN上网日志、宽带上网日志）和详单数据的处理分析，形成DW汇总层模型，以及基于大数据的深度行为分析，如进行路径分析、社交网络分析等.,云化数据交换平台（含ETL）定位：日志预处理：负责GPRS、WLAN、宽带等互联网日志的预处理，生成结构化数据；ETL处理：负责数据抽取、校验等预处理工作；负责对ODS原始生产数据进行清洗、转换，形成遵循第三范式、面向主题的DWD基础层数据模型；并负责数据加载入库.数据交换：负责各系统之间的数据交换.,主数据仓库定位：传统结构化数据处理：负责传统的结构化、轻量级数据处理和及时性较高的KPI、一经等传统经营分析应用.,历史库定位：历史数据存储：存储长周期历史数据，包括主数据仓库和大数据分析平台的历史数据；长周期趋势分析：开展海量历史数据挖掘、趋势分析预测等.,38,大数据处理架构的总体性能量化目标,云化数据交换平台,加载性能：12小时完成11TB的数据加载，峰值数据加载速度 1TB/小时清洗转换能力：12小时清洗转换数据量 7T，峰值数据清洗转换能力 600GB/小时数据导出能力： 12小时完成26TB的数据导出，峰值数据导出速度 2.2TB/小时扩展能力:200台规模内，增加节点后，系统的性能扩展系数 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月，总量 830 TB扩展能力： 100台规模内，增加节点后，系统的性能扩展系数 0.8,具备支撑14年底网络、计费详单数据处理的计算能力具备支撑14年底网络数据3+1月、计费详单数据6+1月的数据存储的能力满足业务核心数据每日8点前查看T-1数据的需求（核心业务包括集团考核和发送管理层KPI彩信）,39,大数据处理目标架构数据分布,参与人,事件,服务,资源,帐务,营销,财务,BOSS,CRM,VGOP,财务,网管,DPI,信令,互联网,主数据仓库,历史库,云化数据交换平台,ST层面向应用主题计算结果数据,DW层（轻度汇总）面向分析主题汇总数据模型在DWD层基础上汇总而得,DWD明细层面向业务主题的明细数据遵循第三范式,ODS接口层按系统划分结构与源系统相同,DWD明细层由云化数据交换平台同步而来，事件域进大数据分析平台，其余进主仓,大数据分析平台完成网络、详单数据的轻度汇总后，再同步给主数据仓库进行跨主题域交叉关联，生成ST共享数据层，供集市应用使用.,参与人,服务,资源,帐务,营销,财务,KPI,主题,报表,一经,专题,精确营销,参与人,事件,服务,资源,帐务,营销,财务,个人客户统一视图,集团客户统一视图,参与人,事件,服务,资源,帐务,营销,财务,KPI,主题,报表,一经,专题,精确营销,流量经营,参与人,事件,服务,资源,帐务,营销,财务,个人客户统一视图,集团客户统一视图,大数据分析平台,流量经营,DW层（关联汇总）面向集市应用的共享数据跨主题域的汇总,40,云化数据交换平台,主数据仓库,8：大数据分析平台将DW层数据导入主库，由主数据仓库进行横向跨主题交叉关联，生成共享数据层，供集市应用使用,6：主仓库负责DWD层数据向DW层、ST层的汇总，并将主仓库DW层、ST层数据同步给云化历史库；7：大数据分析平台负责网络数据和详单数据从DWD层向DW层、ST层的汇总过程，并将其DW层、ST层数据同步给云化历史库,1、2：生产系统数据导入云化数据交换平台，在云化数据交换平台上进行数据的清洗和转换，完成ODS到DWD的数据模型转换,除网络/详单外的DWD数据加载,网络/详单类DWD数据加载,大数据处理目标架构数据流向,大数据分析平台,3、4、5：DWD层数据通过多加载方式进入主数据仓库、历史库和大数据分析平台，其中网络数据和详单数据仅加载进入大数据分析平台，其余数据进入主数据仓库，全量数据加载进入云化历史库，数据之间关系为3+5=4,云化数据交换平台,DWD,DW,ST,DWD,DW,ST,ODS,DWD,ODS,DWD,主库DW数据,主库ST数据,云化历史库,全量的DWD数据加载,DWD,DW,ST,DW数据,ST数据,1,2,3,5,4,6,7,8,9：通过云化数据交换平台向各数据集市同步所需数据,9,41,大数据处理目标架构数据流向（续）客户资料、订购关系类数据分布及流向,云化数据交换平台,主数据仓库,D1：通过云化数据交换平台向各数据集市同步所需数据,C1：主仓库负责数据从DWD层向DW层的汇总过程，生成DW层数据模型C1；C2：将主库DW层数据C1通过云化数据交换平台同步给云化历史库C2,A1：客户资料、订购关系类的生产系统数据导入云化数据交换平台，在云化数据交换平台上进行数据的清洗和转换，完成ODS到DWD的数据模型转换,大数据分析平台,B1、B2：云化数据交换平台处理后的DWD层数据文件通过多加载进入主数据仓库和云化历史库,云化数据交换平台,DWD,DW,ST,DWD,DW,ST,ODS,DWD,ODS,DWD,云化历史库,DWD,DW,ST,A1,B1,B2,D1,C1,C2,除网络/详单外的DWD数据加载,网络/详单类DWD数据加载,全量的DWD数据加载,42,大数据处理目标架构数据流向（续）网络流量、计费详单类数据分布及流向,云化数据交换平台,主数据仓库,D1：通过云化数据交换平台向各数据集市同步所需数据,C1：大数据分析平台负责计费详单、网络数据从DWD层向DW层的汇总过程，生成DW层数据模型C1；C2：将大数据分析平台的DW层数据通过云化数据交换平台同步给云化历史库C2；C3：将大数据分析平台的DW层数据通过云化数据交换平台同步给主数据仓库C3，后续再进行跨主题域交叉关联生成DW/ST共享数据层，供集市应用使用,A1：网络流量、计费详单类的生产系统数据导入云化数据交换平台，在云化数据交换平台上进行数据的清洗和转换，完成ODS到DWD的数据模型转换,大数据分析平台,B1、B2：云化数据交换平台处理后的DWD层数据通过多加载进入大数据分析平台和云化历史库,云化数据交换平台,DWD,DW,ST,DWD,DW,ST,ODS,DWD,DWD,DW,ST,A1,B1,B2,D1,C2,C1,C3,云化历史库,除网络/详单外的DWD数据加载,网络/详单类DWD数据加载,全量的DWD数据加载,43,各平台数据存储周期及数据量需求（单位：TB）,44,大数据处理目标架构关键点分布,3. 构建云化历史库,2. 构建大数据分析平台,1. 构建云化数据交换平台,4. 现有系统配合改造,45,大数据处理目标架构关键点详解-云化数据交换平台,本次云化数据交换平台除实现ETL功能的集中云化部署和增强清洗转换、实现计算前移外，还将提升接口的标准化，并在抽取上进行优化，以减轻网络资源的开销,46,大数据处理目标架构关键点详解-大数据分析平台,平台建设,大数据分析平台负责网络和详单数据的处理，要求具备突出的数据加载、处理性能，以及优秀的高可用性；通过并行加载的方式，同时向各工作节点写入数据，提高数据加载速度；采用哈希算法将数据近似平均地分布到所有工作节点上，并将工作节点划分为多个并行的虚拟处理单元，增加系统的并行度，提高数据处理效率；配置2台管理节点（一主一备），设置1份数据副本（系统共两份数据），保证系统高可用性和数据安全性.,数据管理,大数据分析平台主要承担事件域数据（包括网络和详单数据）的DW层和ST层汇总处理；在大数据分析平台上创建名为Event的Database，用于承担事件域数据模型的存储与管理；根据分层设计原则，在Event DB下，划分出DWD、DW、ST三个schema，分别存储DWD层、DW层、ST层的实体模型，并用schema名称区分.,业务支撑,利用ST层结果数据，支撑流量业务统计监控、业务稽核等流量经营基础应用；在大数据分析平台上部署挖掘模型及分析应用，如时间序列分析（通过路径分析用户的移动轨迹，可用于定位服务推荐）、关联分析（通过交往圈分析用户影响力，可用于营销及维系挽留）、文本分析（通过日志分析用户偏好，可用于精确营销）等.,大数据分析平台,47,大数据处理目标架构关键点详解-云化历史库,业务需求,云化历史库存储历史数据的目的除满足历史数据查询、临时统计外，还包括支撑长周期的数据挖掘、趋势分析预测等业务需求。,数据构成,云化数据交换平台处理后的明细数据；主仓库处理后的客户资料等拍照类数据的汇总模型；大数据分析平台处理的网络、计费等事件类数据的汇总模型。,数据生命周期管理,计费明细数据保存6+1月；网络明细数据保存3+1月；日汇总数据保存3+1月；月汇总数据保存12+1月；所有全量数据容量估算约为830TB。,云化历史库,云化历史库将存储各平台产生的历史数据，根据集团规范要求和实际业务需求实现历史数据存储周期的有效管理，在此基础上支撑历史数据查询、临时取数和长周期趋势分析等业务需求,48,大数据处理目标架构关键点详解-云化历史库,计费历史库,经分历史库,应用,信息子层,汇总模型,计费详单基础模型,4,901G,10,542G,18,366G,56,154G,6-12个月,经分历史库数据,数据量,存储周期,计费原始详单,A库,计费分发,4个月,存储周期,计费历史库数据,1+1 个月,数据仓库分发,67,092G,30,474G,数据量,B库,生产库,26,869G,总存储：72T,A、B库总存储：64T,3-4月,历史库总存储：114T,历史库承载业务,涉及投诉的历史数据查询,历史库承载业务,历史数据查询、临时统计、长周期趋势分析,计费历史库保存4个月的计费批价后的详单历史数据，合计67T，经分历史库保存3-4个月左右的详单基础模型数据，合计56T，占经分历史库数据总量的62%。经分详单基础模型是由计费批价后详单清洗转换的结果，数据结构相似，但存在一定差异。两库承载业务也有相似性，均承担历史数据查询功能。从减少全网数据冗余的角度出发，历史库进行合建，只保存一份计费详单历史数据。,大数据处理目标架构关键点详解-云化历史库,云化历史库保存有语音、短信、GPRS等各类基础详单，但目前计费历史库重处理详单以单独文件标识，没有发送给经分系统，因此未来需要计费把批价重处理详单也发送云化历史库，单独存储，以保持云化历史库数据的完整性，支撑涉及重处理详单的投诉查询。,原计费历史库涉及到维护日常问题处理查询，改造后将由云化历史库支撑。原经分历史库涉及到专题，主要包括：重入网、客服运营分析平台等，重入网建议迁移至创新平台，客服运营分析平台建议新增客服集市。,经分侧基于分析的考虑，去掉了分析不需要的的部分字段，并对数据格式进行了部分调整，但未改变数据业务含义。以GSM话单为例，计费话单131字段，经分CDR层删除46字段。本次改造在经分详单格式基础上增加投诉查询所需字段，确保维护查询及经分现有业务不受影响。,保证数据一致性（详单数据结构差异分析）,业务改造,保证数据完整性（云化历史库保存重处理详单）,历史库合并方案,经分历史库和计费历史库合并思路：鉴于经分云化历史库数据更丰富（除计费详单外，还包括客户资料、订购关系等基础数据和模型数据）、承载业务更广泛（计费历史库主要是涉及投诉的历史数据查询，云化历史库还承载长周期趋势分析等）、架构扩展性更强（采用新型MPP关系型数据库具备线性扩展能力）因此建议采取以云化历史库为基础，吸收合并计费历史库的方案。,大数据处理目标架构关键点详解-各系统配合改造,本项目各系统配合改造范围：ETL工具：多套ETL工具统一为云化数据交换平台主仓库、应急库：计费详单、网络数据迁移到大数据分析平台，ODS、 DWD迁移到云化数据交换平台历史库：现有历史库数据迁移至新云化历史库地市数据分析中心、创新平台和报表库：ETL工具、ODS层统一迁移至云化数据交换平台,51,目录,1,2,背景及问题分析,大数据平台规划方案,大数据处理架构的总体目标国内外大数据分析案例大数据处理目标架构及定位大数据分析平台选型技术要求,52,云化数据交换平台技术要求,云化数据交换平台的系统定位是：负责互联网日志的预处理、原始生产数据的清洗和转换，以及各平台间的数据交换.,功能要求：支持文件、表等多种接口方式的数据抽取和数据加载；支持数据的校验、清洗、合并、关联、汇总等基本转换功能；支持结构化、非结构化数据等多种数据格式的预处理；具备良好的通用性，提供可视化开发界面，支持自定义开发.,性能要求：数据吞吐能力强，数据加载导出性能优异；数据清洗、转换以及简单查询操作的性能突出；系统稳定、可靠、高可用，具备线性扩展能力.,运维要求：提供统一的管理监控平台，系统运维操作简单，管理维护成本低.,成本要求：采用X86+本地硬盘的方式.,53,大数据分析平台技术要求,大数据分析平台的系统定位是：支持非结构化及海量数据处理，包括网络数据和计费详单数据等，满足流量经营等大数据分析业务需求.,功能要求：具备完整的SQL支持能力，支持常用函数，如数据汇总、关联、排序等；支持MapReduce，具备优秀的非结构化数据处理能力；提供完整的事务管理功能，具备完善的混合负载管理能力；具备良好的通用性，支持主流第三方工具，提供可视化开发界面，支持自定义开发.,性能要求：大数据量的加载、处理、导出等关键处理性能表现优异，如大表汇总、大表关联；具备线性扩展能力，支持在线扩容；系统稳定可靠，具备优秀的高可用性.,运维要求：提供统一的管理监控平台，系统运维操作简单，管理维护成本低.,成本要求：采用X86+本地硬盘的方式.,54,云化历史库平台技术要求,功能要求：具备完整的SQL支持能力，支持常用函数，如数据汇总、关联、排序等；提供完整的事务管理功能，具备完善的混合负载管理能力；具备良好的通用性，支持主流第三方工具，提供可视化开发界面，支持自定义开发.,性能要求