2. 需求分析与维度建模基础：金融业务需求调研、维度建模四步法、星型模型与雪花模型选择、事实表与维度表设计原则
各位同学，咱们今天聊点实在的。金融数据仓库的建模，说白了就是给海量数据搭个架子。架子搭不好，后面跑报表、做分析，全得翻车。我见过太多项目，一上来就画ER图，结果业务方一问「我要看昨天某支股票的交易量」，数据查不出来——嗯，这就是需求没对齐。
2.1 金融业务需求调研：别急着建模，先听懂业务在说什么
我个人习惯，拿到一个金融数仓项目，前两周基本不碰代码。干什么？泡在业务部门。你得搞清楚：
- 他们看什么指标？ 比如日均交易额、风险敞口、客户流失率。
- 这些指标怎么算的？ 是T+1还是实时？是按客户维度还是产品维度？
- 数据从哪里来？ 核心系统、风控系统、还是外部行情源？
我在项目中遇到过最坑的事：业务方说「我要看交易量」，结果开发了三个月，才发现他们说的「交易量」是成交笔数，而我们理解成了成交金额。你看，一字之差，整个模型都得重来。
避坑指南： 我曾经因为没确认「交易日」和「自然日」的区别，导致对账报表差了整整一个亿。后来我养成了一个习惯——每次需求调研结束，必须输出一份《指标定义文档》，让业务方签字确认。
2.2 维度建模四步法：金科玉律，一步都不能少
维度建模，说白了就是四步走。我管它叫「四步法」，每一步都有讲究。
- 选择业务过程 —— 比如「下单」、「交易」、「结算」。一个业务过程对应一张事实表。
- 声明粒度 —— 每行记录代表什么？是一笔交易？还是一天的汇总？粒度越细，灵活性越高，但存储成本也越大。
- 确认维度 —— 谁？什么时间？什么产品？在哪里？这些「描述性信息」就是维度。
- 确认事实 —— 度量值，比如金额、数量、时长。注意，事实必须是可加的，或者至少是半可加的。
你想想看，为什么很多数仓项目做着做着就烂尾了？多半是第二步「粒度」没想清楚。我见过一个团队，把交易明细和日汇总混在一张表里，结果查询时要么数据重复，要么汇总不对。嗯，这就是典型的粒度混乱。
核心原则： 事实表关注「发生了什么」，维度表关注「谁、什么时间、在哪里」。两者分开，各司其职。
2.3 星型模型与雪花模型选择：别纠结，看场景
很多新手问我：「老师，星型和雪花到底选哪个？」我的回答是：金融数仓，90%的情况用星型就够了。
为什么？因为金融业务查询量大，星型模型表少、join少，查询快。雪花模型虽然规范化了，但多了一层维度表，查询时多一次join，性能就下来了。
但也不是绝对。我在做客户画像分析时，客户维度有几十个属性，比如年龄、性别、职业、收入等级、风险偏好……如果全塞进一张维度表，表会变得很宽。这时候，我会把「收入等级」单独拆成一张子维度表，形成雪花模型。说白了，星型是默认选项，雪花是优化选项。
注意： 雪花模型不要超过两层。我曾经见过一个项目，维度表嵌套了四层，查询时join了七八张表，性能惨不忍睹。后来全部拉平，查询时间从30秒降到了2秒。
2.4 事实表与维度表设计原则：细节决定成败
这部分我直接上干货，都是踩坑踩出来的经验。
事实表设计原则
- 粒度一致：同一张事实表里，所有行的粒度必须相同。不要混入不同级别的数据。
- 事实可加：金额、数量这类指标，最好能跨维度累加。如果遇到「比率」这种不可加的事实，建议拆成分子和分母两个字段。
- 外键不要为空：如果某个维度不存在，用「-1」或「Unknown」代替NULL。否则查询时left join会丢数据。
维度表设计原则
- 代理键优先：不要直接用业务系统的ID做主键。业务ID可能会变，代理键是自增的，稳定可靠。
- 缓慢变化维处理：客户的地址变了怎么办？我一般用Type 2，加一条新记录，标记生效时间。这样历史报表不会乱。
- 维度属性要完整：能加的描述性字段尽量加。比如产品维度，除了产品ID，还可以加产品名称、类别、风险等级、发行机构等。分析师写报表时，少一次join就快一次。
一个小技巧： 我曾经在维度表里加了一个「是否有效」字段，用于标记维度记录是否被逻辑删除。这样既保留了历史数据，又不会影响当前查询。后来这个设计被团队推广到了所有维度表。
2.5 本章知识体系总览
下面这张图，是我自己总结的维度建模核心逻辑。你把它记在脑子里，建模时就不会跑偏。
这张图从左到右，从上到下，就是咱们做金融数仓建模的完整路径。你每次建模前，对着这张图走一遍，基本不会出大错。
最后说一句： 建模不是一次性的工作。业务在变，数据在变，模型也要迭代。我见过最好的数仓团队，每季度都会复盘一次模型设计，看看有没有冗余、有没有性能瓶颈。这种习惯，值得你养成。
公众号:蓝海资料掘金营，微信deep3321