数据规划大数据平台规划技术方案v4.pptx

《数据规划大数据平台规划技术方案v4.pptx》由会员分享，可在线阅读，更多相关《数据规划大数据平台规划技术方案v4.pptx（70页珍藏版）》请在悟道方案网上搜索。

1、数据规划:大数据平台规划技术方案,1,目录,1,2,背景及问题分析,大数据平台规划方案,架构演进历史及现状业务背景及驱动力现状问题分析相关规范及总部要求,2,经营分析系统架构演进08年之前的系统现状,200X年完成数据仓库重构后到200X年底，数据仓库架构相对稳定,报表库：省级业务部门报表和取数,主仓库：基础数据模型和一经、KPI等关键应用,专题库（历史库）：重入网、套餐分析等专题应用和仓库重要历史数据在线存储,前台库：主要存放门户配置信息和KPI数据,OLAP ：多维分析数据库，主题分析结果数据,3,经营分析系统架构演进-业务驱动,为了支撑业务发展，在XX规范和本省业务需求驱动下，进行集市的

2、建设和扩容,VGOP：20XX年根据XX规范要求建设，支撑数据业务发展,ESOP：20XX年根据XX规范要求建设，支撑政企业务发展,数据挖掘平台：20XX年建设，提供体系化数据挖掘专业能力，支撑数据挖掘应用，如一人多卡,地市数据分析中心20XX年启动地市集中化建设项目，加强地市一线支撑,创新平台：20XX年建设，承载地市试点应用，如存量维系、校园市场分析等,数据挖掘平台,4,经营分析系统架构演进-架构驱动,随着数据源的不断引入和业务自身的发展，数据仓库也在不断扩容，以满足业务发展需求,主仓库：硬件从P690升级到P595、P780，其中石桥机房由P780承载的主仓正在建设中；,历史库：历史数据

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

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

5、能为切割维度,经营分析系统各子系统可归纳为数据仓库和数据集市两大类，数据仓库根据存储数据的周期不同，分为主数据仓库和历史库，数据集市根据服务的部门不同和承载的专业能力不同，分为部门集市和专业集市,本次项目重点调整范围,厂商分布说明：,亚联,华为,思特奇,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*

6、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套、I

7、BM DS系列存储6套，裸容量1200T，可用容量900T,7,经营分析系统数据架构现状,面向业务的应用结果数据汇总，如DW层日新增用户通话信息汇总生成新增用户日通话报表，供前端直接读取；,对DWD层进行主题内轻度汇总，根据业务需求舍弃部分维度，实现轻度汇总，如计费话单日汇总将话单中时间戳信息汇总生成时段信息；对轻度汇总的结果进行跨主题的关联，如服务域中的用户信息关联事件域中的计费语音话单汇总结果，生成日新增用户通话信息；,仓库明细数据，对ODS数据进行清洗、转换、按业务归类形成XX规范要求的7大概念域；如将用户资料信息归类为服务域、将计费语音话单归类于事件域；,ODS层存储的是从外围系统采集

8、的接口数据，与外围系统的数据结构基本保持一致,如用户资料信息、计费语音话单；,ST层,DW层,DWD层,ODS层,参与人,事件,服务,资源,帐务,营销,财务,KPI,主题,报表,一经,专题,精确营销模型,BOSS,CRM,VGOP,财务,网管,参与人,事件,服务,资源,帐务,营销,财务,个人客户统一视图,XX客户统一视图, ,8,主仓库：数据来源于BOSS、CRM等源系统，可用空间51.6T，已用空间46T；应急库：除包含主仓库全部数据外，还包含网络数据，可用空间87T，已用空间60T；历史库：主要存储主仓库处理后的历史数据，详单保留3+1月，其他数据6-12月不等，可用空间114.8T，已用

9、空间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,信令,互联

