3. 金融核心维度设计（客户与产品）

好，咱们进入金融数据仓库里最核心的部分——维度设计。说实话，客户、产品、账户、时间这四个维度，几乎撑起了金融数仓的整个骨架。我做了这么多年金融数仓，踩过的坑有一半都跟这几个维度有关。今天咱们一个一个捋清楚。

3.1 客户维度：SCD策略怎么选？

客户维度，说白了就是「谁在跟银行打交道」。但麻烦的是，客户信息会变——搬家了、改手机号了、甚至婚姻状况变了。你想想看，如果客户上个月还是「未婚」，这个月变成了「已婚」，你的报表该怎么处理？

这就引出了SCD（缓慢变化维度）策略。我个人习惯把金融场景分成三类：

SCD类型	适用场景	我踩过的坑
SCD1（覆盖）	手机号、邮箱等不重要的信息	曾经直接覆盖了客户等级字段，导致历史报表对不上
SCD2（新增行）	客户等级、风险评级等关键属性	没加生效日期索引，查询慢到怀疑人生
SCD3（新增列）	只需要保留上一次变更的场景	用得少，但偶尔用来追「上一个客户经理是谁」

嗯，这里要注意。我曾经在一个项目中，客户维度表跑了两年，数据量从100万涨到800万。为什么？因为SCD2每改一次就加一行。后来我加了分区策略，按effective_date做月度分区，查询效率才提上来。

3.2 产品维度：多层级分类怎么搞？

产品维度，金融行业最头疼的就是层级。一个「结构性存款」可能属于「存款类」，也可能属于「理财类」。你想想看，如果产品分类只有一层，报表根本没法看。

我建议用「递归层级」或者「固定层级」两种方式：

• 固定层级法：产品大类→产品中类→产品小类→产品编码。适合业务稳定的银行。
• 递归层级法：用parent_id自关联。适合产品经常调整的机构。

我个人更倾向固定层级，因为查询性能好。但如果你遇到产品分类经常变，那就老老实实用递归吧。

我曾经帮一家基金公司做产品维度，他们产品分类有7层。用递归查询，一条SQL跑30秒。后来我改成物化路径（materialized path），把层级编码存成字符串，查询直接like匹配，秒级返回。

3.3 账户维度：别小看这个「中间人」

账户维度，很多人觉得不就是「客户+产品」的组合吗？错。账户是金融交易的最小单元，也是风控、核算、报表的交叉点。

账户维度设计，我总结三个要点：

1. 账户状态要快照：正常、冻结、销户、挂失。别只存最新状态，否则历史交易查不到当时账户状态。
2. 账户类型要标准化：活期、定期、贷款、理财。每种类型的属性差异很大，我建议用「子类型表」或者「JSON扩展字段」。
3. 账户与客户的关系：一对多还是多对多？夫妻联名账户就是多对多。别用简单的一对一模型，会出大问题。

账户维度表，我建议至少包含这些字段：

account_sk（代理键）
account_id（业务主键）
customer_sk（客户代理键）
product_sk（产品代理键）
account_type（账户类型）
account_status（账户状态）
open_date（开户日期）
close_date（销户日期）
effective_date（生效日期）
expired_date（失效日期）
current_flag（当前标志）

3.4 时间维度：比你想的更重要

时间维度，很多人觉得「不就是日期表吗？」。嗯，没错，但金融行业的时间维度，比普通行业复杂得多。

为什么？因为金融有「交易日」「自然日」「工作日」「计息日」的区别。你想想看，如果报表要按「第几个工作日」来统计，没有时间维度表，你怎么办？

我设计时间维度表时，一般包含这些：

字段	示例	用途
date_key	20250115	主键，整数类型
full_date	2025-01-15	完整日期
year	2025	年份
quarter	1	季度
month	1	月份
is_workday	1	是否工作日
is_trading_day	1	是否交易日
workday_of_month	11	当月第几个工作日

我记得有一次，业务方要「去年同期的环比数据」。如果没有时间维度表，你得写一堆日期函数。有了时间维度表，直接join自己，按year和month做偏移，简单又高效。

3.5 知识体系总览

下面这张图，是我对金融核心维度设计的总结。你看一眼，基本就能把握全貌：

这四个维度，说白了就是金融数仓的「四梁八柱」。客户维度管「谁」，产品维度管「什么」，账户维度管「怎么关联」，时间维度管「什么时候」。把这四个维度设计好了，你的金融数仓就稳了一大半。

---

公众号:蓝海资料掘金营，微信deep3321