关于维度建模

维度建模+宽表的模式

包含多个事实表，并且维度表是公共的，可以共享。这么做的是为了避免数据冗余和数据复用，套用现成的模式，是比较合理的选择。

维度模型的优缺点

• 数据冗余小（因为很多具体的信息都存在相应的维度表中了，比如用户信息就只有一份） 结构清晰（表结构一目了然）
• 便于做OLAP分析（数据分析用起来会很开心） 增加使用成本，比如查询时要关联多张表
• 数据不一致，比如用户发起购买行为的时候的数据，和我们维度表里面存放的数据不一致

大宽表的优缺点

• 业务直观，在做业务的时候，这种表特别方便，直接能对到业务中。 使用方便，写sql的时候很方便。
• 数据冗余巨大，真的很大，在几亿的用户规模下，他的订单行为会很恐怖
• 粒度僵硬，什么都写死了，这张表的可复用性太低，一旦发生变化，整个都需要重现刷新历史数据。

在目前的情况下，选择两种都存的方式。这是一种trade-off.

Trade-off

数据仓库设计不是仅仅提供了数据存储就可以，而是提供数据服务，让使用方都通过服务的方式访问数据，这样不管是安全性和易用性都容易得到满足。

另外，数据仓库的设计，往往不能是以计算出几张表就结束了，我们更应该提供的是数据服务，让使用方都通过服务的方式来访问我们的数据，而不是简单地将表暴露出去。当我们以数据服务的方式提供数据的时候，不管是易用性还是安全性都更容易得到满足。

两种都存，虽然，这样看起来会占用更多的存储空间，但不失为一种合适的解决方案，因为宽表是通过别的表拼接而成的，因此宽表的存储周期是可以短一些。
只存多个维度表，通过视图来创建宽表。这种方式适合于宽表的查询次数较少的情况。比如在Hive中，宽表其实只是为了计算出来之后导入Es等系统中供其它系统查询，那么久没必要存储一份宽表，直接通过视图来封装就可以。

维度建模是一种十分优秀的建模方式，他有很多的优点，但是我们在实际工作中也很难完全按照它的方式来实现，都会有所取舍，比如说为了业务我们还是会需要一些宽表，有时候还会有很多的数据冗余。这样互为补充。