10、网,报表库,地市数据中心,创新平台,数据挖掘平台,VGOP,ESOP,前台库,OLAP,报表工具（Dblink方式）,地市数据分析中心、创新应用孵化平台在集中化的建设过程中为了地市已有应用的迁移，其数据来源除了数据仓库外，还允许从BOSS、CRM直接抽取数据报表库因先于数据仓库建设，也存在从BOSS、CRM直接抽取数据的情况数据挖掘平台等集市的数据来源是数据仓库，不存在从BOSS、CRM直接抽取数据的情况,12,经营分析系统各子系统数据分布-地市中心数据分布,基础数据包括从仓库和外围数据源直接抽取的数据，包括客户资料、产品、订购、工单、账单和详单等,集市中产生的数据，主要是各地市开发的报表数据

11、和临时取数数据,13,经营分析系统各子系统数据分布-创新平台,根据专题需要从仓库和源系统直接抽取的数据，主要包括客户资料、订购、产品和计费汇总数据，不包括计费详单,集市产生的数据，主要是各专题产生的应用结果数据,14,经营分析系统各子系统数据分布-报表、挖掘平台,基础数据包括仓库模型数据和源系统抽取的数据，包括除详单外的CRM、BOSS主要数据,仓库同步的基础数据，主要是客户资料、订购关系等,仓库同步的详单数据,平台产生的专题应用结果数据,报表库产生的数据，主要是报表结果数据等,15,目录,1,2,背景及问题分析,大数据平台规划方案,架构演进历史及现状业务背景及驱动力现状问题分析相关规范及总部

12、要求,16,流量经营时代带来的大数据挑战,随着互联网的不断发展，智能终端迅速普及、数据流量迅猛增长，流量收入占比快速攀升，流量经营已是运营商战略转型的重点。而流量经营带来的大数据挑战是IT系统架构亟待解决的问题,互联网日志 通过综合网关获得CMWAP/CMNET两类日志，日话单记录数达到40亿条，奠定用户内容偏好分析的基础；,位置信息 通过网络A口全量引入位置变更信息，日话单记录数达到12亿条，奠定活动轨迹行为分析的基础；,Gn口数据 通过DPI设备从Gn口全量获得用户的应用使用行为信息，如QQ、微博、微信等，日话单记录达到70亿，奠定用户应用偏好分析的基础；,1、为了支撑流量经营的发展，引入

13、DPI、互联网日志和位置信令等多种网络数据源,2、网络数据与传统数据相比有非结构化特征,传统计费话单,新增大数据,3、与传统数据相比，网络数据在数据量上有质的变化，并且还在快速增长，根据思科2011-2016年度网络猜测陈述，预计到2016年网络数据流量平均年复合增长率为78%,17,大数据的特点和对IT系统的核心要求,大数据技术将被设计用于在成本可承受（economically）的条件下，通过非常快速（velocity）的采集、发现和分析，从大数据量（volumes）、多类别（variety）的数据中提取价值（value），将引起IT 领域新一轮的技术与架构的变革。,数据量巨大全球在2010

14、 年正式进入ZB 时代，IDC预计到2020 年，全球将总共拥有35ZB 的数据量,18,传统IT架构应对大数据挑战存在的不足,存储层： 1）数据量不断增加，带来的IO瓶颈；2）容易造成数据分布不均匀，导致IO热点。 网络层： IO传输带宽不足，无法快速传输大量数据到服务器。主机层：接收过多数据进行处理，CPU、内存成为瓶颈。,=,=,=,传统小型机+高端存储的数据库架构存在性能、成本、扩展性上的瓶颈，无法满足大数据时代在低成本前提下在海量、多样的数据中实时地提取价值的要求。因此，大数据时代的IT架构需要有所转变：,19,目录,1,2,背景及问题分析,大数据平台规划方案,架构演进历史及现状业务

