大数据最新聊聊数据仓库中维度表设计的二三事_维度建模 维度表之间的关系，字节面试官

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

比如对于商品的描述信息，也许业务人员对此并不敏感，或者认为无关紧要，这种情况可以直接覆盖 。

但是对于商品所属的类目发生变化，则需要认真考虑， 因为这涉及归类这个商品的销售活动到哪个类目一一是全部归到新类目，还是全部归到旧类目？变化前归到旧类目，还是变化后归到新类目？这实际上也涉及了下面要分享的缓慢变化维的几种处理办法。

1. 重写维度值

当一个维度值属性发生变化时，重写维度值方法直接用新值覆盖旧值。

该技术适用于维度建模中不需要保留此维度属性历史变化的情况，常用于错误订正或者维度属性改变无关紧要的场景，比如用户的生日之前发生输入错误，不需要保留之前的生日历史数据。

那么采用重写维度值的方法，就将会改变此维度属性的所有历史度量。

比如，分析师希望分析星座和销售的关系，之前用户的生日属于白羊座，但是修改后的生日属于双子座，那么维度属性修改后，其销售额将都属于双子座。因此维度设计人员只在必要情况下使用此方法，同时需要告知下游分析人员。

采用重写维度值方法的维度表和事实表变化如图：

2. 插入新的维度行

相比重写维度值方法不维护维度属性变化的特点，插入新的维度行方法则通过在维度表中插入新的行来保存和记录变化的情况。

属性改变前的事实表行和旧的维度值关联，而新的事实表行和新的维度值关联。

我们仔细观察变化后的维度表可以发现，新复制了一行该用户的信息，唯一不同在于 state 的不同（之前是 AZ，之后是 CA）。同时，仔细观察订单事实表也会发现，过去的订单是和旧的唯独行关联，而新的订单和新的维度行关联。

通过新增维度行，我们保存了维度的变化，并实现了维度值变化前的 实和变化后的事实分别与各自的新旧维度值关联。

但是这也给维度表用户带来了困惑，为什么查询会员会在维度表中发现多行记录？ 尽管可以向用户解释，但是用户的使用和学习成本无疑增加了， 而且数据开发人员对于维度变化的处理逻辑无疑更复杂了。

3. 插入新的维度列

在某些情况下，可能用户会希望既能用变化前的属性值，又能用变化后的属性值来分析变化前后的所有事实。此时可以采用插入新的维度列这种方法。

不同于前一种方法的添加一行，这种方法通过新增一列，比如用 region_previous 列表示之前的所属大区，同时新增 region_current 来表示变化后的所属大区。如果有多次变化，就需要有多个列来存储。

实际上，这三种方法都能从不同角度解决维度变化的问题，还有通过组合这三种方法形成的其他各种技术可用于处理维度变化，这里就不再赘述。

当然了，不管哪种技术，在大数据时代都不是完美的，而且有一定的处理复杂度和学习使用成本。

如何以一种最简单、直接的办法来解决维度变化呢？我们在后面会聊聊 快照技术 ，以解决大数据时代的维度变化问题。

维度层次

维度层次指的是某个维度表中属性之间存在的从属关系问题。比如商品的类目可能是有层次的（一级类目、二级类目、三级类目等，尤其对于宝洁、联合利华等大的快消企业集团），同时类目、品牌和产品实际上也是有层次的。那么维度建模如何处理这些层次结构呢？

实际上有两种处理办法：

1. 第一种是将所有维度层次结构全部扁平化、冗余存储到一个维度表中，比如商品的一至三级类目分别用三个字段来存储，品牌等的处理也是类似的；
2. 第二种是新建类目维度表，并在维度表中维护父子关系。

第一种其实就是星型架构，第二种是雪花架构。在维度建模中，我们采用第一种来处理维度的层级问题，这样反规范化的处理牺牲了部分存储，但是给用户使用带来了便捷，也降低了学习使用成本。

维度的层次结构通常和钻取联系在一起，所谓钻取即是对信息的持续深入挖掘。

钻取分为向上钻取和向下钻取，比如对于某零售商的年度销售报表，其年度销售总额显示增长20%，那么从时间上分析是哪个季度的增长率比较高呢？

此时可以向下分析各个季度的增长率，同样可以继续向下分析到月增长率乃至天增长率，同样的分析也可以应用到类目 、品牌等，来分析到底是哪个类目的增长或者哪个品牌的增长导致了年度总销售额的增长 20% 。这就是向下钻取。

与之相对的是向上钻取，钻取的实质是增加或者减少维度，增加维度（向下钻取）从汇总数据深入到细节数据，而减少维度（向上钻取）则从细节数据概括到汇总数据 。通过钻取，用户对数据能更深入地了解数据，更容易发现问题，从而做出正确的决策。

维度一致性

在 Kimball 的维度设计理论中，并没有物理上的数据仓库。数据仓库是在对多个主题、多个业务过程的多次迭代过程中逐步建立的，这些多个问题、多个业务过程的多次迭代过程常被从逻辑上划分为数据集市。

所谓数据集市一般由一张和多张紧密关联的事实表以及多个维度表组成，一般是部门级的或者面向某个特定的主题。数据仓库则是企业级的、面向主题的、集成的数据集合。

物理上的数据集市组合成逻辑上的数据仓库， 旦数据集市的建立是逐步完成的，如果分步建立数据集市的过程中维度表不一致，那么数据集市就会变成孤立的集市，不能从逻辑上组合成一个集成的数据仓库，而维度一致性的正是为了解决这个问题。

维度一致性的意思是指：两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。

不一致既包含维度表内容的不 致，也包含维度属性上的不一致。

• 比如对于一个电子商务公司，如果其浏览等相关主题域的商品维度表包含了该企业的所有商品的访问信息，但是由于某种原因其交易域的商品缺失了部分商品 （有可能是成交在其他平台完成），那么对这些缺失商品的交易分析就无法完成 。
• 同样如果两的商品属性不同，比如日期格式、类目划分（有可能浏览分为前天类目，成交是后台类自）等不一致，那么跨浏览域和交易域的对类目和日期的交叉分析就无法进行，因为其类目划分就不一致。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

需要这份系统化资料的朋友，可以戳这里获取