共享数据中心架构设计方案.pptx

《共享数据中心架构设计方案.pptx》由会员分享，可在线阅读，更多相关《共享数据中心架构设计方案.pptx（30页珍藏版）》请在悟道方案网上搜索。

1、共享数据中心架构设计方案,共享数据中心总体方案,系统架构和关键技术,目录,对共享数据中心目标蓝图的理解 总体架构（内外部关系和定位）的关键要点,分析应用： 信令分析应用等纳入性能管理系统实现；性能管理应用、（无线）优化分析应用，应统一从数据中心取数，形成自己的数据集市 提供应用发布与管理平台，实现对各类分析应用的全生命周期管理,数据采集和处理： 信令平台/DPI完成编解码、关联合成为xDR和固定KPI预统计后，应将xDR和KPI同时送往数据中心 基于信令的实时应用及共享（Call Trace、实时QoS监控、CDR和KPI的实时对外共享）、基于拨测和路测的实时应用及共享（拨测验证等）等，还需要

2、保留在信令平台、拨测/路测平台中,数据管理和存储： 需要实现各类网络质量数据的统一建模、建立关联、集中存储、集中管理。 数据范围包含细节数据（CDR、MR、话单、DPI、日志等）和各类统计数据（KPI） 数据中心是网络质量统计类数据的属主，数据中心要实现对准实时性能数据的统一集中管理,数据开放和共享： 实现综合分析系统应用和数据的分离，对外开放共享数据模型和数据内容 不仅仅向分析类应用开放数据，使用准实时性能数据的应用也可以从数据中心获取,对共享数据中心目标蓝图的理解 主要的数据管理范围（目标）,各类网络质量数据的集中，数据粒度包括细节数据和统计汇总数据； 网络质量数据中心作为各类详细数据的备

3、份，根据不同类型数据的特点需要保存一定时间段内的详细数据，用于为支撑分析应用的面向详细数据的溯源分析和满足新的统计需求下的基于历史数据的重计算。,对共享数据中心目标蓝图的理解 主要解决的问题和价值（驱动力）,数据重复处理和存储，口径不一 专业网管、综合网管、无线网优平台以及各类拨测/路测系统、各类信令监测系统并存，各系统各自分散地采集网络质量数据，重复计算存储造成投资、投入浪费 由于缺少统一的计算处理，算法各异，导致呈现指标口径不一，可信度低,分析应用重复建设 由于质量数据的分散、割裂，多个分析优化类系统的质量分析应用在一定程度上存在功能重复，造成投资浪费 同时影响综合分析等重点建设大系统的应

4、用推广,网络性能数据共享困难 专业网管、综合网管、无线网优平台以及各类拨测/路测系统、各类信令监测系统之间的数据共享困难，不及时、不准确，相互理解困难 频繁通过系统接口传递共享数据，数据质量得不到有效保障,质量数据之间缺少关联整合 同时，缺乏统一的网络质量分析数据模型，不同数据源的数据、不同专业的数据、不同时间粒度的数据没有有效整合，用户、终端、平台、网络、设备各环节的数据不能关联，无法满足端到端业务品质管理、集中化性能管理、智能管道管理的一体化、综合化分析需求，无法做到影响客户感知质量问题的可视和可溯源,1,2,3,4,性能管理系统（试点）建设现状,综合网络分析系统从2008年开始探索、启动

5、建设,针对明确而宏大的目标，需要基于现状分析确定技术演进路线,信令分析系统建设： 2011年：启动信令分析系统架构预研 2012年：开展厂家技术测试，厂家招标选型,综合分析系统的现状,综合分析系统在实现对各类综合化的分析需求提供支撑的同时，在数据管理能力方面有如下现状和需求： 集中管理问题：数据类型接入较多，但每类数据都不够完整，单纯以满足应用需求为驱动 元数据管理问题：没有参与实际计算过程，不能实时反映数据现状，无法有效支撑数据质量管理要求、溯源影响分析 大数据分析问题：对新增个性化需求的响应效率低，无法快速支撑生产 计算和存储能力问题：集中式的小型机为主的架构（SMP），节点规模受限、磁盘

6、IO瓶颈等，计算和存储能力可扩展性不足，导致高峰期负荷高，性能劣化明显；并且性价比不高，缺乏冗余备份，安全性不足；无法对信令、话单等进行全量管理，难以支撑端到端的、灵活的分析优化应用 数据开放共享问题：数据分层接口没有标准化和开放，封闭的体系使得进度和质量受限于单一厂家的资源、能力,IBM P55A,8*X86,RAC(IBM P780*2+P570*2),RAC(IBM P570*2),虚拟机+列数据库,信令监测系统架构现状,应用层 应用管理子层：实现应用的全生命管理 应用子层：提供各类分析应用 编解码子层 信令的编解码、合成和关联,向上提供CDR 实时应用提供 采集层 采集原始信令码流数据

