3个维度拆解vintage分析，从入门到精通避坑指南

刚毕业写代码，是不是也常陷在这个死胡同里？语法背得滚瓜烂熟，LeetCode刷到吐，结果真接到业务需求，脑子一片空白，根本不知道怎么搭项目。尤其是涉及数据分析或风控场景时，听到vintage分析（账龄分析）就头大，明明知道要用Python或SQL，却不知如何落地。

今天不聊虚的，直接上干货。我们要把vintage分析从入门到精通的路径彻底讲透。这不是简单的查表，而是一套完整的信贷资产质量监控体系。很多应届生面试大厂风控岗，这道题是高频考点，但90%的人只停留在概念层面，实操时一碰就碎。

1. 为什么你的“账龄”总是算错？场景与痛点直击

先说个真实案例。某应届生入职后负责监控一笔消费贷的坏账率。他直接用Excel，把每个月的逾期金额除以发放金额，画了个折线图。结果汇报时，老板脸都绿了：“这数据怎么每个月都在变？上个月的坏账率怎么突然降了？”

问题出在哪？他混淆了Vintage和Roll Rate的概念，更致命的是，他用了“累计口径”而非“同期群口径”。

Vintage分析的核心逻辑是：按放款月份分组，追踪同一批资产在后续不同账龄（Month Since Maturity, MSM）下的表现。

痛点一：时间错位。 2023年1月放款的贷款，在2023年2月时是MSM=1，在2023年3月是MSM=2。如果你把1月、2月、3月放款的贷款混在一起看“当前逾期率”，那就是垃圾数据。
痛点二：数据缺失。 新放款的贷款，账龄很短，数据不完整。如果你强行和老贷款比，会得出荒谬的结论。
痛点三：口径不一。 是看“逾期金额占比”还是“逾期账户占比”？是看“30天逾期”还是“90天逾期”？这些细节决定了分析的有效性。

记住，Vintage分析不是为了看“现在有多少坏账”，而是为了看“这批人的还款习惯，随着时间推移，到底稳不稳”。

2. 核心原理：三大流派与数据结构的本质差异

在动手写代码前，必须搞清楚市面上处理Vintage分析的三种主流技术路径。很多教程只教SQL，但实际工作中，Python、SQL、甚至Excel（仅限小规模）各有优劣。

2.1 三种方案定位

SQL（数据仓库侧）： 最正统、最高效。适合亿级数据量，直接在数据库层完成清洗和聚合。优点是性能极强，数据一致性由DBA保证；缺点是灵活性差，复杂逻辑写起来晦涩，且依赖数仓权限。
Python（数据科学侧）： 最灵活、最常用。适合中小规模数据（百万级以内），便于与机器学习模型联动。优点是库丰富（Pandas），交互性强，容易做可视化；缺点是内存瓶颈，大数据量下会OOM。
Excel/BI工具（业务侧）： 最直观、最易上手。适合管理层汇报或极小规模试点。优点是零代码门槛，图表精美；缺点是数据更新滞后，无法处理海量数据，易出错。

2.2 核心差异对比表

维度	SQL (Hive/ClickHouse)	Python (Pandas)	Excel/BI
数据规模	TB级，亿行以上	MB-GB级，百万行以内	KB-MB级，万行以内
计算性能	极高，并行处理	中等，单核为主	低，串行处理
灵活性	低，需预定义逻辑	高，动态逻辑支持好	极低，固定模板
学习曲线	陡，需精通窗口函数	中等，需熟悉Pandas	平缓，会拖拽即可
数据一致性	高，源头控制	中，依赖数据提取	低，手动维护
典型场景	生产级日报/周报	探索性分析/建模	高层汇报/快速验证

关键结论： 对于应届生，必须掌握Python实现，因为这是你展示数据工程能力的窗口；必须理解SQL逻辑，因为这是你与数据仓库团队沟通的基石。

3. 代码实战：从入门到精通的三种写法

下面我们用同一份模拟数据（100笔贷款，放款月份2023-01至2023-03，追踪至2023-06），分别用三种方式实现Vintage曲线。