15、背景及驱动力现状问题分析相关规范及总部要求,20,现状分析一：现有架构在处理海量数据时存在系统瓶颈，无法满足业务要求,数据采集,接口机采集,Hadoop处理,应急库DB2入库、处理,48时,0时,24时,宽广实时采集数据，次日4点完成前日完整数据采集，每日数据70亿,Hadoop每小时从接口机加载数据，汇总后加载入应急库，次日12点完成前日完整数据处理，入库数据量5亿,应急库对前日数据进行批处理，次日21点完成,DPI,次日21点，看到前日完整数据处理结果,宽连实时从东方通信采集数据并进行处理，处理后数据分发到接口机，次日17点完成数据分发,互联网日志,应急库次日17时发起入库，T+2日10点

16、完成入库,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入库、处理

17、,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点完成前日数据分发，数

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

19、/S。2、业务流程相对集中：KPI、一经等业务对数据及时性要求高，大量业务运行时段相对集中，网络带宽压力进一步加剧，导致部分业务数据延迟 ，月初峰值能达到8595M/s。3、交换机带宽不足，现有设备扩容困难：应急库建设期间，现有交换机经过反复测试，只找到4个高速口，1台主机只能分配1个高速口，达不到高可用要求，接口机的扩容要求在现有条件也很难做到,23,现状分析一（续）：系统瓶颈分析-应急库,3、网络：jfrddw11和jfrddw13的网卡收发容量峰值时达到了规划值的90%-95% ，jfrddw12和jfrddw14表现正常。其中1号机负责详单入库、DPI和位置信令数据入库，3号机负责传统

20、数据入库（客户资料、订购等）和GPRS上网日志数据入库。,2、存储：存在热点盘，部分磁盘IOPS较多，13%的磁盘（共80块）需要处理40%的主机IO。主要处理的是写集中的IO，后端磁盘的繁忙导致写数据在Cache中有堆积，会导致写IO延迟增加。热点盘主要是数据库日志读写引起。,目前综上所述，主机、网络、存储、数据库都表现为较为繁忙，均存在瓶颈，短期需要对关键瓶颈进行优化来缓解系统压力，但并不能彻底解决问题，从长期看需要考虑系统的扩容或者架构调整。,性能分析结论,4、主机： 每日7-13点，主机内存使用率较高，达到90%，CPU使用率也较高（usr+sys维持在90%-100%），其它时段内存

21、、CPU使用正常。可以得出的结论是系统在上午7点到13点之间系统压力大,5、数据库：通过分析数据，可以看到应急库存在较多的排序溢出，存在排序溢出问题，排序溢出率较高，超过3%的正常值，最高时超过80%，说明系统目前的排序参数设置不合理，亟需调整。,24,现状分析二：数据分布缺乏规则，造成数据冗余，数据交互缺乏统一管理，造成数据质量隐患和数据交互延迟,数据分布缺乏规则，数据仓库、各数据集市等共有4份ODS数据，存在冗余，造成空间浪费；数据交互缺乏统一管理，仓库、集市存在多套ETL工具，接口形式存在文件接口、dblink等多种方式，同时集市违反统一数据源原则直接从源系统抽取数据的情况，不仅反复抽取

22、对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(5

23、0T),ESOP(7T),16T,1.5T,报表工具，实现方式为存储过程+dblink，共部署6套，报表库1套，地市中心四中心四套，创新平台1套，合计1982个接口,仓库/应急ETL，实现方式C+程序+文件接口，合计1666个接口,25,接口工具，实现方式java程序+文件接口，合计815个内部接口,目前历史库数据存储方式依然为传统的小型机+磁盘阵列的模式，这种模式下随着相关经分系统数据量的快速增长而需要不断的进行系统扩容，硬件投资和运维成本较高。,硬件及运维成本分析,目前经分历史库的数据存储周期缺乏统一管理，保持周期长短不一，同时容量已趋近极限，各类详单的存储周期满足不了长周期深度趋势分析的