7、，并实现全省的信令码流数据的汇聚，统一提供给编解码子层进行信令的编解码,共享子层 已经实现了对信令CDR数据的接入 数据计算与存储层：已经实现了海量数据存储、海量数据处理（并行计算）、海量数据仓库 数据共享层：已经实现了基于元数据的信令类各类分析应用的数据提取需求，提供灵活的数据共享接口并通过订阅提供大数据 已经实现了元数据对数据驱动，对外提供基于元数据共享服务,共享数据中心目标落地的技术演进路线选择,综分、信令和目标蓝图各个层次/模块的对应关系,相关系统现状或待建规划,目标蓝图,存在“基于综分系统改造”、“基于信令平台扩展”、“新建”等技术路线，信令平台架构采用了分层开放的架构、具备海量数据

8、存储、计算、共享能力，并且接入了数据共享中心中占比最大的信令数据，具备了数据共享中心的雏形，因此“从信令平台扩展到共享数据中心”的技术路线更符合经济性和可行性，建设风险最低。,共享数据中心试点阶段临时方案,GP服务器：2台IBM 3650 M4（2*8核，主频2.4GHZ CPU，64GB内存，16*1TB SATA硬盘） 数据处理服务器：2台IBM 3650 M4（2*8核，主频2.4GHZ CPU，128GB内存，16*1TB SATA硬盘） 应用服务器：2台IBM 3650 M4（2*8核，主频2.4GHZ CPU，64GB内存，16*1TB SATA硬盘）,Oracle EXADATA

9、 （ 1/2 X2-2 HP EXADATA ）,共享数据中心的关键技术要点,在总部的指导下，通过前期的一系列研讨，梳理了目标蓝图实现要解决的关键技术难点。,共享数据中心的关键技术要点（续）,数据中心和采集平台的边界-试点现阶段现状,协议适配、原始counter文件获取,文件解析、格式归一化整理,在内存中网元级的KPI计算,输出为counter标准文件（CSV）,消息中间件,性能监控数据库,性能监控应用,文件缓存,在数据库中进行时间、空间的汇总、计算,性能分析报表,共享数据中心,ESB,数据中心和采集平台的边界-目标,协议适配、原始counter文件获取,文件解析、格式归一化整理,在内存中网元

10、级的KPI计算,输出为counter标准文件（CSV）,消息中间件,性能监控数据库,性能监控应用,文件缓存,共享数据中心,数据中心和采集平台的边界,已经达成的共识： 数据采集平台不需要数据库，以文件方式缓存，提供接口支持共享数据中心进行补采和核查，建议缓存时间一个月 网元Counter级数据需要纳入共享数据中心管理 采集平台不做时间、空间的汇总，统一由数据中心实现 数据中心需要具备准实时的汇总计算和对外共享能力，按需为准实时性能监控提供KPI指标级数据,争议点：采集平台/信令采集和编解码子层中是否要保留基本的、实时的KPI计算能力？,共享数据中心与应用之间的数据边界,分布计算框架,大数据分析,

11、共享接口层,统一采集平台,其他,数据云、存储云、处理能力云,综分应用,应用数据,其他分析应用,海量数据存储 海量数据处理（并行计算） 海量数据仓库（以资源为基础，多维关联，统一建模），对外提供大数据挖掘分析服务 统一的元数据管理，对外提供元数据服务,元数据 、数据质量管理,元数据服务,数据中心作为基础平台提供数据的存储、计算、共享,报表,专题,BI,自定义,综分应用数据,性能管理系统作为数据中心的一个典型应用： 重点在于应用功能逻辑、界面等的实现 梳理应用数据模型，并从数据中心抽取相关数据（汇总级别数据或Cube），形成应用数据视图 应用数据可以通过cube、传统oracle数据库、列数据库（

12、提供更优的查询效率）来承载 详单数据通过数据中心共享层直接查询,数据中心,企业应用集市,数据中心和应用层的边界（续）,ODS,EDS,DM,STAGE,EDS宽表,数据仓库,ODM,DW Root+汇总,共享数据中心的目标是数据的共享， 将众多应用中的共性的数据集中起来，统一描述，统一计算，统一共享 通过对共性数据的统一处理，降低了整体的系统处理成本，提高了数据的一致性，并且建立了为更多应用提供可靠的一致性数据的服务能力； 应用保留一个轻量级的数据库以满足应用的功能性要求 基于共享数据中心提供的基础数据服务，应用厂商可以使用自己熟悉的工具和手段进行应用建设，数据消费者可以快速获取基础数据，但并

