考察点
反模式题比正面方法论更能区分候选人——背过 Kimball 的人很多，真在烂摊子里打过滚的才能讲出这些坑的成因和后果。面试官想听你描述每个反模式「长什么样、为什么会这样、怎么治」，追问常落在桥接表设计和「已经这样了怎么重构」。
参考答案
反模式一：大宽表滥用
症状：一张 DWS 表几百个字段，什么主题都往里塞，「再加个字段」是唯一的演进方式。成因是路径依赖——第一次建宽表尝到甜头后，所有需求都往这张表上加。
后果前面宽表题讲过：回刷成本高（任何维度变了都牵动全表）、变更僵硬、没人敢删字段、产出时间被最慢的上游依赖拖住。治理信号很明确：字段数超过一两百、每周都有加字段需求、回刷频率超过每月一次。解法是按主题拆表（交易宽表、流量宽表、用户宽表分开，主键可关联）+ 字段使用度审计定期清理。宽表本身没错，错在没有边界。
反模式二：层级穿透
两种表现。一种是雪花化过度：维度归一化做得太狠，查一次「各省销售额」要事实表 join 门店维 join 城市维 join 省份维，链路长、性能差、容易 join 错。维度建模的原则就是适度反范式——把城市、省份属性打平进门店维（或进一步退化进事实表），扁平化换易用性，别用 ER 建模的思维建维度模型。
另一种更隐蔽：绕过一致性维度各自关联。同一个「类目」，报表 A join 类目维表 V1 版本，报表 B join 运营自己维护的类目映射表，两个报表数字对不上，业务方怀疑数据团队算错了。这是「层级」在组织层面的穿透。解法是一致性维度：全公司共享同一套维度表和维度属性定义，由总线矩阵登记各业务过程引用哪些一致性维度，任何「自建映射表」都要过评审。
反模式三：混合粒度
一张事实表里大部分行是订单行粒度，个别行是订单汇总粒度（比如运费单独一行），下游 sum 金额直接翻倍。这是建模新手最常见的错误，危害在于错得隐蔽——数据量小测不出来。防线就一条：粒度声明写进表注释和评审 checklist，每行必须严格满足「一行 = X」的声明，不满足的事实要么分摊到粒度内、要么放另一张表。
反模式四：多值维度硬塞
一个订单对应多个标签、一个用户属于多个兴趣分组——把多值属性用逗号拼接塞进一个字段，或者干脆复制多行。前者让下游每次都要 split 且无法 join 维表，后者直接破坏粒度、金额翻倍。正解是桥接表：事实表与维度表之间加一张桥接表（订单 ID + 标签 ID + 权重因子），需要按标签汇总时通过桥接表关联，权重因子处理重复计数问题；不需要时照常直查，互不影响。
反模式五：SCD 处理缺失或错用
维度变了直接覆盖（Type 1），历史报表数字悄悄变化，业务方拿着上月的报表来对数，永远对不上；或者反过来，什么维度都上拉链（Type 2），维表行数爆炸、join 性能下降。正确姿势是按属性分级：修正类错误用 Type 1（本来就是错的，不留痕）；业务演进类用 Type 2 拉链（用户等级调整，要保留各时点的历史状态）；只关心新旧两个值的用 Type 3（加一列「原类目」）。默认 Type 2，评审时逐属性确认。
已经烂尾了怎么重构
别想着推倒重来。现实路径：先登记现状（总线矩阵补齐、血缘盘清依赖），再立新规矩（新表必须过评审），然后按收益排序逐个改造——先拆影响面最大的那张超级宽表，先统一争议最大的那个一致性维度。重构的每一张表都要走双跑验证再切流，数仓重构最大的风险不是技术而是口径变化吓着业务方。
可能的追问
- 桥接表会不会让模型太复杂，分析师不会用？ 会，所以桥接表只建给真正多值的场景，并且在 DWS 层把它消化掉——分析师用的汇总表已经把多值关系聚合好了，复杂关系不出现在 ADS。
- 怎么判断一个属性该退化进事实表还是留在维表 join？ 看使用频率和稳定性：下游大部分查询都要用、口径稳定的，退化；低频或频繁变更的，留维表。判断错了也没关系，加退化列是向后兼容的变更。
- 一致性维度谁来维护，跨团队怎么推？ 需要组织保障：数据委员会或架构组名义牵头，各域提需求、专人维护维度表，配评审流程。纯靠自觉的一致性维度活不过半年。