数仓大宽表

个人建议是：宽表可以从很多的表中结合数据，但是鉴于宽表自身的缺陷，

不建议过“宽”，在无法提前做测试的情况下，尽量只使用”小宽表“，即只使用宽表涉及面广的特点，但是表本身不大（行列均小），如果行过多可以建立partition机制。

数据仓库模型一般有四种：宽表模型，星型模型，雪花模型，星座模型。

四种模型定义如下：

• 宽表模型（单例模型），通常是指业务主体相关的指标、维度、属性关联在一起的一张数据库表。
• 星型模型，由事实表和维度表组成，一个星型模型中可以有一个或者多个事实表，每个事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状，中心是一个事实表，围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模式这个名字的由来。
• 雪花模型，雪花模式也是由事实表和维度表所组成，它将低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，如性别这样的列基数就很低。在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。星型模式是雪花模式的一个特例(维度没有多个层级)。
• 星座模型，由多个事实表组合，维表是公共的，可以被多个事实表共享。

怎么判断是宽表好还是多维表好？

数据仓库每张表的搭建，主要依赖于这个表在整个数据仓库中的作用和相关意义。首先要清楚这个表的存在是为了解决那些问题，什么角色使用，怎么保证使用者尽可能好的体验解决问题。从以上所提到的角度去看待问题，拆解以下几点因素：

1、多表关联查询的使用频次有多高，将重复高频的事情简化，是不是更好？

2、查询体验上需要考虑多表关联之后的查询性能问题，关联表，是否影响查询速度？

3、某些场景下，是否存在不能打宽的情况，比如事实维度一对多场景？

策略总结

从规范化的角度来讲，数据仓库的设计者是希望越规范越好，因为这样会减少数据的冗余，而且也便于模型的扩展。从反规范化的角度来讲，数据仓库的使用者是希望使用越方便越好，他们并不太关系规范不规范冗余不冗余，只要用着方便就好。这种情况在工作中是十分常见的，那么该怎样来解决它？下面有两个思路：

鉴于以上的一些考量，在数仓底层可以使用星型模型，而宽表则可以存在于更靠后的层次。

如何设计宽表？

宽表的好处和不足我们都讲了，也就是说宽表虽好，但是带来的问题也很多，下面我们就看一下如何从设计的角度来避免宽表的不足之处。

宽表到底多宽？

开始之前，我们思考一个问题，那就是宽表到底有多宽，就想我们前面讲分层的时候说其实我们不分层也玩得转，早起的数仓就只有一层，现在我们考虑一个问题那就是宽表到底多宽才合适，其实你要把所有的数据装进去也可以。

所以我们要思考到底多宽才合适的，前面我们介绍过数据域的概念，我们与其回答多宽这个问题，不如回答宽表都应该覆盖哪些数据，但是这个问题也不好回答，但是我们可以反着思考，宽表不应该包含什么数据，这个问题很好回答，宽表不应该包含不属于它所在域的数据，例如会员域的宽表只应该包含会员相关的信息，同理我们的宽表是针对某一个域而言的，也就是说它是有边界的。

这下我们再来回答宽表到底多宽，只要不跨域，并且方便使用都是合理的。但是这似乎并不能解决我们上面提到的宽表的不足，只是指明了宽表的一个大致的方向。有了方向之后我们通过我们的设计策略就可以让宽表瘦下来。

设计策略主要包括：主次分类、冷热分离、稳定与不稳定分离。
1、主次分类
主次分离，其实我们经常听到的一句话就是做事情要搞清楚主次，我们看一下表设计的主次是什么，假设我们做的是一个会员域的宽表，但是会员域是还是一个比较大的概念，所以我们还要发掘出我们这个表的主题，例如我们做的是一张会员域下的会员基本信息宽表，那么我们专注的肯定就是基本信息，例如会员信息打通。当让因为事宽表你可能还会冗余的其他信息进来，但是当这样的信息越来越多的时候，我们这张表的主题就越来越弱，所以我们就需要做拆分。拆分可以让我们更加聚焦表的主题，对于数仓开发人员而言可以更好的维护、对于使用方而言可以更加清楚的理解这张表的主题。

2、冷热分离
除了前面的主次分离我们还可以做冷热分离，其实冷热分离这个词我相信你不是第一次听到，但是怎么看这个事情呢，你想一下你在数据存储的时候是怎么做冷热分离的，这里也是同样的理念。

假设我有一张宽表，里面有200个字段，有30张报表在使用它，但是我发现前面150个经常字段经常被使用，后面 50个字段只有一两张报表使用到了，那么我们就可以做一个冷热分离，将宽表拆分。

3、稳定与不稳定分离
其实前面的主次分离、冷热分离都可以提高稳定性，但是前面我们不是为了稳定性分离的。

我们经常有这样的宽表，它依赖埋点数据，但是我们的埋点数据的特点就是量大，导致计算经常延迟，那么我们的宽表就会受影响，从而我们的报表就受影响，但是很多时候你发现报表根本没有用过埋点计算出来的指标，或者是只用了一两个。那我们可以将其拆分，如果报表没有使用到那就最好了，如果使用到了，那就后推，在报表层面上做关联，这样我们的埋点数据即使出不来，我们的报表数据还是可以看的。

• 宽表模型（单例模型），通常是指业务主体相关的指标、维度、属性关联在一起的一张数据库表。
• 星型模型，由事实表和维度表组成，一个星型模型中可以有一个或者多个事实表，每个事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状，中心是一个事实表，围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模式这个名字的由来。
• 雪花模型，雪花模式也是由事实表和维度表所组成，它将低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，如性别这样的列基数就很低。在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。星型模式是雪花模式的一个特例(维度没有多个层级)。
• 星座模型，由多个事实表组合，维表是公共的，可以被多个事实表共享。

• 宽表优缺点？

  在数据仓库建设中，组织相关和相似数据，采用明细宽表，减少数据扫描，提高明细数据表的易用性，以及查询性能。然而宽表也存在一些缺点：

• 数据冗余，由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余，对存储是个挑战。
• 灵活性差，就比如说线上业务表结构变更，宽表模式改造量也比较大。
• 开发流程变长，我们需要去了解业务全流程，得需要知道需扩展哪些维度，沉淀哪些指标，这样就流程会比较长，特别是有些业务快速迭代的话，就有点捉襟见肘。
• 两种方式都存。虽然，这样看起来会占用更多的存储空间，但不失为一种合适的解决方案，因为宽表是通过别的表拼接而成的，因此宽表的存储周期是可以短一些。
• 只存多个维度表，通过视图来创建宽表。这种方式适合于宽表的查询次数较少的情况。比如在Hive中，宽表其实只是为了计算出来之后导入Es等系统中供其它系统查询，那么久没必要存储一份宽表，直接通过视图来封装就可以。