24、业务需求，其中GPRS计费详单还以年均60%的速度快速增长，网络侧的历史数据目前并没有放入历史库中，由于其数据特点（百亿级、增长快），采用传统数据库构建模式建设历史库，成本将过于昂贵。,现状分析三：数据生命周期缺乏管理，历史数据存储不满足XX规范要求和业务长周期趋势分析需求,1、数据存储周期缺乏规划，容量趋于饱和，存储周期不满足业务长周期趋势分析需求：历史库各类详单要求存储至少6+1月，目前只保存3+1月，占总数据量的62%,2、GPRS详单数据量占全部详单数据量51%，而数据还在快速增长，年增速60%：,3、海量网络侧数据目前没有放入在历史库,26,目录,1,2,背景及问题分析,大数据平台规

25、划方案,大数据处理架构的总体目标国内外大数据分析案例大数据处理目标架构及定位大数据分析平台选型技术要求,27,现有经分系统优化方案,存储,热点盘，13%的磁盘（共80块）需要处理40%的主机IOPS,网络,主机,数据库,1、3号主机达到网络瓶颈，峰值是目标值的90-95%,每天6-18点CPU使用率较高（90-100%）、1号机内存使用率较高（90%）,排序溢出率较高，超出3%正常值，最高达到80%,短期优化方案：短期内通过对现有系统从存储、网络、主机、数据库和应用等层面进行优化，缓解系统面临的压力,该热点盘主要是数据库重做日志读写引起,1、3号机作为入库协调节点，负责数据到其它数据节点的分发

26、,该时间段是终端和网络数据处理等大作业运行的业务高峰期,需要处理的数据量较大，单表记录在亿级别,关闭数据库镜像日志，减少热点盘的数据库日志写压力，5月15日执行，热点盘IOPS最高下降50%，整体IOPS下降20%,每个节点通过san直接load数据，将load分成拆分文件和加载文件两阶段，计划6月底进行可行性验证，验证通过后实施，预计可消除1、3号机的网络瓶颈,优化劣质SQL，峰值从93%下降到83%整合数据模型，减少系统相似处理步骤，降低仓库主机性能开销，计划7月底完成，效果待评估,建议放大sortheap参数10倍，计划5月底前完成验证和实施，效果待评估,问题,分析,优化措施,网络,接口

27、机机达到网络瓶颈，峰值是目标值的90-95%,承载内外部数据交换，业务流量大，交换机无闲置端口,扩容交换机，主机实施双网卡绑定，增加带宽,接口机,应急库,28,经分系统扩容的方式无法满足长期规划需求，建议调整大数据处理架构,扩容方式,扩容成本,主库：石桥新主库（2台P780，约1200w TPMC）需扩容约900w TPMC的计算能力，存储空间不需要扩容（主仓裸容量180TB，可用126TB，DB2 v9.7压缩比40%）；应急库：应急库（4台P570，约900w TPMC）需扩容约1200w TPMC的计算能力，以及约20TB的有效存储空间（应急库可用空间87TB，DB2 v9.7压缩比40

28、%）；历史库：历史库需扩容约500TB的有效存储空间（现有可用空间100TB，版本升级后压缩40%）.,为满足至2014年底的需求，经分系统共需扩容2100w TPMC的计算能力，以及520TB的有效存储空间，扩容硬件总成本约2400万元,现有经分系统（IBM小型机+磁盘阵列+DB2数据库）可以扩容，但是其水平扩展性差，虽然可以通过扩容满足短期的业务需求，考虑到数据的快速增长和非结构化数据的出现，难以满足长远的大数据分析需求;现有经分系统的扩容成本高，若采用X86+本地盘的云架构，相同TPMC的X86平台价格是IBM小型机价格的1/10，相同容量的普通硬盘价格是高端存储+SAN网络价格的1/2

29、0；因此建议调整大数据处理架构，引入基于分布式技术的云架构，以满足流量经营大数据分析需求.,评估结论,需求评估：当前主库（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的

