数据仓库架构以及多维数据模型的设计.docx

数据仓库架构以及多维数据模型的设计|云祁°封图|CSDN下载于视觉中国一、前言最近看了?Hadoop构建数据仓库理论?这本书收获很多把一些关于数仓理论的心得整理出来方便大众共同学习。注本文内容由摘自?Hadoop构建数据仓库理论?与其他相关参考资料旨在方便大众参考学习如您觉得进犯了您的权益请联络我们删除谢谢二、数据仓库的定义数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合用于对管理决策经过的支持。数据仓库本身并不“消费任何数据同时自身也不需要“消费任何的数据数据来源于外部并且开放给外部应用使用。三、数据仓库的特点面向主题的数据仓库都是基于某个明确的主题仅需要与该主题相关的数据其他的无关细节将会被去掉。集成的数据仓库里面的数据都是经过ETLExtract-Transform-Load抽取-转换-加载操作后被集中放到同一个数据源数据仓库里的数据是来自于各种不同的数据源。随时间变化的关键数据隐式或显示地随时间变化而变化。数据相对稳定的数据装入后一般只是进展查询操作没有传统数据库的增删改操作。总结数据仓库就是整合多个数据源的历史数据进展细粒度的、多维的分析可以有效地帮助高层管理者或业务分析人员做出商业战略决策或者商业报表。四、数据仓库的作用可以整合公司的所有业务建立统一的数据中心。分析用户行为数据通过数据挖掘来降低投入本钱进步投入效果。可以作为各个业务的数据源形成业务数据相互反应的良性循环。可以提供数据报表用于公司的决策等等。数据处理大致可以分成两大类联机事务处理OLTPon-linetransactionprocessing、联机分析处理OLAPOn-LineAnalyticalProcessing。OLTP是传统的关系型数据库的主要应用主要是根本的、日常的事务处理例如银行交易。OLAP是数据仓库系统的主要应用支持复杂的分析操作侧重决策支持并且提供直观易懂的查询结果。OLTP系统强调数据库内存效率强调内存各种指标的命令率强调绑定变量强调并发操作。OLAP系统那么强调数据分析强调SQL执行市场强调磁盘I/O强调分区等。五、数据仓库的架构数据收集与分析数据收集层的任务就是把数据从各种数据源中收集以及存储到数据库上期间有可能会做一些ETL抽取extra转化transfer装载load操作。数据源种类可以有多种日志所占份额最大存储在备份效劳器上业务数据库如Mysql、Oracle来自HTTP/FTP的数据合作伙伴提供的接口其他数据源如Excel等需要手工录入的数据数据存储与分析HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。离线数据分析与计算也就是对实时性要求不高的局部Hive是不错的选择。使用Hadoop框架自然而然也提供了MapReduce接口假如真的很乐意开发Java或对SQL不熟那么可以以使用MapReduce来做分析与计算。Spark性能比MapReduce好很多同时使用SparkSQL操作Hive。数据分享前面使用Hive、MR、Spark、SparkSQL分析以及计算的结果还是在HDFS上但大多业务以及应用不可能直接从HDFS上获取数据那么就需要一个数据分享的地方使得各业务以及产品能方便的获取数据。这里的数据分享其实指的是前面数据分析与计算后的结果存放的地方其实就是关系型数据库以及NOSQL数据库。数据应用报表报表所使用的数据一般也是已经统计汇总好的存放于数据分享层。接口接口的数据都是直接查询数据分享层即可得到。即席查询即席查询通常是现有的报表以及数据分享层的数据并不能知足需求需要从数据存储层直接查询。一般都是通过直接操作SQL得到。六、数据仓库的要求高效率数据仓库的分析数据一般分为日、周、月、季、年度等可以看出以日为周期的数据要求的效率最高要求24小时甚至12小时内客户能看到昨天的数据分析。由于有的企业每日的数据量很大假如数据仓库设计的不好需要延时一到两天才能显示数据这显然是不能出现这种事情的。数据质量高数据仓库所提供的各种信息肯定要准确的数据。数据仓库通常要经过数据清洗装载查询展现等多个流程而得到的假如复杂的架构会有更多层次那么由于数据源有脏数据或代码不严谨都可以导致数据不准确或有错误假如客户看到错误的信息就可能导致分析出错误的决策造成损失经济的损失。扩展性之所以有的大型数据仓库系统架构设计复杂是因为考虑到了将来3-5年度的扩展性因为假如在将来需要扩展一些新的功能了就可以不用重建数据仓库系统就能很稳定运行。因为重建一个数据创库是比拟消耗人力以及财力。可扩展性主要表达在数据建模的合理性。为了到达上述的要求建立起一个高效率、高数据质量、良好的可扩展性再加上为了进步建仓的速度根据在实际消费环境中的经历的总结于是就提出来了数据仓库的分层概念。那么到底什么是数据仓库的分层为什么要分成?数据仓库的分层的好处是什么呢接下来将介绍关于数据仓库分层的一些概念。七、数据仓库分层分层是数据仓库解决方案中数据架构设计的一种数据逻辑构造通过分层理念建立的数据仓库它的可扩展性非常好这样设计出来的模型架构可以任意地增减、交换数据仓库中的各个组成局部。用空间换时间通过大量的预处理来提升应用系统的用户体验效率因此数据仓库会存在大量冗余的数据。假如不分层的话假如源业务系统的业务规那么发生变化将会影响整个数据清洗经过工作量宏大。通过数据分层管理可以简化数据清洗的经过因为把原来一步的工作分到了多个步骤去完成相当于把一个复杂的工作拆成了多个简单的工作把一个大的黑盒变成了一个白盒每一层的处理逻辑都相对简单以及容易理解这样我们比拟容易保证每一个步骤的正确性当数据发生错误的时候往往我们只需要部分调整某个步骤即可。八、数据仓库四个层次的划分标准的数据仓库分层ODS临时存储层PDW数据仓库层MID数据集市层APP应用层。ODS临时存储层它以及源系统数据是同构的而且这一层数据粒度是最细的这层的表分为两种一种是存储当前需要加载的数据一种是用于存储处理完后的数据。PDW数据仓库层它的数据是干净的数据是一致的准确的也就是清洗后的数据它的数据一般都遵循数据库第三范式数据粒度以及ODS的粒度一样它会保存bi系统中所有历史数据。MID数据集市层它是面向主题组织数据的通常是星状以及雪花状数据从数据粒度来讲它是轻度汇总级别的数据已经不存在明细的数据了从广度来讲它包含了所有业务数量。从分析角度讲大概就是近几年度。App应用层数据粒度高度汇总但不一定涵盖所有业务数据只是MID层数据的一个子集。8.1ODS层 “面向主题的数据运营层是最接近数据源中数据的一层数据源中的数据经过抽取、洗净、传输也就讲传讲中的ETL之后装入本层。本层的数据总体上大多是按照源头业务系统的分类方式而分类的。例如这一层可能包含的数据表为人口表包含每个人的身份证号、姓名、住址等、机场登机记录包含乘机人身份证号、航班号、乘机日期、起飞城市等、银联的刷卡信息表包含银行卡号、刷卡地点、刷卡时间、刷卡金额等、银行账户表包含银行卡号、持卡人身份证号等等等一系列原始的业务数据。这里我们可以看到这一层面的数据还具有鲜明的业务数据库的特征甚至还具有一定的关系数据库中的数据范式的组织形式。但是这一层面的数据却不等同于原始数据。在源数据装入这一层时要进展诸如去噪例如去掉明显偏离正常程度的银行刷卡信息、去重例如银行账户信息、公安局人口信息中均含有人的姓名但是只保存一份即可、提脏例如有的人的银行卡被盗刷在特别钟内同时有两笔分别在中国以及日本的刷卡信息这便是脏数据、业务提取、单位统一、砍字段例如用于支撑前端系统工作但是在数据挖掘中不需要的字段、业务判别等多项工作。8.2PDW层数据仓库的主体在这里从ODS层中获得的数据按照主题建立各种数据模型。例如以研究人的旅游消费为主题的数据集中便可以结合航空公司的登机出行信息和银联络统的刷卡记录进展结合分析产生数据集。在这里我们需要解析四个概念维dimension、事实Fact、指标Index以及粒度Granularity。PDM层数据集市从数据的时间跨度来讲通常是DW层的一局部按照业务划分如流量、订单、用户等生成字段比拟多的宽表用于提供后续的业务查询OLAP分析数据分发等。8.3APP层在这里主要是提供应数据产品以及数据分析使用的数据一般会存放在es、mysql等系统中供线上系统使用可以能会存在Hive或Druid中供数据分析以及数据挖掘使用。比方我们经常讲的报表数据或讲那种大宽表一般就放在这里。九、数据流向数据来源层ODS层这里其实就是我们如今大数据技术发挥作用的一个主要战场。我们的数据主要会有两个大的来源1、业务库这里经常会使用sqoop来抽取比方我们每天定时抽取一次。在实时方面可以考虑用canal监听mysql的binlog实时接入即可。2、埋点日志线上系统会打入各种日志这些日志一般以文件的形式保存我们可以选择用flume定时抽取可以以用用sparkstreaming或storm来实时接入当然flumekafka是企业常用的组合。其它数据源会比拟多样性这以及详细的业务相关不再赘述。ODS层APP层这里面也主要分两种类型1、每日定时任务型比方我们典型的日计算任务每天凌晨算前一天的数据早上起来看报表。这种任务经常使用Hive、Spark或MR程序来计算最终结果写入Hive、Hbase、Mysql、Es或Redis中。2、实时数据这局部主要是各种实时的系统使用比方我们的实时推荐、实时用户画像一般我们会用SparkStreaming、Storm或Flink来计算最后会落入Es、Hbase或Redis中。PDW层-APP层pdw分析完的数据一般借助sqoop传输到关系型数据库如mysqlapp层根据业务需要以可视化的形式展示给决策层BOSS。十、数据仓库模型设计根底10.1维度数据模型维度数据模型简称维度模型Dimensionalmodeling,DM是一套技术以及概念的集合用于数据仓库设计。不同于关系数据模型维度模型不一定要引入关系数据库。在逻辑上一样的维度模型可以被用于多种物理形式比方维度数据库或者是简单的平面文件。根据数据仓库大师Kimball的观点维度模型是一种趋向于支持最终用户对数据仓库进展查询的设计技术是围绕性能以及易理解性构建的。尽管关系模型对于事务处理系统表现非常出色但它并不是面向最终用户的。事实以及维度是两个维度模型中的核心概念。事实表示对业务数据的度量而维度是观察数据的角度。事实通常是数字类型的可以进展聚合以及计算而维度通常是一组层次关系或者描绘信息用来定义事实。例如销售金额是一个事实而销售时间、销售的产品、购置的顾客、商店等都是销售事实的维度。维度模型按照业务流程领域即主题域建立例如进货、销售、库存、配送等。不同的主题域可能分享某些维度为了进步数据操作的性能以及数据一致性需要使用一致性维度例如几个主题域间分享维度的复制。术语“一致性维度源自Kimball指的是具有一样属性以及内容的维度。10.2维度数据模型建模经过维度模型通常以一种被称为星型形式的方式构建。所谓星型形式就是以一个事实表为中心周围环绕着多个维度表。还有一种形式叫做雪花形式是对维度做进一步标准化后形成的。一般使用下面的经过构建维度模型选择业务流程声明粒度确认维度确认事实这种使用四步设计法建立维度模型的经过有助于保证维度模型以及数据仓库的可用性。1选择业务流程确认哪些业务处理流程是数据仓库应该覆盖的是维度方法的根底。因此建模的第一个步骤是描绘需要建模的业务流程。例如需要解析以及分析一个零售店的销售情况那么与该零售店销售相关的所有业务流程都是需要关注的。为了描绘业务流程可以简单地使用纯文本将相关内容记录下来或使用“业务流程建模标注BPMN方法可以以使用统一建模语言UML或者其他类似的方法。2声明粒度确定了业务流程后下一步是声明维度模型的粒度。这里的粒度用于确定事实中表示的是什么例如一个零售店的顾客在购物小票上的一个购置条目。在选择维度以及事实前必须声明粒度因为每个候选维度或者事实必须与定义的粒度保持一致。在一个事实所对应的所有维度设计中强迫实行粒度一致性是保证数据仓库应用性能以及易用性的关键。从给定的业务流程获取数据时原始粒度是最低级别的粒度。建议从原始粒度数据开场设计因为原始记录可以知足无法预期的用户查询。汇总后的数据粒度对优化查询性能很重要但这样的粒度往往不能知足对细节数据的查询需求。不同的事实可以有不同的粒度但同一事实中不要混用多种不同的粒度。维度模型建立完成之后还有可能因为获取了新的信息而回到这步修改粒度级别。3确认维度设计经过的第三步是确认模型的维度。维度的粒度必须以及第二步所声明的粒度一致。维度表是事实表的根底也讲明了事实表的数据是从哪里收集来的。典型的维度都是名词如日期、商店、库存等。维度表存储了某一维度的所有相关数据例如日期维度应该包括年度、季度、月、周、日等数据。4确认事实确认维度后下一步也是维度模型四步设计法的最后一步就是确认事实。这一步识别数字化的度量构成事实表的记录。它是以及系统的业务用户亲密相关的因为用户正是通过对事实表的访问获取数据仓库存储的数据。大局部事实表的度量都是数字类型的可累加可计算如本钱、数量、金额等。10.3维度标准化与关系模型类似维度可以以进展标准化。对维度的标准化又叫雪花化可以去除冗余属性是对非标准化维度做的标准化处理在下面介绍雪花模型时会看到维度标准化的例子。一个非标准化维度对应一个维度表标准化后一个维度会对应多个维度表维度被严格地以子维度的形式连接在一起。实际上在很多情况下维度标准化后的构造等同于一个低范式级别的关系型构造。设计维度数据模型时会因为如下原因此不对维度做标准化处理标准化会增加表的数量使构造更复杂。不可防止的多表连接使查询更复杂。不合适使用位图索引。查询性能原因。分析型查询需要聚合计算或者检索很多维度值此时第三范式的数据库会遭遇性能问题。假如需要的仅仅是操作型报表可以使用第三范式因为操作型系统的用户需要看到更细节的数据。正如在前面关系模型中提到的对于是否应该标准化的问题存在一些争论。总体来讲当多个维度共用某些通用的属性时做标准化会是有益的。例如客户以及供给商都有省、市、区县、街道等地理位置的属性此时别离出一个地区属性就比拟适宜。10.4维度数据模型的特点易理解相对于标准化的关系模型维度模型容易理解且更直观。在维度模型中信息按业务种类或者维度进展分组这会进步信息的可读性也方便了对于数据含义的解释。简化的模型也让系统以更为高效的方式访问数据库。关系模型中数据被分布到多个离散的实体中对于一个简单的业务流程可能需要很多表结合在一起才能表示。高性能维度模型更倾向于非标准化因为这样可以优化查询的性能。介绍关系模型时屡次提到标准化的本质是减少数据冗余以优化事务处理或者数据更新的性能可扩展维度模型是可扩展的。由于维度模型允许数据冗余因此当向一个维度表或者事实表中添加字段时不会像关系模型那样产生宏大的影响带来的结果就是更容易包容不可意料的新增数据。这种新增可以是单纯地向表中增加新的数据行而不改变表构造可以以是在现有表上增加新的属性。基于数据仓库的查询以及应用不需要太多改变就能适应表构造的变化老的查询以及应用会继续工作而不会产生错误的结果。但是对于标准化的关系模型由于表之间存在复杂的依赖关系改变表构造前一定要仔细考虑。10.5星形模型starschema星型形式是维度模型最简单的形式也是数据仓库和数据集市开发中使用最广泛的形式。星型形式由事实表以及维度表组成一个星型形式中可以有一个或者多个事实表每个事实表引用任意数量的维度表。星型形式的物理模型像一颗星星的形状中心是一个事实表围绕在事实表周围的维度表表示星星的放射状分支这就是星型形式这个名字的来历。星型形式将业务流程分为事实以及维度。事实包含业务的度量是定量的数据如销售价格、销售数量、间隔、速度、重量等是事实。维度是对事实数据属性的描绘如日期、产品、客户、地理位置等是维度。一个含有很多维度表的星型形式有时被称为蜈蚣形式显然这个名字也是因其形状而得来的。蜈蚣形式的维度表往往只有很少的几个属性这样可以简化对维度表的维护但查询数据时会有更多的表连接严重时会使模型难于使用因此在设计中应该尽量防止蜈蚣形式。1事实表事实表记录了特定事件的数字化的考量一般由数字值以及指向维度表的外键组成。通常会把事实表的粒度级别设计得比拟低使得事实表可以记录很原始的操作型事件但这样做的负面影响是累加大量记录可能会更耗时。事实表有以下三种类型事务事实表。记录特定事件的事实如销售。快照事实表。记录给定时间点的事实如月底账户余额。累积事实表。记录给定时间点的聚合事实如当月的总的销售金额。一般需要给事实表设计一个代理键作为每行记录的唯一标识。代理键是由系统生成的主键它不是应用数据没有业务含义对用户来讲是透明的。2维度表维度表的记录数通常比事实表少但每条记录包含有大量用于描绘事实数据的属性字段。维度表可以定义各种各样的特性以下是几种最长用的维度表时间维度表。描绘星型形式中记录的事件所发生的时间具有所需的最低级别的时间粒度。数据仓库是随时间变化的数据集合需要记录数据的历史因此每个数据仓库都需要一个时间维度表。地理维度表。描绘位置信息的数据如国家、省份、城市、区县、等。产品维度表。描绘产品及其属性。人员维度表。描绘人员相关的信息如销售人员、市场人员、开发人员等。范围维度表。描绘分段数据的信息如高级、中级、低级等。通常给维度表设计一个单列、整型数字类型的代理键映射业务数据中的主键。业务系统中的主键本身可能是自然键可以能是代理键。自然键指的是由现实世界中已经存在的属性组成的键如身份证号就是典型的自然键。3优点星型形式是非标准化的在星型形式的设计开发经过中不受应用于事务型关系数据库的范式规那么的约束。星型形式的优点下简化查询。查询数据时星型形式的连接逻辑比拟简单而从高度标准化的事务模型查询数据时往往需要更多的表连接。简化业务报表逻辑。与高度标准化的形式相比由于查询更简单因此星型形式简化了普通的业务报表如每月报表逻辑。获得查询性能。星型形式可以提升只读报表类应用的性能。快速聚合。基于星型形式的简单查询可以进步聚合操作的性能。便于向立方体提供数据。星型形式被广泛用于高效地建立OLAP立方体几乎所有的OLAP系统都提供ROLAP模型关系型OLAP它可以直接将星型形式中的数据当作数据源而不用单独建立立方体构造。4缺点星型形式的主要缺点是不能保证数据完好性。一次性地插入或者更新操作可能会造成数据异常而这种情况在标准化模型中是可以防止的。星型形式的数据装载一般都是以高度受控的方式用批处理或者准实时经过执行的以此来抵消数据保护方面的缺乏。星型形式的另一个缺点是对于分析需求来讲不够灵敏。它更侧重于为特定目的建造数据视图因此实际上很难进展全面的数据分析。星型形式不能自然地支持业务实体的多对多关系需要在维度表以及事实表之间建立额外的桥接表。10.6雪花模型snowflakeschema雪花形式是一种多维模型中表的逻辑布局其实体关系图有类似于雪花的形状因此得名。与星型形式一样雪花形式也是由事实表以及维度表所组成。所谓的“雪花化就是将星型形式中的维度表进展标准化处理。当所有的维度表完成标准化后就形成了以事实表为中心的雪花型构造即雪花形式。将维度表进展标准化的详细做法是把低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数如主键列具有唯一值所以有最高的基数而像性别这样的列基数就很低。在雪花形式中一个维度被标准化成多个关联的表而在星型形式中每个维度由一个单一的维度表所表示。一个标准化的维度对应一组具有层次关系的维度表而事实表作为雪花形式里的子表存在具有层次关系的多个父表。星型形式以及雪花形式都是建立维度数据仓库或者数据集市的常用方式适用于加快查询速度比高效维护数据的重要性更高的场景。这些形式中的表没有十分的标准化一般都被设计成一个低于第三范式的级别。1数据标准化与存储标准化的经过就是将维度表中重复的组别离成一个新表以减少数据冗余的经过。正因为如此标准化不可防止地增加了表的数量。在执行查询的时候不得不连接更多的表。但是标准化减少了存储数据的空间需求而且进步了数据更新的效率。这点在前面介绍关系模型时已经进展了详细的讨论。从存储空间的角度看典型的情况是维度表比事实表小很多。这就使得雪花化的维度表相对于星型形式来讲在存储空间上的优势没那么明显了。举例来讲假设在220个区县的200个商场共有100万条销售记录。星型形式的设计会产生1,000,200条记录其中事实表1,000,000条记录商场维度表有200条记录每个区县信息作为商场的一个属性显式地出如今商场维度表中。在标准化的雪花形式中会建立一个区县维度表该表有220条记录商场表引用区县表的主键有200条记录事实表没有变化还是1,000,000条记录总的记录数是1,000,4201,000,000200220。在这种特殊情况作为子表的商场记录数少于作为父表的区县记录数下星型形式所需的空间反而比雪花形式要少。假如商场有10,000个情况就不一样了星型形式的记录数是1,010,000雪花形式的记录数是1,010,220从记录数上看还是雪花模型多。但是星型形式的商场表中会有10,000个冗余的区县属性信息而在雪花形式中商场表中只有10,000个区县的主键而需要存储的区县属性信息只有220个当区县的属性很多时会大大减少数据存储占用的空间。有些数据库开发者采取一种折中的方式底层使用雪花模型上层用表连接建立视图模拟星型形式。这种方法既通过对维度的标准化节省了存储空间同时又对用户屏蔽了查询的复杂性。但是当外部的查询条件不需要连接整个维度表时这种方法会带来性能损失。2优点雪花形式是以及星型形式类似的逻辑模型。实际上星型形式是雪花形式的一个特例维度没有多个层级。某些条件下雪花形式更具优势一些OLAP多维数据库建模工具专为雪花模型进展了优化。标准化的维度属性节省存储空间。3缺点雪花模型的主要缺点是维度属性标准化增加了查询的连接操作以及复杂度。相对于平面化的单表维度多表连接的查询性能会有所下降。但雪花模型的查询性能问题近年度来随着数据阅读工具的不断优化而得到缓解。以及具有更高标准化级别的事务型形式相比雪花形式并不确保数据完好性。向雪花形式的表中装载数据时一定要有严格的控制以及管理防止数据的异常插入或者更新。10.7事实星座模型FactConstellation或者星系模型galaxyschema数据仓库由多个主题构成包含多个事实表而维表是公共的可以分享这种形式可以看做星型形式的聚集因此称作星系形式或事实星座形式。本形式例如如下列图所示如上图所示事实星座形式包含两个事实表sales以及shipping二者分享维表。十一、总结事实星座形式是数据仓库最长使用的数据形式尤其是企业级数据仓库EDW。这也是数据仓库区别于数据集市的一个典型的特征从根本上而言数据仓库数据模型的形式更多是为了防止冗余以及数据复用套用现成的形式是设计数据仓库最合理的选择。当然大数据技术体系下数据仓库数据模型的设计还是一个盲点探究中。本文为在CSDNboke首发原文链接s:/同时欢送所有开发者扫描下方二维码填写?开发者与AI大调研?只需2分钟便可收获价值299元的AI开发者万人大会在线直播门票!推荐浏览怎样成功构建大规模Web搜索引擎架构“出道5年度采用率达78%Kubernetes的成功秘诀是什么一群阿里人怎样用10年度自研洛神云网络平台技术架构演进全揭秘拿下Gartner容器产品第一阿里云打赢云原生关键一战大话卷积神经网络CNN小白也能看懂的深度学习算法教程全程干货建议珍藏朱广权李佳琦直播掉线1.2亿人在线等“抗疫新战术世卫组织结合IBM、甲骨文、微软构建了一个开放数据的区块链工程真香朕在看了CSDN云计算