核心技术：维度建模.docxVIP

核心技术：维度建模 在实际开发中，我们不管是基于 Hadoop 的数据仓库（如 Hive ），还是基于传统 MPP 架构的数据仓库（如Teradata ），抑或是基于传统 Oracle 、MySQL 、MS SQL Server 关系型数据库的数据仓库，其实都会面临如下问题： 怎样组织数据仓库中的数据？ 怎样组织才能使得数据的使用最为便利和便捷？ 怎样组织才能使得数据仓库具有良好的可扩展性和可维护性？ Ralph Kimball 维度建模理论很好地回答和处理了上述问题 维度建模理论和技术也是目前在数据仓库领域中使用最为广泛的、也最得到认可和接纳的一项技术。今日我们就来深化探讨 Ralph Kimball 维度建模?的各项技术，涵盖其基本理论、一般过程、维度表设计和现实表设计等各个方面，也为后面讲Hadoop 数据仓库实战打下基础。 维度建模关键概念 度量和环境 维度建模是支持对业务过程的分析，所以它是通过对业务过程度量进行建模来实现的。 那么，什么是度量呢？ 实际上，我们通过和业务方、需求方交谈，或者阅读报表、图表等，可以很简约地识别度量。 考虑如下业务需求： 店铺上个月的销售额如何？ 店铺库存趋势如何？ 店铺的访问情况如何（ pv，uv) ? 店铺访问的熟客占比多少？ 这里的销售额、库存、访问量、熟客量就是度量。 但是，单单谈论度量，是没有意义的。 度量和环境这两个概念构成了维度建模的基础。而全部维度建模也正是通过对度量和 及其上下文和环境的具体设计来实现的。 现实和维度 在 Kimball 的维度建模理论中，度量称为现实，上下文和环境则称为维度。 通常来说，现实常以数值方式消灭，而且一般都被大量文本方式的上下文包围着。 这些文本方式的上下文描述了现实的?“ 5个W ”（ When 、 Where 、 What 、 Who 、 Why ）信息，通常可被直观地分割为独立的规律块，每一个独立的规律块即为一个维度，比如一个订单可以格外直观地分为商品 、买家、卖家等多个维度。 在维度建模和设计过程中，可以依据需求描述或者基于现有报表，很简约地将信息和分析需求分类到现实和度量中。 比如业务人员需求为“依据一级类目，统计本店铺上月的销售额情况”，“依据一级类目”这个描述，很清楚地说明需求方期望对一级类目的销售额进行统计分析，这里的一级类目即为一个维度 。类似的是，“上月”为另一个维度，而销售额明显是现实。 现实表 现实表是维度模型中的基本表，或者说核心表 现实上，业务过程的全部度量在维度建模中都是存储在现实表中的，除此之外，现实表还存储了引用的维度。 现实表通常和一个 企业的业务过程 紧密相关，由于一个企业的业务过程数据构成了其全部数据的绝大部分，因而现实表也通常占用了数据仓库存储的绝大部分。 比如对于某个超市来说，其 销售的明细数据 通常占其拥有数据的绝大部分且每天还在不断地累计和增长，而商品、门店、员工、设备等其他数据相对来说固定且变化不大。 现实表的一行对应一个度量大事 现实上，每行对应的度量大事可粗可细，比如对某个超市来说，在设计其维度模型时，表示顾客购买大事的现实表的一行即可以记录一张顾客的小票，也可以记录顾客小票的一个子项。 那么我们到底应当到何种级别呢？ 维度建模认为现实表应当包含最底层的、最原子性的细节，由于这样会带来最大的机警性 维度建模中，细节的级别称为现实表的粒度，比如上文顾客购买行为现实表的粒度就应当是小票子项，而非小票。 现实表中最常用的度量一般是数值型和可加类型的 比如小票子项的销售数量、销售金额等，可加性对于数据分析来说至关重要，由于数据应用一般不只检索现实表的单行数据，而往往一次性检索数百、数千乃至百万行的现实，并且处理这么多行的最有用的和最常见的事就是将它们加起来，而且是从各个角度和维度加起来。 但现实表中的度量并不都是可加的，有些是半可加性质的，另一些则是非可加性质的 半加性现实是指仅仅某些维度可加，例如库存，可以把各个地方仓库的库存加起来，或者把一个仓库不同的商品加起来，但是很明显不能把一个仓库同一商品在不同时期的库存加起来。 银行的账户余额也是半可加现实的例子，可以把不同分行的账户余额加起来或者不同账户人的账户余额加起来，但是不能把不同月份的账户余额加起来。 非可加性现实则根本就不能相加的现实，比如商品的价格以及订单的形态等。 除了存储的现实外，现实表都会包含多个相关的外键 用于关联和连接相应的维度表。 例如，订单现实表会包含连接到商品表的商品外键、连接到会员表的买家外键、或者连接到门店表的门店外键等。 正是通过这些外键，才能进行各个角度的、各个维度的分析。 现实表依据粒度的角色划分不同，可分为事务现实表、周期快照现实表和累积快照现实表。 事务现实表用于承载事务数据，通常粒度比较低，例如产品买卖