《中国电信eda总体规范-技术与架构分册》初稿

allenlei 贡献于2016-09-13

作者 Yeyh  创建于2010-01-05 03:33:00   修改者Paradise  修改于2013-07-06 05:47:00字数64452

文档摘要:ITSP大背景,企业环境的大背景,集约化要求等等引出全网数据共享服务中心的概念.
关键词:

 中国电信EDA 总体规范2.0 《中国电信EDA总体规范-技术与架构分册》 2013年6月 版权声明,保密 第页 中国电信EDA 总体规范2.0 目录 1 文档说明 1 1.1 编制说明 1 1.2 适用范围 1 1.3 内容说明 1 1.4 起草单位 1 1.5 解释权 1 1.6 版权 1 2 概述 2 2.1 现状分析 2 2.2 业务目标 2 2.3 技术目标 2 3 架构体系 2 3.1 总体架构 2 3.1.1 总体架构 2 3.2 数据平台 2 3.2.1 ETL平台 2 3.2.2 ODS 2 3.2.3 EDW 2 3.2.4 大数据平台 2 3.2.5 ODS与生产系统的功能定位 2 3.2.6 ODS与EDW的功能定位 3 3.2.7 大数据平台与ODS、EDW的功能定位 3 3.3 数据架构 3 3.3.1 EDA域数据流程图 3 3.3.2 ODS数据架构 3 3.3.2.1 接口数据层 3 3.3.2.2 整合数据层 3 3.3.2.3 汇总数据层 3 版权声明,保密 第页 中国电信EDA 总体规范2.0 3.3.2.4 共享数据层 3 3.3.3 EDW数据架构 3 3.3.3.1 接口数据层 4 3.3.3.2 整合数据层 4 3.3.3.3 汇总数据层 4 3.3.3.4 应用数据层 4 3.3.4 大数据平台数据架构 4 3.3.4.1 接口数据层 4 3.3.4.2 处理数据层 4 3.3.4.3 共享数据层 4 3.3.5 EDA两级数据交互 4 3.3.6 数据集市 4 3.3.6.1 数据集市综述 4 3.3.6.2 应用集市 4 3.3.6.3 专业集市 4 3.3.6.4 地域集市 4 3.3.6.5 基于大数据的创新集市 5 3.4 数据应用 5 3.4.1 数据展现与服务提供 5 3.4.2 企业数据应用视图 5 3.4.3 企业管理分析 5 3.4.3.1 战略分析 5 3.4.3.2 预算管理 5 3.4.3.3 。。。。 5 3.4.4 企业运营分析 5 3.4.4.1 竞争分析 5 3.4.4.2 客户分析 5 3.4.4.3 。。。 5 3.4.5 企业服务分析 5 3.4.6 企业销售分析 5 3.4.7 产品开发 6 3.5 数据运营管理平台 6 3.5.1 元数据管理 6 版权声明,保密 第页 中国电信EDA 总体规范2.0 3.5.1.1 业务元数据 6 3.5.1.2 技术元数据 6 3.5.1.3 元数据管理要求 6 3.5.2 主数据管理 6 3.5.2.1 主数据概述 6 3.5.2.2 主数据统一编码 6 3.5.3 数据安全管理 6 3.5.4 数据质量管理 6 3.5.4.1 数据质量管理的目的 6 3.5.4.2 数据质量管理原则 6 3.5.4.3 数据质量管理的内容 6 3.5.4.4 数据质量管理的方法 7 3.5.5 统一调度管理 7 4 专题应用 7 5 EDA与生产系统及运维要求 7 5.1 EDA对生产系统的数据提取要求 7 5.2 生产系统对EDA的数据响应要求 7 6 技术要求 7 6.1 系统平台要求 7 6.2 推荐技术 7 7 部署实施策略指导 7 8 附录 7 8.1 主要编制人员 7 版权声明,保密 第页 中国电信EDA 总体规范2.0 1 文档说明 1.1 编制说明 1.2 适用范围 本规范适用于指导中国电信集团公司及下属省(市)公司进行EDA项目建设相关工作。 1.3 内容说明 本文档主要包括EDA的架构体系、重点应用支撑、数据质量管理和系统运营管理等方面内容。 1.4 起草单位 本规范的起草单位属于中国电信集团公司。 1.5 解释权 本规范的解释权属于中国电信集团公司。 1.6 版权 本规范的版权属于中国电信集团公司。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 2 引言 ITSP大背景,企业环境的大背景,集约化要求等等引出全网数据共享服务中心的概念. 2.1 全网数据共享服务中心 全网数据共享服务中心的概念、架构及在itsp3.0中的定位 全网数据共享服务中心核心构成是两级EDA及全网数据交换枢纽,由此引出规范EDA建设的重要性. 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 2.2 本规范制定的目的和意义 围绕本规范作为总部和省EDA建设的指导规范这样一个定位,说明本规范的设计目的、功能定位、构成要素等。 3 EDA概述 3.1 现状分析 大数据时代,EDA存储不够,扩容难,非结构化数据处理能力不足,数据实时性处理能力不足 数据应用能力不足 数据基础能力不足 数据运营能力不足 3.2 技术目标 优化架构体系,支撑大数据处理(包括实时处理)与存储能力 建设数据运营管理平台,提升数据运营管理能力 ,提升数据汇聚、交互、共享与服务能力 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 4 EDA系统架构(国信) 中国电信 EDA 是中国电信信息化转型的战略体系(CTG-MBOSS)的重要组成部分,服务于整个中国电信企业发展战略。EDA 在整个 CTG-MBOSS 中起到对企业数据整体的规范和管控作用,其范围包括对企业所有数据的规范体系和管控体系。 EDA 是指企业实施全面的企业运营数据的管理和控制,实现数据在采集之后的分析,从企业的整体视角了解企业、客户和市场,通过数据更好地支撑企业运营。根据ITSP 3.0的目标要求,中国电信企业数据架构以数据共享为目标,做好基础数据管理,积极探索和推进大数据应用,以系统为载体,以数据管控为保障,实现企业数据共享、业务支撑和价值提升。 EDA 是由运营数据仓储(ODS)、大数据平台(BDS)、企业数据仓库(EDW)系统及承载在其上的数据展现与服务、数据应用组成,包括 EDW 、 ODS和BDS 所涉及 的ETL、元数据管理、数据存储、报表和 OLAP 以及数据挖掘等。 4.1 技术架构 EDA技术架构由数据存储与处理平台、数据展现和服务、数据应用、数据运营管理四部分组成,如下图所示。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 图4-1 中国电信 EDA 技术与架构 n 数据存储与处理:由ETL平台、运营数据仓储(ODS)、大数据平台(BDS)、企业数据仓库(EDW)和 数据集市构成,是数据应用承载的基础。 Ø ETL平台:为了满足对当前非结构化、海量数据的实时处理要求,在原有ETL基础上引入了分布式ETL处理模式。ETL 平台包括数据的抽取、转换、装载的过程,为 ODS、EDW、大数据平台提供数据基础。传统ETL采用文本文件、数据库、消息服务等技术方式对传统的结构化数据进行增量或全量的采集和处理,将数据提供给ODS平台。分布式ETL通过多服务器间按照协同工作机制,将要执行的ETL流程分配在多台机器上执行,将数据提供给大数据平台。ETL 平台的数据处理过程涵盖了数据生产源系统、ODS、EDW、大数据平台、数据集市的数据流向全过程,使经过处理后的数据符合 EDA 域各层的使用需要。 Ø ODS:ODS的大部分数据来源于生产系统,主要采用批处理的数据处理方式,多基于OLTP技术的SMP架构的数据存储管理,存储了短期的面向运营的准实时结构化数据,提供统一的企业运营数据视图,支撑跨系统的生产报表、跨系统数据的批量计算、准实时运营数据查询和准实时的数据共享应用。ODS 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 给大数据平台提供数据共享,ODS的部分数据来源于EDW的分析结果数据。ODS通过共享层将数据提供给外围系统使用,作为EDW的主要数据来源。 Ø 大数据平台:为了满足移动互联网时代数据处理和分析的要求,新的EDA以混搭架构引入了大数据技术,负责对非结构化、海量数据进行处理、整合、存储及分析应用,形成大数据平台。大数据平台的数据来源于互联网日志、信令和外部系统数据。海量结构化数据和非结构化数据采用批处理的数据处理方式,基于MPP高可扩展并行数据库架构或hadoop架构的数据存储管理方式,存储了诸如用户话单、DPI等数据信息;消息类流数据采用流处理的数据处理方式,实时处理,实时对外共享结果,一般不做存储要求。大数据平台通过hadoop等技术对海量数据进行轻度汇总,对海量的、非结构化的数据进行标准化、标签化,共享给ODS,同时使用大数据挖掘和探索手段,支撑全网大数据的创新应用。大数据平台与ODS和EDW相互补充,丰富了原有EDA的数据存储和数据应用。 Ø EDW:面向分析型的数据仓库,数据主要来源于ODS,ODS未整合的运营数据直接从源系统抽取。采用批处理的数据处理方式,基于SMP架构或MPP高可扩展并行数据库架构的存储管理,存储了长期的、明细和概要的分析型信息,采用数据统计、多维分析和数据挖掘等手段,细分市场和客户,支撑市场的经营分析和决策。 Ø 数据集市:数据集市作为中国电信 EDA 系统的组成部分,从企业运营数据仓储 ODS 、大数据平台和企业数据仓库EDW 抽取相关数据并进行转换和装载,并根据应用需求形成数据集合,支撑各种专业化应用,是为满足已定义的用户组或业务领域对于特定业务信息的需求而创建,较数据仓库而言,更关注在数据中构建复杂业务规则来支持功能强大的分析。数据集市包括地域集市、应用集市、专业集市、基于大数据的创新集市。在实现方式上,数据集市可 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 依附于三大平台进行建设,考虑到系统性能和应用效果也可以采用物理部署的模式,但是数据必须由EDA 统一提供,不允许直接和生产系统对接。 n 数据展现和数据服务:该层将数据存储与处理平台生成的数据进行封装处理后,提供统一数据共享接口,通过固定报表、多维分析、界面集成、自助取数对数据进行展现,同时以数据服务调用的方式提供给周边系统或内部应用。 Ø 数据封装:利用数据封装技术按照业务需求,根据一定规律将底层数据封装成上层服务。 Ø 数据展现:展现层接收用户请求,响应用户操作,并以Web页面的形式向用户返回结果,具备基于Portlet技术与门户平台集成的能力。 Ø 数据服务:数据服务提供是指将EDA 经过整合、加工处理后的数据,以数据服务调用的方式提供给周边系统或内部应用。数据服务提供主要有数据共享、服务调用和API接入服务多种技术实现手段。 n 数据应用:数据应用基于数据服务层的共享接口获取数据或通过展现工具实现数据的直接展现。统一的数据应用平台,对内支撑企业管理分析、企业经营分析、企业服务分析、企业销售分析及产品开发;对外支撑产品化的数据服务以及数据提供。 Ø 企业管理分析:企业管理分析是对企业管理涉及的人、财、物等各方面进行综合分析,为企业管理层制定企业战略及预算考核等提供决策依据,主要包括战略分析、绩效管理、预算管理、人力分析、财务分析、工程与物资分析。 Ø 企业经营分析:企业运营分析是对企业在营销、销售、服务管理等方面进行分析与支撑,包括业务发展分析、客户发展分析、营销活动策划、结算分析等。企业运营分析面向市场、营销、和策划人员日常工作的分析支撑。 Ø 企业服务分析:企业服务分析是对企业在服务管理方面进行分析与支撑,包括客户满意度分析、产品评估、服务质量分析、营销活动评估等。企业服务分析面向服务管理和服务质量的分析支撑。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Ø 企业销售分析:企业销售分析是对企业在销售管理方面进行分析与支撑,包括终端销售分析、产品与套餐分析、流量热点区域分析、营销活动过程监控分析、业务收入分析等。企业销售分析是面向产品或营销活动过程的分析支撑。 Ø 产品开发:通过数据分析应用,发现用户的消费行为习惯、消费心理,支持对企业的产品、网络资源、财务管理等方面进行产品优化和产品开发,使产品更适应市场需求,满足用户需求,方便企业管理。 Ø 产品化:是对企业内部的数据资源按需进行分析、整合、包装,形成产品,通过统一的服务接口,对外提供数据经营。 Ø 数据提供:直接以数据信息形式,通过统一的服务接口,对外提供数据经营。 n 数据运营管理:数据运营管理平台是中国电信集团在ITSP3.0规划的数据运营体系下,所建立的面向EDA域各数据系统和支撑系统的,统一的、综合性的运营数据管理支撑平台。主要包含数据质量、数据安全、元数据管理、主数据管理和统一调度管理五个方面。 Ø 元数据管理:元数据是关于数据的数据,是对数据的含义、功能、来源等进行描述,元数据管理贯穿于EDA构建、运行和维护的整个生命周期。 Ø 主数据管理:主数据是指在企业生产运营过程中产生,被多个系统重复使用的,相对稳定的核心实体数据。其特点是基于业务、长生命周期、跨系统使用。主数据的属主特性以产生主数据的系统为主。 Ø 数据安全管理:企业数据是企业的核心资源,数据安全管理是数据管理工作重要组成部分,需要集中管控。 Ø 数据质量管理:是数据采集、传输、处理、汇总、审核、发布等各个环节的质量的闭环管理体系。 Ø 统一调度管理:实现对元数据、主数据、稽核规则的变更日志、程序运行日志的查询;实现对流程的调度配置 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 。 4.2 数据架构 EDA数据架构是EDA整体架构设计中的关键部分,它围绕数据共享服务中心的目标,对EDA的数据体系进行科学规划和全面设计,EDA数据架构图如下所示: EDA数据架构描述了 ODS 、EDW和大数据平台的数据分层架构,以及 ODS、EDW、大数据平台和数据集市之间的数据流向。ODS 分成接口层、整合层、汇总层和共享层,EDW 分成接口层、整合层、汇总层和应用层,大数据平台分为接口层、处理层和共享层。数据源通过ETL平台加载到ODS和大数据平台,在ODS、EDW和大数据平台中通过一系列整合、汇总后,形成各类数据集市,最终支撑各类数据应用、展现和服务。 数据源按照数据类型可以分为结构化核心数据、海量结构化数据、非结构化数据和消息类流数据。 结构化核心数据如MSS、BSS、OSS和业务平台等应用系统中的数据,通过传统ETL平台加载到ODS中, 存储在ODS的接口层,接口层的数据模型与外围系统基本保持一致,ODS整合层的数据主要来源于ODS接口层,是ODS的核心数据层,数据模型遵循集团EDM模型对数据进行整合,按照应用和主题报表的要求将ODS整合层的数据进行汇总,形成汇 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 总层,基于ODS中各层整合好的数据,形成共享数据层,对外提供共享数据,通过共享数据层将数据提供给EDW平台和大数据平台,提供给大数据平台的主要有用户资料类、客户资料类等数据。EDW的数据主要采集ODS整合层的数据,存储在EDW的接口层,根据企业经营分析、企业管理分析等应用要求,对数据进行整合、汇总最终形成应用集市、专业集市、地域集市等各类数据集市。同时,也允许EDW的分析结果回送给ODS,弥补ODS分析加工数据能力的不足,支撑ODS的对内对外数据支撑需求。 海量结构化数据和非结构化数据如语音详单、DPI详单等数据从源系统通过分布式ETL平台加载到大数据平台,存储在大数据平台的接口层,接口层的数据模型与外围系统基本保持一致,大数据平台的数据处理层主要对采集到的大数据平台接口层的数据和ODS提供的用户资料、客户资料等数据进行整合、汇总,最终对处理整合好的数据形成共享数据层,通过共享数据层对外提供数据共享服务,并将客户标签清单、用户标签清单等数据回送给ODS汇总层,支撑ODS的对内对外数据支撑需求。同时为了支撑移动互联网业务创新,基于大数据平台建立创新集市,如增值和移动互联网数据集市等。 消息类流数据如互联网日志,信令等通过分布式ETL平台加载到大数据平台,大数据平台对消息类流数据进行流处理实时对外共享等。 4.3 功能架构(待定) 各平台功能模块 4.4 部署架构 根据数据共享服务中心的建设要求,全网EDA体系结构分为两级,如下图所示,即集团企业数据应用(EDA)和省分公司企业数据应用(EDA)。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 图4-3 中国电信EDA部署架构 第一级:集团企业数据应用(EDA),在原有ODS、EDW、ETL平台的基础上,部署总部大数据平台,对ETL平台进行改造以满足非结构化海量数据处理要求。 第二级:省分企业数据应用(EDA),有两种模式,一种是含大数据平台的EDA模式,一种是不含大数据平台的EDA模式,根据集团统筹安排建设情况。 两级EDA通过全网数据交换枢纽进行数据交互。通过数据服务体系,进行数据的上传和下发工作,通过数据运营体系,进行主数据、元数据、数据安全、数据质量和统一调度等工作管理。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5 EDA数据处理与存储平台 5.1 ODS(亚联) 5.1.1 平台定位 ODS系统是中国电信EDA架构中的重要组成部分,是生产系统和EDW系统中间的数据缓冲层, 承载企业级数据模(EDM)型落地重要职责,通过数据的抽取、加载、整合等手段,对来源于生产系统(CRM、计费、销账、网厅,10000号,百事通等系统)的结构化数据进行清洗,不修改源数据,同时也从大数据平台获取轻度汇总的海量数据,提供数据整合、客户统一视图、批量计算、运营报表展示和查询统计等功能,通过数据质量管理和稽核策略,保障数据的完整性,及时性和准确性,通过共享数据层,对外围系统(包括EDW、营销、维系、代理商、佣金结算、10000号等系统)提供整合层,轻度汇总层和应用层不同层面数据,以准实时,按天,按月不同频率,有力保障应用系统对数据的需求,同时也保障了一线生产和管理人员对数据不同层面的使用和查询。 5.1.2 功能要求 ODS系统主要通过ETL处理手段,提供了数据整合,数据共享,数据应用和数据质量稽核功能,充分落地企业级数据模型(EDM),通过共享数据层,对外围系统提供数据共享。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.1.2.1 数据整合 ODS在对企业运营数据的整合过程中能够实现以下三个统一:统一数据模型、统一数据标准、统一数据视图。ODS 承载企业数据模型(EDM),促进企业各系统数据逻辑模型的统一。ODS 中建立标准的数据编码目录,源系统数据依据标准的数据编码目录,经过整合后进入ODS 中存储,实现企业数据的标准化与统一存储。基于ODS 所存储的数据,支撑实现统一数据视图,使企业在客户、产品、资源等视角获取到的信息是一致的,提升客户、企业内部的管理人员与分析人员对系统的感知。在ODS的数据整合方面,不仅仅包含目前BSS域的数据整合,也要逐步把OSS域的数据整合进来,支撑OSS方面的数据整合,,数据共享和网络运营分析,同时,ODS-B和ODS-O的之间数据要充分共享,避免反复从源系统抽取数据和重新整合,保持数据使用的一致性。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 数据整合根据不同的数据源,匹配预先定义的规则流程,在任务引擎的调度下,按照定义好的流程经过数据抽取、数据转换、数据加载、数据校验几个关键环节最终存储到ODS系统中。数据整合主要具备特点如下: Ø 数据抽取 ODS从数据源系统获取数据,在实施时需要综合考虑业务需求、抽取效率、源系统代价等因素确定抽取策略,抽取策略包括抽取方式(增量、全量)、抽取时机、抽取周期等。能够满足多种不同系统平台和数据类型的数据抽取,包括各种关系型数据库系统、各种文件格式的源数据等,对于时效性要求较高的业务需求,可以通过对源系统的数据进行实时/准实时的数据同步,采取在源端建立物化视图,或者解析源系统的Redolog/Arachlog日志文件同步入库,这类接口主要应用在和CRM系统的资料同步接口,也包含OSS域的服开,激活,客调等系统,按天和按月的数据同步,尽量采用文件接口,通常应用在计费域的日详单、日账、日欠费、日余额、日缴费、日销账、月账、月欠费、月销账;10000号的投诉告障;EDW的分析汇总数据;营销的客户认领落地数据;代理商的管理数据等。 对于大数据时代的海量数据和非结构化的数据,ODS也需要和大数据平台进行数据对接,从大数据平台抽取用户行为,轻度汇总数据,ODS也把整合层的数据同步给大数据平台共享,包括客户资料数据等。同时,在数据传递过程中,增加数据的安全管控,并对接口的数据进行校验和检查,确保接口数据的完整性、及时性和正确性的要求,对于文件接口的进行常规的文件名、文件大小、记录数等校验;对于实时同步的接口,进行定期的数据比对和完善。 Ø 数转换 数据转换是ETL中最复杂的处理过程,主要完成了从源数据向目标数据转换的各种处理。在数据转换的过程中必须深刻的了解和认识源数据信息,识别异常数据情况,建立从源数据到目标数据的映射规则。在映射的过程中,有些信息是直接可以从源数据得到的,有些并不能从源数据直接得到,需要进行复杂的加工处理过程,包括格式和类型转换、数据翻译、数据匹配、数据聚合以及其他复杂计算等。多数情况下,数据源到ODS之间主要的转换是格式转换、数据翻译、数据匹配,常用的转换手段主要有:字段映射;映射的自 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 动匹配;字段的拆分;多字段的混合运算;跨异构数据库的关联;自定义函数;多数据类型支持;复杂条件过滤;时间类型的转换;对各种码表的支持;环境变量可以动态修改;记录间合并或计算;记录拆分;行、列变换;排序;统计;支持度量等常用的转换函数;抽取远程数据;增量抽取的处理方式;在转换过程中支持数据比较;数据清洗及标准化;按行、按列的分组聚合等;在转换过程中,对于不符合转换规则的异常数据,进行数据轨迹的保留,分类,分析,不定期的进行数据反补,对于无法反补的情况下,把异常数据抛出来,提交源系统进行异常数据修正,再通过正常通道,同步到ODS系统.同时,ODS通过增量的时间戳,把对应的数据同步到外围系统,确保整个环节的数据完整性、一致性和准确性。ODS的数据转换,也要考虑大数据平台过来的用户行为数据的整合和轻度汇总数据的多次汇总。 Ø 数据加载 数据加载是指将抽取转换后的数据加载到ODS中,包括数据行加载和数据块加载。在综合考虑效率和业务实现等因素基础上确定数据加载周期和数据追加策略。数据的追加策略根据数据的抽取策略以及业务规则确定,主要有三种类型:直接追加、全部覆盖、更新追加。 l 直接追加:是指每次加载时直接将数据追加到目的表,以流水数据为主。比如清单、帐务等数据; l 全部覆盖:对于抽取数据本身已包括了数据的当前和所有历史状况,对目标表采用全部覆盖方式。比如规格表、定义表、维度表等数据量较小的数据; l 更新追加:对于需要连续记录业务的状态变化,用当前的最新状态同历史状态数据进行对比的情况采用更新追加的方式。比如客户、用户等数据。 Ø 数据校验 数据校验贯彻在各个环节,包括接口层,整合层,应用层,汇总层,在每个环节, 都需要嵌入数据校验,确保在每个层面的数据都能闭环收敛,确保数据完整性、 一致性和准确性。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.1.2.2 数据存储 数据存储完成ODS系统中各种数据的存储。存储数据按照功能的划分,主要分成接口数据层、整合数据层和汇总数据层。数据首先由源系统被抽取到接口数据层,在该层进行转换处理之后进入整合数据层,整合层数据经过整合及计算操作存储到汇总层。由于几个数据层说承担的功能和作用不尽相同,所以对各个层的存储策略和设计也所有差异。接口层的模型设计以短周期存储为主,作为临时缓冲区,需要支撑数据的快速载入和清理,以主键为主,尽量减少索引等额外开销,如果需要在接口层存储源系统的同构全量数据的, 尽量通过分区等策略处理,对于订单等流水数据制定对应的存量策略,比如1年周期的数据,定期清理历史数据,确保空间的高效使用。整合数据层中的数据模型遵循中国电信企业数据模型,是ODS的核心数据层,也是对外提供共享的主要数据层,需要在模型设计上进行规范化设计,减少不必要的数据冗余,要充分考虑逐条整合和批量整合高效性,高并发查询的快速响应,能够满足在大数据量、大并发量的快速数据操作,支持数据行级锁、多CPU并发、多服务器并行的要求。能够满足准实时数据的快速增删改查的要求,同时在物理数据存储策略要确保数据的安全性,避免由于硬件的损坏造成数据的丢失而带来业务的中断。对历史和过期的数据要制定数据清理的策略,减少整合层表级数据量过大和冗余,提高单表的处理性能,同时减少和节约存储空间,提升性能。在策略上主要关注以下几点 n 模型部分 1. 接口数据层数据模型可以采用平面表,表结构可以根据需要做无索引、无主键、无外键设计; 2. 整合数据层数据模型应采用第三范式的模型设计,考虑到ODS的特点和需要,数据模型可进行适度地不规范化处理; 3. 汇总数据层模型设计可以采用宽表、星型模型,也可以进行适度地不规范化处理。 n 存储部分 1. 数据库采用表分区技术,提高数据的访问性能和可操作性; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 2. 使用集群技术/并行处理技术,提高数据操作的性能、稳定性和可扩展性; 3. 提供数据库的自动诊断和调优功能,提供各种优化建议:内存参数、表结构、索引、SQL语句等; 4. 数据库支持在线备份恢复机制,支持灾备解决方案,实现同城或异地数据保护。 5.1.2.3 数据共享 ODS系统对外提供数据共享,共享的信息尽可能从整合数据层获取,通过数据文件、数据库物理共享、接口表、视图、数据高级复制、Webservice等技术手段,以不同的频率要求,对外提供共享数据服务,系统包括EDW、营销、维系、代理商、百事通、10000号等系统。 数据共享主要需要关注以下几点: 1. 支持数据视图、FTP文件和Web服务等方式对外提供接口服务; 2. 支持高并发性访问,通过连接池、负载均衡、集群等技术提高访问的并发性; 3. 批量的数据导出作业,根据不用的业务需求,以错峰和优先级高低的,避开ODS系统处理的繁忙时段,充分利用系统资源;减少由于同一时间段的作业,引起系统的堵塞和性能下降; 4. FTP的文件传递,FTP文件单文件不超过2GB,超过2GB时分割成多个文件; 5. 对大量并发的准实时批量数据共享操作可以按资源占用和所需时间进行合理调度。 5.1.2.4 数据应用 ODS系统承载和整合了企业细粒度运营数据,支撑一线的生产和管理人员数据分析应用需求,主要提供了以下几种数据应用 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Ø 批量计算 l 批量计算主要包括客户积分计算,客户信用度计算,客户品牌标签计算等 Ø 报表统计 l 主要针对及时性要求较高的准实时报表,比如主数据发展量报表,主数据受理量报表等 Ø 客户统一视图 l 以统一的口径,把客户端基本信息,用户信息,受理信息,客户落地信息,客户接触信息等,通过客户资料查询功能模块整合,在功能展现上,打包成一个统一的展现视图,方便操作与共享。 5.1.2.5 数据稽核 通过建立稽核点,配置稽核任务,设定告警阀值,收集和分析稽核结果,检查和稽核接口层,整合层,汇总层的数据质量,对接口层的数据质量问题,反馈给源系统进行处理,对整合层和汇总的数据质量问题,系统内部及时的进行修正和处理,通过不断的数据质量闭环处理,从而提升企业数据质量。主要从几个层面对数据进行稽核 Ø 接口层 l 主要体现及时性、完整性、一致性。 l 确保ETL加载过程及时,准确,完整、保持与源系统数据一致的原则、做到加载及时,加载目标准确无误。加载对象与预定内容一致,加载内容无缺失。 Ø 整合层 l 主要体现准确性、及时性、一致性。 l 确保对数据加工过程质量的可控,验证处理环节操作的准确性和数据生成的及时性,验证关键指标的准确性和一致性 Ø 汇总层 l 主要体现逻辑性、完整性。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 l 确保数据汇总结果之间的逻辑平衡、包括各汇总层表量收平衡、发展量平衡、到达数平衡等,同时保证汇总层数据展示完整性,稽核项目缺失 5.1.3 模型设计 Ø 模型设计需要考虑高速批量加载及高并发查询的快速响应; Ø 模型能够支持不同粒度的查询与报表需求,综合考虑业务需要,具备适应性; Ø 通过数据模型的规范化设计,减少不必要的数据冗余; Ø 模型具有良好的扩展能力。 5.1.3.1 存储策略 数据类型 保持周期 存储内容 客户产品 档案资料 长久保存 包括客户资料、账户资料、用户资料、营销套餐业务受理订单资料、业务受理订单产品特性资料、业务受理订单资料、营销套餐业务受理细项订单资料、子产品订单历史表 档案资料 归档数据 定期清理 归档级别的数据库,可以认为是在近期不太可能被经常查询访问到的数据,往往指18个月以上的业务数据; 详单 1+1(月) 包括语音业务,数据业务,增值业务等 账单 6+1(月) 以月会单位进行数据整合处理,包括月账单,月欠费,月销账记录等等 汇总数据 12+1(月) 按照日期、地区、产品、销售品、渠道等维度对运营数据进行计算、汇总后生成的数据 参数定义 长久保存 配置数据和定义表 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.1.3.2 模型设计 接口数据层 接口数据层存储的是由ODS从源系统采集的数据,其主要特点如下: 1) 接口数据层存储ODS采集的外围接口数据,如CRM、计费、销账、10000号、百事通、服开、激活、客调、资源、GIS等系统; 2) 接口数据层的数据模型,如果是同构模式的,与外围系统基本保持一致,如果是源系统经过数据关联抽取出来作为临时加载使用,模型可以根据实际业务定义; 3) 接口数据层的数据与外系统保持实时/准实时同步/按天/按月数据同步,对于有实时要求的数据,应尽可能提高数据的实时性。按天,按月的数据,在模型设计过程中,要考虑时间戳,加载状态等关键信息。 4) 和大数据平台的对接,要考虑大数据平台的模型设计特点,保持高效同步。 整合数据层 整合数据层存储是经过数据清洗、转换、整合后的运营数据,是ODS的核心数据层,其主要特点如下: 1) 整合数据层是ODS存储数据的核心层; 2) 整合数据层的数据原则上是经过统一编码转换后的数据,可作为企业数据标准指导外围系统逐步统一数据格式; 3) 数据模型遵循集团EDM模型,按照3NF模式落实具有物理特征的EDM逻辑模型。 汇总数据层 汇总数据层是针对ODS支撑的跨系统生产报表等应用需要,根据主题的维度形成的企业统计、汇总数据,其存储的数据主要特点如下: 1) 根据主题报表加工需要,形成汇总数据; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 2) 结合应用的要求,按照日期、地区、产品、销售品、渠道等维度对运营数据进行计算、汇总后生成的数据; 3) 可基于原有汇总数据基础上,根据需要继续汇总,形成多级汇总数据 共享数据层 共享数据层是基于ODS中各层整合好的数据,对外提供数据共享,其主要特点如下: 1) 共享数据层统一对外系统提供共享服务; 2) 对各系统数据共享的信息尽可能从整合数据层获取。 优化处理 ODS系统是一个以数据处理为核心的系统,大量的数据时刻处于动态变化之中。尤其是当前处理准实时的资料数据,对数据量大,时效性要求高,如何使这些海量数据处于最优的存储状态,能够快速响应多种应用需求,并且尽可能少占用系统资源,是数据优化工作要重点解决的问题。 5.1.3.2.1.1 模型优化 在源系统数据发生改变之后,或者当前数据模型无法很好对各种应用进行支撑时,应该启用数据模型优化流程,对数据模型进行修正。 1. 数据分区或索引 通过索引或分区技术,避免对大数据量表的全表扫描。 5.1.3.2.1.2 处理优化 数据处理任务的优化,很大程度上依赖于对SQL语句的优化。SQL执行性能对ODS数据库的性能影响很大,必须形成一个长期的SQL监控和优化机制: l 监控数据库,捕获引起特定性能问题的应用对应的 SQL 语句,对其进行具有针对性的分析与重写,提高特定应用的响应 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 速度。 l 定期检查最消耗系统资源的应用进程,分析应用对应的SQL的执行逻辑,避免出现交叉重复、死循环等,减少不必要的性能浪费。 l 定期监控索引使用、数据库锁等事件,对数据库表与索引进行重组,获得更优的查询效率等。 l 定期监控数据库运行频繁的SQL语句,从而确定关键事务,并进行优化。 l 定期对数据表连接常用的字段和索引等关键数据进行统计分析。 另外,ODS系统的的数据整合任务种类较多,在不同时段,不同类型的数据处理其紧迫程度和所需要的系统资源也不相同,应该针对各类任务设置不同的调度方式和运行优先级,进行分级负载管理。 5.1.4 实施指南(含软硬件选型) n SMP架构(小型机) 目前ODS系统主要采用的是传统的商用环境,主要以采用IBM小型机、Oracle数据库与EMC存储设备的组合为主,构成了一个从软件到硬件的完整商用数据库系统,主要强调了单一系统的规模和处理能力,也就是纵向扩展(Scale-up)能力。支撑和解决目前大部门省份的ODS系统数据处理,以处理结构化数据为主,运行稳定性高,计算和查询效率中等,尤其对于有海量数据处理的情况下,需要高并发进行处理时,IO的瓶颈就比较明显,集中爆发式的任务,导致系统性能整体下降,对于硬件扩容,存在周期长,扩容的成本和代价高的问题,很难快速的响应和解决系统问题。 n Hadoop架构 电信业务在现有的基础上,数据也开始呈波浪式的往前推进,不断出现海量的结构化数据,同时,随着电信业务的不大扩展和延伸,在传统业务的处理和分析的基础上,也出现了需要分析非结构化的数据,以目前的架构,在性能上是比较难以满足的,那么就非常需要一个新的架构来进行补充,需要在海量的非结构数据中,快速的分析,抽取有 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 价值的信息,识别海量网页信息,不断跟踪网页信息,获取真实的结果数据,那么就需要有能处理海量互联网数据的架构和存储技术 ,那么X86分布式集群和hadoop架构,带来了高并发,高计算能力的解决方案,解决了扩容难,高并发,非结构的处理问题,为电信行业的“高效低成本”的运营模式开启了新的模式。该方式主要具备以下特点: Ø 扩展性:能可靠地存储和处理PB级关系型、非关系型数据。在不保证低延时的前提下,具有相当大的吞吐量,非常适合海量数据的运算。 Ø 成本低:可以通过普通机器组成的服务器群来分发以及处理数据。这些服务器群总计可达数千个节点。 Ø 高效率:通过分发数据,hadoop可以在数据所在的节点上并行地(parallel)处理它们,这使得处理非常的快速。 Ø 高可靠:可以自动地维护数据的多份复制,任务失败后能自动地重新部署计算任务 n 逐步演变的过程 X86分布式集群做为传统SMP架构的补充和延伸,不是替换和替代,主要为目前的海量和非结构化的处理提供强力有的保证,同时,对于“IOE”中的去“IE”,降低硬件的成本投入,提高并行处理能力,解决IO瓶颈还是大有帮助,可以解决事情情况,逐步引入和在部分业务中优先使用,比如大批量的详单处理和查询业务上,月作业的收入的海量数据关联,减缓月初的出帐压力,提升效率。 5.2 EDW(亚联) 5.2.1 平台定位 EDW从ODS、大数据平台和生产系统获取整合后数据进行面向应用的加工和存储,存储了长期的、明细和概要的分析型信息,采用数据统计、多维分析和数据挖掘等手段,细分市场和客户,提供专业的分析模型和挖掘算法,发现数据中的价值信息,为市场精细化营销、客户针对性关怀和维系提供支持;通过数据反映出来的趋势,为领导的经营决策提 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 供支持;通过数据服务展现层,进行数据共享;为数据集市提供数据支持;EDW的使用对象为市场分析人员、管理人员、决策领导等。 5.2.2 功能要求 EDW平台的数据来源主要以ODS、大数据平台为主,也可以直接从生产系统接入数据;EDW不产生、不修改源数据。创建的数据为分析的结果和用户行为等数据产生的标签,创建的结果数据直接进行结果展现或者反馈给ODS、大数据平台和各应用数据集市;EDW主要支持OLAP类型的数据操作。 EDW主要以固定报表、多维分析、数据挖掘、即席查询、数据探索等应用方式来对业务需求进行支撑。固定报表主要使用对象为市场分析人员、管理人员、决策领导,主要用以支撑经营分析、决策分析、营销政策制订等应用;多维分析主要的使用对象为市场分析人员、管理人员,主要应用场景为从不同角度分析企业生产经营状况,掌握发展趋势等;数据挖掘主要的使用对象为市场分析人员,用以支撑对未知数据的分析汇总,掌握数据间的关联关系,对企业收入、发展趋势的预测,找到营销的目标客户群等;即席查询主要的使用对象为市场分析人员、管理人员,主要用来支撑固定报表、多维分析等应用不能满足的业务需求;数据探索主要的使用对象为市场分析人员,主要用于对数据进行深层次研究,找出数据在时间、空间上的隐藏关系,为市场经营分析提供不同的分析视角,指导经营决策。 EDW从各业务系统、非业务系统中将相关业务数据进行融合,在EDW系统打造统一业务数据视图,之后根据数据的管理及应用分类,进行相关主题的数据应用的支撑,整体功能要求如下图所示: 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.2.2.1 数据获取层 数据获取层,顾名思义就是数据仓库系统进行数据获取的层面,各个业务系统的数据在这里进行汇集,初次清洗审核之后进才能进入统一视图层。 业务系统的数据汇集可以是物理上的,也可以是逻辑上的,逻辑上的可以是各个业务系统提供数据的映射集合,物理上可以是一个存放各个系统的提供的接口数据的区域。 由于数据从ODS、大数据平台或者其他系统获取的时候,还没有进行融合,所以在数据获取层中,各数据是依据其所在的数据源进行分类存放,这样做的好处是有利于数据校验及异常回退。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.2.2.2 数据存储层 数据存储层,是整个数据仓库系统的核心部分,各类业务数据都在这里进行汇集,通过ODS、大数据平台、其他系统进行数据采集;经过统一清洗,统一编码,分门别类之后存放在细节数据层;然后根据业务规则统一数据处理口径,为数据打上业务标签,进行数据的轻度汇总,将数据放在业务视图层;最后根据不同的业务需求生成应用数据,形成应用视图层。 5.2.2.3 数据展现层 数据仓库系统由于承担着各类数据应用支撑,使用系统的角色众多,而不同的角色,使用及观察数据的需求、角度及方式都会有所不同。这就要求数据仓库系统能够提供多种的数据展现方式来满足不同用户的需求。 数据展现层,除了提供KPI展现、多维分析、固定报表、即席查询等不同的展现方式之外,还要更多的考虑将这些展现的方式进行有机的结合,使得各种展现方式之间能够无缝衔接、平滑过渡。在数据展现层面,要结合用户的使用操作习惯及数据组织方式进行设计。让用户从繁琐的操作中解放出来,使用起来得心应手,专注于数据的分析及应用。 5.2.2.4 数据应用层 数据展现的目的是为了能有具体的应用,能解决相关的问题。若只有展现,而没有应用,数据的价值无法完全体现。应用需要循序渐进,开始可以是一些产品管理、营销管理、用户管理之类的应用,然后,可以对其进行总结和提取,如专家评论、咨询建议等,将这些信息形成知识库沉淀下来,通过智能问答等形式,形成营销政策、投资预算之类的,形成完整营销闭环流程的应用。以科学全面地支撑企业的经营分析决策。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.2.3 模型设计 5.2.3.1 存储策略 模型层面 数据 数据周期 存储周期 说明 接口数据层 用户资料、帐务资料等 日 永久 月 永久 详单数据 日 1天 月 1月 整合数据层 用户资料、帐务资料等 日、月 12+1月 一般指12个月内的业务数据;具体业务数据的在线周期可以根据该数据的重要度指数,月访问频率分析来决定; 详单数据 日、月 12+1月 汇总数据层 用户资料、帐务资料等 日、月 24+1月 一般具有相对较长的存在时间,一般指12个月至24个月的业务数据;通常针对汇总数据的在线周期可以更长; 详单数据 日、月 24+1月 应用数据层 用户资料、帐务资料等 日、月 永久存储 在线存储数据中的高频率访问数据或有快速响应要求的数据; 详单数据 日、月 永久存储 5.2.3.2 模型设计 EDW的数据模型体现的是技术架构数据存储层的模型,其中包括接口数据层、整合数据层、汇总数据层和应用数据层。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 接口数据层 接口数据层为数据临时存储区,数据来源于ods、大数据平台等其他外围系统。为了保证获取数据的一致性、准确性、可重复操作性,在做模型设计时,需要基本与数据源保持一致。接口层一般不作为汇总数据层和数据应用层的来源,除了一些实时性要求很高的应用,如用户发展、终端销售等。 1、数据来源:接口数据层主要存储来源于ODS的数据,其他还可以从大数据平台、其他外围接口采集数据 2、数据模型:与源系统保持一致 3、存储时效:用户资料、帐务数据永久储存,详单类数据通常采用每日清空重新加载 4、处理频度:用户资料、详单类数据采用每日采集,帐务数据每月采集 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 整合数据层 数据整合层的数据来源为接口数据层,是整个EDW数据模型的核心部分,所有的数据在获取之后,经过统一清洗,统一编码,分门别类存放在这个区域,之后再为不同的应用提供支撑。模型以CTG-EDM为标准,结合数据仓库模型设计方法论进行物理化处理。 1、数据来源:整合数据层的数据来源于EDW的接口层 2、数据模型:采用CTG-EDM数据模型 3、存储时效:用户资料、帐务数据储存12+1月,详单类数据存储12+1月 4、处理频度:用户资料、详单类数据采用每日处理,帐务数据每月处理 汇总数据层 汇总数据层主要数据的来源为整合数据层,接口数据层也可以有少量数据直进入汇总数据层,整合层模型一般采用第二范式或者第三范式的模型。汇总数据层与整合数据层最大的区别在于,整合数据层的数据经过ETL的过程后,模型体现的是原始业务的逻辑,而汇总层进行数据汇总以后,加入数据处理统计逻辑、各种统计规则、数据映射方法、数据挖掘分析方法等数据处理手段,是一个初步的数据处理存放的轻度汇总数据层。 汇总数据层可以采用多维度轻度汇总的星型模型,也可以采用第二范式的多指标模式建模。星型模型的优点是数据处理简单,逻辑清晰,易扩展,缺点是数据处理结果集比较大,记录数多,不利于查询和应用;第二范式模型的优点是记录数小,查询响应速度快,缺点是数据处理逻辑不易体现,模型不易扩展。 1、数据来源:汇总数据层的数据来源于EDW的整合数据层或者接口层; 2、数据模型:采用星型模型或者第二范式模型 3、存储时效:星型模型类数据储存24+1月,第二范式模型数据存储12+1月 4、处理频度:用户资料、详单类数据采用每日处理,帐务数据每月处理 数据应用层 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 数据应用层的数据主要来源于汇总数据层,有少量数据直接来源于整合数据层和接口数据层。数据应用层的模型需要面向具体的分析应用,支撑各类统计分析、多维分析、专题分析及快速的决策支撑,模型主要高度汇总的、主题分析型、专题分析型等模型; 数据应用层为长期保留的数据,建议不进行数据压缩,建立索引。 1、数据来源:整合数据层的数据来源于EDW的汇总数据层、整合数据层或者接口层; 2、数据模型:采用少维度高汇总模式星型模型 3、存储时效:永久存储 4、处理频度:日应用按天处理,月应用按月处理 5.2.3.3 优化处理 EDW系统是一个以数据为核心的数据仓库系统,大量的数据时刻处于动态变化之中。如何使这些海量数据处于最优的存储状态,能够快速响应多种应用需求,并且尽可能少占用系统资源,是数据优化工作要重点解决的问题。 数据优化分为数据模型优化、数据处理优化、数据压缩优化三部分。 模型优化 在源系统数据发生改变之后,或者当前数据模型无法很好对各种应用进行支撑时,应该启用数据模型优化流程,对数据模型进行修正。数据模型优化重点解决以下四类操作问题: 1. 多表连接 对一些经常需要关联的表进行预连接(Pre-Join),当数据规模较小时,也可以适当采用星型(Star-Schema)建模方式。 2. 表的累计 在数据模型中增加有关轻度汇总数据(Summarized Data)的项。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 3. 数据排序 模型设计时,对数据进行预先排序。 4. 数据分区或索引 通过索引或分区技术,避免对大数据量表的全表扫描。 处理优化 数据仓库中数据处理任务分为数据加载和数据生成。 数据加载任务包括: Ø 业务数据抽取 Ø 基础数据加载与转换 数据生成任务包括: 1. 业务分析数据处理 2. 分析结果展现 3. 数据结果导出 4. 临时分析查询 5. KPI展现 6. 多维分析展现 7. 数据挖掘等专题展现 以上数据处理任务的优化,很大程度上依赖于对SQL语句的优化。SQL执行性能对数据仓库的性能影响很大,必须形成一个长期的SQL监控和优化机制: 1. 监控数据仓库,捕获引起特定性能问题的应用对应的 SQL 语句,对其进行具有针对性的分析与重写,提高特定应用的响应速度。 2. 定期检查最消耗系统资源的应用进程,分析应用对应的SQL的执行逻辑,避免出现交叉重复、死循环等,减少不必要的性能浪费。 3. 定期监控索引使用、数据库锁等事件,对数据仓库表与索引进行重组,获得更优的查询效率等。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 4. 定期监控数据库运行频繁的SQL语句,从而确定关键事务,并进行优化。 5. 定期对数据表连接常用的字段和索引等关键数据进行统计分析。 另外,数据仓库的应用种类较多,在不同时段,不同类型的数据处理其紧迫程度和所需要的系统资源也不相同,应该针对各类任务设置不同的调度方式和运行优先级,进行分级负载管理。 压缩优化 运用数据压缩技术,数据库可以对重复性比较高的数据进行压缩,以减少存储空间,降低查询I/O,提高查询的响应速度。 通常,数据压缩可以在不影响数据读取性能的前提下,节省10%-70%的空间。 5.2.4 实施指南(含软硬件选型) 5.2.4.1 相关技术指标 大项 小项 固定报表功能 查看目标报表的点击次数<4次 查询结果的返回时间,从点击查询开始到数据展现,要求<6秒 报表保存时间,从点击下载报表开始到选择保存文件内容,要求<6秒 多维分析功能 查询结果的返回时间,从点击查询开始到数据展现,要求<6秒 点击下转、拖拽、旋转、切片的响应时间,从点击开始到数据展现,要求<3秒 自动汇总数据响应时间,从点击开始到数据汇总完毕,要求<3秒 图形展现时间,从点击开始到图形展现完毕,要求<3秒 报表保存时间,从点击下载报表开始到选择保存文件内容,要求<6秒 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.2.4.2 架构选型 EDW平台主要承载企业数据仓库的建议与实施,需要支撑复杂的、高级的数据分析应用,包括综合分析、数据挖掘和专题分析等。基于这个目标,EDW的主要数据的特征就需要为海量、非实时、结构化、静态的。 建议采用基于MPP高可扩展并行数据库架构,或者传统的小机加高端存储的架构,这两种架构都可以实现EDW的生产运营。 5.2.4.2.1 MPP架构 MPP提供了另外一种进行系统扩展的方式,它由多个SMP服务器通过一定的节点互联网络进行连接,协同工作,完成相同的任务,从用户的角度来看是一个服务器系统。其基本特征是由多个SMP服务器(每个SMP服务器称节点)通过节点互联网络连接而成,每个节点只访问自己的本地资源(内存、存储等),是一种完全无共享(Share Nothing)结构,因而扩展能力最好,理论上其扩展无限制,目前的技术可实现512个节点互联,数千个CPU。 目前业界对节点互联网络暂无标准,如NCR的Bynet,IBM的SPSwitch,ORACLE的Exadata,它们都采用了不同的内部实现机制。但节点互联网仅供MPP服务器内部使用,对用户而言是透明的。 5.2.4.2.2 小型机+高端存储架构 传统的数据仓库架构,由小型机+高端存储构成。主要特点是数据集中、处理高效、数据库操作简单,结构化海量数据处理便捷。其短处主要是投资高,可扩展性差。 目前各大硬件厂商象HP、IBM、DELL都有各自的小型机+高端存储的数据仓库解决方案。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.3 大数据平台(迪科) 5.3.1 平台定位 移动互联网时代给电信运营商带来前所未有的机遇,这个时代的到来同样也给电信运营商带来了无限的挑战,特别是业务数据复杂化的挑战。这个挑战主要表现在以下两个方面:其一、传统数据仓库难以满足日益增长的业务数据所带来的存储、计算需求。随着业务发展数据量的增加,应用复杂导致的数据量增加,这些数据量导致了数据存储和处理压力; 数据仓库无法线性扩容,管理难度加大,成本高扩容压力大,效率下降等。其二、传统数据仓库难以满足非结构化数据的处理要求。移动互联网和物联网业务带来的非结构化数据、半结构化数据(如网页、微博、投诉/咨询建议)对分析系统提出了不同以往的处理要求,如自然语言处理、网页分类等。以上两个方面的数据已经开始对运营商的数据业务形成了部分障碍,随着大数据的应用将能相关问题将能获得有效解决。 大数据平台是在此背景下对传统EDA架构的扩充,负责处理海量结构化数据、非结构化及半结构化化数据的处理分析,通过hadoop技术对海量数据进行轻度汇总,对非结构化及半结构化数据进行标准化、标签化,共享到ODS,同时开放清单库查询、自助取数功能。 5.3.2 功能要求 5.3.2.1 标签分类 标签分类是对移动互联网、宽带互联网及信令位置数据进行分类标签化。通过用户的行为数据与基础信息库的匹配,为客户行为打上分类标签。基础信息库包括url分类库、app分类库、搜索关键词库、位置信息库。 标签分类的处理流程如下图所示: 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 数据处理逻流程 数据装载:包含移动互联网数据(DPI数据、wap网关日志)、宽带互联网数据(城域网网关日志、家庭网关日志)、位置数据(信令数据)、业务平台数据(网厅轨迹)等海量结构化/非结构化用户行为接口数据实时/准实时装载到hadoop平台分布式文件系统; 数据标准化:对原始的非结构化、半结构化、海量结构化数据进行标准化处理,过滤无效数据。 标签化:用户的行为数据与基础信息库进行匹配,如url访问,拿用户的访问的url地址与url分类库进行匹配,匹配成功打上分类标签,未匹配成功的无规则URL数据通过网络爬虫爬取网页内容,并对网页内容进行分词,然后与词库进行匹配,并根据关键词出现的频率通过算法对URL进行分类。 数据汇总:对标准化、标签化后的清单数据进行轻度汇总。主要的汇总维度有用户、标签类别、APP类别,对应的指标主要有访问次数、访问流量等。 数据存储:存储标签化及轻度汇总后的数据,构建清单库。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 数据共享:清单级数据向应用层共享,主要应用于清单库查询,自助取数,轻度汇总数据向ODS共享。 基础信息库:包含url分类库、app分类库、搜索关键词库、位置信息库。 Ø url分类库:由分类标签、url地址构成; Ø app分类库:由分类标签、app名称、通信url地址、下载url地址构成; Ø 搜索关键词库:由分类标签、关键词构成; Ø 位置信息库:由商区类别、位置名称、扇区ID构成; 5.3.2.2 文本分析 文本分析是对文本的表示及其特征项的选取;文本分析是文本挖掘、信息检索的一个基本问题,它把从文本中抽取出的特征词进行量化来表示文本信息。将它们从一个非结构的原始文本转化为结构化的计算机可以识别处理的信息,即对文本进行科学的抽象,建立它的数学模型,用以描述和代替文本。使计算机能够通过对这种模型的计算和操作来实现对文本的识别。 文本分析主要分析对象包含投诉/咨询建议、互联网网页内容、微博内容等,从中发掘客户关注内容。 5.3.2.3 清单查询 在移动互联网时代,除传统的语音清单、短信清单、账单查询之外,内容类详单带来数据量数量级的增长。在此环境下,大并发量、海量的数据查询服务带来了新的挑战,传统的数据库平台已经不能满足要求,因此需要引入大数据平台对海量数据的快速处理、查询能力。 基于大数据平台提供清单查询服务主要要求如下: Ø 支撑互联网场景下的高并发用户清单查询、账单查询; Ø 同时具备承载未来CCG内容类话单的查询能力; Ø 同一服务多节点部署,提供高吞吐量查询,更好的支撑持续增长的业务量; Ø 基于Hadoop+HBASE技术,低廉PC集群,分布式可伸缩架构,减低成本; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Ø 单节点故障服务不中断,提升客户感知。 5.3.2.4 实时分析 对用户的行为数据进行实时分析,实时对外共享,从中找出与事先定义的行为动作相匹配的目标用户,支撑实时营销服务活动。 实时分析的对象主要包扩url访问行为数据、app访问行为数据、关键词搜索行为数据、信令位置数据。 支撑实时营销主要有终端销售、流量提升、商圈位置营销等。 5.3.2.5 数据可视化 在海量的数据存储及快速查询能力的基础上,提供可视化的功能界面,帮助使用人员更直观地获取信息。 可视化的主要功能包括: Ø 用户全息视图:可以通过用户服务号码,查找用户,并展示用户的人口特征、套餐特征、上网特征、终端特征、用户偏好、访问互联网的详单、适用业务推荐; 用户全息视图 Ø 用户群查找:通过用户共同访问过的URL、APP、搜索内容、用户特征进行用户群的提取, 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 并对用户组成进行分析,为营销活动策划提供决策支持; 用户群查找 Ø 站点/APP推广评估:通过定义要评估的APP、站点路径,周期性评估所推广内容的用户响应程度、整体推广效果; 站点/APP推广评估 5.3.2.6 数据挖掘 随着大数据时代的来临,用户的互联网访问行为、信令位置信息大量的丰富了客户理解的数据来源,同时海量数据的计算也给传统的数据库平台带来了压力。 大数据平台基于hadoop技术及MPP架构混搭架构,清晰的分工界面,为大数据时代的数据挖掘提供良好的平台支撑。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Hadoop平台负责对用户原始的行为清单数据进行清晰、转换、加工,形成标准化、标签化的行为清单数据。 MPP架构的关系型数据库平台在行为清单数据的基础上建立数据挖掘模型,负责海量数据的计算。 例如交往圈分析模型就是需要通过海量的数据计算进行建模。 5.3.3 分层数据架构 大数据平台数据架构可以分为接口数据层,处理数据层、共享数据层,如下图所示: 大数据平台数据架构 5.3.3.1 数据接口层 接口数据层存储的是由大数据平台从源系统采集的数据,其主要特点如下: 1) 接口数据层存储大数据平台采集的外围接口数据,包含移动互联网数据(DPI数据、wap网关日志)、宽带互联网数据(城域网网关日志、家庭网关日志)、位置数据(信令数据)、业务平台数据(网厅轨迹)、流数据; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 2) 接口数据层的数据模型与外围系统基本保持一致; 接口数据层的数据与外系统保持实时/准实时同步,对于有实时要求的数据,应尽可能提高数据的实时性。 3) 存储周期:日数据保存1天,月数据保存1个月; 5.3.3.2 数据处理层 数据处理层数据分为整合数据和汇总数据以及流数据。 整合数据是经过数据清洗、转换、整合后的数据,是大数据平台的基础数据,其主要特点如下: 1) 整合数据是大数据平台存储最细粒度的数据及关键数据; 2) 整合数据清洗、转换、整合后可识别的结构化清单数据; 3) 关键数据包含url分类地址库、app分类库、搜索关键词库、位置信息库及全量的资料类数据; 4) 存储周期:清单数据存储90天以上,关键数据永久保存; 汇总数据是根据特定的维度形成的轻度汇总数据,数据主要特点如下: 1) 根据分析报表和实时营销等应用需要,形成轻度汇总数据; 2) 结合应用的要求,按照时间、应用、兴趣标签等维度对数据进行计算、汇总后生成的数据; 3) 存储周期:24+1个月 流数据面向实时应用,数据实时到达,实时处理,实时对外共享;流数据处理的结果实时对外共享后,大数据平台自身对结果数据一般不做存储要求。 整合数据和汇总数据都可直接支撑应用,如清单库查询、实时营销支撑等; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.3.3.3 数据共享层 共享数据层是基于大数据平台已处理整合好的数据,对外提供数据共享,其主要特点如下: 1) 共享数据层统一对外系统提供共享服务; 2) 共享数据层包括轻度汇总数据和标准化、标签化清单数据、流数据; 5.3.4 实施指南 5.3.4.1 软硬件建议 Ø 平台搭建建议采用PC服务器构建分布式hadoop集群; Ø 网络环境要求:主节点及各从节点要求部署在同一交换机下,千兆以上带宽,保证数据交互流畅; Ø Hadoop平台:分布式系统基础架构,用户可以在不了解分布式底层细节的情况下,开发分布式程序。充分利用集群的威力高速运算和存储。 Ø HDFS: 分布式文件系统,具有有着高容错性(fault-tolerant)的特点,并且设计用来部署在低廉的硬件上。而且它提供高吞吐量来访问应用程序的数据,适合那些有着超大数据集的应用程序。HDFS放宽了(relax)POSIX的要求(requirements)这样可以实现流的形式访问(streaming access)文件系统中的数据。 用于大型的、分布式的、对海量数据进行访问的应用。 Ø Hbase: 是一个分布式的、面向列的开源数据库,该技术来源于Chang et al所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样,HBase在Hadoop之上提供了类似于Bigtable 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 的能力。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。 主要用于海量清单查询。 Ø HIVE:建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具,可以用来进行数据提取转化加载(ETL),这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言,称为 HQL,它允许熟悉 SQL 的用户查询数据。同时,这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。 负责海量数据的关联、排序、汇总。 Ø MapReduce:MapReduce是一种编程模型,用于大规模数据集(大于1TB)的并行运算。概念"Map(映射)"和"Reduce(化简)",和他们的主要思想,都是从函数式编程语言里借来的,还有从矢量编程语言里借来的特性。他极大地方便了编程人员在不会分布式并行编程的情况下,将自己的程序运行在分布式系统上。 当前的软件实现是指定一个Map(映射)函数,用来把一组键值对映射成一组新的键值对,指定并发的Reduce(化简)函数,用来保证所有映射的键值对中的每一个共享相同的键组。 负责数据的清洗、字段规整及标签化。 5.4 数据集市(迪科) 5.4.1 数据集市综述 数据集市也可叫做“小数据仓库”,属于数据仓库的子集。它主要面向部门级或某个特定的主题而建立。在实现方式上,数据集市原则上采用逻辑集市的模式。考虑到系统性能和应用效果,可以允许物理部署的模式,但是数据必须由EDA统一发布,不允许直接 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 和生产系统对接。数据集市的建立可以确保应用数据的一致性、优化系统的处理能力、提升数据运营能力,实现快速支撑业务需求的目的。 5.4.1.1 技术要求 数据集市中数据的结构通常被描述为星型结构或雪花结构而不遵循3NF结构。一个星型结构包含两个基本部分:一个事实表和各种维表,加工过程需要遵循如下要求: ² 支持异常控制:事务加工需要支持异常控制处理。转换清洗出错时,事务需要回滚。首先异常控制可以提供给ETL平台报错信号,终止ETL流程的执行;其次在数据稽核环节时可快速定位记录数为0的异常集市。 ² 异常数据处理: 主要包括两块,首先集市中的维度编码必须存在于对应的主数据范围内,维度编码定义时也要考虑未知情况;其次指标字段出现空值时,需要参考业务口径填充默认值,避免分析应用和多维分析工具加载异常。 ² 一致性原则:包括数据集市的维度编码一致性和指标统计口径的一致性; 1)相同维度在不同集市中编码和字段类型的一致性,2)相同的业务指标在不同的集市中统计结果的一致性。 ² 可扩展性:数据集市是数据仓库中应用层取数的重要来源,它的灵活性直接影响经营分析系统的支撑效率,所以数据集市建模时可以参考数据量适当扩展维度和指标。 5.4.1.2 功能要求 Ø 报表定制:构建营销分析多维报表模型,通过多维报表定制功能,用户可通过图形操作界面,按照实际的需要,灵活地定制和生成个性化的多维报表; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Ø OLAP分析:在多维报表模型的基础上,支持从多维角度对数据进行钻取,以便灵活对数据进行分析; Ø 即席查询:提供多种访问方式支持灵活的取数以及二次开发的功能。提供客户信息查询、客户筛选、锁定客户数据提取等一系列灵活的客户数据提取操作;提供查询统计功能,支筛选维度和指标阀值设置,根据不同的业务要求使用户能够灵活地提取到所关注的数据;允许用户直接访问数据库并创建临时表和上传数据,支持进行二次开发,满足用户个性化的营销分析需求。 Ø 取数工具:在元数据和主数据的支撑下,为固定报表提供稳定、快速支撑方案,灵活组合指标,快速形成分析体系,确保数据一致性和数据质量的最好解决方案。 5.4.1.3 集市分类 数据集市以提升应用取数的访问效率和统计灵活性为主要目的,根据集市的服务对象不同可分为四类:应用集市、专业集市、地域集市、基于大数据的创新集市: 序号 集市分类 服务对象 1 应用集市 业务系统、专题应用 2 专业集市 部门分析人员、高级业务分析人员 3 地域集市 分公司分析人员、一线生产人员、客户经理等 4 基于大数据的创新集市 数据挖掘、营销策划等人员 5.4.1.4 数据范围 数据集市的取数主要来源于ODS/EDW的接口层、整合层和汇总层: 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 ² 参与人信息、客户信息、合作伙伴信息、竞争对手信息、员工信息等参与人域数据; ² 产品信息、销售品信息,以及客户订购产品后形成的产品实例信息和销售品实例等产品域数据; ² 账户信息、账目、账单信息、支付关系、余额账本、欠费处理信息、定价信息等账务域数据; ² 市场计划、营销活动、销售活动、销售机会、渠道、责任对象等营销域数据。 ² 计费数据源产生的使用记录、客户订单、服务订单等事件域数据; ² 行政区域的角度和电信管理要求的角度描述了地域信息的地域域数据; 大数据创新集市的数据来源以非结构化数据为主,包括宽带互联网数据、移动互联网数据、信令位置数据等。 5.4.1.5 数据频率 数据频率主要包含:实时/准实时、日、月、年; 数据频率 接口枚举 集市名称 说明 实时、准实时 产品、龙终端数据等 大数据集市、应用集市 主要针对数据量小的业务发展量的数据提取 日 产品实例、详单、订单等 大数据集市、应用集市、专业集市、地域集市 主要包括日全量和日增量数据 月 账单、产品等 大数据集市、应用集市、专业集市、地域集市 由接口的业务属性决定,部分月接口由日增量累计而成 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.4.2 应用集市 应用集市是面向专题应用和业务系统的集中支撑,可以缩短系统建设周期,减少对清单数据的依赖从而提高取数效率。应用集市以特定业务需求为驱动,具有独立性强、耦合性低、访问效率高的特点。包括客户发展质量集市、营销挽留集市、收入稽核集市等。 Ø 应用案例:收入稽核数据集市 收入数据稽核通过对收入流程的梳理,在流程中的关键环节设置稽核点,并开展稽核点的数据比对和分析,从而发现收入流失,在此基础上开展流失分析与评估,同时进行流失监控,并采取措施挽回收入流失,适用于收入真实性的全程稽核检查。收入稽核数据集市以支撑收入保障为目的,围绕收入稽核点,抽取某个时间点所有涉及收入稽核范围的相关系统的数据,并开展一致性比对和分析,从而发现收入流失问题。 收入稽核集市数据包括来自于CRM、计费系统、资源管理系统、交换网管系统、增值业务平台以及其他网关/网元设备等的ODS整合数据。数据内容包括客户和产品的状态、订单、使用记录、计费出账处理的规则和流程、配置参数信息等。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.4.3 专业集市 专业集市是面向各个业务部门,围绕各部门的业务问题的集中支撑。专业集市把数据仓库与部门相关性强的数据整合在一起,建立拥有部门特性维度和指标的数据集市,如政企部聚类客户集市、客服部的客户服务集市、公众的校园市场集市等。 Ø 应用案例:客户服务集市 为全面提升电信服务质量,了解电信服务的薄弱环节,提升客户满意度,集团下发客户服务分析规范,要求实现相关客服数据的自动采集、汇总、分析功能,为各级公司提供服务过程管控、指标监测、数据分析等基础管理能力。通过整合CRM、计费、10000 号等BSS 系统域数据和电子运维、施工调度等OSS 系统域数据,建立客户服务集市,满足客户服务系统的高效取数要求。 5.4.4 地域集市 由于本地网层面在数据粒度和数据应用需求方面和与省公司需求存在一定差异,现有EDW和ODS难以快速高效的支撑本地网个性化需求。规划建设本地网数据集市的主要目的,在于进一步加强对本地网精确化管理的支撑,满足本地网个性化营销分析的需求,提升本地网的市场快速响应能力。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 地域集市原则上采用省公司EDA逻辑集市的部署方式建设,针对技术支撑能力较强的大中型本地网可利用省公司EDA下发的数据单独建设本地网数据集市。 Ø 应用案例 :本地网营销活动评估 本地网层面考核客户经理和营销人员时,因为补贴模式和时间点上的差异,导致考核指标、报表频率、表样都不一样,所以此类需求都落地在本地分析中心的本地网节点上,依赖EDW下发的各层数据,根据个性化的需求建立维度和指标不同的地域集市,支撑各本地网营销活动评估的需求分析。 5.4.5 基于大数据的创新集市 大数据时代的到来,给运营商带来了新的挑战和商机,互联网数据为经营分析提供更多的维度和指标,由此引入大数据平台来处理海量、非结构化数据。大数据的创新集市是以大数据平台生成的轻度汇总数据为基础建立的数据集市,如互联网增值业务集市。为提升分析广度,大数据的创新集市也可以抽取ODS/EDW数据作关联分析。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Ø 应用案例 :互联网增值业务集市 移动互联网时代,客户消费形态发生巨大变化,移动互联网流量发生爆炸式增长,3G用户快速增长,客户关注智能终端。需要整合移动互联网行为数据,提供移动互联网下的客户行为分析等应用;需要整合终端信息数据,提供移动互联网业务环境下,客户与终端关联分析、终端与套餐关联分析等应用;为推进基地自有业务规模突破,需要整合基地业务数据,提供基地业务活跃度、使用量、业务发展常规分析应用,实现跨基地业务的交叉销售、客户响应等针对性营销支撑应用。大数据平台整合基地数据、总部增值业务数据、移动/过网等详单数据、移动互联网行为数据、基础宽表数据,建设移动互联网增值业务数据集市。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 5.5 ETL平台(迪科) ETL负责将分散、异构的数据源抽取到EDA系统后进行清洗、转换、加载,最后加载到数据仓库中成为联机分析处理、数据挖掘的基础。由于EDA域数据重要性的日益凸显,数据处理复杂程度越来越高,为了提升ETL处理的专业化,需建设独立的ETL平台负责数据的处理过程。 随着大数据的崛起,出现了分布式ETL平台。它是基于传统ETL平台上的分布式部署,保证海量数据的抽取、转换、加载的及时性和稳定性。相对于传统ETL平台处理计费、CRM等结构化数据来说,分布式ETL主要用来处理互联网、DPI等海量、非结构化数据。 ETL平台的基础功能抽取、转换、加载,具体如下技术特点: Ø 抽取 ² 数据来源:文件接口、数据库数据等。 ² 抽取方式:根据具体的业务方式采取增量和全量的数据抽取。 ² 抽取效率:针对数据量大的数据接口,根据时间频率拆分合并处理或多进程并行处理。 ² 抽取策略:根据具体业务定制抽取的时间、频率以及抽取的流程。 Ø 数据清洗 ² 数据补缺:针对空数据、缺失数据进行数据补缺操作,无法处理的作空操作。 ² 格式规范化:将抽取的源数据数据格式转换成为适合数据仓库处理的目标数据格式。 ² 主外键约束:通过建立主外键约束,对非法数据进行替换或导出到错误文件,提供生产库作为数据处理依据。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 ² 转换规则:包括数据合并、数据拆分、行列转换、排序剃重、数据验证等,常用实现方式为ETL数据转换引擎、SQLPlus、内存数据库等。 Ø 加载 加载包括两中方式,增量加载方式、全量加载方式: ² 增量加载方式:1)在业务表中统一添加字段作为时戳,当OLTP系统更新修改业务数据时,以增加的时戳为依据,直接INSERT方式加载接口,适用于日增量、月全量的数据接口,如语音详单、上网详单等;2)在数据仓库中添加日志表或使用数据库的归档日志获取增量数据进行数据加载。通过DELETE、UPDATE、INSERT操作加载接口,适用于增量接口数据,如增量产品实例接口、增量套餐实例接口等; ² 全量加载方式:清空接口表数据,插入最新的接口数据。适用于全量数据接口,如账单、全量产品实例、账目类型维表等; 5.5.1 传统ETL平台 ETL平台具有灵活的抽取、清洗、加载、数据审核、ETL配置和监控的功能,具有灵活的集成和开放性。平台可以选择成熟、稳定、扩展性强的工具或者自主开发,根据中国电信数据的具体情况,支持自定义的数据处理需求。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Ø 适用场景:CRM和计费数据抽取 EDA的主要数据来源于CRM和计费系统,为了不影响生产库的性能,EDA通过ETL平台定时将生产库的数据抽取至ODS的接口层,再利用ETL平台调度功能对接口数据进行清洗、加载得到目标数据结构,支撑分析应用系统。 5.5.2 分布式ETL处理 (一) 业务背景 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Ø 传统方式下采用小型机来承载ETL的处理所面临的问题; ² 投入规模大,服务器、存储占目前扩容投资的最大比例,核心硬件投资比重居高不下,导致应用建设方面的投入受到挤压; ² 目前大致有两种ETL模式,一类利用数据库自身处理能力,一类是通过程序或三方工具在数据库外部来实现复杂的ETL转换过程,但最终压力都集中在单台主机上,极易出现性能瓶颈; ² 容易出现单点故障,一旦问题出现影响面积大。 Ø 业务发展对现有架构提出了新的挑战; ² 随着网络信令、互联网信息等新数据源的引入,实时BI能力的支撑需求对数据的处理计算能力的时效性提出了新的要求,而现有架构的动态扩展能力受限、设备已接近可利用上限; ² 互联网类非结构化数据源的引入,对于ETL处理机制有新的要求。 (二) 实施部署 Ø 将传统ETL调度管理组件拆分为主/从两个部分:Master/Slave; ² Master主机将ETL数据源分发到不同的slave上,控制众多slave同时运行ETL作业; ² 在Slave上部署配置ETL工具, Slave可由廉价的PC服务器承担; Ø 传统的ETL任务被拆分成多个子任务,并在多个服务器上协调完成处理; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Ø 分布式ETL在计算方面的优势,提高了以文件形式存放的数据源的处理效率,如互联网类数据; Ø 通过分布式ETL避免在数据仓库中进行清洗转换工作,因此可以有效降低数据仓库的性能压力。 (三) 适用场景:海量数据接口分布式加载 对于ETL系统来说,当处理对象是海量数据集的时候,数据导入效率是衡量ETL系统性能优劣的重要指标之一。分布式ETL使用如下技术处理海量数据导入: ² 多线程:在制定数据集市的相关接口数据时,出于避免各个节点主题数据的交叉冗余的考虑,需要利用多线程响应多个节点仓库。基于彼此分离的缓冲区机制,线程之间避免了互相等待;各节点仓库上主题之间的独立性也使线程无须考虑数据导入逻辑先后问题; ² 数据导入缓冲区:数据导入数据库的方法是通过数据库提供的API接口,与数据库建立应用连接,运用数据库自身的游标将记录逐条导入数据仓库相应的表中。记录数据时频繁的读取磁盘会占用大量的系统运行时间,严重影响数据抽取的效率。为了减少磁盘I/O读写次数,在内存中为程序开辟一段区域用来放置临时记录块,然后采用批处理方法将记录集一次性写入到数据仓库中。这样可以在数量级的程度上减少读写磁盘次数,提高系统效率。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 索引删除方法:为一些重要的表建立索引是必不可少的内容,然而当一条数据插入到数据表中时,数据库需要判别新数据与老数据在索引方面是否有冲突,同时要更新表中的所有索引,重复更新索引会消耗一定的时间。因此,在导入数据之前删除所有索引,在数据逐条插入到表中后再统一创建表的索引。 6 EDA数据服务架构(福富 信合) 数据服务层主要负责将数据处理存储平台生成的数据进行封装后,提供统一数据共享接口,数据应用通过共享接口获取数据或通过报表工具实现数据的直接展现。该层主要负责接收用户请求,响应用户操作,并以数据展现或数据服务接入两种方式向用户返回结果,承载着数据处理存储平台与数据应用之间的转换处理过程,从而实现数据与应用关系的解藕,达到以灵活、快速地响应业务变化对系统的需求。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 6.1 接入访问 数据接入主要负责对数据处理与存储平台生成的数据接入访问处理,实现对各种异构平台的接入与互联,必须具备强大的连接各种不同接入协议的能力,满足数据应用对数据接入访问的要求。 6.1.1 接入方式 数据接入方式主要有服务总线及数据总线两种方式。 n 服务总线 用于实现服务请求者和服务调用者之间交互,提供了服务管理的方法和在分布式异构环境中进行服务交互的功能,它支持异构环境中的服务、消息,以及基于事件的交互,并且具有适当的服务级别和可管理性。如网厅通过调用客户积分查询服务获取客户积分信息。 n 数据总线 支持数据库接入模式,支持批量数据处理及传输功能。如客户授信额度、有效在网时长等计算应用结果批量推送给外围系统,一线分析人员批量导出号码级的报表清单等。 6.1.2 功能要求 1) 支持但不限于WS、JMS、CORBA、Socket、FTP等各种异构应用接口协议的接入; 2) 支持负载均衡能力,满足数据应用的高并发量接入需求; 3) 支持面向服务的中介功能,提供位置透明性的服务路由和定位服务,多种消息传递型式,请求/响应,单路请求,发布/订阅等; 4) 支持但不限于JDBC、ODBC等多种数据库接入模式; 5) 支持批量数据传输功能; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 6) 支持数据分布的差异性和分散性,例如实现跨表、跨库、跨地域的数据操作和访问。 6.2 封装处理 封装处理主要负责对通过数据接入层返回的数据进行封装处理,并把封装后的数据转换成有价值的业务与服务信息,向其上的服务层提供一致的与物理数据存放无关的信息服务,简化IT系统与业务对话的接口,提升了IT系统适应业务变化的能力,通过服务封装处理为上层应用模块提供规范、高效的数据服务,实现业务数据的充分共享。 6.2.1 封装分类 从封装的应用分类上区分出业务封装、数据封装、规则封装、公共封装和服务封装。 n 业务封装 提供业务服务的载体,负责实现具体的业务逻辑。 n 数据封装 提供数据访问、数据计算和数据缓存等功能。 n 规则封装 实现规则的技术功能,如规则定义,规则执行,规则修改、规则版本管理等。 n 公共封装 为EDA系统提供统一的配置管理、监控管理、安全管理、日志管理和异常处理等公共服务组件。 n 服务封装 包括原子服务和由原子服务组成的组合服务,以面向服务的方式对一个或者多个业务的功能进行封装,它具有明确的接口描述,可以被其它业务服务调用,也可以被上层服务流程或展现层调用。具有高内聚、可重用的特征,可通过标准的、明确的服务接口描述将具体的一个或多个组件中的功能按一定的规则和标准进行封装,可以被发现、绑定和调用。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 6.2.2 功能要求 1) 屏蔽数据模型和数据格式方面的差别,例如当数据定义的语义和语法不同时,可以在必要时进行语法转换和语义解析。 2) 可对业务对象(Business Object)的封装,以及业务对象到底层数据库结构之间的转换,实现对原始数据的存取访问,从而帮助业务组件层实现对业务对象的处理,使得业务组件层对数据的访问不受数据库物理设计、物理分布的影响。 3) 支持Cache机制以提高系统处理能力; 6.3 数据服务 数据服务提供是指经过封装处理后的,以数据服务调用的方式提供给周边系统或内部应用。主要包括数据共享、服务调用和API接入服务技术实现手段。 6.3.1 服务提供方式 n 数据共享 通过文件、数据视图、接口表、数据高级复制等形式直接向外围系统提供准实时的共 享服务,如通过标准文件接口为代理商、本地网数据应用子系统提供整合后的明细与汇总数据;通过接口表的方式向CRM 提供积分、信用度计算结果,向10000 号、CRM 等系统推送批量的营销数据等。 n 服务调用 EDA 通过WebService 等方式访问封装处理层提供的服务,外围系统通过调用EDA 的服务获取准实时的数据信息,如网厅通过调用ODS 的服务获取客户积分等相关数据信息,CRM、10000、网格等通过调用ODS 服务获取实时的客户接触结果等信息。 n API接入服务 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 提供强大的二次开发能力,包括提供各种门户组件开发接口。如报表权限控制定义开发。 6.3.2 功能要求 数据服务提供作为EDA 域对外提供数据的重要途径,其功能和技术要求如下: 1) 支持通过服务调用实现跨平台应用程序之间的应用到应用(A2A)集成。包括应 用程序接口(APIs)、Java 远端方法调用(RMI)、面向消息的中间件以及Web服务 等多种技术手段; 2) 支持提供数据服务定义、数据服务目录、服务参数定义的功能; 3) 统一制定数据服务的接口模型和接口标准。 6.4 数据展现 数据展现可直接接收用户请求,响应用户操作,并以固定报表、多维分析、自助取数等途径向用户返回结果,且具备基于Portlet技术与门户平台集成的能力。 6.4.1 展现方式 n 固定报表 主要是指按业务需求进行固化的报表,可简单支持用表格、图表等格式来动态显示数据并支持EXCEL、TXT、PDF等常规格式导出功能。 n 多维分析 结合商业智能的OLAP技术帮助用户进行多角度、灵活动态的分析。多维分析报表由“维”(影响因素)和 “指标”(衡量因素)组成,能够真正为用户所理解、并真实的反映企业特性信息。 n 自助取数 是一个基于数据仓库、采用WEB技术实现的软件系统。通过该系统,业务人员可以在没有IT人员支撑的情况下,独立在WEB页面上设定各种取数约束条件,便捷、灵活 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 地实现自助取数。同时,使用者可以在已有各种约束参数的基础上通过运算生成新的约束参数,并可以定制结果清单文件中需要显示的字段。 n 界面集成 界面集成是指通过URL等方式将EDA的应用集成到生产系统或业务平台中,一方面减少生产系统的压力,另一方面为生产系统、业务平台等提供准实时的跨系统数据共享。如CRM系统集成了ODS提供的生产历史报表,10000号等通过URL方式集成了ODS提供的营销建议信息、接触结果统计报表、营销监控信息等。界面集成的权限一般在服务调用端控制。 6.4.2 功能要求 1) 提供专业化的门户组件图表化开发工具,可以将门户组件构建器获取的数据进行直接的图表化展现,如柱状图、饼图、面积图、雷达图等各种形式; 2) 提供良好的界面集市方式,提高开发部署效率、提高构件重用性、利于系统的健壮性和稳定性; 3) 自助取数平台应允许用户进行预约取数,且系统能够实现预约自动排序、以防止数据仓库压力过大; 4) 提供EXCEL、TXT、PDF等格式导出。 6.5 服务管理 服务管理提供了EDA统一的服务管理机制和工具,主要包含参数管理、异常处理机制、服务注册及服务管理服务,承载系统提供服务的就绪过程,保障服务的正常运行。 6.5.1 参数配置 为用户提供一种通用机制与工具管理系统的服务运行参数配置,应支持以下功能: 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 1) 可提供图形化界面集中配置管理服务运行参数,至少支持统一文件的配置能力; 2) 支持服务运行参数配置信息的预校验,及校验配置信息的合法性; 3) 建议支持对经过校验后的配置信息的立即生效,也可以指定在某一时刻后生效; 4) 建议支持对配置信息的版本管理,能够查询参数的历史配置信息,并支持对不同配置信息的版本比较。 6.5.2 服务注册 服务注册提供封装服务的服务注册和服务发布功能,主要包含如下功能: 1) 支持服务接口、服务运行与服务参数等各种服务信息的注册和发布; 2) 可建立服务目录和服务库,对这些服务以及服务的元数据进行定义和存储,以便进行服务的查找、发布、注册和管理。 6.5.3 服务管理服务 服务管理服务帮助用户管理各种服务元数据信息、服务交互、服务运行状态监控及生命周期管理可视化操作。主要包含功能如下: 1) 可管理服务分组、服务使用策略并监控服务的变化与版本控制情况; 2) 提供服务影响分析能力,根据捕获的服务相关信息分析服务使用情况、历史以及业务影响,在服务性能超出设定参数时发送通知; 3) 支持对服务本身信息及服务之间关联关系等内容进行可视化控制的能力; 4) 具有用户定义的服务状态转换同步与异步验证能力; 5) 支持通过监控服务查询服务的关键运行状态; 6) 支持对服务的部署、激活、停用等管理操作; 7) 建议支持服务生命周期管理,管理各种服务变化,并制定发布、使用以及退出服务的策略,支持服务变更通知。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 6.5.4 异常处理机制 异常是指系统在运行过程中发生的、导致服务无法正常处理下去的事件或操作,主要包括异常发现与俘获、异常处理两部分功能。 n 异常发现与俘获 1) 能够精确地捕获到异常发生的时间与位置; 2) 可对异常分为警告、错误、严重错误等不同的级别; 3) 异常的模块必须通过日志组件记录相应的异常信息; 4) 异常级别决定是否向运营管理平台监控告警。 n 异常处理 1) 提供集中的图形化异常事件管理工具管理各模块发出的所有异常事件; 2) 用户处理完该异常事件时,异常事件管理工具必须支持管理员关闭该异常事件,并建议支持管理员输入该异常事件的处理方法; 3) 应该能够根据异常事件的状态,对超出处理时限的异常主动向运营管理平台服务告警; 4) 建议提供根据异常信息代码或其他关键字等信息搜索已有的相关异常事件的处理方法,并支持模糊查询; 5) 建议提供对不同状态异常事件的统计查询功能,并支持灵活排序; 6) 建议支持对异常事件状态生命周期的统计。 6.6 应用安全 6.6.1 安全审计 安全审计主要是负责管理EDA系统相关的组织、用户、角色、认证、授权鉴权等安全审计功能。主要包含的功能如下: 5) 可提供组织、用户、角色及资源的动态维护,支持组织的分级管理; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 6) 角色所拥有的权限必须包括能够管理的数据资源范围和操作权限的集合; 7) 操作权限集合应该包括使用权限(如:增加、删除、修改等)和授权两类; 8) 当角色所拥有授权权限,支持将其拥有的权限进行转赋; 9) 支持一个用户可以拥有多个角色; 10) 支持自动生成用户的初始密码,并提供密码的修改功能; 11) 不允许以明文的方式存储和使用密码; 12) 支持自动或人工生成账号,账号不能重复,用户在组织间调整时,无需调整用户的账号; 13) 支持设置账号有效期及其到期后设置该账号状态为“无效”,删除用户时,只需将该用户置为“无效”状态; 14) 用户登录后必须支持自动初始化用户鉴权信息,仅显示该用户所拥有权限的功能菜单及信息展现。 6.6.2 安全防护 安全防护主要是以监控为工具主动发现安全隐患及系统的运行状态,提供一种通用的机制与能力,监视系统各部件的运行状态,提供统一的系统监控和应用安全,从而主动规避安全隐患。主要包含功能如下: n 监控管理 1) 支持图形化的监控管理工具及图表分析功能; 2) 能够捕获到系统服务发出的异常告警信息; 3) 支持对服务的监控,监控内容包括运行状态、处理能力、负载均衡能力; 4) 建议支持对不同的监控对象设定不同的采集频率,并通过随时间变化的性能监视图反映状态的变化; 5) 支持用户主动地获取各监控对象的状态。 n 数据展现脱敏 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 鉴于用户实名制后对用户信息的保护,需对部分用户信息进行脱敏处理。功能要求如下: 1) 支持信息敏感级别定义,如从低到高为一级、二级、三级; 2) 对敏感规则定义及脱敏处理。提供脱敏规则定义,用户数据脱敏处理中对某些敏感信息通过脱敏规则进行数据的变形,实现敏感隐私数据的可靠保护; 3) 支持按授权进行敏感信息查看,无授权情况下,用户信息将不可见或经脱敏处理后显示。经授权后,可查询相应级别的用户信息或未脱敏处理的用户信息。 n 服务交换安全 数据传输交换过程中,需要进行安全控制,可以采用如下安全技术手段: 1) 密钥管理。密钥是一种基于密码技术的安全机制。密钥机制中除密码的设计安全外,另一个重要的方面就是密钥管理体制,包括密钥的产生、分发、更换、存储和销毁等内容; 2) 数字签名机制。数字签名是基于非对称加密技术的安全机制。它为需要加密的对象提供两类密钥:公钥和私钥,统一采用公钥方式加密,采用私钥方式解密; 3) 加密机制。加密可提高数据或业务流量信息的机密性。通常有两种形式的加密:物理层的群路加密和网络层或应用层的端到端加密。 6.6.3 安全日志 安全日志管理管理系统产生的系统运行日志和系统操作日志,并提供操作回溯、日志审计等功能。系统运行日志是在某一时刻对系统某一运行状态的记录,其主要目的是对系统自身的运行状态、过程与性能进行跟踪、分析与调试。系统操作包括功能操作和数据操作,功能操作包括用户登录、注销信息,功能调用信息,数据操作包括数据的增加、删除、修改、查询。具体要求功能如下: 1) 提供集中式、图形化界面的系统日志管理机制; 2) 支持不同的服务、应用定义不同的系统日志采集等级,采集等级应该可以定义后立即生效,也可以指定在某一时刻后生效; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 3) 记录操作级别高于或等于当前日志采集等级的日志; 4) 支持定期转储日志信息,以提高系统性能; 5) 支持对失效日志的人工或自动删除; 6) 支持统一的结构化的日志格式; 7) 建议能够动态地根据日志属性的不同组合而查看特定内容的日志; 8) 建议支持对日志内容的全文搜索; 9) 当系统发生异常时,在对该异常进行日志记录的同时,还需要启动相应的异常处理服务和监控服务。 7 EDA数据应用架构(待定) 8 统一数据应用门户(待定) 9 EDA数据运营管理平台(待定) 元数据管理 业务元数据 技术元数据 元数据管理要求 主数据管理 主数据概述 主数据统一编码 数据安全管理 数据质量管理 数据质量管理的目的 数据质量管理原则 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 数据质量管理的内容 数据质量管理的方法 统一调度管理 10 两级EDA数据交互(待定) 11 EDA相关技术(理想) 在EDA数据架构的不同层面可能使用不同的技术,多个层面也可能服用相同的数据处理技术;例如,以EDA为边界,其余下游系统数据的交互(数据服务的形式),可采用文件接口方式,而起于上游系统的交互(数据采集的形式)也可采用文件接口的方式; 此图是否需要重新绘制?? 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 11.1 数据交互接口(数据采集/数据服务) 数据采集和数据服务都是系统之间的数据传递接口,一般而言,数据采集层的数据量相对较大.它们主要使用的技术包括文件接口,消息队列,API调度,流数据采集等 11.1.1 文件接口 流行的文件传输接口一般使用文件传输协议(FTP:File Transfer Protocol),使得系统间可以共享文件。 FTP 使用 TCP 生成一个虚拟连接用于控制信息,然后再生成一个单独的 TCP 连接用于数据传输。控制连接使用类似 TELNET 协议在主机间交换命令和消息。 文件传输协议是TCP/IP网络上两台计算机传送文件的协议,FTP是在TCP/IP网络和INTERNET上最早使用的协议之一,它属于网络协议组的应用层,它基于传输层,为用户服务,它们负责进行文件的传输。FTP是一个8位的客户端-服务器协议,能操作任何类型的文件而不需要进一步处理,就像MIME或Unicode一样。FTP服务一般运行在20和21两个端口。端口20用于在客户端和服务器之间传输数据流,而端口21用于传输控制流,并且是命令通向FTP服务器的进口。 FTP有两种使用模式:主动和被动。主动模式要求客户端和服务器端同时打开并且监听一个端口以创建连接。在这种情况下,客户端由于安装了防火墙会产 生一些问题。所以,创立了被动模式。被动模式只要求服务器端产生一个监听相应端口的进程,这样就可以绕过客户端安装了防火墙的问题。 主动模式的FTP连接创建要遵循以下步骤: 1. 客户端打开一个随机的端口(端口号大于1024,在这里,我们称它为x),同时一个FTP进程连接至服务器的21号命令端口。此时,该tcp连接的来源地端口为客户端指定的随机端口x,目的地端口(远程端口)为服务器上的21号端口。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 2. 客户端开始监听端口(x+1),同时向服务器发送一个端口命令(通过服务器的21号命令端口),此命令告诉服务器客户端正在监听的端口号并且已准备好从此端口接收数据。这个端口就是我们所知的数据端口。 3. 服务器打开20号源端口并且创建和客户端数据端口的连接。此时,来源地的端口为20,远程数据(目的地)端口为(x+1)。 4. 客户端通过本地的数据端口创建一个和服务器20号端口的连接,然后向服务器发送一个应答,告诉服务器它已经创建好了一个连接。 11.1.2 消息队列 消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列,应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。 在分布式计算环境中,为了集成分布式应用,开发者需要对异构网络环境下的分布式应用提供有效的通信手段。为了管理需要共享的信息,对应用提供公共的信息交换机制是重要的。 设计分布式应用的方法主要有:远程过程调用(PRC)--分布式计算环境(DCE)的基础标准成分之一;对象事务监控(OTM)--基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合;消息队列(MessageQueue)--构造分布式应用的松耦合方法。 MQ的基本概念包括: 1) 队列管理器 队列管理器是MQ系统中最上层的一个概念,由它为我们提供基于队列的消息服务。 2) 消息 在MQ中,我们把应用程序交由MQ传输的数据定义为消息,我们可以定义消息的内容并对消息进行广义的理解,比如:用户的各种类型的数据文件,某个应用向其它应用发出的处理请求等都可以作为消息。消息有两部分组成: 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 消息描述符(Message Discription或Message Header),描述消息的特征,如:消息的优先级、生命周期、消息Id等; 消息体(Message Body),即用户数据部分。在MQ中,消息分为两种类型,非永久性(non-persistent)消息和永久性(persistent)消息,非永久性消息是存储在内存中的,它是为了提高性能而设计的,当系统掉电或MQ队列管理器重新启动时,将不可恢复。当用户对消息的可靠性要求不高,而侧重系统的性能表现时,可以采用该种类型的消息,如:当发布股票信息时,由于股票信息是不断更新的,我们可能每若干秒就会发布一次,新的消息会不断覆盖旧的消息。永久性消息是存储在硬盘上,并且纪录数据日志的,它具有高可靠性,在网络和系统发生故障等情况下都能确保消息不丢、不重。 此外,在MQ中,还有逻辑消息和物理消息的概念。利用逻辑消息和物理消息,我们可以将大消息进行分段处理,也可以将若干个本身完整的消息在应用逻辑上归为一组进行处理。 3) 队列 队列是消息的安全存放地,队列存储消息直到它被应用程序处理。 消息队列以下述方式工作: a) 程序A形成对消息队列系统的调用,此调用告知消息队列系统,消息准备好了投向程序B; b) 消息队列系统发送此消息到程序B驻留处的系统,并将它放到程序B的队列中; c) 适当时间后,程序B从它的队列中读此消息,并处理此信息。 由于采用了先进的程序设计思想以及内部工作机制,MQ能够在各种网络条件下保证消息的可靠传递,可以克服网络线路质量差或不稳定的现状,在传输过程中,如果通信线路出现故障或远端的主机发生故障,本地的应用程序都不会受到影响,可以继续发送数据,而无需等待网络故障恢复或远端主机正常后再重新运行。 在MQ中,队列分为很多种类型,其中包括:本地队列、远程队列、模板队列、动态队列、别名队列等。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 本地队列又分为普通本地队列和传输队列,普通本地队列是应用程序通过API对其进行读写操作的队列;传输队列可以理解为存储-转发队列,比如:我们将某个消息交给MQ系统发送到远程主机,而此时网络发生故障,MQ将把消息放在传输队列中暂存,当网络恢复时,再发往远端目的地。 远程队列是目的队列在本地的定义,它类似一个地址指针,指向远程主机上的某个目的队列,它仅仅是个定义,不真正占用磁盘存储空间。 模板队列和动态队列是MQ的一个特色,它的一个典型用途是用作系统的可扩展性考虑。我们可以创建一个模板队列,当今后需要新增队列时,每打开一个模板队列,MQ便会自动生成一个动态队列,我们还可以指定该动态队列为临时队列或者是永久队列,若为临时队列我们可以在关闭它的同时将它删除,相反,若为永久队列,我们可以将它永久保留,为我所用。 4) 通道 通道是MQ系统中队列管理器之间传递消息的管道,它是建立在物理的网络连接之上的一个逻辑概念,也是MQ产品的精华。 在MQ中,主要有三大类通道类型,即消息通道,MQI通道和Cluster通道。消息通道是用于在MQ的服务器和服务器之间传输消息的,需要强调指出的是,该通道是单向的,它又有发送(sender), 接收(receive), 请求者(requestor), 服务者(server)等不同类型,供用户在不同情况下使用。MQI通道是MQ Client和MQ Server之间通讯和传输消息用的,与消息通道不同,它的传输是双向的。群集(Cluster)通道是位于同一个MQ 群集内部的队列管理器之间通讯使用的。 11.1.3 界面集成 界面集成或者界面整合一般被看作是企业应用集成的一部分,但由于界面直接和用户进行交互,可当作数据服务的一种技术;它是指将几种相关软件的界面统一集成到一个界面中来,使用户达到统一入口,统一界面,避免登入不同系统时频繁切换页面。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 界面整合的前提条件是进行集成的软件本身支持Portal等界面整合的技术。 在经分统一门户中,通过界面集成,可以将不同应用系统集成起来,给用户提供一个统一的管理门户,通过这个统一的管理门户,实现统一登录、统一认证、统一权限管理、统一界面风格,并保护用户原来的投资,将几种软件的优点保留下来。 11.1.4 网络爬虫(SPAM) 网络爬虫是一个自动提取网页的程序,它为搜索引擎从万维网上下载网页,是搜索引擎的重要组成。网络爬虫的基本工作流程如下: 1.首先选取一部分精心挑选的种子URL; 2.将这些URL放入待抓取URL队列; 3.从待抓取URL队列中取出待抓取在URL,解析DNS,并且得到主机的ip,并将URL对应的网页下载下来,存储进已下载网页库中。此外,将这些URL放进已抓取URL队列。 4.分析已抓取URL队列中的URL,分析其中的其他URL,并且将URL放入待抓取URL队列,从而进入下一个循环 在爬虫系统中,待抓取URL队列是很重要的一部分。待抓取URL队列中的URL以什么样的顺序排列也是一个很重要的问题,因为这涉及到先抓取那个页面,后抓取哪个页面。而决定这些URL排列顺序的方法,叫做抓取策略。下面重点介绍几种常见的抓取策略: 1.深度优先遍历策略 深度优先遍历策略是指网络爬虫会从起始页开始,一个链接一个链接跟踪下去,处理完这条线路之后再转入下一个起始页,继续跟踪链接。 2.宽度优先遍历策略 宽度优先遍历策略的基本思路是,将新下载网页中发现的链接直接插入待抓取URL队列的末尾。也就是指网络爬虫会先抓取起始网页中链接的所有网页,然后再选择其中的一个链接网页,继续抓取在此网页中链接的所有网页。 遍历路径:A-B-C-D-E-F G H I 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 3.反向链接数策略 反向链接数是指一个网页被其他网页链接指向的数量。反向链接数表示的是一个网页的内容受到其他人的推荐的程度。因此,很多时候搜索引擎的抓取系统会使用这个指标来评价网页的重要程度,从而决定不同网页的抓取先后顺序。 在真实的网络环境中,由于广告链接、作弊链接的存在,反向链接数不能完全等他我那个也的重要程度。因此,搜索引擎往往考虑一些可靠的反向链接数。 4.PageRank算法策略及扩展 PageRank是Google专有的算法,用于衡量特定网页相对于搜索引擎索引中的其他网页而言的重要程度。它由Larry Page 和 Sergey Brin在20世纪90年代后期发明。PageRank实现了将链接价值概念作为排名因素。 PageRank将对页面的链接看成投票,指示了重要性。 Partial PageRank算法借鉴了PageRank算法的思想:对于已经下载的网页,连同待抓取URL队列中的URL,形成网页集合,计算每个页面的PageRank值,计算完之后,将待抓取URL队列中的URL按照PageRank值的大小排列,并按照该顺序抓取页面。 如果每次抓取一个页面,就重新计算PageRank值,一种折中方案是:每抓取K个页面后,重新计算一次PageRank值。但是这种情况还会有一个问题:对于已经下载下来的页面中分析出的链接,也就是我们之前提到的未知网页那一部分,暂时是没有PageRank值的。为了解决这个问题,会给这些页面一个临时的PageRank值:将这个网页所有入链传递进来的PageRank值进行汇总,这样就形成了该未知页面的PageRank值,从而参与排序。下面举例说明: 5.OPIC策略策略 该算法实际上也是对页面进行一个重要性打分。在算法开始前,给所有页面一个相同的初始现金(cash)。当下载了某个页面P之后,将P的现金分摊给所有从P中分析出的链接,并且将P的现金清空。对于待抓取URL队列中的所有页面按照现金数进行排序。 6.大站优先策略 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 对于待抓取URL队列中的所有网页,根据所属的网站进行分类。对于待下载页面数多的网站,优先下载。这个策略也因此叫做大站优先策略。 11.1.5 日志收集日志搜集本身是强调的是一种数据搜集的范围,是否是特定技术? 技术 //主要参考http://dongxicheng.org/search-engine/log-systems/ 系统平台每天会产生大量的日志,除了传统的数据库日志和系统日志外,网页等其他日志也越发重要,他们一般般为流式数据,如,搜索引擎的pv,查询等,处理这些日志需要特定的日志系统,一般而言,需要具有以下特征: (1) 构建应用系统和分析系统的桥梁,并将它们之间的关联解耦; (2) 支持近实时的在线分析系统和类似于Hadoop之类的离线分析系统; (3) 具有高可扩展性。即:当数据量增加时,可以通过增加节点进行水平扩展。 日志系统需具备三个基本组件,分别为agent(封装数据源,将数据源中的数据发送给collector),collector(接收多个agent的数据,并进行汇总后导入后端的store中),store(中央存储系统,应该具有可扩展性和可靠性,应该支持当前非常流行的HDFS)。 比较典型的开源日志处理系统包括FaceBook的Scribe, Apache的Chukwa和LinkedIn的Kafka,Cloudera的Flume FaceBook下面可根据需要进行取舍,个人建议在正文中进行删除. 的Scribe Scribe是facebook开源的日志收集系统,在facebook内部已经得到大量的应用。它能够从各种日志源上收集日志,存储到一个中央存储系统 (可以是NFS,分布式文件系统等)上,以便于进行集中统计分析处理。它为日志的“分布式收集,统一处理”提供了一个可扩展的,高容错的方案。 它最重要的特点是容错性好。当后端的存储系统crash时,scribe会将数据写到本地磁盘上,当存储系统恢复正常后,scribe将日志重新加载到存储系统中。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Apache的Chukwa chukwa是一个非常新的开源项目,由于其属于hadoop系列产品,因而使用了很多hadoop的组件(用HDFS存储,用mapreduce处理数据),它提供了很多模块以支持hadoop集群日志分析。 LinkedIn的Kafka Kafka是2010年12月份开源的项目,采用scala语言编写,使用了多种效率优化机制,整体架构比较新颖(push/pull),更适合异构集群。 设计目标: (1) 数据在磁盘上的存取代价为O(1) (2) 高吞吐率,在普通的服务器上每秒也能处理几十万条消息 (3) 分布式架构,能够对消息分区 (4) 支持将数据并行的加载到hadoop 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Cloudera的Flume Flume是cloudera于2009年7月开源的日志系统。它内置的各种组件非常齐全,用户几乎不必进行任何额外开发即可使用。 设计目标: (1) 可靠性 当节点出现故障时,日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障,从强到弱依次分别为:end-to-end(收到数据agent首先将event写到磁盘上,当数据传送成功后,再删除;如果数据发送失败,可以重新发送。),Store on failure(这也是scribe采用的策略,当数据接收方crash时,将数据写到本地,待恢复后,继续发送),Best effort(数据发送到接收方后,不会进行确认)。 (2) 可扩展性 Flume采用了三层架构,分别问agent,collector和storage,每一层均可以水平扩展。其中,所有agent和collector由master统一管理,这使得系统容易监控和维护,且master允许有多个(使用ZooKeeper进行管理和负载均衡),这就避免了单点故障问题。 (3) 可管理性 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 所有agent和colletor由master统一管理,这使得系统便于维护。用户可以在master上查看各个数据源或者数据流执行情况,且可以对各个数据源配置和动态加载。Flume提供了web 和shell script command两种形式对数据流进行管理。 (4) 功能可扩展性 用户可以根据需要添加自己的agent,colletor或者storage。此外,Flume自带了很多组件,包括各种agent(file, syslog等),collector和storage(file,HDFS等)。 11.1.6 流数据(信令数据等) 流数据是一组顺序、大量、快速、连续到达的数据序列,一般情况下,数据流可被视为一个随时间延续而无限增长的动态数据集合。如信令数据等; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 流数据具有四个特点: 1)数据实时到达; 2)数据到达次序独立,不受应用系统所控制; 3)数据规模宏大且不能预知其最大值; 4)数据一经处理,除非特意保存,否则不能被再次取出处理,或者再次提取数据代价昂贵。 在数据流处理的研究领域中,海量流数据处理主要包括两种情况:分布式海量流数据处理和集中式海量流数据处理,针对两个不同的情况也有相应的不同处理技术。对于分布式海量数据处理而言,这种分布式系统一般由若干个节点组成,由于这种分布是由问题本身的性质决定的,因此这种分布形式是数据的固有形式而不是人为的结果。它的数据规模是由各个节点的数据规模相加得到,各个节点上的数据有相同之处也有不同之处,因此不能单纯的采用数据累加汇总的方式来处理。 另外一种就是集中式海量流数据处理,这是实际问题出现的最多的数据形式,也是海量流数据处理的默认数据组织形式,目前的研究大多数都是针对这种数据流形式。 11.1.7 API调度方式 API(Application Programming Interface,应用程序编程接口)是一些预先定义的函数,目的是提供应用程序与开发人员基于某软件或硬件的以访问一组例程的能力,而又无需访问源码,或理解内部工作机制的细节。 API又分为(Windows、Linux、Unix等系统的)系统级API,及非操作系统级的自定义API。作为一种有效的代码封装模式,微软Windows的API开发模式已经为许多商业应用开发的公司所借鉴,并开发出某些商业应用系统的API函数予以发布,方便第三方进行功能扩展。如Google、苹果电脑公司,以及诺基亚等手机开发的API等等。 在linux中,用户编程接口API遵循了UNIX中最流行的应用编程界面标准---POSIX标准。POSIX标准是由IEEE和ISO/IEC共同开发的标准系统。该标准基于当时现有的UNIX实践和经验,描述了操作系统的系统调用编程接口API,用于保证应用程序可以在源 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 程序一级上在多种操作系统上移植运行。这些系统调用编程接口主要是通过C库(LIBC)来实现的。 11.1.8 WebService服务 Web Service是一项新技术, 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件, 就可相互交换数据或集成。依据Web Service规范实施的应用之间, 无论它们所使用的语言、 平台或内部协议是什么, 都可以相互交换数据。Web Service是自描述、 自包含的可用网络模块, 可以执行具体的业务功能。Web Service也很容易部署, 因为它们基于一些常规的产业标准以及已有的一些技术,诸如XML和HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。 可扩展的标记语言XML 是Web Service平台中表示数据的基本格式。除了易于建立和易于分析外,XML主要的优点在于它既与平台无关,又与厂商无关。XML是由万维网协会(W3C)创建,W3C制定的XML SchemaXSD 定义了一套标准的数据类型,并给出了一种语言来扩展这套数据类型。 Web Service平台是用XSD来作为数据类型系统的。当你用某种语言如VB. NET或C# 来构造一个Web Service时,为了符合Web Service标准,所有你使用的数据类型都必须被转换为XSD类型。如想让它使用在不同平台和不同软件的不同组织间传递,还需要用某种东西将它包装起来。这种东西就是一种协议,如 SOAP。SOAP即简单对象访问协议(Simple Object Access Protocol),它是用于交换XML编码信息的轻量级协议。它有三个主要方面:XML-envelope为描述信息内容和如何处理内容定义了框架,将程序对象编码成为XML对象的规则,执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。例如,你可以使用 SMTP,即因特网电子邮件协议来传递SOAP消息,这可是很有诱惑力的。在传输层之间的头是不同的,但XML有效负载保持相同。 Web Service 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用,打破了软件应用、网站和各种设备之间的格格不入的状态,实现“基于Web无缝集成”的目标。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Web Service描述语言WSDL 就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言,用于描述Web Service及其函数、参数和返回值。因为是基于XML的,所以WSDL既是机器可阅读的,又是人可阅读的。 11.2 数据处理 11.2.1 批处理 集中式处理: 集中式数据存储的主要特点是能把所有数据保存在一个地方,客户端通过网络相联,保证了每个终端使用的都是同一信息。备份数据容易,因为他们都存储在服务器上,而服务器是唯一需要备份的系统。同时服务器是唯一需要安全保护的系统,终端没有任何数据。所有的事务都在主机上进行处理,所以网络感染病毒的可能性很低。 分布式处理: 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 分布式处理系统必须有能力在短时间内动态地组合成面向不同服务对象的系统。对用户来说系统是透明的,用户只需指定系统干什么而不必指出哪个部件可以提供这一服务。系统各组成部分是自主的,但不是无控制状态,而是遵循某个主计划由高级操作系统进行协调工作。如果这样的系统不具备动态组合及任务再指派的能力,那么它们仍然是集中式处理。高级操作系统是分布式处理的关键。在分布式系统中不再使用完整的信息,各个组 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 成部分提供自己的状态信息,高级操作系统根据这些状态信息进行任务协调和资源再分配,各组成部分之间没有层次关系而是自主的。 11.2.2 标签分类 通过互联网分析相关平台获取用户上网数据、互联网分类数据、用户标签数据。其中:数据范围包括移动互联网(ctnet、ctwap)数据;数据内容包括URL分类数据、APP分类数据、未匹配URL、漫游用户移动互联网数据等。 集团统一建设URL、APP分类库以从宏观层面统一把握用户互联网标签。并定期将最新APP库以更新的形式下发到各省份。 集团公司:并通过接口将规则下发到各省份接口服务器,同时还负责针对各省份汇总上来的未识别的URL条目进行分类识别处理 省公司:接收同步本省URL、APP分类库,同时将本省未能识别出的URL、APP条目通过上传传输到集团统一分类库; 11.2.3 流数据技术 在某些场景下,大了的数据以流的形式到达,浙些流数据持续到达,速度快,容量近乎无限,传统的数据库技术已经不能很好支撑,把流数据处理引入,能提高数据处理的性 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 能,缓解时间窗口的瓶颈,流数据的模型中,与传统可在文件、数据库或者内存中随机访问的数据不同,数据是连续、不断的到达,与传统数据相比,流数据中具备一下四个特点: 实时性:数据是实时发生,要求立刻能得到处理,例如 无序性:到底的数据相互之间是独立的,不受应用系统控制,例如 无限性:理论上数据规模没有上限,数据源源不断的到达,随着时间的推移,规模不断增加 单遍处理性:数据一旦被处理,要么被抛弃,要么被存档,并且存储的数据量极大,从存储介质总提取数据代价高昂,不考虑重新计算,因此数据元素不能轻易被重新获取,除非被特意存放在载体中。 数据处理有一下特点: 1、 特殊的数据处理模型,传统的处理方式要保存整个流数据,流数据的系统不要钱也不可能保存整个刘,而是维护一个闺蜜远小于流数据大小的概要数据结构; 2、 实施接受送到的数据,处理速度要求满足输入数据的速度要求,能够应对流速增大是的峰值清行; 3、 查询处理是实时的,在不影响实际应用的前提下可以接受近似处理结果。因为在时间和空间的上的严格限制,为了达到实时的效果,降低结果的精确度是可以接受的,通常可以提供一个错误上限 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 流数据模型中的流数据处理引擎和概要数据结构是系统的关键因素,一般包括二部分,一个是监控流数据,更新概要数据结果,一部分是响应客户查询请求,返回近似结果。 1、 单次少么,流数据处理后不再被重复扫描和计算; 2、 低时间复杂度,为了跟上流数据传输速度,处理每个数据项的时间不能太长 3、 低空间密度,流数据的算法是在内存中进行,算法的的空间密度不能随数据库里的无限增长 4、 结果的相似性,流数据无法存储和再次扫描,存在信息的损失,因此只能得到相近似的处理结果 5、 实施的响应性。处理必须能相应用户在线提出的任意时段处理请求 http://developer.51cto.com/art/201207/350684.htm · Storm是什么 如果只用一句话来描述storm的话,可能会是这样:分布式实时计算系统。按照storm作者的说法,storm对于实时计算的意义类似于hadoop对于批处理的意义。我们都知道,根据google mapreduce来实现的hadoop为我们提供了map, reduce原语,使我们的批处理程序变得非常地简单和优美。同样,storm也为实时计算提供了一些简单优美的原语。我们会在第三节中详细介绍。 我们来看一下storm的适用场景。 1. 流数据处理。Storm可以用来处理源源不断流进来的消息,处理之后将结果写入到某个存储中去。 2. 分布式rpc。由于storm的处理组件是分布式的,而且处理延迟极低,所以可以作为一个通用的分布式rpc框架来使用。当然,其实我们的搜索引擎本身也是一个分布式rpc系统。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 11.2.1 大数据处理 目前大数据处理主要有以下两种方法: 1. 利用hive作为数据处理引擎 Hive是一个基于Hadoop之上的开源数据仓库解决方案,它提供了与SQL类似的一种查询语言HiveQL,用于支持查询表达并能将其转化为map-reduce任务在hadoop中执行。HiveQL还支持在查询中插入自定义的函数脚本。HiveQL包含了一个类型系统,用来支持表中出现的原始类型、类似于数组和ap的集合类型以及由他们嵌套组成的类型。可以扩展其基本IO库进行自定义格式的数据查询。Hive还包括了一个系统目录(system catalog) Hive-Metastore,此系统提供模式(schemas)和统计,用于数据挖掘和查询优化。 使用hive的优势在于易于开发和维护,由于它使用了类sql引擎,传统数据库开发人员可以平滑过渡成hadoop开发人员。 一般我们在开发复杂的关系型的数据处理程序时候建议采用hive。如数据关联、排序、汇总等。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Hive架构图 2. 直接使用map-reduce作为数据处理引擎 MapReduce是一种编程模型,用于大规模数据集(大于1TB)的并行运算。概念"Map(映射)"和"Reduce(化简)",和他们的主要思想,都是从函数式编程语言里借来的,还有从矢量编程语言里借来的特性。他极大地方便了编程人员在不会分布式并行编程的情况下,将自己的程序运行在分布式系统上。 当前的软件实现是指定一个Map(映射)函数,用来把一组键值对映射成一组新的键值对,指定并发的Reduce(化简)函数,用来保证所有映射的键值对中的每一个共享相同的键组。 作为hadoop的核心组件,MapReduce只是一个框架,它支持多语言的开发,如java、C++、python等。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 使用MapReduce来实现数据处理的优势在于可以开发更高效的处理程序,彻底发挥hadoop系统的性能优势。 一般在开发字段级的数据预处理程序时建议采用MapReduce,如数据清洗、字段规整、关键字提取等。 11.2.2 非结构化数据处理 中文分词 中文分词 (Chinese Word Segmentation) 是文本挖掘的基础, 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 指的是将一个汉字序列切分成一个一个单独的词。分词就是将连续的字序列按照一定的规范重新组合成词序列的过程。我们知道,在英文的行文中,单词之间是以空格作为自然分界符的,而中文只是字、句和段能通过明显的分界符来简单划界,唯独词没有一个形式上的分界符. 和以英文为代表的拉丁语系语言相比,中文具备如下特点: 1,中文由于继承自古代汉语的传统,词语之间没有分隔。 古代汉语中除了连绵词和人名地名等,词通常就是单个汉字,所以当时没有分词书写的必要。而现代汉语中双字或多字词居多,一个字不再等同于一个词。 2.在中文里,“词”和“词组”边界模糊 现代汉语的基本表达单元虽然为“词”,且以双字或者多字词居多,但由于人们认识水平的不同,对词和短语的边界很难去区分。 现有的分词算法可分为三大类:基于字符串匹配的分词方法、基于理解的分词方法和基于统计的分词方法。按照是否与词性标注过程相结合,又可以分为单纯分词方法和分词与标注相结合的一体化方法。 英文分词的工具算法包流行的有Lucene,它是一套用于全文检索和搜寻的开放源码程式库,由Apache软件基金会支持和提供。Lucene提供了一个简单却强大的应用程式接口,能够做全文索引和搜寻,在Java开发环境里Lucene是一个成熟的免费开放源代码工具;就其本身而论,Lucene是现在并且是这几年,最受欢迎的免费java资讯检索程式库。 中文分词技术包很多是基于Lucene,常用的有: Ø SCWS:Hightman开发的一套基于词频词典的机械中文分词引擎,它能将一整段的汉字基本正确的切分成词。采用的是采集的词频词典,并辅以一定的专有名称,人名,地名,数字年代等规则识别来达到基本分词,经小范围测试大概准确率在 90% ~ 95% 之间,已能基本满足一些小型搜索引擎、关键字提取等场合运用。45Kb左右的文本切词时间是0.026秒,大概是1.5MB文本/秒,支持PHP4和PHP 5。 Ø FudanNLP:FudanNLP主要是为中文自然语言处理而开发的工具包,也包含为实现这些任务的机器学习算法和数据集。本工具包及其包含数据集使用LGPL3.0许可证。开发语言为Java。功能包括中文分词等,不需要字典支持。 Ø ICTCLAS:这是最早的中文开源分词项目之一,ICTCLAS在国内973专家组组织的评测中活动获得了第一名,在第一届国际中文处理研究机构 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 SigHan组织的评测中都获得了多项第一名。ICTCLAS3.0分词速度单机996KB/s,分词精度98.45%,API不超过200KB,各种词典数据压缩后不到3M.ICTCLAS全部采用C/C++编写,支持Linux、FreeBSD及Windows系列操作系统,支持C/C++、C#、Delphi、Java等主流的开发语言。 Ø HTTPCWS:HTTPCWS 是一款基于HTTP协议的开源中文分词系统,目前仅支持Linux系统。HTTPCWS 使用“ICTCLAS 3.0 2009共享版中文分词算法”的API进行分词处理,得出分词结果。HTTPCWS 将取代之前的 PHPCWS 中文分词扩展。 Ø CC-CEDICT:一个中文词典开源项目,提供一份以汉语拼音为中文辅助的汉英辞典,截至2009年2月8日,已收录82712个单词。其词典可以用于中文分词使用,而且不存在版权问题。Chrome中文版就是使用的这个词典进行中文分词的。 Ø IK:IKAnalyzer是一个开源的,基于java语言开发的轻量级的中文分词工具包。从2006年12月推出1.0版开始,IKAnalyzer已经推出了3个大版本。最初,它是以开源项目Luence为应用主体的,结合词典分词和文法分析算法的中文分词组件。新版本的IKAnalyzer3.0则发展为面向Java的公用分词组件,独立于Lucene项目,同时提供了对Lucene的默认优化实现。 Ø Paoding:Paoding(庖丁解牛分词)基于Java的开源中文分词组件,提供lucene和solr 接口,具有极 高效率和 高扩展性。仅支持Java语言。 Ø MMSEG4J:MMSEG4J基于Java的开源中文分词组件,提供lucene和solr 接口Jcseg:jcseg是使用Java开发的一个中文分词器,使用流行的mmseg算法实现。 Ø friso:friso是使用c语言开发的一个中文分词器,使用流行的mmseg算法实现。完全基于模块化设计和实现,可以很方便的植入到其他程序中; 中文分词的应用包括名址匹配等; 11.3 数据存储 11.3.1 SMP/MPP 从系统架构来看,目前的商用服务器大体可以分为三类,即对称多处理器结构 (SMP : Symmetric Multi-Processor) ,非一致存储访问结构 (NUMA : Non-Uniform Memory Access) ,以及海量并行处理结构 (MPP : Massive Parallel Processing) 。它们的特征分别描述如下: SMP(Symmetric Multi-Processor) 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 所谓对称多处理器结构,是指服务器中多个 CPU 对称工作,无主次或从属关系。各 CPU 共享相同的物理内存,每个 CPU 访问内存中的任何地址所需时间是相同的,因此 SMP 也被称为一致存储器访问结构 (UMA : Uniform Memory Access) 。对 SMP 服务器进行扩展的方式包括增加内存、使用更快的 CPU 、增加 CPU 、扩充 I/O( 槽口数与总线数 ) 以及添加更多的外部设备 ( 通常是磁盘存储 ) 。 SMP 服务器的主要特征是共享,系统中所有资源 (CPU 、内存、 I/O 等 ) 都是共享的。也正是由于这种特征,导致了 SMP 服务器的主要问题,那就是它的扩展能力非常有限。对于 SMP 服务器而言,每一个共享的环节都可能造成 SMP 服务器扩展时的瓶颈,而最受限制的则是内存。由于每个 CPU 必须通过相同的内存总线访问相同的内存资源,因此随着 CPU 数量的增加,内存访问冲突将迅速增加,最终会造成 CPU 资源的浪费,使 CPU 性能的有效性大大降低。实验证明, SMP 服务器 CPU 利用率最好的情况是 2 至 4 个 CPU 。 NUMA(Non-Uniform Memory Access) 由于 SMP 在扩展能力上的限制,人们开始探究如何进行有效地扩展从而构建大型系统的技术, NUMA 就是这种努力下的结果之一。利用 NUMA 技术,可以把几十个 CPU( 甚至上百个 CPU) 组合在一个服务器内。 NUMA 服务器的基本特征是具有多个 CPU 模块,每个 CPU 模块由多个 CPU( 如 4 个 ) 组成,并且具有独立的本地内存、 I/O 槽口等。由于其节点之间可以通过互联模块 ( 如称为 Crossbar Switch) 进行连接和信息交互,因此每个 CPU 可以访问整个系统的内存 ( 这是 NUMA 系统与 MPP 系统的重要差别 ) 。显然,访问本地内存的速度将远远高于访问远程内存 ( 系统内其它节点的内存 ) 的速度,这也是非一致存储访问 NUMA 的由来。由于此设计特点,为了更好地发挥系统性能,开发应用程序时需要尽量减少不同 CPU 模块之间的信息交互。 但 NUMA 技术同样有一定缺陷,由于访问远程内存的延时远远超过本地内存,因此当 CPU 数量增加时,系统性能无法线性增加。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 MPP(Massive Parallel Processing) 与NUMA 不同,MPP 提供了另外一种进行系统扩展的方式,它由多个 SMP 服务器通过一定的节点互联网络进行连接,协同工作,完成相同的任务,从用户的角度来看是一个服务器系统。其基本特征是由多个 SMP 服务器 ( 每个 SMP 服务器称节点 ) 通过节点互联网络连接而成,每个节点只访问自己的本地资源 ( 内存、存储等 ) ,是一种完全无共享 (Share Nothing) 结构,因而扩展能力最好,理论上其扩展无限制,目前的技术可实现 512 个节点互联,数千个 CPU 。目前业界对节点互联网络暂无标准,如 NCR 的 Bynet , IBM 的 SPSwitch ,它们都采用了不同的内部实现机制。但节点互联网仅供 MPP 服务器内部使用,对用户而言是透明的。 在 MPP 系统中,每个 SMP 节点也可以运行自己的操作系统、数据库等。但和 NUMA 不同的是,它不存在远程内存访问的问题。换言之,每个节点内的 CPU 不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的,这个过程一般称为数据重分配 (Data Redistribution) 。 但是 MPP 服务器需要一种复杂的机制来调度和平衡各个节点的负载和并行处理过程。目前一些基于 MPP 技术的服务器往往通过系统级软件 ( 如数据库 ) 来屏蔽这种复杂性。举例来说, NCR 的 Teradata 就是基于 MPP 技术的一个关系数据库软件,基于此数据库来开发应用时,不管后台服务器由多少个节点组成,开发人员所面对的都是同一个数据库系统,而不需要考虑如何调度其中某几个节点的负载。 NUMA 与 MPP 的区别从架构来看, NUMA 与 MPP 具有许多相似之处:它们都由多个节点组成,每个节点都具有自己的 CPU 、内存、 I/O ,节点之间都可以通过节点互联机制进行信息交互。那么它们的区别在哪里?通过分析下面 NUMA 和 MPP 服务器的内部架构和工作原理不难发现其差异所在。 首先是节点互联机制不同, NUMA 的节点互联机制是在同一个物理服务器内部实现的,当某个 CPU 需要进行远程内存访问时,它必须等待,这也是 NUMA 服务器无法实现 CPU 增加时性能线性扩展的主要原因。而 MPP 的节点互联机制是在不同的 SMP 服务器外部通 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 过 I/O 实现的,每个节点只访问本地内存和存储,节点之间的信息交互与节点本身的处理是并行进行的。因此 MPP 在增加节点时性能基本上可以实现线性扩展。 其次是内存访问机制不同。在 NUMA 服务器内部,任何一个 CPU 可以访问整个系统的内存,但远程访问的性能远远低于本地内存访问,因此在开发应用程序时应该尽量避免远程内存访问。在 MPP 服务器中,每个节点只访问本地内存,不存在远程内存访问的问题。 哪种服务器更加适应数据仓库环境?这需要从数据仓库环境本身的负载特征入手。众所周知,典型的数据仓库环境具有大量复杂的数据处理和综合分析,要求系统具有很高的 I/O 处理能力,并且存储系统需要提供足够的 I/O 带宽与之匹配。而一个典型的 OLTP 系统则以联机事务处理为主,每个交易所涉及的数据不多,要求系统具有很高的事务处理能力,能够在单位时间里处理尽量多的交易。显然这两种应用环境的负载特征完全不同。 从 NUMA 架构来看,它可以在一个物理服务器内集成许多 CPU ,使系统具有较高的事务处理能力,由于远程内存访问时延远长于本地内存访问,因此需要尽量减少不同 CPU 模块之间的数据交互。显然, NUMA 架构更适用于 OLTP 事务处理环境,当用于数据仓库环境时,由于大量复杂的数据处理,必然导致大量的数据交互,将使 CPU 的利用率大大降低。 相对而言, MPP 服务器架构的并行处理能力更优越,更适合于复杂的数据综合分析与处理环境。当然,它需要借助于支持 MPP 技术的关系数据库系统来屏蔽节点之间负载平衡与调度的复杂性。另外,这种并行处理能力也与节点互联网络有很大的关系。显然,适应于数据仓库环境的 MPP 服务器,其节点互联网络的 I/O 性能应该非常突出,才能充分发挥整个系统的性能。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 11.3.2 列数据库 列式数据库是以列相关存储架构进行数据存储的数据库,主要适合与批量数据处理和即席查询。相对应的是行式数据库,数据以行相关的存储体系架构进行空间分配,主要适合与小批量的数据处理,常用于联机事务型数据处理。而列数据库具备如下特征: 高效的储存空间利用率 传统的行式数据库由于每个列的长度不一,为了预防更新的时候不至于出现一行数据跳到另一个block 上去, 所以往往会预留一些空间。而面向列的数据库由于一开始就完全为分析而存在,不需要考虑少量的更新问题,所以数据完全是密集储存的。列式数据库由于其针对不同列的数据特征而发明的不同算法使其往往有比行式数据库高的多的压缩率,普通的行式数据库一般压缩率在3:1 到5:1 左右,而列式数据库的压缩率一般在8:1到30:1 左右。(InfoBright 在特别应用可以达到40:1 , Vertica 在特别应用可以达到60:1 , 一般是这么高的压缩率都是网络流量相关的)   列式数据库由于其特殊的IO 模型所以其数据执行引擎一般不需要索引来完成大量的数据过滤任务(Sybase IQ 除外) 。这又额外的减少了数据储存的空间消耗。   列式数据库不需要物化视图,行式数据库为了减少IO 一般会有两种物化视图,常用列的不聚合物化视图和聚合的物化视图。列式数据库本身列是分散储存所以不需要第一种,而由于其他特性使其极为适合做普通聚合操作。(另外一种物化视图是不能实时刷新的,比如排名函数,不规则连接connect by 等等,这部分列数据库不包括。) 数据迭代 (Tuple Iteration)   现在的多核CPU 提供的L2 缓存在短时间执行同一个函数很多次的时候能更好的利用CPU 的二级缓存和多核并发的特性。而行式数据库由于其数据混在一起没法对一个数组进行同一个简单函数的调用,所以其执行效率没有列式数据库高。 压缩算法   列式数据库由于其每一列都是分开储存的。所以很容易针对每一列的特征运用不同的压缩算法。常见的列式数据库压缩算法有Run Length Encoding , Data Dictionary , Delta Compression , BitMap Index , LZO , Null Compression 等等。根据不同的特征进行的压缩效率从10W:1 到10:1 不等。而且数据越大其压缩效率的提升越为明显。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 迟物化 列式数据库由于其特殊的执行引擎,在数据中间过程运算的时候一般不需要解压数据而是以指针代替运算,直到最后需要输出完整的数据时 在整个计算过程中, 无论过滤,投影,连接,聚合操作,列式数据库都不解压数据直到最后数据才还原原始数据值。这样做的好处有减少CPU 消耗,减少内存消耗,减少网络传输消耗,减少最后储存的需要。 总而言之,列式数据库优点: § 极高的装载速度 (最高可以等于所有硬盘IO 的总和,基本是极限了) § 适合大量的数据而不是小数据 § 实时加载数据仅限于增加(删除和更新需要解压缩Block 然后计算然后重新压缩储存) § 高效的压缩率,不仅节省储存空间也节省计算内存和CPU。 § 非常适合做聚合操作。 而列数据不适合下列场景: § 不适合扫描小量数据 § 不适合随机的更新 § 批量更新情况各异,有的优化的比较好的列式数据库(比如Vertica)表现比较好,有些没有针对更新的数据库表现比较差。 § 不适合做含有删除和更新的实时操作。 11.3.3 内存数据库http://hemeicun.blog.163.com/blog/static/11157304820113645525209/ MDB 在数据库技术中,目前主要有两种方法来使用大量的内存。一种是在传统的数据库中,增大缓冲池,将一个事务所涉及的数据都放在缓冲池中,组织成相应的数据结构来进行查询和更新处理,也就是常说的共享内存技术,这种方法优化的主要目标是最小化磁盘访问。另一种就是内存数据库(MMDB:Main Memory Database,也叫主存数据库)技术,就是干脆重新设计一种数据库管理系统,对查询处理、并发控制与恢复的算法和数据结构进行重新 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 设计,以更有效地使用CPU周期和内存,这种技术近乎把整个数据库放进内存中,因而会产生一些根本性的变化。两种技术的区别如下表:    内存数据库系统带来的优越性能不仅仅在于对内存读写比对磁盘读写快上,更重要的是,从根本上抛弃了磁盘数据管理的许多传统方式,基于全部数据都在内存中 管理进行了新的体系结构的设计,并且在数据缓存、快速算法、并行操作方面也进行了相应的改进,从而使数据处理速度一般比传统数据库的数据处理速度快很多, 一般都在10倍以上,理想情况甚至可以达到1000倍。    常用的内存数据库包括; § SQLite:是一个小型的C程序库,实现了独立的,可嵌入的,零配置的SQL数据库引擎。比较适合网站和嵌入式设备 § Altibase:提供极限性能、容错能力和事务管理的方便性,适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。 §  Oracle Berkeley DB:是Oracle 收购了开源数据库厂商后推出的产品,其前身是Berkeley DB。它有开源版本,但且对于开源软件免费。商业版本是要付费。 § Oracle TimesTen:Oracle 内存数据库 TimesTen 是一个针对内存进行了优化的关系数据库,它为应用程序提供了当今实时企业和行业(如电信、资本市场和国防)所需的即时响应性和非常高的吞吐量。 § eXtremeDB内存式实时数据库是为实时系统及嵌入式系统而特别设计的数据库。与同类产品不同,eXtremeDB不是通过 对企业数据库面向实时嵌入式应用进行剪裁而来;而是总结了30年来McObject公司在编译器、实时编程、数据管理、内核级驱 动软件等领域的经验,面向实时嵌入式应用从头开发的最新实时数据管理技术。 11.3.4 分布式文件系统 分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连。分布式文件系统的设计基 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外,对等特性允许一些系统扮演客户机和服务器的双重角色。例如,用户可以“发表”一个允许其他客户机访问的目录,一旦被访问,这个目录对客户机来说就象使用本地驱动器一样,下面是三个基本的分布式文件系统。 比较著名的分布式文件系统包括: § 谷歌的GoogleFS,是一个可扩展的分布式文件系统,用于大型的、分布式的、对海量数据进行访问的应用。 § Hadoop 分布式文件系统 (HDFS) 是运行在通用硬件上的分布式文件系统。HDFS 提供了一个高度容错性和高吞吐量的海量数据存储解决方案。HDFS 已经在各种大型在线服务和大型存储系统中得到广泛应用,已经成为各大网站等在线服务公司的海量存储事实标准,多年来为网站客户提供了可靠高效的服务。HDFS 可以提供以下特性: n 可自我修复的分布式文件存储系统 n 高可扩展性,无需停机动态扩容 n 高可靠性,数据自动检测和复制 n 高吞吐量访问,消除访问瓶颈 n 使用低成本存储和服务器构建 11.4 数据应用 11.4.1 报表技术 水晶报表(Crystal Report) 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Crystal Reports(水晶报表)是一款商务智能(BI)软件,主要用于设计及产生报表。水晶报表是业内最专业、功能最强的报表系统,它除了强大的报表功能外,最大的优势是实现了与绝大多数流行开发工具的集成和接口。 最开始的开发公司名为Crystal Services Inc.,最初的软件的名称为Quik Reports,开发版本从1.0到3.0。1996年被Seagate Technology公司收购,集成在Crystal Decisions软件中。Crystal Decisions于2003年被Business Objects公司收购,开发了版本10与11(Crystal reports XI系列).2007年10月8日,Business Objects公司被SAP公司收购. 水晶报表程序控制上有两种模式,也就是传说中的PULL模式和PUSH模式。口语化点就是拉模式和推模式。拉(PULL)模式 由水晶报表模板(引擎)直接连接数据库(源),从数据库(源)里拉取数据就是我们在水晶报表里设置好数据库信息,以及相关的表。当我们在程序中调用水晶报表引擎,挂载模板后,水晶报表引擎会根据模板里的数据库信息,及表信息主动连接数据库,返回数据给报表模板,模板根据设计样式进行呈现。推(PUSH)模式 由应用程序从数据库(源)获取数据,然后把数据推送给水晶报表引擎。水晶报表本身不不跟数据库进行交互。 使用PUSH模式将会比PULL模式多了不少代码。 而且因为PULL模式是直连数据库,比PUSH模式先获取数据结果,然后推送给水晶报表少了一个过程。而中间结果集本身就占用系统资源。所以PULL模式比PUSH执行效率高。 而PUSH的优势。 1:可以公用系统数据库连接,减少数据库连接损耗; 2:可自由组合多数据源(如多数据库等),这一点PULL模式也可以实现,但是不如这个方便 3:灵活多变,灵活多变的说法,是因为由于我们是把数据获取后,再PUSH给水晶报表的,那么在这个中间,就有很多数据再加工的可能性。无论是PULL还是PUSH模式,数据源处理部分只负责把数据传给报表,至于怎么呈现是报表里去做的。 OLAP OLAP(Online Analytical Processing)联机分析处理,指的是对存储在数据库或数据仓库中的数据提供分析的一种软件技术。OLAP 工具能快速提供复杂数据库查询的答案,并帮助用户分析多维数据中的各维情况。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 联机分析处理的主要特点,是直接仿照用户的多角度思考模式,预先为用户组建多维的数据模型,在这里,维指的是用户的分析角度。例如对销售数据的分析,时间周期是一个维度,产品类别、分销渠道、地理分布、客户群类也分别是一个维度。一旦多维数据模型建立完成,用户可以快速地从各个分析角度获取数据,也能动态的在各个角度之间切换或者进行多角度综合分析,具有极大的分析灵活性。这也是联机分析处理被广泛关注的根本原因,它从设计理念和真正实现上都与旧有的管理信息系统有着本质的区别。 OLAP的基本多维分析操作有钻取(Drill-up和Drill-down)、切片(Slice)和切块(Dice)、以及旋转(Pivot)等。 Ø 钻取:是改变维的层次,变换分析的粒度。它包括向下钻取(Drill-down)和向上钻取(Drill-up)/上卷(Roll-up)。Drill-up是在某一维上将低层次的细节数据概括到高层次的汇总数据,或者减少维数;而Drill-down则相反,它从汇总数据深入到细节数据进行观察或增加新维。 Ø 切片和切块:是在一部分维上选定值后,关心度量数据在剩余维上的分布。如果剩余的维只有两个,则是切片;如果有三个或以上,则是切块。 Ø 旋转:是变换维的方向,即在表格中重新安排维的放置(例如行列互换)。 OLAP 具有三种类型: Ø 多维 OLAP(MOLAP) ― MOLAP 是 OLAP 中较为“流行”的一种。它使用摘要型数据库,具有一个专用数据库引擎,并且按照需求创建包含基本数据和数据集合的多纬度模式。MOLAP 在小型数据设置方面占有一定优势,集合计算和返回答案的速度都比较快,但同时也能快速创建海量数据。 Ø 关系 OLAP(ROLAP) ― ROLAP 与关系数据库直接相关,基本数据和纬度表代表关系表,此外创建一个包含数据集合信息的新表。ROLAP 是较 MOLAP 更为高级的一种类型,优点是占有空间小,但其预处理和查询性能也是最低的。 Ø 混合 OLAP(HOLAP) ― 混合 OLAP 使用关系表表示基本数据和纬度表。在所有领域中 HOLAP 介于 MOLAP 和 ROLAP 之间,但它能提供快速预处理和良好的衡量。 常用的OLAP软件包括Hyperion等; 图表展现工具 数据一般的呈现方式为二维表格,但是图形有时候具备更加直观的展现方式,一般通用报表工具都包含如下图标展现方式: Ø 仪表盘 Ø 条形图/直方图 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 Ø 饼图 Ø 折线图 Ø 散点图 Ø 区域图 Ø 其他 不同的图表展现适合不同的业务需求,譬如饼图适合展现百分比相关,散点图适合查看聚类模式; 数据量也影响图标的展现;譬如,如果要展示一个月的对比数据,一般就不适合用条状图,而适合用折线图;进一步的交互需要,可能还涉及到使用Java应用定制报表. 11.4.2 数据挖掘算法库 SPSS和一个从事数据挖掘研究的全球性企业联盟制定了关于数据挖掘技术的行业标准--CRISP-DM (Cross-Industry Standard Process for Data Mining)。与以往仅仅局限在技术层面上的数据挖掘方法论不同,CRISP-DM把数据挖掘看作一个商业过程,并将其具体的商业目标映射为数据挖掘目标。最近一次调查显示,50%以上的数据挖掘工具采用的都是CRISP-DM的数据挖掘流程,它已经成为事实上的行业标准。 不同的算法适应于不同的业务,而且同一种业务,不同的业务人员可能使用不同算法来实现;利用数据挖掘进行数据分析常用的方法主要有分类、回归分析、聚类、关联规则、特征、变化和偏差分析、Web页挖掘等, 它们分别从不同的角度对数据进行挖掘。   ①分类。分类是找出数据库中一组数据对象的共同特点并按照分类模式将其划分为不同的类,其目的是通过分类模型,将数据库中的数据项映射到某个给定的类别。它可以应用到客户的分类、客户的属性和特征分析、客户满意度分析、客户的购买趋势预测等,如一个汽车零售商将客户按照对汽车的喜好划分成不同的类,这样营销人员就可以将新型汽车的广告手册直接邮寄到有这种喜好的客户手中,从而大大增加了商业机会。   ②回归分析。回归分析方法反映的是事务数据库中属性值在时间上的特征,产生一个将数据项映射到一个实值预测变量的函数,发现变量或属性间的依赖关系,其主要研究问题包括数据序列的趋势特征、数据序列的预测以及数据间的相关关系等。它可以应用 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 到市场营销的各个方面,如客户寻求、保持和预防客户流失活动、产品生命周期分析、销售趋势预测及有针对性的促销活动等。   ③聚类。聚类分析是把一组数据按照相似性和差异性分为几个类别,其目的是使得属于同一类别的数据间的相似性尽可能大,不同类别中的数据间的相似性尽可能小。它可以应用到客户群体的分类、客户背景分析、客户购买趋势预测、市场的细分等。   ④关联规则。关联规则是描述数据库中数据项之间所存在的关系的规则,即根据一个事务中某些项的出现可导出另一些项在同一事务中也出现,即隐藏在数据间的关联或相互关系。在客户关系管理中,通过对企业的客户数据库里的大量数据进行挖掘,可以从大量的记录中发现有趣的关联关系,找出影响市场营销效果的关键因素,为产品定位、定价与定制客户群,客户寻求、细分与保持,市场营销与推销,营销风险评估和诈骗预测等决策支持提供参考依据。   ⑤特征。特征分析是从数据库中的一组数据中提取出关于这些数据的特征式,这些特征式表达了该数据集的总体特征。如营销人员通过对客户流失因素的特征提取,可以得到导致客户流失的一系列原因和主要特征,利用这些特征可以有效地预防客户的流失。   ⑥变化和偏差分析。偏差包括很大一类潜在有趣的知识,如分类中的反常实例,模式的例外,观察结果对期望的偏差等,其目的是寻找观察结果与参照量之间有意义的差别。在企业危机管理及其预警中,管理者更感兴趣的是那些意外规则。意外规则的挖掘可以应用到各种异常信息的发现、分析、识别、评价和预警等方面。   ⑦Web页挖掘。随着Internet的迅速发展及Web 的全球普及, 使得Web上的信息量无比丰富,通过对Web的挖掘,可以利用Web 的海量数据进行分析,收集政治、经济、政策、科技、金融、各种市场、竞争对手、供求信息、客户等有关的信息,集中精力分析和处理那些对企业有重大或潜在重大影响的外部环境信息和内部经营信息,并根据分析结果找出企业管理过程中出现的各种问题和可能引起危机的先兆,对这些信息进行分析和处理,以便识别、分析、评价和管理危机。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 11.4.3 即席查询(ad hoc) Ad hoc是拉丁文常用短语中的一个短语。这个短语的意思是“特设的、特定目的的(地)、即席的、临时的、将就的、专案的”。这个短语通常用来形容一些特殊的、不能用于其它方面的的,为一个特定的问题、任务而专门设定的解决方案。 在经营分析领域,即席查询(Ad Hoc)是用户根据自己的需求,灵活的选择查询条件,系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的,而即席查询是由用户自定义查询条件的。即席查询生成的方式很多,最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是,将数据仓库中的维度表和事实表映射到语义层,用户可以通过语义层选择表,建立表间的关联,最终生成SQL语句。 即席查询与通常查询从SQL语句上来说,并没有本质的差别。 在某种层面上,主要是数据可以支撑灵活的查询; 11.4.4 数据探索 探索数据是对数据进行初步研究,以便更好的理解它的特殊性质,有助于选择合适的数据预处理和数据分析技术。一般而言,数据探索属于数据挖掘的前期工作;强调的是数据本身的研究;而数据探索工具一般是为了更好的让业务人员来探索数据,主要强调数据的可视化,和交互友好型; 在具体业务领域的数据探索过程中,往往存在某种通用的模式或者套路,这需要将各个业务人员的知识沉淀,并进行结构化存储,使得分析人员在每一步时能够获取对应的建议和指导;分层设计原则 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 12 系统接口(中软) 12.1 接口要求 l 保证在指定的时间范围内生成接口规范规定的数据内容并上传至指定地方(接口表、文件、消息) l 源数据提供方提供的数据需要具备时间戳数据。 l 保证接口文件中的记录各值域在有效的取值范围内,汉字编码为GBK,数据中均不能包含0x0D0A(回车换行符)和0x05字符,确保数据的有效性和准确性; l 源系统负责数据的业务逻辑一致性控制,保证不将逻辑错误的数据提供给EDA系统 。 l 遵循接口规范中规定的校验规则和异常处理规则,保证提供数据质量,确保数据的准确性、一致性、完整性; l 根据EDA系统提供的报告信息,及时处理异常情况; l 对于本规范中未尽事宜,源数据提供方应协助数据接收方协商解决相关问题; 12.2 接口归类 主要规定下列类型数据接口的传输频度、传输方式、数据结构、校验数据文件格式、文件名规范等。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 12.2.1 增量数据接口 对于小数据量、实时性要求很高的源数据采用增量数据实现。整体数据合并和稽核可以通过时间戳来保障数据完整性,这类型数据适合采用增量数据接口。 12.2.1.1 小时级数据接口 源系统按照接口规范每小时传送一份数据给EDA系统,传送的数据需要具备时间戳,方便EDA系统进行数据入库整合。 类似下面这些数据就可以采用 1、crm竣工工单数据 2、 计费话单数据 3、三户资料 12.2.1.2 日增量数据接口 源系统按照接口规范将每天增量产生的数据送给EDA系统,传送的数据需要具备时间戳,方便EDA系统进行数据入库整合。 类似下面这些数据就可以采用 1、 障碍投诉类清单 2、欠费数据 3、 缴费、充值数据 4、流量清单数据 12.2.1.3 月增量数据接口 源系统按照接口规范将每月增量产生的数据送给EDA系统,传送的数据需要具备时间戳,方便EDA系统进行数据入库整合。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 类似下面这些数据就可以采用: 1、计费账单数据 12.2.2 全量数据接口 由于业务规则限制或者特殊需求造成,不能通过时间戳实现数据整合,这类型数据需要通过月全量数据接口和日全量数据接口来进行数据传送。 12.2.2.1 日数据接口 源系统按照接口规范将每日全量产生的数据送给EDA系统 类似下面这些数据就可以采用: 1、规格类数据 12.2.2.2 月数据接口 源系统按照接口规范将每月全量产生的数据送给EDA系统。 类似下面这些数据就可以采用: 1、 月用户资料数据 2、 月客户资料数据 3、 月账户数据 4、 月销售品实例 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 12.3 接口技术 12.3.1 接口方式 12.3.1.1 数据文件方式 接口文件设计要求 EDA系统与源系统的数据交换采用文本文件方式,文件格式采用ASCII码格式。在形成所传输的ASCII格式文件之前,将数据转成本接口规范所规定的数据类型和格式。接口文件均按规范要求的数据内容,每行数据以回车换行符0x0D0A结束(抽取的数据内容中不能包含此符号)。 接口信息交互机制 Ø 每个数据文件都有一个对应的校验文件,跟对应的数据文件同步提供。 Ø 源数据提供方在完成数据文件的提供后,需要提供一个该接口的CHECK文件。 Ø 数据接收方对每个数据文件的处理结果将反馈一个校验报告文件,包括对CHECK文件的校验。 接口文件操作规定 Ø 源数据提供方所生成的数据过程文件、检验过程文件和CHECK过程文件,要以“~”字符开头,以“.TMP”字符串结尾。 Ø 源数据提供方要对DAT数据文件进行压缩,压缩算法统一采用gzip算法。 Ø 各字段之间以0x05做为分隔符,记录之间以回车换行符0x0D0A分隔(最后一行也以回车换行符0x0D0A结束)。 文件的分类及命名 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 接口文件按抽取频率分为小时、天、月。 命名规则:接口单元名称.文件传送时间(小时、日、月).数据时间(小时、日、月).重传次数.文件名后缀 Ø 接口单元名称 接口单元编码是每一个接口单元的唯一标识。 Ø 文件传送时间 格式是yyyyMMdd。 Ø 数据日期 数据日期是描述当前抽取周期中,数据的发生日期(如:20120515,则表示抽取的是2012年05月15日的数据快照)。 按日抽取的数据文件,其数据日期就是数据的发生日期。 按月抽取的数据文件,则数据日期取数据发生的年月(如:201205)。 根据传送频率不一样,主要有yyyyMMddHH, yyyyMMdd ,yyyyMM三种格式 Ø 重传次数 表示源数据提供方对某一接口的某一数据日期的数据重传次数。 00-99:00表示初次正常上传;01表示第1次重传,02表示第2次重传,…,N表示第N次重传。如果数据接收方在未处理完上次数据重传的情况下,源数据提供方不允许进行下次数据重传处理。 Ø 文件名后缀 “DAT”字符串(过程文件使用“TMP”字符串)。 校验文件格式及命名 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 该文件由源数据提供方负责提供,文件命名规则跟对应的数据文件命名规则保持一致,文件名后缀字符串为“VAL”。该文件用于描述每一个传输周期内每个接口单元的每个数据文件需要校验的信息和数据处理接收方进行登记的信息,字段之间以0x05做为分隔符,文件信息由以下内容组成: 序号 信息内容 数据类型及长度 说明 1 接口数据文件名称 Varchar 2 文件的大小(字节数) Number 文件的物理存储大小 3 文件中包含的记录数 Number 4 数据日期 Varchar 日期格式:YYYYMMDD,如果抽取周期为月,则格式为:YYYYMM 5 接口数据文件的生成时间 Char 日期格式: YYYYMMDDHH24MMSS 6 0xOD0A 回车换行符 CHECK文件格式及命名 该文件由源数据提供方负责提供,该文件命名规则中没有文件批次和批次流水号的概念,均默认成“000”字符串,其它规则跟对应的数据文件命名规则保持一致,文件名后缀字符串为“CHECK”。该文件的内容用于描述该接口在本次操作的动作内所传送的文件列表,文件信息由以下内容组成: 序号 信息内容 数据类型及长度 说明 1 待核查的接口数据文件名称 Varchar 2 0x0D0A 回车换行符 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 回执文件格式及命名 该文件由数据处理接收方提供,通过传输通道传送到省份前置机。 1) VAL文件校验:如果根据检验文件对数据文件进行校验时,所生成的回执文件名跟对应的数据文件名一致: 命名规则:接口单元名称.文件传送时间.数据时间.重传次数.文件名后缀 如校验成功,校验报告文件名的后缀为“RPT”,否则为“ERR”。 校验报告文件的字段分隔符为0x05,文件内容如下: 序号 文件信息内容 数据类型及长度 说明 1 接口数据文件名称 Varchar 2 处理时间 Char(14) 日期格式:YYYYMMDDHH24MISS 3 校验结果代码 Char(2) 00:校验成功 01:接口文件名与规则不符 02:接口数据文件不存在 03:接口数据文件无法打开 04:文件大小不符 05:文件记录数不符 06:文件数据日期不符 07:校验文件记录非法结束符(非换行) 08:校验文件数据日期非法 09:校验文件无法打开 10:校验文件不存在 11:一个VAL文件对应多个DAT文件 12:重传号不连续 13:一个DAT文件对应多个VAL文件 14:上一次重传号对应的相关数据文件未处理完成,不允许重传 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 4 0x0D0A 回车换行符 2) CHECK文件校验:如果根据CHECK文件核查接口文件列表处理的情况时,所生成的报告文件名跟对应的CHECK文件名一致: 命名规则:CHECK文件名(包括后缀字符串“CHECK”). 文件名后缀 如果待核查的接口数据文件名称列表全部核查成功,校验报告文件名的后缀为“RPT”,否则为“ERR”。 校验报告文件的字段分隔符为0x05,文件内容信息跟CHECK文件内容一致,文件内容如下: 序号 信息内容 数据类型及长度 说明 1 待核查的接口数据文件名称 Varchar 校验结果代码为“99”时,该字段信息为CHECK文件名称 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 2 核查结果代码 Char(2) 00:核查成功 01:接口数据文件通过VAL校验文件校验未成功 02:接口数据文件不存在 03:CHECK文件格式错误 04:CHECK文件无法打开 05:CHECK文件列表中无此数据文件 06:CHECK文件重传号不连续 07:CHECK文件中数据文件通过VAL文件的校验,但数据加载失败 08:上一次重传号对应的相关数据文件未处理完成,不允许重传 09:CHECK文件重传号错误 10:重传号不连续 11:待核查的接口数据文件名称为非DAT文件 99:数据接口在规定时间内无CHECK文件 3 0x0D0A 回车换行符 注:如果数据处理接收方在接口所规定的时间内未收到CHECK文件,那么数据处理接收方需要发出提醒报告,报告文件的校验结果代码为“99”,报告文件命名方式跟CHECK文件命名规则一致 12.3.1.2 数据消息方式 频率高,数据量小的数据采用这种方式传送。主要通过webservice、http请求传递数据。 主要有以下几种接口 ² 告警短信接口 ² 告警邮件接口 ² 监控日报告警接口 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 ² 增量和少量数据接口 12.3.2 接口原则 Ø 开放性原则: 接口的设计应符合开放系统互联标准和协议,方便系统间的互联。 Ø 可靠性原则: 接口应保证所有的数据传送可靠,能够对交互的过程和状态进行监控,支持交互失败时的恢复。 Ø 安全性原则: 接口连接必须具有多级别的安全控制机制,同外部系统连接或广域网连接时应通过有安全控制的网关设备或防火墙进行连接,不允许直接联网。 Ø 灵活性原则: 接口应该能够方便的与各业务系统交换数据,当数据量增加或外围系统发生改变时,能够平滑地进行扩充,包括处理能力、处理节点、业务功能的扩充。 Ø 规范性原则: 接口的数据交换格式要明确一致,符合通用标准,方便利用成熟的技术进行处理。 Ø 有效性原则: 接口的交换数据要既要保证数据质量,避免在后续的处理中引入数据失真,又要保证数据时效,及时传送数据,避免引起处理延迟。 Ø 稳定性原则: 接口的定义应保持稳定,生产系统的变动应尽量避免改变其提供给交互系统的数据格式。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 13 EDA与生产系统及运维要求(中软) 本章主要对EDA与各生产系统之间数据流程、数据交互接口的要求进行详细说明。 EDA与生产系统的交互原则上在ODS系统中完成,ODS作为准实时整合数据共享平台,可以简化系统间的数据接口。目前采用数据交互方式包括: l 批量数据交互方式:可以通过接口表、文件传输、高级数据复制等方式。 l 准实时性数据交互方式:生产系统在进行业务处理交易时,可以通过EAI方式把数据同时发送到ODS,以便ODS可以同步更新数据。 13.1 EDA对生产系统的数据提取要求 对生产系统数据的采集必须能够充分满足ODS/EDW系统的需要,又能保证不对业务系统的性能造成较大的影响,所以EDA数据获取和加载过程,兼顾实时性和大批量数据加载需要。进行数据采集时应制定相应的策略,包括采集模式、采集时机、采集周期、技术方式、稽核方式等内容。 l 采集模式:增量采集、全量采集等; l 采集时机:尽可能避开业务系统的高峰时段,可选择在业务系统闲时进行; l 采集周期:对不同类型的数据源,应综合考虑业务需求和系统代价,制定合理的采集周期; l 技术方式:接口表、文件传输、高级数据复制; l 稽核方式:生产系统对EDA提供数据的同时,也必须提供数据稽核方式和口径,并确定异常处理流程,确保所提供源数据的及时、安全、准确、可靠。 生产系统为EDA提供数据,必须通过技术的手段固化流程,提升监控质量。为达到EDA取数要求,需要尽可能采用技术手段减少出错的环节和机率、提高数据处理和报送能力。要求在生产系统中,通过技术手段实现以下要求: 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 接口监控、通报和反馈 数据接口的稳定性是EDA及时准确获取源数据的关键。但是由于生产系统等源系统或者传输通道可能存在这样或那样的问题,错误的接口数据发现的越晚,重新处理的时间就越长,因此需要对接口进行监控,及时发现问题,及时应对,快速解决问题。除了要建立一整套接口管理机制外,要通过技术的手段对接口数据从监控、通报到反馈的流程固化,尽可能早地发现接口问题并及时解决问题。 数据加工过程监控 数据加工是个复杂的过程。主机性能、代码错误、规则调整、主数据变更、编码变更等均可能造成数据加工失败,为了减少重复计算带来的实时性影响,需要生产系统对数据加工过程进行监控。尽可能将检查和校验规则程序化,减少手工操作,减少数据处理环节的时间,为数据的及时性提供保障。 生产系统注意事项 1)接口变更 任何涉及到接口方式或接口内容发生改变的调整,都应事先通知EDA主管部门,确认后再做调整,并预先制定应对措施。 2)数据传输异常 数据传输的异常情况包括如下类型: l 数据没有在规定的时间范围内传输完毕; l 传输的数据不完整。 发生异常时数据提供方应及时采取相关应对措施加以处理。 数据采集时限要求(建议) 内容分类 采集的生产系统 采集时机 建议采集方式 采集周期 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 客户类信息(客户资料、订单、产品等) CRM系统 近实时 增量 接口表方式 小时 账单类信息(账单、账单明细等) 计费系统 每月4日12:00前 增量 接口表/高级复制 月 帐务类信息(销帐、欠费等) 计费系统 每天1:00 增量 接口表方式 天 详单类信息(通话详单、增值业务详单、结算详单等) 计费系统、结算系统、ISMP平台等 近实时 增量文件方式 小时 资源类信息(资源、开通等) OSS平台 每天1:00 增量,接口表方式 天 13.2 生产系统对EDA的数据响应要求 EDA提供给生产系统的数据包括: l 统一客户视图 l 积分数据 l 信用度数据 l 代理商佣金计算数据 l 其他共享数据 在接口数据的构建问题上,应遵循以下原则: l 完整性 接口定义和方式应考虑全面完整; l 统一性 接口应有统一的管理规范及要求; 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 l 便利性 接口设计应尽可能贴近生产系统,方便业务系统的数据生成工作,减轻其压力;同时对已有的各种可获得数据应尽可能支持; l 扩展性 接口设计应充分考虑系统及业务的发展,对各种粒度的接口数据应有良好的兼容性。 l 高效性 接口数据应能快速地实现导入、导出操作。 13.3 EDA运维要求 13.3.1 运行维护准则 13.3.1.1 安全性 网络安全:严格隔离用户访问层、展现层之间,及其与内部各层的直接网络访问,对外网访问信息进行安全过滤。应设定多种访问规则限制,能对常见的入侵行为进行检测并阻止。可考虑采用双层异构防火墙。 系统安全:对于关键服务器的系统本身和运行于其上的应用,应给予专门的保护,防止未授权用户的非法访问。应用系统的用户管理、权限管理应充分利用操作系统和数据库的安全性。 防病毒与安全策略:提供有效的手段,对在网络中传输的数据进行实时的监视,对各种类型的文件皆可进行病毒的查杀工作。考虑完整的安全策略,实现集中的管理、修订、发布和统一实施。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 13.3.1.2 可用性 各层网络设备、主机和存储设备必须冗余配置,包括设备级、板卡级和链路级的冗余。 充分利用设备failover机制保证故障点的隔离和恢复,要求采用Active集群模式,降低系统切换时间和提高设备利用率。 关键数据应保持适当的备份频率,统筹规划数据级或应用级容灾部署。 通过监控系统实时管控系统运营状况,及早发现或预测故障隐患。 13.3.1.3 高效性 通过设备层面或应用层面技术实现负载分担,提升系统响应速度和设备利用率。 充分利用中间件集群、数据库集群、数据库分库分区、Cache、内存数据库等技术优化系统处理性能。 前后端应用和设备部署适当分离,缓解前台快速响应和后台密集处理之间的矛盾。 13.3.1.4 伸缩性 本系统可以通过运行更多的实例或者采用分布式处理来支持更多的用户。可以通过线性的增加硬件设备、实例个数或者分布式处理点来处理更多的数据量,能更好地在不增加响应时间的前提下支持更多的业务处理。 通过纵向扩展(增加单节点的处理资源,如CPU和内存)和横向扩展(增加处理节点)扩展处理性能。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 13.3.1.5 规划性 规模适配:依据用户规模及设备负载情况,选择适合的部署模式,考虑3年内部署架构的相对稳定性。 投资保护:应用主机和存储虚拟化、多节点集群等技术整合现有设备,提高设备利用率和使用生命周期。 灵活应用:依据实际情况,包括运维模式、现网设备和机房环境等综合评估,确定部署模式。 13.3.2 网络设备运行维护 网络的运行维护管理是网络管理的一项经常性的工作,网络的运行维护管理包括通信维护管理(交换机、路由器、光纤、双绞线),应用维护管理(服务器、网络安全设施,操作系统及应用系统)及用户维护管理(用户的权限,用户的咨询及用户的培训)等部分,为了做好网络运行维护管理工作,特制定本制度。 1. 根据网络的使用情况及时检测、调整网络通信设施的状态参数,力求使网络通信设施处于最佳运行状况。 2. 对于网络通信设施的一般性调整(局部性),由网络通信设施管理人员自行实施,在调试完毕后,务必保存现行的运行配置,并在值班日志上做纪录。 3. 对于网络通信设施的重大调整,必须报分管技术的主任,并经分管主任协调审定后方可实施,实施务必保存调整前运行配置及现行的运行配置,并在值班日志上做纪录。 4. 对于改动的运行调整情况,在每周召开的中心会议上通报全体人员及时掌握情况。 5. 以周为单位,建立主值班制度,主值班人员在值班期内负责运行状况的监测、记录,负责完成一般性调整工作,及时向各管理负责人报告值班期内重大事件,请示处理意见,并参与实施。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 6. 运行维护必须检测记录下列情况。DNS、WEB 的运行状况,核心路由器、交换机的带宽占用情况,数据包的协议分类情况、丢包情况,并根据检测情况及时调整网络状况。 7. 详细记录设备的故障情况及故障处理的情况。 8. 及时安排处理用户报修的网络通断问题,保证网络设备及线路的 畅通。 9. 维护管理如果影响到用户的工作,必须事先报告网管中心主任批准并通知用户,再进行调整。在调整过程中尽量将影响范围及时间控制在最少。 13.3.3 数据库及中间件运行维护 13.3.3.1 数据库运行维护 数据库用于用户、客户、账户等所有重要数据,所以,对数据库的维护是系统运维的重中之重。 序号 维护内容 维护内容描述 1 数据库 7*24电话支持服务 每周7天,每天24小时支持中心电话,电子邮件答询,以满足业务发展的需要。 技术专家直接同客户对话,帮助解决客户提出的疑难问题。 根据问题的严重程度,将优先解决客户认为是关键而紧急的任务。 对客户提出的一般性问题进行技术咨询、指导。 定期的客户管理报告, 避免问题再度发生。 2 数据库产品 现场服务响应 数据库宕机 数据坏块 影响业务不能进行的产品问题 软件产品的更新及维护。 3 数据库产品 系统健康检查 对系统的配置及运作框架提出建议,以帮助您得到一个更坚强可靠的运作环境 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 序号 维护内容 维护内容描述 降低系统潜在的风险,包括数据丢失、安全漏洞、系统崩溃、性能降低及资源紧张 检查并分析系统日志及跟踪文件,发现并排除数据库系统错误隐患 检查数据库系统是否需要应用最新的补丁集 检查数据库空间的使用情况 协助进行数据库空间的规划管理 检查数据库备份的完整性 监控数据库性能 确认系统的资源需求 明确您系统的能力及不足 优化数据库服务的表现 通过改善系统环境的稳定性来降低潜在的系统宕机时间 4 数据库产品 性能调优 分析用户的应用类型和用户行为 评价并修改数据库的参数设置 评价并调整数据库的数据分布 评价应用对硬件和系统的使用情况,并提出建议 利用先进的性能调整工具实施数据库的性能调整 培训用户有关性能调整的概念 提供用户完整的性能调整报告和解决方法 13.3.3.2 中间件运行维护 中间件管理是指对商用、免费等中间件的日常维护管理和监控工作,提高对中间件平台事件的分析解决能力,确保中间件平台持续稳定运行。中间件监控指标包括配置信息管理、故障监控、性能监控。 n 执行线程:监控应用服务器配置执行线程的空闲数量。 版权声明,保密 第页 共136页 中国电信EDA 总体规范2.0 n JVM内存:JVM内存曲线正常,能够及时地进行内存空间回收。 n JDBC连接池:连接池的初始容量和最大容量应该设置为相等,并且至少等于执行线程的数量,以避免在运行过程中创建数据库连接所带来的性能消耗。 n 检查应用服务器日志文件是否有异常报错。 13.4 如果有应用服务器集群配置,需要检查集群的配置是否正常。 14 附录 14.1 主要编制人员 14.2 术语解释 14.3 引用标准(规范) 版权声明,保密 第页 共136页

下载文档到电脑,查找使用更方便

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享文档获得金币 ] 1 人已下载

下载文档