1、数据仓库系统的设计及开发数据仓库系统的设计及开发2022年8月3日22.3.数据仓库设计数据建模最佳实践构建高性能的数据仓库数据仓库设计ETL设计数据仓库设计建模过程日程安排日程安排数据仓库设计界面设计数据仓库的开发应用过程2022年8月3日3能够很好的分离出底层技术的实现和上层业务的展现1)当上层业务发生变化时,通过数据模型,底层技术实现可以较为轻松的完成业务的变动,从而达到整个数据仓库系统的灵活性能够全面了解业务系统的业务架构图和整个业务运行情况2)能够将业务按照特定的规律进行分门别类和程序化1)建立全方法的数据视角;2)保证整个企业的数据的一致性;3)消除各个部门之间的信息孤岛;为什么需
2、要数据模型为什么需要数据模型2022年8月3日4数据仓库建模人员所需的技能和能力数据仓库建模人员所需的技能和能力 分析能力见树又见林模拟论证 学习能力抽象综合 交流能力组交互演示调查访谈 原型设计能力企业体系架构2022年8月3日5数据仓库设计建模的要点和原则数据仓库设计建模的要点和原则建模原则 选择创建什么模型对如何动手解决问题和如何解决方案有深远影响 每一种模型可以在不同的精度级别上表示 最好的模型是与现实相联系 单个模型不充分,需要一组模型去处理建模的要点 正确认识建模方法论2022年8月3日6利用图形来建立数据模型利用图形来建立数据模型 图形具有直观性、简单性以及可理解性等优点 图形能
3、自然地表达客观世界 理解图中路径探索2022年8月3日7什么是数据模型什么是数据模型 业务建模,生成业务模型,主要解决业务层面的分解和程序化。领域建模,生成概念模型,主要是对业务模型进行抽象处理,生成领域概念模型。逻辑建模,生成逻辑模型,主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。物理建模,生成物理模型,主要解决,逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。2022年8月3日8思考思考 需求建模与业务建模 需求建模与业务建模谁先谁后?软件开发过程是否应该是:业务调研,业务建模(业务分析),(业务模型分析)需求调研(这时,已经有一部分需求可从业务模型
4、中获得),需求建模,需求分析2022年8月3日9业务建模业务建模组织结构分析组织结构分析组织结构组织结构,用户及权限的分析用户及权限的分析客户组织结构的分析n公司组织机构n区域位置n集团/省/地市用户的分析n用户n组n角色权限的分析n功能权限分析n数据权限分析2022年8月3日102022年8月3日星期三11例:三大运营商的组织架构调整2022年8月3日12业务建模业务建模业务流程分析业务流程分析什么是业务流程什么是业务流程2022年8月3日13业务流程分析的内容业务流程分析的内容(1)原有流程的分析。(2)业务流程的优化。(3)确定新的业务流程(4)新系统的人机界面。2022年8月3日14业
5、务流程分析的步骤业务流程分析的步骤 1.系统环境调查 2.组织机构和职责的调查 3.功能体系的调查与分析 4.管理业务流程的调查与分析2022年8月3日15案例学习:案例学习:新业务客户服务业务流程新业务客户服务业务流程新业务查询流程新业务查询流程2022年8月3日16业务流程可以代替业务建模吗业务流程可以代替业务建模吗 在业务流程的背后,有一个更加根本的因素商业需求。商业需求才是真正的业务模型,业务流程只是一种实现手段而已。例:新用户入网业务流程:1:首先把SIM卡和号码在交换网络上做对应关系的注册;2:市场部把SIM卡存入一定的金额,发给销售商,收取销售商的货款;3:销售商把卡卖给用户,用
6、户填写入网合同,SIM装入手机可以立即通话;4:销售商把入网合同交给市场部,市场部资料录入人员将用户的资料录入系统;5:计费系统按照用户选择的资费对话单进行计费;6、市场部按照用户的消费情况给销售商计算佣金和返利。思考:真正的业务模型(需求)是什么?2022年8月3日17从业务流程中提取概念和逻辑模型从业务流程中提取概念和逻辑模型 心得体会:看到背后的商业需求,你会发现模型原来非常稳定 不需要急于知道所有的细节性的需求,只要了解比较重要的20的需求2022年8月3日182022年8月3日19数据仓库数据模型数据仓库数据模型-星型模型与雪花模型星型模型与雪花模型2022年8月3日20数据仓库建模
7、的原则数据仓库建模的原则2022年8月3日21数据仓库建模的三个阶段数据仓库建模的三个阶段概念模型设计概念模型设计(Concept Data Modeling):这一阶段之前的首要工作是通过需求分析,明确需求所涵盖的业务范围。然后再对需求范围内的业务及其间关系进行高度概括性的描述,把密切相关业务对象进行归类,即划分主题域。概念模型的设计是为逻辑模型的设计做准备,它没有统一的标准,主要根据设计者的经验。逻辑模型设计逻辑模型设计(Logical Data Modeling):分别对概念模型的各个主题域进行细化,根据业务定义、分类和规则,定义其中的实体并描述实体之间的关系,并产生实体关系图(ERD)
8、,然后遵照规范化思想在实体关系的基础上明确各个实体的属性。实体产生于中国移动开展的业务、服务及其涉及的对象(如客户、帐户、员工、机构、资源),实体间的对应、约束关系则来自于各业务过程中的规则。可以说,这一阶段面对的是业务。物理模型设计物理模型设计(Physical Data Modeling):n物理模型设计主要依据逻辑模型针对具体的分析需求和物理平台采取相应的优化策略。此时会在一定程度上增加数据冗余或者隐藏实体之间的关系或者进行实体的合并和拆分,目的是提高数据分析的速度,适应具体数据库的容量、性能等限制。可以说,这一阶段面对的是具体软硬件平台和性能要求。n一旦逻辑模型到位,物理模型就有了可参
9、照的依据,开发工作内容也同时得到明确。物理模型设计一般在架构设计阶段2022年8月3日22数据仓库系统所采用的建模流程数据仓库系统所采用的建模流程 概念模型为逻辑模型的设计作准备,没有统一标准,主要根据设计者经验 逻辑模型对概念模型的各个主题域进行细化,根据业务定义、分类和规则,定义其中的实体并描述实体之间的关系,并产生实体关系图(ERD)一旦逻辑模型到位,物理模型就有了可参照的依据,开发工作内容也同时得到明确 2022年8月3日23数据仓库概念模型数据仓库概念模型主题域的设计主题域的设计 DW主题的划分必须是基于需求的主题划分,而不仅仅是基于已有查询和报表数据的主题划分 DW主题是通过对业务
10、人员的访谈,充分了解业务流程和信息使用需求为主要根源的 DW主题的设计必须能够满足业务人员的内在的分析需求 DW主题设计的过程中,业务环节点分析是关键 DW细化分析主题,解决指标的歧义问题,为模型设计、数据提取、数据展现等多个方面奠定基础2022年8月3日24数据仓库的数据模型数据仓库的数据模型 系统记录域(System of Record):这部分是主要的数据仓库业务数据存储区,数据模型在这里保证了数据的一致性。内部管理域(Housekeeping):这部分主要存储数据仓库用于内部管理的元数据,数据模型在这里能够帮助进行统一的元数据的管理。汇总域(Summary of Area):这部分数据
11、来自于系统记录域的汇总,数据模型在这里保证了分析域的主题分析的性能,满足了部分的报表查询。分析域(Analysis Area):这部分数据模型主要用于各个业务部分的具体的主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。反馈域(Feedback Area):可选项,这部分数据模型主要用于相应前端的反馈数据,数据仓库可以视业务的需要设置这一区域。2022年8月3日25数据模型的技术功能结构划分 分段存储区(Staging Area)是为了保证数据移动的顺利进行而开设的阶段性数据存储空间,它是业务系统原始数据进入数据仓库前的缓存区。基础数据仓库 根据业务需求的不同,基础数据仓库的组织形式
12、以三范式模型为主,在有的系统中也可能采用星型或雪花模型。数据集市(Data Mart)数据集市中的数据通常由基础数据仓库的详细数据聚合而来,根据数据聚合程度的不同包含轻度聚合、中度聚合和高度聚合三种不同的层次。汇总的方式将依据数据量的大小和使用频度综合考虑 2022年8月3日26数据仓库的模型数据仓库的模型关系模型关系模型2022年8月3日27数据仓库的模型数据仓库的模型星型模型星型模型 通过数据预连接和建立有选择的数据冗余,设计者为访问和分析过程大大简化了数据。星型连接应用于设计数据仓库中很大的实体,而数据模型则应用于数据仓库中较小的实体。2022年8月3日28数据仓库的模型数据仓库的模型雪
13、花模型雪花模型 许多维度存在着比较复杂的结构,它们有的还具有多层的层次结构。因此,很难将这样的维表只采用一个关系表的形式表达出来,必须将这些维表规范成有多个外键关联的关系表2022年8月3日29星型模型星型模型 VS 雪花模型雪花模型比较项目比较项目优点优点缺点缺点星型模式1.查询效率高,事实表作连接时其速度较快;2.便于用户理解。比较直观,通过分析星形模式,很容易组合出各种查询增加了存储空间雪花模式1.在一定程度上减少了存储空间2.规范化的结构更容易更新和维护1.比较复杂,用户不容易理解;2.浏览内容相对困难3.额外的连接将使查询性能下降2022年8月3日30宽表宽表 横表与纵表 处理方便性
14、与业务支撑灵活性的差异 宽表 在横表的基础上拓展,强化处理方便性 开放给业务人员使用,直接解决业务问题 单条记录包括用户基本信息、产品选择和使用量、费用信息明细帐单表1PK account_datePK user_idPK account_idPK item_id item_fee item_favour明细帐单表2PK account_datePK user_idPK account_id base_fee toll_fee message_fee other_fee.2022年8月3日31数据仓库建模方法数据仓库建模方法范式建模法范式建模法 优点:从关系型数据库的角度出发,结合了业务系统的
15、数据模型,能够比较方便的实现数据仓库的建模 缺点:在某些时候反而限制了整个数据仓库模型的灵活性,性能等2022年8月3日32数据仓库建模方法数据仓库建模方法维度建模法维度建模法 优点:维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题 缺点:如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性2022年8月3日33数据仓库建模方法数据仓库建模方法实体建模法实体建模法 优点:能够很轻松的实现业务模型的划分,因此,在业务建模阶段和领域概念建模阶段,实体建模法有着广泛的应用 缺点:不太适用于物理建模2022年8月3日34数据仓库建模的十大戒律数据仓库建模的十大戒律 1
16、)必须回答紧迫的问题;2)必须有正确的事实表;3)将有正确的维表,描述必须按最终用户的业务术语表达;4)必须理解数据仓库所影响的公司过程或影响数据仓库的公司过程;5)对于事实表,应该有正确的“粒度”;6)根据需要存储正确长度的公司历史数据;7)以一种对于公司有意义的方式来集成所有必要的数据;8)创建必要的总结表;9)创建必要的索引;10)能够加载数据仓库数据库并使它以一种适宜的方式可用。2022年8月3日35数据仓库缓慢变化维的一个案例数据仓库缓慢变化维的一个案例一个案例 在一个零售业数据仓库中,事实表保存着各销售人员的销售记录,某天一个销售人员从北京分公司调到上海分公司了,那么如何来保存这个
17、变化呢?也就是说销售人员维度要怎么恰当的处理这一变化。如果我们要统计北京地区或上海地区的总销售情况的时候,这个销售人员的销售记录应该算在北京还是算在上海?当然是调离前的算在北京,调离后的算在上海,但是如标记这个销售人员所属区域?这里就需要处理一下这个维度的数据,即我们缓慢变化维需要做的事情。2022年8月3日36数据仓库缓慢变化维的解决方案数据仓库缓慢变化维的解决方案 新数据覆盖旧数据 保存多条记录,并添加字段加以区分添加记录的生效日期和失效日期来标识新旧数据 不同字段保存不同值,这种方法用不同的字段保存变化痕迹.但是这种方法不能象第二种方法一样保存所有变化记录,它只能保存两次变化记录.适用于
18、变化不超过两次的维度。另外建表保存历史记录,而维度只保存当前数据 混合模式2022年8月3日37数据仓库建模数据仓库建模_案例案例2022年8月3日38案例:怎样构建数据仓库模型案例:怎样构建数据仓库模型确定主题域确定主题域及各主题域之间的关系确定主题域的业务数据确定业务数据中的业务实体确定业务实体之间的关系确定物理模型2022年8月3日39确定确定主题域及各主题域之间的关系主题域及各主题域之间的关系服务通过网络实现/网络支持服务网络产生事件/事件包括网络类产品被销售给客户/参与人使用和管理产品跟踪应付&应收/提供成本&收入历史事件包含财务类参与人产生和经历事件/事件包括参与人的产品/服务产生
19、事件 事件包括产品类营销产生事件事件实现营销营销被锁定位置/位置定位营销针对特定产品/产品通过营销推向市场为参与人建立帐户、帐单/记录帐户、成本和付款服务使用的帐务信息/帐务记录产品的成本和付款定位网络/网络支持的位置营销的目标针对参与人/参与人是营销的受众包括消费者和运营商在内/位置定位Finance Management(财务管理)(财务管理)BILLING(帐务)(帐务)NETWORK(网络资源)(网络资源)PRODUCT(产品)(产品)MARKETING(市场营销)(市场营销)LOCATION(地域)(地域)PARTY(参与人)(参与人)EVENT(事件事件)跟踪总帐/负责2022年8
20、月3日40基基 本本 结结 构构特特 征征奖奖 励励隐隐 私私 参与人主题描述了和电信运营商有着业务联系的参与人主题描述了和电信运营商有着业务联系的 任何个人、企业、组织、团体等。任何个人、企业、组织、团体等。确定主题域的业务数据确定主题域的业务数据2022年8月3日41参与人间参与人间关联关联 参与人角色参与人角色组织组织层次结构层次结构层次结构层次结构级别级别层次结构层次结构类型类型商业组织商业组织内部组织内部组织标准分类标准分类代码代码确定基本结构业务数据的业务实体及关系确定基本结构业务数据的业务实体及关系参与人:和电信运营商有参与人:和电信运营商有着业务联系的任何个人、着业务联系的任何
21、个人、组织机构、家庭和虚拟客组织机构、家庭和虚拟客户户 。例:例:财务财务市场营销市场营销网管网管例:例:客户客户潜在客户潜在客户电信运营商电信运营商代理商代理商供应商供应商管理者管理者雇主雇主职工职工个人个人家庭家庭组织组织参参 与与 人人2022年8月3日42特征特征符合程度符合程度特征特征类别值类别值客客 户户 特特 征征帐帐 户户 特特 征征特特 征征 类类 别别例:例:个人喜好个人喜好信用类信息信用类信息家庭类信息家庭类信息教育类信息教育类信息职业类信息职业类信息机构类信息机构类信息 例:例:信用等级信用等级职业状态职业状态收入收入子女数子女数教育程度教育程度特特 征征 分分 组组完
22、全符合完全符合部分符合部分符合不符合不符合确定特征业务数据中的业务实体及关系确定特征业务数据中的业务实体及关系2022年8月3日43奖励计划管理奖励计划管理参与人角色参与人角色奖励目标客户群奖励目标客户群目目 标标 群群奖奖 励励 等等 级级奖奖 励励 类类 型型参与人参与人奖励历史记录奖励历史记录奖奖 励励 计计 划划奖励计划:记录电信奖励计划:记录电信运营商向客户提供奖运营商向客户提供奖励和回报的历史。励和回报的历史。确定奖励业务数据中的业务实体及关系确定奖励业务数据中的业务实体及关系2022年8月3日44隐私信息隐私信息类别类别同意周期同意周期组织隐私组织隐私策略信息策略信息参与人帐户参
23、与人帐户隐私信息隐私信息帐户同意帐户同意等级信息等级信息参与人同意参与人同意等级信息等级信息参与人参与人隐私信息隐私信息隐私信息类别隐私信息类别确定隐私业务数据中的业务实体及关系确定隐私业务数据中的业务实体及关系2022年8月3日45业务系统与业务系统与数据仓库模型的数据仓库模型的映射映射2022年8月3日46数据仓库建模数据仓库建模_案例实践案例实践国内社保行业背景2022年8月3日47n目前我们国家的社保主要分为养老,失业,工伤,生育,医疗保险和劳动力市场这 6 大块主要业务领域。n在这 6 大业务领域中,目前的状况养老和事业的系统已经基本完善,已经有一部分数据开始联网检测。n对于工伤,生
24、育,医疗和劳动力市场这一块业务,有些地方发展的比较成熟,而有些地方还不够成熟。?请大家思考并简单描述社保行业的数据仓库模型:大致的业务模型大致的概念模型社保行业数据仓库业务模型社保行业数据仓库业务模型2022年8月3日48社保行业数据仓库领域概念模型社保行业数据仓库领域概念模型2022年8月3日49社保行业数据仓库逻辑模型社保行业数据仓库逻辑模型2022年8月3日50通过领域概念模型细化逻辑模型每一个抽象的实体,例如:“人”的属性包括年龄,性别,受教育程度等等。各个抽象实体间的联系。例如:对于养老金征缴这个“事件”的属性得考虑,对于失业劳动者培训这个“事件”的属性得考虑等等。找出抽象事件的关系
25、,并对其进行说明。例如:对于“事件”中的地域,事件等因素的考量等等。建议:可以参考 3NF 的建模方法,表达出实体的属性,以及实体与实体之间的联系。例如:在这个阶段,我们可以通过采用 ERWIN 等建模工具等作出符合 3NF 的关系型数据模型来。社保行业数据仓库物理模型社保行业数据仓库物理模型2022年8月3日51完成物理模型生成创建表的脚本。不同的数据仓库平台可能生成不同的脚本。针对数据集市的需要,按照维度建模的方法,生成一些事实表,维表等工作。针对数据仓库的ETL车和元数据管理的需要,生成一些数据仓库维护的表,例如:日志表等。注:根据业务实际的需要和自己对抽象能力的把握来创建适合根据业务实
26、际的需要和自己对抽象能力的把握来创建适合自己的数据模型自己的数据模型2022年8月3日52总结总结:数据仓库建模需注意的几个问题数据仓库建模需注意的几个问题 数据粒度和数据组织 维和度量的唯一性和公用性 数据粒度一旦变粗,就要考虑多个主题的融合汇总 不论如何归并,需要保持数据之间的联系 对ODS中的各个主题的事实数据进行时间上的汇总 把包含细节过多的交易记录进行拆分 汇总、再汇总2022年8月3日532.3.数据仓库数据模型星形与雪花最佳实践构建高性能的数据仓库数据仓库设计ETL设计数据仓库设计建模过程日程安排日程安排数据仓库设计界面设计数据仓库的开发应用过程2022年8月3日54ETL 数据
27、转换过程的功能模块设计数据转换过程的功能模块设计 ETL 数据转换操作大致可以分为 6 个组或模块:数据的提取、验证、清理、集成、聚集和装入。2022年8月3日55ETL的设计要点的设计要点(1)ETL的设计一定是针对具体的应用相关的,针对不同的业务和分析模型有不同的抽取要求 在设计过程中需要考虑是否需要预留字段,增加属性等等 数据的粒度,在同一CUBE中必须统一 数据周期的确定,在设计ETL时需要事先确定抽取的时间 抽取的方式尽量采用增量的抽取以减小每次抽取的数量 数据流和工作流的考虑2022年8月3日56ETL的设计要点的设计要点(2)流程的异常处理 ETL的调整,运行管理以及监控 针对业
28、务的需求进行ETL的配置和设置界面 ETL对CUBE的管理 ETL装载数据初始化的过程 程序具有自修复功能2022年8月3日57确定确定ETL的抽取及加载策略的抽取及加载策略抽取策略-每日增量-每日全量-每月增量-每月全量抽取策略-全表覆盖-历史加载-直接追加-主表加载-初始加载-其它加载2022年8月3日58ETL Mapping 实体映射表实体映射表2022年8月3日59确定确定ETL接口需求接口需求 系统和任何其他外部系统或组件进行交互相关需求 接口一般由系统间的传输方式、传输协议、传输过程、接口处理模式、抽取周期、编码原则、命名规则、验证方式和数据单元等组成 2022年8月3日60确定
29、确定ETL接口的实现方式接口的实现方式2022年8月3日61确定确定ETL接口的数据要求及保障接口的数据要求及保障2022年8月3日62确定确定ETL接口文件的格式接口文件的格式2022年8月3日63确定确定ETL接口文件的内容接口文件的内容2022年8月3日64确定确定ETL接口单元接口单元2022年8月3日65ETL接口数据处理流程接口数据处理流程2022年8月3日66ETL接口出错处理接口出错处理接口处理重传机制 1、经营分析系统方校验数据源内容后把出错记录放入“出错记录文件存放目录”2、数据源厂商定时查阅此目录,分析错误原因,并采取纠正措施例如:重新传送此数据项文件。具体的实现方式需双
30、方协定。大数据文件分拆机制 只要是增量抽取的,原则上不考虑分拆,对于GSM清单和普通短信清单,数据量很大,考虑分拆成12个数据文件,每2小时一个。2022年8月3日67案例学习案例学习2022年8月3日682.3.数据仓库数据模型星形与雪花BI项目设计开发的最佳实践数据仓库设计ETL设计数据仓库设计建模过程日程安排日程安排数据仓库设计界面设计数据仓库的开发应用过程2022年8月3日69确定界面元素确定界面元素 界面主颜色 字体颜色及大小 界面布局 界面交互方式 界面功能分布 界面输入输出模式2022年8月3日70某运营商某运营商KPI系统目标系统目标 以最方便的形式让各级领导对考核指标完成情况
31、进行浏览分析 采用良好方式实现常用指标的关联展示,更加符合业务人员的分析逻辑 采用树型菜单对个体分散指标进行分类展示组织,提高指标分析的操作的便捷性 详细编写各业务指标的统计口径,让用户可以方便查询和检索2022年8月3日71KPI系统指标体系系统指标体系2022年8月3日72数据准确性数据准确性刷新刷新/上载数据的频率上载数据的频率(定期定期)数据下钻能力数据下钻能力访问控制访问控制KPI系统系统关键性关键性:低高KPI分层分层KPI系统主要功能系统主要功能2022年8月3日731。支持角色,有预定义好的权限 视图 2。分层管理:每个KPI有对应的“保障”KPI的层次定义3。动态交互式环境
32、用户可以设置KPI分解的百分比 支持分解维度(按部门、运营中心如地市等)可调整的KPI分解规则4。阀值预警5。内部标杆共享KPI系统框架和关键功能系统框架和关键功能2022年8月3日74 整体KPI首页界面分为三个目录级 KPI考核指标 KPI通报指标 KPI个体指标 体现以表格的形式展现数据,辅助以图型 增加指标之间的关联性,从多角度体现指标的内容。增加指标说明的模块,对用户使用该指标时容易产生理解误差的内容提供相应解释。KPI系统首页界面系统首页界面2022年8月3日75树状的目录力求简单,清晰,操作方便,减少用户的点击切换环节过程。KPI系统树状目录结构系统树状目录结构2022年8月3日
33、76简单明了的KPI指标往往成为管理者和普通市场人员最关注的对象领导的聊望台滚动指标告警指标列表区首页或结果展示区 滚动指标告警区KPI系统首页界面系统首页界面2022年8月3日77增强指标之间的关联性,对若干指标的内在联系,进行归类对比展示,以多种图形方式进行多角度地展现。KPI系统界面系统界面12022年8月3日78lKPI指标主要展现此项指标在时间上的对比,例如,上月当日,历史同期,环比等。lKPI指标按业务分析逻辑有机排列,方便业务人员对比观看。lKPI在表格上增加趋势的展现,分为三种,“平稳”,“升高”,“降低”点击以后将展示最近一周的趋势KPI系统界面系统界面22022年8月3日7
34、92.数据仓库数据模型星形与雪花BI项目设计开发的最佳实践数据仓库设计ETL设计数据仓库设计建模过程日程安排日程安排数据仓库的开发应用过程数据仓库设计界面设计2022年8月3日80自顶向下自顶向下(Top-down Approach)建造企业数据仓库 建设中心数据模型 一次性的完成数据的重构工作 最小化数据冗余度和不一致性 存储详细的历史数据 从企业数据仓库中建造数据集市 得到大部分的集成数据 直接依赖于数据仓库的可用性 对信心的极大考验:投资大,建设时间长,阶段成果显现困难!ExternalDataODSCentral DataWarehouseDataMartDataMart2022年8月
35、3日81自底而上自底而上(Bottom-up Approach)创建部门的数据集市 范围局限于一个主题区域 快速的ROI-局部的商业需求得到满足 本部门自治-设计上具有灵活性 对其他部门数据集市是一个好的指导 容易复制到其他部门 扩大到企业数据仓库 创建EDW作为一个长期的目标 重复投资:每个部门都重复进行数据整理!企业数据仓库建设困难:数据口径、不一致性问题突出!DataMartDataMartCentral DataWarehouseExternalDataODSpartpartpartpartpartpart2022年8月3日82数据仓库工程项目的特点数据仓库工程项目的特点 数据仓库工程
36、既包括数据又包括程序,而且是以数据为基础的系统 数据仓库工程中的数据仓库的目标是面向主题 数据仓库工程是以处理分析型目标为主而不是事物型目标,它对数据内容正确性与形式规范性有严格要求 数据仓库工程中数据来源已有多种信息系统,因此对系统的数据要有一定的限制制约,也就是有了建立统一数据平台的需求2022年8月3日83数据仓库工程项目的开发应用过程数据仓库工程项目的开发应用过程 解决方案启动(解决方案启动(Solution start up)业务发现(业务发现(Business discovery)解决方案建议(解决方案建议(Solution proposal)解决方案计划)解决方案计划(Solut
37、ion planning)仓库概念建模仓库概念建模(Warehouse conceptual modeling)仓库阶段设计仓库阶段设计(Warehouse phase design)解决方案实现周期解决方案实现周期(Solution implementation cycle)解决方案部署(解决方案部署(Solution deployment)2022年8月3日84数据仓库业务发现过程数据仓库业务发现过程 收集记录业务需求 理解客户业务环境 差异分析,理解客户的业务难题及需求,弥补当前业务状态及其业务需求之间差异2022年8月3日85收集记录业务需求确定业务对象确定数据分析场景确定功能需求理解
38、客户的业务环境理解基础架构环境理解数据环境 差异分析 需求分析识别业务主题领域识别数据差异识别基础设施差异识别资源的差异理解客户环境 三个任务可以重叠进行 数据仓库的业务发现内容数据仓库的业务发现内容2022年8月3日862022年8月3日87数据仓库工程项目的开发流程图数据仓库工程项目的开发流程图2022年8月3日88数据仓库的数据流程数据仓库的数据流程(1):对原始数据进行数据抽取、清洗、整理后成为数据仓库中的各种综合度的数据表。(2):经过维度分析得到维表并定义相应的格式表。(3):从数据仓库中抽取数据形成事实表及补充事实表。(4):从数据仓库中抽取信息,整理成数据挖掘宽表,用于数据挖掘
39、。(5):宽表中的数据通过数据挖掘程序处理后生成的扩展数据(挖掘结果)需要重新回写进事实表。(6):利用数据展现工具展现 OLAP 和数据挖掘的结果。2022年8月3日89数据仓库需求分析数据仓库需求分析 数据仓库的特点是面向主题,按主题组织数据。1、主题分析对于在层次结构中的每个主题,需要进行详细的调研,确定要分析的指标,确定用户从哪些角度来分析数据即维度,还要确定用户分析数据的细化或综合程度即粒度。主题、指标、维度、粒度是是建立数据仓库的基本要素。2、数据分析(1)数据源分析(2)数据数量分析 (3)数据质量分析 3、环境要求分析需要对满足需求的系统平台与环境提出要求,包括设备、网络、数据
40、、接口、软件等的要求。2022年8月3日90数据仓库系统总体设计数据仓库系统总体设计体系结构设计接口设计应用程序模块设计数据源层数据后端处理层数据仓库及其管理层数据集市层数据仓库应用层数据展示层数据源与分析模型的接口分析模型与应用的接口2022年8月3日91分析分析设计设计实施实施需求分析需求分析风险分析风险分析方案设计方案设计POC实施实施UAT发布发布环境准备环境准备Scope系统功能系统功能目标分析目标分析系统性能系统性能环境环境所带来的风险所带来的风险分析分析可以容忍可以容忍的见险的见险关键流程关键流程的定义的定义确定组织架构确定组织架构方案设计方案设计(技术框架(技术框架/流程流程)
41、数据备份方案数据备份方案时间窗时间窗环境环境(DB/TOOL/DATA)源代码源代码/POC数据数据POC报告报告CUT计划测试计划测试/用户用户测试测试数据备份数据备份系统观察系统观察系统发布系统发布Bug Fix项目建设方法论项目建设方法论2022年8月3日92BI项目组织图928/3/20222022年8月3日93BI项目组织说明 项目指导委员会(Steering Committee):项目指导委员会主要由甲方与HP的资深主管们所组成,负责决定项目的策略方向与目的,并提供项目执行所需要的支持与承诺。协助处理与仲裁项目执行过程由项目经理所提报(Escalate)所遇到之困难与争议。协助处理
42、项目执行上所需要之人力资源支持与调动,如项目团队之人员指派等。项目经理(Project Manager):在 项目经理的协助下,承担并完成下列工作:规划详细的项目计划书管理项目中所有的日常事务与工作事项,以期达成项目每的阶段性任务及目标核审项目进度与项目里程碑定期与甲方项目经理共同执行项目的审核并商讨项目的计划定期以书面方式向项目指导委员会报告项目进行的状况针对项目执行上所遭遇的例外事件进行处理,并适当提报给项目指导委员会以寻求支持与协助与甲方项目经理共同担负起项目建置成功的责任938/3/20222022年8月3日94BI项目组织说明 专案架构师(Solution Architect):负责
43、项目相关之技术架构与功能设计等,并领导项目执行技术团队 确认项目技术架构符合甲方之维运要求与质量标准。ETL组 2人:负责ETL部分的开发与实施 Report组 2人:负责BO Report部分的开发与实施 Test组 2人:负责项目的系统测试与用户最终测试 其中测试组有1人兼任QA和KM角色。948/3/20222022年8月3日95M0M1M2M3M4M5BI项目里程碑项目里程碑Milestone注注:在大约项目启动后在大约项目启动后2个月,个月,POC阶段将完成阶段将完成,也即最初也即最初的原型构建的原型构建,用户可以得到一个阶段性的用户可以得到一个阶段性的Release,下一步下一步的
44、项目实施及集成测试将以迭代的方式实现。的项目实施及集成测试将以迭代的方式实现。2022年8月3日96BI项目实施阶段项目实施阶段阶段阶段输入输入输出输出项目启动-评估SOW/方案建议书/迁移评估问题清单评估计划,迁移方案,原始系统检查报告项目启动-项目计划项目实施方案,当前环境和业务需求,数据和属性,适用的实施工具项目计划,质量计划,风险管理计划,配置管理计划,单元测试案例(持续更新),集成测试案例(持续更新)POC源代码,POC数据,原始系统检查报告,实施方案实施模块,POC测试结果,POC经验总结,实施方案(更新),模块实施步骤报告迁移源代码,POC数据,原始系统检查报告,迁移方案实施的E
45、TL脚本,数据模型,数据代码,迁移测试脚本,模块实施步骤报告集成测试测试计划,测试案例,基准版本,质量计划已测试应用,测试报告,测试案例(更新)发布已实施应用Release Note用户验收测试(UAT)验收测试计划验收测试报告Roll Out已迁移应用部署计划,培训材料2022年8月3日97优化及案例分析业务环境优化及案例分析业务环境 数据库服务器:Windows 2000 Server+Oracle8i+IIS+PowerPlayEnterprise Server应用服务器:Windows 2000 Server+Transformer客户端以上版本。2022年8月3日98优化及案例分析优
46、化内容优化及案例分析优化内容 1.RAID 2.索引的建立 3.SQL优化 4.直接装载、分区选择、网络设置2022年8月3日992.数据仓库数据模型星形与雪花BI项目设计开发的最佳实践数据仓库设计ETL设计数据仓库设计建模过程日程安排日程安排数据仓库的开发应用过程数据仓库设计界面设计2022年8月3日100影响仓库性能的关键因素影响仓库性能的关键因素 系统硬件 磁盘(转速、容量)IO速度(光纤卡、网卡、路由器)CPU(个数、主频)主机个数 数据模型 逻辑模型 物理模型 应用复杂度及业务发展 EDW Data Warehousing2022年8月3日101物理模型对性能的影响物理模型对性能的影
47、响 数据仓库的创建(Build)初始化每天数据载入每月数据载入数据维护 应用查询,统计的支持(Query)KPI 固定报表 OLAP 数据挖掘 专题分析 即席查询 经营分析报告/策划查询性能更应该被优先保证查询性能更应该被优先保证!空间换取时间的优化思想依然适用空间换取时间的优化思想依然适用!2022年8月3日102非规范化优化技术非规范化优化技术 增加冗余列(预连接)避免查询时进行表连接操作 举例:姓名、联系方式、预存款、当前积分 增加派生列(预计算)避免查询时连接和使用聚合函数 累计积分、ARPU、MOU、前3月平均话费、量收比 重新组表(应用导向)经常使用的查询内容以表的形式存放(物化视
48、图)分割(水平垂直)用户常用属性与不常用属性 当前资料与历史资料 非规范化技术建立在查询统计分析的基础上的 适合对记录数非常多的表进行 需要维护数据的完整性,加大了建设、维护的复杂度非规范化是一项高级设计技巧非规范化是一项高级设计技巧!OLTPOLTP系统也有,但系统也有,但OLAPOLAP需要更多,而且是核心需要更多,而且是核心!2022年8月3日103分表优化技术分表优化技术 利用数据仓库的Partition功能 数据仓库引擎提供,发挥都处理器及多主机执行的并行性 很方便使用,而且必须使用 表大到一定程度后,在Partition基础上进行下述的分表 按业务分表 如详单按品牌拆分(分析频率、
49、特征均不同)按日期分表 详单按日分表 帐单等按月分表 汇总结果按月分表 按地区分表 分地区处理较多的表 混合分表 如每地区每日一张表分表技术与非规范化技术类似分表技术与非规范化技术类似只应用在物理模型中只应用在物理模型中!2022年8月3日104高扩展性设计高扩展性设计1、业务驱动数据仓库模型设计 2、仓库内数据分层3、合理选用3NF、混合、星型、雪花及宽表模式Data Warehouse(Hybird)ODS(3NF)OLAP ModelMining ModelReport ModelAnalysis(Star Schema、宽表)Data WarehouseODSAnalysisparal
50、lel loaderQuery数据仓库设计需要艺术地处理性能与灵活性之间的矛盾2022年8月3日105高可用性设计高可用性设计 非规范化和分表技术应用最大化 查询影响最快 维护方便、代价最小 编程复杂,但运行极快 完善处理变更历史数据 可长期追踪 不影响当前数据的处理效率 科学的表命名机制 所属层次指示 业务内容指示 汇总粒度指示 更新特性指示 分表特性指示 汇总数据再处理 相对于“远小近大”dw_call_city_ymddw_call_msSample:WeekItemStore1/7/90111/14/9013123344.1/7/901/7/901/7/901/7/901/7/901/
侵权处理QQ:3464097650--上传资料QQ:3464097650
【声明】本站为“文档C2C交易模式”,即用户上传的文档直接卖给(下载)用户,本站只是网络空间服务平台,本站所有原创文档下载所得归上传人所有,如您发现上传作品侵犯了您的版权,请立刻联系我们并提供证据,我们将在3个工作日内予以改正。