30、有效存储空间，历史库应具备约800TB的有效存储空间.,29,系统架构调整原则和思路,目前经分历史库的数据存储周期缺乏统一管理，保持周期长短不一；历史库容量已趋近极限，各类详单的存储周期不满足XX规范要求和业务长周期深度趋势分析需求.,历史数据存储,3,合理规划数据存储周期，完善数据的生命周期管理，历史数据存储网络数据3+1月、计费详单数据6+1月，满足XX规范要求和趋势性分析的业务需求,流量数据处理,2,调整数据分布，将数据量大、系统资源消耗高的流量数据处理过程从数据仓库中剥离出来，减轻主仓库的压力，提升数据处理的及时性；引入基于分布式技术的云架构，负责流量数据（包括网络数据、计费详单）的汇

31、总处理，提升经分系统的大数据处理能力和数据处理的及时性.,统一ETL流程及数据交换,1,建立统一的ETL流程，将ODS至DWD层的数据清洗、转换过程移至数据仓库外，减轻仓库压力，提升数据处理的及时性；参照ESB架构，建立统一的数据交换平台，负责各系统的数据统一交换和集中管理，提升数据交换的及时性和规范性；禁止数据集市抽取存储ODS数据，消除数据冗余，提高数据的准确性和数据分布的合理性.,大数据处理架构,数据生命周期缺乏管理,网络数据和计费详单数据量大，现有架构在处理海量数据时存在系统瓶颈，主机、网络、存储、数据库都较为繁忙，处理时延严重，无法满足业务要求.,系统性能存在瓶颈，处理时延严重,数据

32、分布缺乏规则，数据仓库、各数据集市等共有4份ODS数据，造成数据冗余和空间浪费，也影响数据的一致性；目前网络数据仅在应急库上运行.,数据分布缺乏规则,数据交互缺乏统一管理，数据源与数据仓库、数据仓库与集市之间依靠接口机进行点对点数据交互，且存在文件、dblink等多种接口方式，接口机成为数据传输瓶颈，影响数据的及时性；部分集市存在直接从源系统抽取数据的情况，对BC库造成压力，同时存在数据不一致的隐患，影响数据的准确性；现有ELT模式在库内进行数据清洗转换工作，不仅增加了数据仓库的处理负荷，而且导入和导出过程影响了仓库与集市数据交互的及时性。,数据交互缺乏统一管理,经分系统现状问题,30,目录,

33、1,2,背景及问题分析,大数据平台规划方案,大数据处理架构的总体目标国内外大数据分析案例大数据处理目标架构及定位大数据分析平台选型技术要求,31,XX集中化经分案例：主数据仓库+深度分析云+非结构化数据云,数据采集,多渠道访问门户,应用专区、专题分析、指标等,非结构化数据云,基于高性能平台，预计610TB,低成本技术，3套，预计1983TB,主数据仓库,深度分析云,基于X86平台，预计668TB,电脑,智能手机,PAD,从各省经采集语音、短信、GPRS和彩信等全量明细数据；采集互联网网页和日志,搭建主数据仓库，满足集中化经分数据存储及分析需求，主数据仓库数据压缩后存储需求预计：610TB；,按

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

35、安全筛选,EDW,EDW/ADW/ODW,“与去年的用户活动比较”趋势和预测分析（大量历史数据）,运营分析交易分析大批量临时查询,低端企业级系统,发现和探索,分析和报告,+,+,100+并发用户,500+并发用户,企业级系统,5-10并发用户,图像指纹处理图像分类图案识别检测假冒产品和虚假描述产品,将非结构化数据结构化检测图案,Hadoop,商业硬件系统,6+PB,55PB,20+PB,摘自201X年Teradata University Extreme Analytics at eBay - Oliver Ratzesberger ,33,目录,1,2,背景及问题分析,大数据平台规划方案,大

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