3.1 Python实现（推荐入门首选）

Python的优势在于Pandas的groupby和pivot_table非常直观。

import pandas as pd
import numpy as np# 1. 模拟数据生成
# 假设我们有贷款基础表
data = {'loan_id': range(1, 101),'disburse_date': pd.to_datetime(['2023-01-15']*34 + ['2023-02-10']*33 + ['2023-03-05']*33),'principal': np.random.uniform(1000, 5000, 100),# 模拟每月还款情况，逾期金额'm1_overdue': np.random.uniform(0, 0.1, 100),'m2_overdue': np.random.uniform(0, 0.2, 100),'m3_overdue': np.random.uniform(0, 0.3, 100),'m4_overdue': np.random.uniform(0, 0.4, 100),'m5_overdue': np.random.uniform(0, 0.5, 100),'m6_overdue': np.random.uniform(0, 0.6, 100)
}
df = pd.DataFrame(data)# 2. 计算放款月份
df['disburse_month'] = df['disburse_date'].dt.to_period('M')# 3. 计算MSM (Months Since Maturity)
# 这里简化处理，实际项目中需根据当前日期动态计算
# 假设当前是2023-06，则2023-01放款的MSM最大为5
df['current_month'] = pd.Timestamp('2023-06-01')
df['max_msm'] = (df['current_month'].dt.year - df['disburse_date'].dt.year) * 12 + \(df['current_month'].dt.month - df['disburse_date'].dt.month)# 4. 重塑数据：将宽表变长表，以便分组
# 提取逾期列
overdue_cols = [col for col in df.columns if col.startswith('m') and col.endswith('_overdue')]
# 这里为了演示简洁，直接对每个放款月份计算平均逾期率
# 实际项目中，需根据每笔贷款的具体MSM状态筛选# 简化版Vintage计算逻辑
vintage_data = []
for month, group in df.groupby('disburse_month'):for i, col in enumerate(overdue_cols, start=1):# 只有当放款月份 + i <= 当前月份时，该MSM数据才有效if (month.start_time.year * 12 + month.start_time.month) + i <= (2023*12 + 6):vintage_data.append({'disburse_month': month,'msm': i,'avg_overdue_rate': group[col].mean() # 简化：直接取均值，实际应加权})vintage_df = pd.DataFrame(vintage_data)# 5. 透视表展示
vintage_pivot = vintage_df.pivot_table(index='disburse_month', columns='msm', values='avg_overdue_rate')
print(vintage_pivot)

代码解析：

关键点： groupby('disburse_month')是核心。一定要按放款月分组，绝不能按当前月。
避坑： 注意max_msm的判断。2023年1月放款的贷款，在2023年6月时，最多只能看到MSM=5的数据。如果你强行显示MSM=6，那就是数据泄露（Leakage），分析结果无效。

3.2 SQL实现（生产环境标准）

SQL的优势在于处理海量数据时的效率。这里使用Hive SQL语法示例。

-- 假设表结构：loan_base(loan_id, disburse_date, principal), 
-- loan_status(loan_id, report_date, overdue_amount, overdue_days)WITH monthly_disburse AS (SELECT loan_id,SUBSTR(disburse_date, 1, 7) AS disburse_month, -- 'YYYY-MM'principalFROM loan_base
),
monthly_status AS (SELECT loan_id,SUBSTR(report_date, 1, 7) AS report_month,SUM(overdue_amount) AS total_overdueFROM loan_statusGROUP BY loan_id, SUBSTR(report_date, 1, 7)
),
joined_data AS (SELECT d.loan_id,d.disburse_month,d.principal,s.report_month,s.total_overdue,-- 计算MSM(YEAR(TO_DATE(s.report_month, 'yyyy-MM')) - YEAR(TO_DATE(d.disburse_month, 'yyyy-MM'))) * 12 + (MONTH(TO_DATE(s.report_month, 'yyyy-MM')) - MONTH(TO_DATE(d.disburse_month, 'yyyy-MM'))) AS msmFROM monthly_disburse dLEFT JOIN monthly_status s ON d.loan_id = s.loan_id
)
SELECT disburse_month,msm,SUM(total_overdue) / SUM(principal) AS overdue_rate
FROM joined_data
WHERE msm <= 12 -- 只看前12个月
GROUP BY disburse_month, msm
ORDER BY disburse_month, msm;

