维度建模四个步骤,维度分析怎么做

1.维度表概述     维度表是对业务过程的上下文描述，主要包含代理键、文本信息和离散的数字。它是进入事实表的入口，丰富的维度属性给出了对事实表的分析切割能力，它一般是行少列多。如果属性值是离散的，用于过滤和标记的，就放到维度表里，如果是属性值是连续取值，用于计算的，就放到事实表中。   2.维度的基本设计方法     维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所有生成维度属性的优势，决定了维度使用的方便性。     Kimball所说，数据仓库的能力直接与维度属性的质量和深度成正比。 2.1 第一步：选择维度或新建维度     作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性，以淘宝商品维度为例，有且只允许有一个维度定义； 2.2 第二步：确定主维表     此处的主维表一般是ODS表，直接与业务系统同步。以淘宝商品维度为例，s_auction_auctions是与前台商品中心系统同步的商品，此表即是主维表； 2.3 第三步：确定相关维表     数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以淘宝商品维度为例，根据对业务的逻辑梳理，可以得到商品与类目、SPU、卖家、店铺等维度存在关联关系； 2.4 第四步：确定维度属性     第一个阶段是从主维表选择维度属性或生成新的维度属性；     第二个阶段是从相关维表中选择维度属性或生成新的属性； 确定维度属性的几点提示： 尽可能生成丰富的维度属性； 尽可能多地给出包括一些富有意思的文字性描述； 区分数值型属性和事实； 尽量沉淀出通用的维度属性；   3.维度设计高级主题 3.1 维度整合     数据仓库：是一个面向主题、集成的、非易失的且随时间变化的数据集合，用来支持管理人员的决策。其中继承是数据仓库的四个特性中最重要的一个；     数据仓库的重要数据来源是大量的、分散的面向应用的操作型环境。不同的应用在设计过程中，可以自由决策，主要满足本应用的需求，很少会考虑或其他系统进行数据集成。应用之间的差异表现在如下几个方面： 应用在编码、命名、度量单位等方面会存在很大的差异； 应用处于性能和扩展性的考虑，或者随着技术架构的演变，以及业务的发展，采用不同的物理实现；     所有数据由面向应用的操作型环境进入数据仓库后，需要进行数据集成。将面向应用的数据转换为面向主题的数据仓库数据，本身就是一种集成，具体方面： 命名规范的统一；（表名、字段名等统一） 字段类型的统一；（相同和相似字段的字段类型统一） 公共代码以及码值的统一；（公共代码以及标志性字段的数据类型、命名方式等统一） 业务含义相同的表的统一；（高内聚、低耦合在屋里中的实现，将业务关系大、源系统影响差异小的表进行整合），下面有几种集成的方式： 采用主从表的设计方式，将两个表或者多个表都有的字段放在主表中（主要信息表），从属信息分别放在各自的从表中。对于主表中的主键，要么采用符合主键、源主键和系统或表区别标志；要么采用唯一主键、“源主键和系统或表区别标志”生成新的主键。通常建议采用复合主键的方式； 直接合并，共有信息和个性信息都放在同一个表中。如果表字段重合度较低，则会出现大量空置，对于存储和易用性会有影响，需要谨慎选择； 不合并，因为源表的表结构以及主键等差异很大，无法合并，使用数据仓库里的多个表存放各自的数据； 3.2 表级别的整合 第一种是垂直整合，即不同来源表包含相同的数据集，只是存储信息不同。 比如淘宝会员在源系统中有多个表，如会员基础信息表、会员扩展信息表、淘宝会员等级信息表、天猫会员登记信息表，这些表都属于会员相关信息表，依据维度设计方法，尽量整合至会员维度模型中，丰富其维度属性； 第二种是水平整合，即不同来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。 比如针对蚂蚁金服的数据仓库，其采集的会员数据有淘宝会员、1688会员、国际站会员、支付宝会员等，是否需要将所有的会员整合到一个会员表中呢？如果进行整合首先需要考虑各个会员体系是否有交叉，如果存在交叉，则需要去重； 如果不存在交叉，则需要考虑不同子集的自然键是否存在冲突，如果不冲突，则考虑将各子集的自然键作为整合后的表的自然键； 另一种方式是设置超自然键，将来源表各子集的自然键加工称为一个字段作为超自然键。在阿里巴巴，通常采用将来源表各子集的自然键作为联合主键的方法，并且在屋里上实现时将来源字段作为分区字段； 3.3 表级别的拆分 第一种是水平拆分，维度通常可以按照类别或类型进行细分。 如淘系商品表，根据业务线或行业等可以对商品进行细分，如淘宝的商品、天猫的商品、1699的商品、飞猪旅行的商品、淘宝海外的商品、天猫国际的商品等； 不同分类的商品，其维度属性可能相同，也可能不同。 比如航旅的商品和普通的淘系商品，都属于商品，都有价格、标题、类型、上架时间、类目等维度属性； 但是航旅的商品除了这些公共属性外，还有酒店、景点、门票、旅行等自己独特的维度属性； 第二种是垂直拆分 ，在进行维度设计时，依据维度设计的原则，尽可能丰富维度属性，同时进行反规范化处理。 3.4 历史归档 归档策略1: 同前台归档策略，在数据仓库中实现前台归档算法，定期对历史数据进行归档。但是存在一些问题，一是前台归档策略复杂，实现成本较高；二是前台归档策略可能经常会变化，导致数据仓库归档算法也要随着变化，维护和沟通成本较高。此方法适用于前台归档策略较为简单，且变更不频繁的情况； 归档策略2: 同前台归档策略，但采用数据库变更日志的方式。对于如此庞大的数据里那个，阿里巴巴采用的数据抽取策略一般是通过数据库的binlog日志解析获取每日增量，通过增量merge全量的方式获取最新的全量数据。可以使用增量日志的删除标志，作为前台数据归档的标志；此策略不需要关注前台归档的策略，简单易行。但是对于前台应用的要求是数据库的物理删除只有在归档时才执行，应用中的删除只是逻辑删除； 归档策略3: 数据仓库自定义归档策略，可以将归档算法用简单、直接的方式实现，但原则是尽量比前台应用晚归档，少归档。避免出现数据仓库中已经归档的数据再次更新； 注意：如果技术条件允许，能够解析数据库binlog日志，建议使用归档策略2，规避前台归档算法。具体可以根据自身数据仓库的是实际情况进行选择；   4.维度表的分类 4.1 缓慢变化维 类型1：字段值发生变化时覆盖原来的值。  类型2：字段值发生变化时会新增一行，重新分配代理键，每一行添加开始日期，结束日期，版本号，是否当前值。 类型3；每条记录会新增一列来标识变化前的值，发生变化时，把旧值放到新增的列中，把新值覆盖旧值。 4.2 日期维     它是数据仓库必须有的维度，包含日期，日期所属的周，月，季度，年等信息。  4.3 角色维      相同的维度表在维度模型中扮演不中的逻辑角色，一般通过创建视图来表示。 4.4 杂项维     如果每个属性值都很少，可以把这些维度的组合起来生成一个维度表。  4.5 支架维     如果维度之间是一对多的关系或区别于原维度的多个描述性维度属性，可以建雪花型支架维度。 4.6 多值维度桥接维     如果二个维度表是多对多的关系，可以使用多值维度设计。 4.7 微型维      一个大型维有些属性变化比较频繁，把这些属性单独生成一个微型维度表。 4.8 缩小维     它是维度表的一个子集或部分属性。 4.9 查找维     系统里代码表里维度信息。 4.10 层次维     有些维度表是有层次结构的，可以通过视图生成树形结构的维度表。 4.11 手工维护的维表      有些数据不在业务系统里，需要业务用户手工维护的维度表。