中国电信构架高性能的数据仓库-亚信0909.ppt

上传人:laozhun 文档编号:2277909 上传时间:2023-02-08 格式:PPT 页数:28 大小:1.87MB
返回 下载 相关 举报
中国电信构架高性能的数据仓库-亚信0909.ppt_第1页
第1页 / 共28页
中国电信构架高性能的数据仓库-亚信0909.ppt_第2页
第2页 / 共28页
中国电信构架高性能的数据仓库-亚信0909.ppt_第3页
第3页 / 共28页
中国电信构架高性能的数据仓库-亚信0909.ppt_第4页
第4页 / 共28页
中国电信构架高性能的数据仓库-亚信0909.ppt_第5页
第5页 / 共28页
点击查看更多>>
资源描述

《中国电信构架高性能的数据仓库-亚信0909.ppt》由会员分享,可在线阅读,更多相关《中国电信构架高性能的数据仓库-亚信0909.ppt(28页珍藏版)》请在三一办公上搜索。

1、构架高性能的数据仓库,亚信科技(中国)有限公司,演讲人介绍,亚信经营分析产品研发经理冯海文毕业于桂林工学院,学士学位多年电信行业经营分析、计费,营业帐务等支撑系统的开发和设计经验。非常熟悉电信业务,擅长复杂计算及大规模数据处理。有丰富的大规模数据仓库及决策支持系统设计开发经验。,议题,数据仓库系统的架构数据仓库的设计方法性能影响的关键可用性设计,议题,数据仓库系统的架构数据仓库的设计方法性能影响的关键可用性设计,数据仓库,Data warehouse is a subject oriented,integrated,non-volatile and time variant collectio

2、n of data in support of managements decision Inmon,1996面向主题的集成的非易失的时变的支持管理决策的数据集合数据仓库是一个环境,而不是一个产品 数据仓库是一个过程,而不是一个项目,数据仓库 VS 数据库,数据库系统(OLTP)面向应用、事务驱动的实时性高、并发量大检索的表多、使用的数据量小只存当前数据数据仓库系统(OLAP)面向主题、分析和决策实时性要求不高、并发少检索表少,但使用的数据量巨大存储当前数据和历史数据数据库引擎相同配置参数不同建模原则不同,生产系统,营帐,计费,客服,网络,MIS,客户,产品,渠道,业务量,收益,带ODS的体系

3、结构,SourceDatabases,ArchitectedData Marts,Data Accessand Analysis,Central Data Ware-house and ODS,Central DataWarehouse,Mid-Tier,DataMart,Mid-Tier,DataMart,Local Metadata,Local Metadata,Local Metadata,MetadataExchange,ODS,MDB,End-UserDW Tools,OLTP Tools,Hub-Data Extraction,Transformation,load,Extract

4、,Transformand Load,Central,Metadata,数据仓库体系结构大都在此基础上衍生出来的,但具体实现却大相径庭,并且效果迥异!,中国电信EDA的整体架构,中国电信企业数据仓库构成,议题,数据仓库系统的架构数据仓库的设计方法性能影响的关键可用性设计,自顶向下(Top-down Approach),建造企业数据仓库建设中心数据模型一次性的完成数据的重构工作最小化数据冗余度和不一致性存储详细的历史数据从企业数据仓库中建造数据集市得到大部分的集成数据直接依赖于数据仓库的可用性,自底而上(Bottom-up Approach),创建部门的数据集市范围局限于一个主题区域快速的ROI

5、-局部的商业需求得到满足本部门自治-设计上具有灵活性对其他部门数据集市是一个好的指导容易复制到其他部门 需要为每个部门做数据重建有一定级别的冗余和不一致性扩大到企业数据仓库创建EDB作为一个长期的目标,数据仓库建模,第三范式(3NormalForm)非规范化技术星型、雪花模式、宽表固化频繁的大量表连接时间、用户是共享维度用户维表也是非规范化代表 针对应用的支持,加快汇总的响应,第三范式(ER模型),第三范式要求1、每个属性的值唯一,不具有多义性;2、每个非主属性必须完全依赖于整个主键,而非主键的一部分;3、每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。不满

