对于应用星型建模来建设数据仓库业务，在工程实践时绕不开的一个话题。但在数据仓库工具箱（第3版）- 维度建模权威指南和大数据之路 - 阿里巴巴大数据实践却没有详细说明，很有意思。
我接触数据仓库类业务时间不长，距今不过9个月左右，但在这个问题上迷惑了很长时间。前后咨询了多位从业同事，他们给出了很多答案，满足我的好奇心。
维表变化的可能场景有：
- 物理主键变了。
- 业务主键变了。
- 维度的属性变了。
- 维度的缓慢变化。
- 维度的数据量增加了，增加了新记录。
可能的原因有：
- 比如维表从其它系统直抽过来。
- 维表的实现不规范。
- 因业务变化，导致属性发生了变化。
- 因业务变化，新增了记录。
- 业务自身实现原因，导致数据变化。
- ...
那么，维表的数据变化了，相关的事实表、宽表怎么办？
这个问题看似简单，其实依据实际业务场景，还隐含另外一个问题，即维表变化后，多长时间需要体现到数据中？
对于第一个问题，很多人提供的答复是重新刷数据。这个答复本身没有问题，只是在工程实践的时候，刷新数据操作的频率、涉及变更的表的范围、针对单张表单次操作引入的时间和人力投入、可能存在的业务中断的风险和影响，这几个问题需要认真思考。
考虑到上述关注点，第二个问题有实际的意义，即在业务可容忍的范围内，降低刷新数据的频率，一定程度上缓解刷新数据引入的问题。
当前业务处于快速发展中，因此维表的变化非常频繁，为适应现状，R层模型的设计和开发过程中做了一定的调整，比如：
- DWR层事实表中，只保留维表对应行的物理主键和业务主键，其它属性不会冗余到表内，降低维表数据变化引发的影响。
- DM层，各业务模块按需建设专用的维表，变化频率较低。当前源维表产生变化，则经业务评估、验证后再将相关数据引入DM层对应的维表中。
- 各层在建设宽表时，视业务复杂程度，有选择性的将维表的属性冗余到宽表里。
此外，维表有一个特点，即相对于业务数据，数据规模相对较小。因此在Hive平台上使用维表时，需要关注是否涉及大表join小表的现象，如是的话，则需要设计相应的规避方案，避免降低效率。
对于大数据之路 - 阿里巴巴大数据实践中没有深入说明维表变化后的应对方法，部门内有一个前阿里人是这么解释的，原因是阿里的数据开发人员尽可能的将维表的属性退化至宽表中，数据生成之后，假如维表属性变化，一般不会去刷新宽表中的相关记录的属性，仅在后端应用数据时做一定的调整。
考虑到阿里的数据量非常巨大，这种办法大概也是不得以的办法。