13、不意味着不需要本地存储，应用系统需要将应用个性化的数据存储于本地数据库中，用于支撑完整应用逻辑 提高应用设计灵活性 通过应用和数据共享中心确定了明确的边界， 降低了数据共享中心和应用的耦合度，降低了数据共享中心实施难度；数据共享中心如果对应用ETL过程和个性化数据进行管理，那么就需要介入到每个应用的功能设计过程中，容易使数据共享中心成为瓶颈，而且使应用与共享中心之间责任不清；当然，数据中心所在的物理平台可以为应用提供PaaS服务（资源层面） 增强数据共享中心的健壮性和安全性,数据中心分层的数据模型,不同存储形式的数据：不同数据采取不用的存储方式，以达到更高的存储性价比与更快的访问效率 多种维度

14、的数据：借助数据仓库的能力，有效存放和管理各种不同维度的数据。 稳定的数据结构：DW和ODM相对稳定，灵活满足业务分析的需求,DW(Aggregation)：提供中性的数据服务以及专题基础数据汇聚。 DW：面向全局，数据整合，按照主题域建模。 ODM：对数据进行简单处理和识别，如维度化，以及对数据进行业务分类。 Staging：纯技术加工，为ODM提供技术清理后的数据。,数据中心分层的数据模型（DW）,网络主题域：以资源为核心的建模，主要关注网元的性能与容量、质量等。 业务主题域：以业务为核心的建模，主要关注业务的性能以及业务量上，并支持从业务到网元的穿透分析。 客户主题域：以客户为核心的建模

15、，主要从用户的角度来关注用户的体验，包括建立用户的档案、用户的行为特征、用户的业务使用、用户的行动轨迹（网元）、用户的投诉。 公共主题域：包括公共的维度模型，这些公共的维度模型在各个其他主题域的计算或者中性汇聚过程中是需要的，并且也常常是上层应用所经常使用到的。 维度模型的统一和共享：维度模型在全局范围内是唯一的，且可以被其他各主题域的模型所共享。 主题域间的维度集成：为了支持网络-业务-客户之间的穿透分析需求，在设计各个主题域时，单个主题域需保留其他主题域的核心模型维度。比如：客户主题域中需支持客户-网络，或者客户-业务的事实数据，以支持用户轨迹或者用户业务分析的功能。,ODM可以分为从存储

16、PM数据的ODM-DB和存储话单的CDR-DB ODM-DB：作为PM/CM数据的存储域，使用关系型数据库 CDR-DB：存储数据量大的信令数据以及日志数据,大数据量处理的系统架构,分布式库外计算：分布式库外计算将原始文件汇聚成Counter。 库内数据聚合计算：完成基于数据库的统计数据聚合计算。 统计数据仓库：依据数据仓库数据模型要求建模，存放统计数据。 CDR数据库：存放原始CDR文件。 元数据&数据质量管理：提供算法并驱动计算；对数据质量进行管控。 数据共享：通过数据共享北向输出数据。,大数据量处理的系统架构（分布式计算和存储）,文件服务器集群（PC服务器），接收编解码送来CDR

17、（Call Detail Record）文件。 分布式计算集群（ PC服务器），CDR数据流处理，数据汇总和聚合技术。 汇总数据存储（EXADATA 一体机），存储汇总数据。 分布式存储集群（ PC服务器），存储原始CDR数据。 数据共享集群（ PC服务器），为上层应用提供数据共享服务。 备份集群（ PC服务器），数据安全备份。,分布式方案,准实时数据计算和共享,流式计算框架是基于规则引擎的计算，并在XX业务方向上做了优化，以满足准实时Counter/KPI数据计算的要求。流式计算的优势： 可以水平扩展 支持按照业务进行数据分布，大大提高数据处理效率 基于OSGI框架的设计，方便业务组件的升级

18、和扩展 准实时Counter/KPI通过实时数据接口北向共享，满足准实时应用的需求,端到端的元数据管理,端到端的元数据管理驱动数据在系统中流转，驱动数据建模过程和数据质量管控过程 生产数据的过程做灵活的控制和调度，确保数据生产线生产出的数据按照既定图纸生产，并灵活可变 生产出的数据做质量控制，数据质量可视、可监控、可追溯 元数据驱动的数据生产与管理本质上是体现规范的开发过程要求，体现的是设计指导实现，实现与设计吻合的管理要求,大数据分析,平台化的自定义计算服务、大数据自定义分析服务：基础数据集中后，如何发挥更大价值，需要提供一个平台化的自定义计算分析服务框架，让更多的集成商能基于平台进行数据计

