锐客网

  1. 首页 > it技术 > >

工作实践|数据仓库建设思想五--维度设计

一、概述 1、概念
维度建模思想事数据仓库领域的另一位大师 Ralph Kimball 所倡导，按照书中主要思想，维度建模并不要求维度建模满足三范式，数据库中强调3NF 主要是为了消除冗余。规范化的 3NF 将数据划分为多个不同的实体，每个实体构成一个关系表。比如说订单数据库，开始可能是每个订单中的一行表示一条记录，到后来为了满足3NF会变成类似蜘蛛网状图。也许会包含上百个规范化表。而且对于BI查询来讲，规范化模型太复杂，用户会难以理解这些记录和模型的使用。而且维度建模解决了模型过于复杂的问题。
维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实”将环境描述为“维度”，而维度所包含的表示维度的列，我们称之为维度属性。维度属性事查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。（。例如，在查询请求中，获取某类目的商品、正常状态的商品等，是通过约束商
品类目属性和商品状态属性来实现的；统计淘宝不同商品类目的每日成交金额，是通过商品维度的类目属性进行分组的）
2、维度和维度属性的获取
**维度使用主键标志其唯一性，**再维度建模过程中主键有两种：代理键和自然键，它们都是用于标识某维度的具体值。但代理键是不具有业务含义的键， 般用于处理缓慢变化维；自然键是具有业务含义的键。比如商品，（在在 ETL程中，对于商品维表的每一行，可以生成一个唯一的代理键与之对应；商品本身的自然键可能是商品 ID 等。其实对于前台应用系统来说，商品ID 是代理键：而对于数据仓库系统来说，商品 ID 则属于自然键）
而维度和维度属性的获取一般我们可以通过报表中，也可以通过业务分析中按照by 分组的语句中获得到。
3、维度基本设计方法
维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成的维度属性的优劣，决定了维度使用的方便性，成为数据仓库易用性的关键。
第一步：**选择维度或新建维度，作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以电商商品维度为例，有且只允许有一个维度定义。
第二步 确定主维表。此处的主维表一般是 ODS 表，直接与业务系统同步。以电商商品维度为例， 一般会同步前台商品中心系统同步的商品表，此表即是主维表。
第三步：确定相关维表。**数据仓库是业务源系统的数据整合，不同业务系统或者同 业务系统中的表之间存在关联性。商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、 SPU 卖家、店铺等维度存在关联关系。
第四步 **：确定维度属性。**本步骤主要包括两个阶段，第一个步骤是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或产生新的维度属性。同样以商品维度为例子。从
主维表 和类目、 SPU 、卖家、店铺等相关维表中选择维度属性或生成新的维度属性。
注意：确定维度属性的几点提示：
（1）、尽可能生成丰富的维度属性。
比如淘宝商品维度有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基础。
（2）、尽可能多地给出包括一些富有意义的文字性描述
属性不应该是编码，而应该是真正的文字。如在一般维度建模中，要求是编码和文字同时存在，比如商品维度中的商品 ID 和商品标题、类目 ID 类目名称等。 ID 般用于不同表之间的关联，而名称一般用于报表标签。
(3）、区分数值型属性和事实
数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性；如果通常用于参与度量的计算， 则是作为事实。比如商品价格，可以用于查询约束条件或统计价格区间 的商品数量，此时是作为维度属性使用的；也可以用于统计某类目 下商品的平均价格，此时是作为事实使用的。
(4)、尽量沉淀出通用的维度属性
有些维度属性获取需要进行比较复杂的逻辑处理，需要将尽可能多的通用的维度属性进行沉淀。一方面，可以提高下游使用的方便性，减少复杂度；另 一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。（有些需要通过多表关联得到，或者通过单表的不同宇段混合处理得到，或者通过对单表的某个字段进行解析得到。）例如淘宝的例子，中商品是否在线就需要我们对数据进行加工处理。（商品状态为0和1且商品上架时间小于或等于当前时间，则为在线商品；否则是非在商品。所以需要封装商品是否在线的逻辑作为 个单独的属性字段。）
4、维度设计之维度的层次
维度中的一些描述属性以层次的方式或一对多的方式相关关联，可以被理解未包含连续的主从关系的属性层次。层次的最底层电表维度中描述的最低级别的详细信息，最高层代表最高级别的概要信息。维度常常有多个这样的嵌入式的层次结构。（例如：淘宝商品维度，有卖家、类目、品牌等。商品属于类目，类目属于行业，其中类目的最低级别是叶子类目，叶子类目属于二级类目，二级类目属于一级类目。）
在属性的层次结构中进行钻取是数据钻取的方法之一。（例如：已有一个淘宝交易订单，创建事实表现在统计下单GMV,得到一行记录；沿着层次向下钻取，添加行业，等到行业实例个数的记录数；继续沿着层次向下钻取，添加行业。等到行业实例个数的记录数；继续向下钻取，添加一级类目。等到一级类目实例个数的记录数。可以看到，通过向报表中添加连续的维度细节级别，实现层次结构中进行钻取）
5、规范化和反规范化
与范化处理相对应的是反规范化。其反规范化的意思是经维度属性的多个层次合并到单个维度中。而我们一般在范化处理（一般采用雪花模型）中，用户在统计分析过程中需要大量的关联操作，使用复杂度较高，查询麻烦且性能很差；而我们采用反规范化的处理则方便、易用且性能好。对于例子中，如果采用反规范化处理，将表现为
工作实践|数据仓库建设思想五--维度设计
文章图片

综上：从用户角度来看简化了模型，并且使数据库查询优化器的连接路径比完全规范化的模型简化许多。反规范化的维度仍包含与规范化模型同样的信息和关系，从分析角度来看，没有丢失任何信息，但
复杂性降低了。
6、一致性维度和交叉探查**（统一维度的方式）**
数据仓库总线架构的重要基石之一是一致性维度。在针对不同数据域进行迭代构建或并行构建时。存在很多需求是对于不同数据域的业务过程或同一个数据域的业务工程合并在一起观察的。比如对于日志域中，统计了商品维度的最近一天的PV和UV; 对于交易数据域，统计了商品尾端的最近一天的PV和UV; 对于纪要数据域，统计了商品维度最近一天的下单GMV。现在将不同数据域的上坪事实合并在疫情精选数据探查，如计算转化率，称职位交叉探查。
如果不同数据域的计算过程使用的维度不 致，就会导致交叉探查存在 问题 当存在 复的维度，但维度属性或维度属性 值不 致时，会导 叉探查无法进行或 叉探查结果错误。接上个例子，假设对于日志数据域，统计使用的是商品维度 ；对于交易数据域，统计使用的是商品维度 商品维度 包含维度属性 类型 而商品维度2无此属性，则无法在 BC 类型上进行交叉探查；商品维度 的商品上架时间这一维度属性时间格式是 yyyy-MM-dd HH:mm:ss ，商品维度 的商品上架时间这一维度属性时间格式是 UNIX timestamp ，进行交叉探查时如果需要根据商品上架时间做限制，则复杂性较高；商品维度 不包阿里旅行的商品，商品维度 包含全部的淘系商品，交叉探查也无法进行。还有很多种形式的不一致，这里不再一一列举，但基本可以划分为维度格式和内容不一致两种类型。
【工作实践|数据仓库建设思想五--维度设计】上面对维度不一致性进行了详细分析，下面总结维度一致性的几种表现形式。
1）、共享维表。 比如在的数据仓库中，商品、卖家、买家、类目等维度有且只有一个。所以基于这些公共维度进行的交叉探查不会存在任何问题。
2）、一致性上卷，其中一个维度的维度属性是另 一个维度的维度属性的子集，且两个维度的公共维度属性结构和内容相同，比如在商品体系中，有商品维度和类目维度，其中类目维度的维度属性是商品维度的维度属性的子集，且有相同的维度属性和维度属性值。这样基于类目维度进行不同业务过程的交叉探查也不会存在任何问题。
3)、交叉属性 ：，两个维度具有部分相同的维度属性。比如在商品维度中具有类目属性，在卖家维度中具有主营类目属性，两个维度具有相同的类目属性，则可以在相同的类目属性上进行不同业务过程的交叉探查。

    推荐阅读


    上一篇：工作常用|java阻塞队列LinkedBlockingQueue源码分析

    下一篇：flink|flink windows窗口 应用范例