37、、GPRS上网日志、位置信令和详单数据的处理分析过程部署在DB2系统中，建议迁移至云化数据交换平台和大数据分析平台；新增数据：WLAN上网日志、宽带上网日志数据为今年计划从网络侧新引入到大数据分析平台的数据.,大数据分析平台定位：大数据分析：负责非结构化和海量数据处理，包括（DPI 数据、GPRS上网日志、位置信令、WLAN上网日志、宽带上网日志）和详单数据的处理分析，形成DW汇总层模型，以及基于大数据的深度行为分析，如进行路径分析、社交网络分析等.,云化数据交换平台（含ETL）定位：日志预处理：负责GPRS、WLAN、宽带等互联网日志的预处理，生成结构化数据；ETL处理：负责数据抽取、校验等

38、预处理工作；负责对ODS原始生产数据进行清洗、转换，形成遵循第三范式、面向主题的DWD基础层数据模型；并负责数据加载入库.数据交换：负责各系统之间的数据交换.,主数据仓库定位：传统结构化数据处理：负责传统的结构化、轻量级数据处理和及时性较高的KPI、一经等传统经营分析应用.,历史库定位：历史数据存储：存储长周期历史数据，包括主数据仓库和大数据分析平台的历史数据；长周期趋势分析：开展海量历史数据挖掘、趋势分析预测等.,36,大数据处理架构的总体性能量化目标,云化数据交换平台,加载性能：12小时完成11TB的数据加载，峰值数据加载速度 1TB/小时清洗转换能力：12小时清洗转换数据量 7T，峰值数

39、据清洗转换能力 600GB/小时数据导出能力： 12小时完成26TB的数据导出，峰值数据导出速度 2.2TB/小时扩展能力:200台规模内，增加节点后，系统的性能扩展系数 0.8,大数据分析平台,云化历史库,加载性能：12小时完成6TB明细数据加载进入大数据分析平台，峰值数据加载速度 500G/小时处理性能：6小时内完成流量、计费200亿条记录、12TB数据的处理，数据处理能力 2TB/小时存储能力：流量数据、详单数据的存储周期 7天，数据存储总量 80 TB扩展能力：100台规模内，增加节点后，系统的性能扩展系数 0.8,加载性能：12小时内完成云化数据交换平台、大数据分析平台和主仓库当日产

40、生的模型数据11TB，数据加载峰值速度 1TB/小时压缩能力：数据压缩比 1:6存储能力：历史库数据存储计费6+1月，网络3+1月，资料12+1月，总量 830 TB扩展能力： 100台规模内，增加节点后，系统的性能扩展系数 0.8,具备支撑14年底网络、计费详单数据处理的计算能力具备支撑14年底网络数据3+1月、计费详单数据6+1月的数据存储的能力满足业务核心数据每日8点前查看T-1数据的需求（核心业务包括XX考核和发送管理层KPI彩信）,37,大数据处理目标架构数据分布,参与人,事件,服务,资源,帐务,营销,财务,BOSS,CRM,VGOP,财务,网管,DPI,信令,互联网,主数据仓库,历

41、史库,云化数据交换平台,ST层面向应用主题计算结果数据,DW层（轻度汇总）面向分析主题汇总数据模型在DWD层基础上汇总而得,DWD明细层面向业务主题的明细数据遵循第三范式,ODS接口层按系统划分结构与源系统相同,DWD明细层由云化数据交换平台同步而来，事件域进大数据分析平台，其余进主仓,大数据分析平台完成网络、详单数据的轻度汇总后，再同步给主数据仓库进行跨主题域交叉关联，生成ST共享数据层，供集市应用使用.,参与人,服务,资源,帐务,营销,财务,KPI,主题,报表,一经,专题,精确营销,参与人,事件,服务,资源,帐务,营销,财务,个人客户统一视图,XX客户统一视图,参与人,事件,服务,资源,帐

42、务,营销,财务,KPI,主题,报表,一经,专题,精确营销,流量经营,参与人,事件,服务,资源,帐务,营销,财务,个人客户统一视图,XX客户统一视图,大数据分析平台,流量经营,DW层（关联汇总）面向集市应用的共享数据跨主题域的汇总,38,云化数据交换平台,主数据仓库,8：大数据分析平台将DW层数据导入主库，由主数据仓库进行横向跨主题交叉关联，生成共享数据层，供集市应用使用,6：主仓库负责DWD层数据向DW层、ST层的汇总，并将主仓库DW层、ST层数据同步给云化历史库；7：大数据分析平台负责网络数据和详单数据从DWD层向DW层、ST层的汇总过程，并将其DW层、ST层数据同步给云化历史库,1、2：生