19、算定义，最大发挥平台价值，也避免了数据中心成为瓶颈 大数据分析能力：在数据共享的基础上，平台提供了大数据的即席查询和分析任务定制两种功能，进一步开放了平台的处理能力,采集层,数据质量检测,分布式计算,数据质量检测,SQL Engine(DB) Calculation engine,Data Warehouse,DataModuling,Metadata Master,JAVA Engine,Metadata client,Metadata client,数据质量模型,Counter,Counter,Counter,数据质量检测,Counter,元数据驱动数据质量定义： 数据质量的要求由元数据定

20、义， 不同的数据 和指标允许有不同的数据质量等级,各层的数据质量检测模块驱动检测： 元数据主模块同步数据质量要求到SQL计算模块和Java计算模块及采集层的元数据子模块， 由元数据子模块驱动对应的数据质量检测模块进行数据质量检测，并把检测结果返回数据质量模型。,数据质量模型化模块进行数据质量计算并提供API：收集到的数据质量Counter进行数据质量建模，经过CounterKPIDQI 过程实现对指标数据源数据质量评估,数据质量架构框图,数据质量管理功能,数据质量监控,数据质量分析,数据质量模型管理,数据质量溯源,Data Center,3rd application,接口开放性，适用多种数据

21、共享需求环境,GreenPlum,Exadata,JDBC / ODBC,Data Center,GreenPlum,Data Proxy,Exadata,3rd application,应用模块,Web Service + File,SQL,SQL,数据中心直接开放数据库JDBC、ODBC 连接应用抽取数据,通过API/Webservice的数据接口订阅数据 ， 数据网关通过元数据组织数据提供给使用方。 优点： 应用和数据中心松耦合， 应用移植相对容易 ， 缺点： 实现较复杂,查询,基本功能： 数据库直连接口,DataProxy查询接口,优点： 简单，实现容易， 缺点： 系统紧耦合，数据中心

22、表的变动，会直接影响应用,Data Center,3rd application,应用模块,File,三方应用通过Data Proxy 以Web service方式订阅数据 经过一次订阅，数据中心通过Data Proxy 以文件方式周期性返回订阅数据，作为应用处理模块的数据源,订阅,File,DataProxy订阅接口,GreenPlum,Data Proxy,Exadata,SQL,SQL,Data Center,3rd application,应用模块,File,三方通过Data Proxy 以Web service方式点播rawcounter数据，并制定算法 数据中心通过Data Pro

23、xy 以文件方式一次性返回点播数据，作为应用处理模块的数据源,点播,File,GreenPlum,Data Proxy,SQL,DataProxy点播接口 （大数据分析服务）,打造可运营的平台能力-后台承载,数据采集层：完成与原始数据的适配和数据采集及数据的过滤，复制和分发。 数据计算和存储层：完成数据计算和存储，将汇总数据和CDR数据存放进不同的数据存储实体中。 数据共享层：基于存储层的数据，提供北向数据输出能力。 数据质量管理：检测从数据源到数据输出全过程的数据质量情况，并进行监控和分析，建模和追溯功能。 元数据：描述系统核心数据结构和关键计算算法，驱动数据在系统各个模块中的流转。,打造可

24、运营的平台能力前台“四可”能力,要使共享数据中心成为稳定的平台，需要建立“可视、可控、可分析、可溯源”的可运营平台，需要建设相应的管控功能 端到端的数据质量管理功能，全过程保证数据质量 运行状态的监控功能，对端到端的数据处理过程进行监控 元数据可视化管理的功能，完整呈现所管理的数据内容,应用管理层功能架构 借鉴App Store功能架构,应用层分为应用管理平台和应用子层。应用管理平台是信令应用的容器及承载平台。应用子层提供各类丰富的应用。 应用管理平台 实现对应用的准入、发布、订阅的管理，从而实现应用的快速复制 实现对应用使用情况的分析和管理,所有应用厂商均按照统一的接口技术规范与数据共享子层、应用管理平台进行接口开发 所有应用厂商均按照统一的CSS规范进行界面开发，保持界面风格的统一。 各应用需求，可自行挑选合适的开发厂商，平台对所有的开发厂商开放,谢谢,