数仓微型维度怎么设计？
面试怎么回答
微型维度用于从大型维度中拆出频繁变化、通常已分段的属性，以属性组合生成画像键，避免主体维度因 Type 2 频繁生成版本。事实表同时保存主体键和事件发生时的画像键，从而还原历史状态。当前画像则要通过主体维度指针、关系表或周期快照解决。设计时要控制组合基数，并明确分段规则、事件时点和历史重算策略。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
客户主维度有上亿行，风险等级、活跃度、收入区间却每天都可能变化。如果全部按 SCD Type 2 保存，维度版本数会迅速膨胀。
这时可以考虑把一组快速变化的描述属性拆成微型维度。
微型维度（Mini-Dimension）是从大型维度中拆出一组频繁变化、通常经过分段的属性，按属性组合生成较小的档案维度。事实表同时关联主体维度键和当时的微型维度键。
它解决什么问题？
假设客户维度同时保存姓名、注册日期、收入区间、活跃等级和风险等级。姓名等属性变化较慢，但后三项可能频繁变化。
如果任何一个快变属性改变，都为客户生成新的 Type 2 版本，客户维度会爆炸式增长；查询当前客户也要从大量历史版本中筛选。
可以拆成：
dim_customer
customer_key
customer_id
name
register_date
dim_customer_profile
profile_key
income_band
activity_level
risk_level
微型维度一行代表一种画像组合，不是一名客户。多个客户在某时点可以共享同一个 profile_key。
历史画像如何关联？
交易事实发生时，同时写入 customer_key 和当时有效的 profile_key。这样查询历史订单时，可以看到客户在交易发生当时的风险或活跃档案，而不是套用今天的状态。
这里的关键是“事实发生时”。如果加载任务晚到或画像按天快照更新，要定义使用事件时间、业务日期还是处理时间匹配画像，否则历史归属会漂移。
那当前画像放在哪里？
事实表能回答历史事件对应的画像，却不能方便地回答“这个客户现在是什么画像”，因为没有事件时就没有新的事实行。
常见做法包括：在客户维度维护一个当前 profile_key，按 Type 1 方式覆盖；或者建立客户当前画像关系表、周期快照表。历史画像与当前画像是两个问题，不能指望一套外键自动同时解决。
为什么经常要先分段？
如果把精确收入、精确积分和连续评分直接组合，微型维度仍可能产生海量组合。通常先把连续值转成收入区间、活跃等级、风险档位，控制基数并提升可解释性。
但分段边界必须由业务定义和版本管理。今天修改“高活跃”的阈值，历史事实是否重算，要提前约定，不能只更新维表标签。
什么时候不该用？
属性变化不频繁时，普通 Type 2 已经足够；属性只用于当前状态且不分析历史，可以 Type 1 覆盖；如果属性组合几乎每个客户都唯一，拆出后也不会显著复用。
微型维度不是为所有快变字段准备的万能方案。要综合评估主维度规模、变化频率、组合基数、历史分析要求和事实加载复杂度。