43、产系统数据导入云化数据交换平台，在云化数据交换平台上进行数据的清洗和转换，完成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数据,S

44、T数据,1,2,3,5,4,6,7,8,9：通过云化数据交换平台向各数据集市同步所需数据,9,39,大数据处理目标架构数据流向（续）客户资料、订购关系类数据分布及流向,云化数据交换平台,主数据仓库,D1：通过云化数据交换平台向各数据集市同步所需数据,C1：主仓库负责数据从DWD层向DW层的汇总过程，生成DW层数据模型C1；C2：将主库DW层数据C1通过云化数据交换平台同步给云化历史库C2,A1：客户资料、订购关系类的生产系统数据导入云化数据交换平台，在云化数据交换平台上进行数据的清洗和转换，完成ODS到DWD的数据模型转换,大数据分析平台,B1、B2：云化数据交换平台处理后的DWD层数据文件通

45、过多加载进入主数据仓库和云化历史库,云化数据交换平台,DWD,DW,ST,DWD,DW,ST,ODS,DWD,ODS,DWD,云化历史库,DWD,DW,ST,A1,B1,B2,D1,C1,C2,除网络/详单外的DWD数据加载,网络/详单类DWD数据加载,全量的DWD数据加载,40,大数据处理目标架构数据流向（续）网络流量、计费详单类数据分布及流向,云化数据交换平台,主数据仓库,D1：通过云化数据交换平台向各数据集市同步所需数据,C1：大数据分析平台负责计费详单、网络数据从DWD层向DW层的汇总过程，生成DW层数据模型C1；C2：将大数据分析平台的DW层数据通过云化数据交换平台同步给云化历史库C

46、2；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数据加载,

47、全量的DWD数据加载,41,各平台数据存储周期及数据量需求（单位：TB）,42,大数据处理目标架构关键点分布,3. 构建云化历史库,2. 构建大数据分析平台,1. 构建云化数据交换平台,4. 现有系统配合改造,43,大数据处理目标架构关键点详解-云化数据交换平台,本次云化数据交换平台除实现ETL功能的集中云化部署和增强清洗转换、实现计算前移外，还将提升接口的标准化，并在抽取上进行优化，以减轻网络资源的开销,44,大数据处理目标架构关键点详解-大数据分析平台,平台建设,大数据分析平台负责网络和详单数据的处理，要求具备突出的数据加载、处理性能，以及优秀的高可用性；通过并行加载的方式，同时向各工作节

48、点写入数据，提高数据加载速度；采用哈希算法将数据近似平均地分布到所有工作节点上，并将工作节点划分为多个并行的虚拟处理单元，增加系统的并行度，提高数据处理效率；配置2台管理节点（一主一备），设置1份数据副本（系统共两份数据），保证系统高可用性和数据安全性.,数据管理,大数据分析平台主要承担事件域数据（包括网络和详单数据）的DW层和ST层汇总处理；在大数据分析平台上创建名为Event的Database，用于承担事件域数据模型的存储与管理；根据分层设计原则，在Event DB下，划分出DWD、DW、ST三个schema，分别存储DWD层、DW层、ST层的实体模型，并用schema名称区分.,业务支撑,利用ST层结果数据，支撑流量业务统计监控、业务稽核等流量经营基础应用；在大数据分析平台上部署挖掘模型及分析应用，如时间序列分析（通过路径分析用户的轨迹，可用于定位服务推荐）、关联分析（通过交往圈分析用户影响力，可用于营销及维系挽留）、文本分析（通过日志分析用户偏好，可用于精确营销）等.,大数据分析平台,45,