代码解析：

关键点： JOIN操作可能产生数据膨胀，需确保loan_status中每个loan_id在每个report_month只有一条记录。
性能优化： 在亿级数据下，JOIN是最耗时的步骤。建议将disburse_month和report_month作为分区字段，利用分区裁剪提升查询速度。

3.3 Excel实现（快速验证）

虽然不推荐用于生产，但面试时若被问到“如何快速给老板看个趋势”，Excel是最快的。

数据准备： 将贷款明细表导入Excel，确保放款日期和当前日期为日期格式。
辅助列：
- 放款月：=TEXT(放款日期, "YYYY-MM")
- MSM：=DATEDIF(放款日期, 当前日期, "M")
数据透视表：
- 行：放款月
- 列：MSM
- 值：逾期金额（求和）/ 本金（求和）-> 需要新建计算字段 逾期率 = 逾期金额/本金
- 注意：在数据透视表中，值字段设置需选择“平均值”或“求和”，具体取决于数据粒度。

避坑： Excel在数据超过100万行时会卡顿严重，且容易因格式错误导致计算偏差。仅用于Demo。

4. 适用场景与选型建议：别选错工具

很多应届生喜欢“技术炫技”，不管场景用什么工具。这是大忌。

4.1 场景匹配

场景A：日常监控日报。
- 推荐：SQL + BI工具（如Tableau/PowerBI）。
- 理由： 数据量大，要求稳定、自动更新。SQL跑批写入结果表，BI工具拉取展示。Python在此场景下启动慢，且缺乏权限管理。
场景B：策略回溯与模型评估。
- 推荐：Python。
- 理由： 需要与评分卡模型、机器学习算法联动。Pandas可以与scikit-learn无缝对接，方便计算KS值、AUC等指标。
场景C：临时性专项分析。
- 推荐：Python + Jupyter Notebook。
- 理由： 交互式探索，快速验证假设。可以边写代码边看图表，灵活调整逻辑。

4.2 高频考点与合格标准

在面试中，关于Vintage分析的考察通常集中在以下几点：

MSM的计算逻辑： 能否准确区分Month Since Origination（自放款月数）和Month Since Maturity（自到期月数）？注意，很多消费贷是循环额度，没有固定到期日，此时通常用Month Since Origination。
加权平均 vs 简单平均： 逾期率是金额加权还是账户数加权？
- 金额加权： 反映资产损失风险，更受财务关注。
- 账户加权： 反映客户群体质量，更受运营关注。
- 合格标准： 必须能解释两种口径的差异及适用场景。
数据截断问题： 如何处理最近几个月数据不完整的情况？
- 正确做法： 在图表中用虚线或灰色显示不完整月份，并在分析时注明“数据未成熟”。
- 错误做法： 强行填充或忽略，导致曲线失真。

5. 进阶技巧与避坑指南

5.1 常见违规问题

幸存者偏差： 只分析“存活”的贷款，忽略了提前结清的贷款。这会导致Vintage曲线看起来比实际更优。
- 解决： 在计算逾期率时，分母应包含所有曾放款的贷款，包括已结清的。
口径漂移： 中途修改了逾期定义（如从30天改为60天），但未对历史数据重算。
- 解决： 建立数据版本管理，每次口径变更需重新跑批并标注版本。

5.2 重点章节与高频考点

MDN Web Docs 虽主要讲Web标准，但其关于Date对象的处理逻辑，在Python和JS中处理日期时是通用参考。例如，时区问题会导致disburse_date跨月错误。务必确认服务器时区与业务时区一致。
Pandas的resample功能： 在将日粒度数据聚合为月粒度时，resample('M')是高频考点。注意M（Month End）和ME（Month End）在不同版本中的兼容性。