6、足第三范式的举例class(class_id,class_name,teacher_id,teacher_name)规范化后class(class_id,class_name,teacher_id)teacher(teacher_id,teacher_name)总结确定主键和非主键属性的关系关注逻辑层面上的实体和关系,不考虑可用性问题需物化为表后,方可在DW创建、使用,ER模型适用清楚表达业务逻辑关系,但不适合直接落成物理模型!,优点:查询响应快速,既定需求支持良好不足:数据准备慢,但随业务变化的能力差,星型模式(Star Schema),一种多维的数据关系,由一个事实表和一组维表组成。每个维

7、表表达一个维度,所有维度字段组成事实表的复合主键。事实表的非主属性称为事实,都是汇总出来的数值型数据。维大都是文字、时间等类型的数据,雪花模式(Snowflake Schema),是对星型模式的扩展(维度)日期、地区等多层次的维度均可类似扩展,优点:支持更多的查询需求,而且性能很好!不足:编程较复杂,宽表,横表与纵表处理方便性与业务支撑灵活性的差异宽表在横表的基础上拓展,强化处理方便性开放给业务人员使用,直接解决业务问题单条记录包括用户基本信息、产品选择和使用量、费用信息,议题,数据仓库系统的架构数据仓库的设计方法性能影响的关键可用性设计,非规范化技术,增加冗余列(预连接)避免查询时进行表连接

8、操作举例:姓名、联系方式、预存款、当前积分增加派生列(预计算)避免查询时连接和使用聚合函数累计积分、ARPU、MOU、前3月平均话费、量收比重新组表(应用导向)经常使用的查询内容以表的形式存放(物化视图)分割(水平垂直)用户常用属性与不常用属性当前资料与历史资料非规范化技术建立在查询统计分析的基础上的适合对记录数非常多的表进行需要维护数据的完整性,加大了建设、维护的复杂度,非规范化不是坏事,相反却是高级技巧!OLTP系统也有,只是OLAP需要更多,是核心!,分表技术,利用数据仓库的Partition功能数据仓库引擎提供,发挥都处理器及多主机执行的并行性很方便使用,而且必须使用表大到一定程度后,

9、在Partition基础上进行下述的分表按业务分表如详单按品牌拆分(分析频率、特征均不同)按日期分表详单按日分表帐单等按月分表汇总结果按月分表按地区分表分地区处理较多的表混合分表如每地区每日一张表,分表技术也属也非规范化技术,但是,也只应用在物理模型中!,电信行业特点,业务发展快市场竞争加快了新业务的推出新业务的使用情况及发展趋势需要即时分析和预测现有产品多、用户量大用户可选用多产品部分产品需要和用户资料结合计费、出帐及管理等,业务较为复杂。业务使用量巨大通话详单数据存放时间长分析、查询等需要源系统系统较多业务推出先后不同,导致很多源系统系统之间数据存在冗余和一致性问题,电信行业特点,要求数据

10、仓库设计:1、现有统计、分析支持好2、扩展性高3、良好的性能4、完善数据质量保证机制,议题,数据仓库系统的架构数据仓库的设计方法性能影响的关键可用性设计,高扩展性设计,1、业务驱动数据仓库模型设计 2、仓库内数据分层,3、合理选用3NF、混合、星型、雪花及宽表模式,充分发挥非规范化技术,Data Warehouse(Hybird Schema),ODS(3FM),OLAP Model,Mining Model,Report Model,Analysis(Star Schema、宽表),“解剖学不是美术,实物是那么样的,我们没法改换它”鲁迅藤野先生,高可用性设计,非规范化和分表技术应用最大化查询

11、影响最快维护方便、代价最小编程复杂,但运行极快完善处理变更历史数据可长期追踪不影响当前数据的处理效率科学的表命名机制所属层次指示业务内容指示汇总粒度指示更新特性指示分表特性指示汇总数据再处理相对于“远小近大”,数据质量保证机制,工作方法深入分析数据源系统整理出接口文档注明业务口径,适用范围与各业务系统确认一致性问题开发质量保障模块数据稽核修复自动维表维护ETL过程中关键数据质量稽核,数据一致性保障,纯净目标数据文件(含修复数据),错误数据文件,格式化文件输出,格式化但错误众多的数据源文件,错误核查修复指示文件,映射文件,数据稽核修复引擎,稽核报告,自动维表维护,DataCleansingTool,Relational,Appl.Package,Legacy,External,Code Files,Data Files,AutoDimensionEngine,Map Files,DataQualityEngine,Q&A,谢谢!,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 建筑/施工/环境 > 项目建议


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号