深入理解数据仓库建模.docxVIP

深入理解数据仓库建模 一、数据仓库建模的意义如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话：“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，最能够说明数据模型的重要性。 只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。 性能：帮助我们快速查询所需要的数据，减少数据的I/O吞吐，提高使用数据的效率，如宽表。成本：极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低存储和计算成本。效率：在业务或系统发生变化时，可以保持稳定或很容易扩展，提高数据稳定性和连续性。 质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。 数据模型能够促进业务与技术进行有效沟通，形成对主要业务定义和术语的统一认识，具有跨部门、中性的特征，可以表达和涵盖所有的业务。 大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡！ 下图是个示例，通过统一数据模型，屏蔽数据源变化对业务的影响，保证业务的稳定，表述了数据仓库模型的一种价值： 二、数据仓库分层的设计 以下是我们的一种分层设计方法，数据缓冲区（ODS）的数据结构与源系统完全一致。基础数据模型(DWD)和融合数据模型（DWI与DWA）是大数据平台重点建设的数据模型。应用层模型由各应用按需自行建设，其中基础数据模型一般采用ER模型，融合数据模型采用维度建模思路。 三、两种经典的数据仓库建模方法 前面的分层设计中你会发现有两种设计方法，关系建模和维度建模，下面分别简单介绍其特点和适用场景。 当今的数据处理方式大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。二者的主要区别对比如下表所示 1、维度建模（1）定义 维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。 在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型。 星座模型与前两种情况的区别是事实表的数量，星座模型是基于多个事实表基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座不星座只反映是否有多个事实表，他们之间是否共享一些维度表。所以星座模型并不和前两个模型冲突 星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。 首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不用选择。星型还是雪花，取决于性能优先，还是灵活更优先目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存 (一层维度和多层维度都保存) 。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少Join就是减少Shuffle，性能差距很大(关系型数据可以依靠强大的主键索引) （2）建模方法 选择业务过程→声明粒度→确认维度→确认事实 （a）选择业务过程 在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。 如果是中小公司，尽量把所有业务过程都选择。如果是大公司（1000多张表），选择和需求相关的业务线。（b）声明粒度 数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。 声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。 典型的粒度声明如下： 订单当中的每个商品项作为下单事实表中的一行，粒度为每次。 每周的订单次数作为一行，粒度为每周。 每月的订单次数作为一行，粒度为每月。 如果在DWD层粒度就是每周或者每月，那么后续就没有办法统计细粒度的指标了。所以建议采用最小粒度。 （c）确定维度 维度的主要作用是描述业务是