4. 精算数据仓库：保险数据仓库架构、事实表与维度表设计、保单/理赔/客户主题域
精算坏样本归因分析的基础，是构建一个稳定、可追溯、面向分析主题的数据仓库。保险精算数据仓库（Actuarial Data Warehouse, ADW）不同于传统业务报表库，它需要支持跨保单年度的聚合、多维下钻以及理赔链路的全生命周期追踪。本节将围绕保险数据仓库的经典分层架构、事实表与维度表的设计原则，以及保单、理赔、客户三大核心主题域展开。
4.1 保险数据仓库分层架构
保险精算数据仓库通常采用四层架构：ODS（操作数据存储层）→ DWD（明细数据层）→ DWS（汇总数据层）→ ADS（应用数据层）。每一层承担不同的精算职责：
| 分层 | 英文全称 | 核心职责 | 精算典型用途 |
|---|---|---|---|
| ODS | Operational Data Store | 实时/准实时同步核心、理赔、财务系统源数据 | 数据新鲜度校验、增量抽取监控 |
| DWD | Data Warehouse Detail | 清洗、去重、标准化，保留保单/理赔/客户原子粒度 | 单保单赔付率计算、理赔链路明细追溯 |
| DWS | Data Warehouse Summary | 按业务主题轻度汇总（如保单月结、理赔月结） | 经验发生率、退保率、件均赔付月度趋势 |
| ADS | Application Data Store | 面向精算模型、监管报送、归因分析集市 | 坏样本标签宽表、准备金计提底稿、IFRS 17 分组 |
精算实践提示： 坏样本归因分析的数据主要取自 DWS 和 ADS 层。DWD 层用于验证原始数据质量，ADS 层用于构建“保单-理赔-客户”宽表，避免在分析时反复 join 明细表。
4.2 事实表与维度表设计
保险精算数据仓库遵循 星型模型 或 雪花模型。事实表存储可度量、可连续累加的精算指标；维度表存储描述业务实体的文本属性，用于分组和筛选。
4.2.1 事实表设计要点
- 粒度声明：每行代表一个保单责任、一次理赔申请或一次保费入账。粒度必须明确，不可混搭。
- 可加性指标：保费、赔付金额、佣金、准备金计提额等，按时间、产品、渠道维度可累加。
- 半可加/不可加指标：保单件数（按时间可加，按保单不可加）、赔付率（不可直接累加，需加权计算）。
- 退化维度：如保单号、理赔号，在事实表中直接保留 ID，不单独建维度表。
4.2.2 维度表设计要点
- SCD 策略：保险产品条款、渠道佣金比例、客户等级经常变化，建议使用 SCD Type 2（增加生效日期、失效日期、当前标志）。
- 角色扮演维度：日期维度可同时扮演“保单生效日期”、“理赔出险日期”、“报案日期”，在事实表中使用不同外键。
- 退化维度处理：对于高基数且无分析属性的维度（如银行流水号），直接放入事实表，不建维表。
星型模型示例（保单事实表）：
-- 保单月度事实表（DWS 层）
CREATE TABLE dws_policy_monthly_fact (
policy_sk BIGINT COMMENT '保单代理键',
product_sk INT COMMENT '产品维度外键',
channel_sk INT COMMENT '渠道维度外键',
date_sk INT COMMENT '日期维度外键（保单生效月）',
written_premium DECIMAL(18,2) COMMENT '承保保费',
earned_premium DECIMAL(18,2) COMMENT '已赚保费',
incurred_loss DECIMAL(18,2) COMMENT '已发生赔付',
policy_count INT COMMENT '保单件数',
etl_batch_id STRING COMMENT 'ETL批次号'
) PARTITIONED BY (year_month STRING);4.3 保单主题域
保单主题域是精算数据仓库的核心，覆盖从投保、承保、续期、退保到满期的全生命周期。主要维度包括：
- 产品维度：产品代码、产品名称、险种大类（寿险/健康险/意外险）、缴费方式、保险期限。
- 渠道维度：销售渠道（个险/银保/网销/经代）、渠道层级、代理人代码。
- 保单维度：保单号、投保人/被保人关系、承保年龄、缴费年期、基本保额。
- 日期维度：生效日期、到期日期、续期日期、退保日期。
保单主题域的事实表通常包括：保单月度事实表（承保保费、已赚保费、退保金、保单件数）、保单生命周期事实表（每张保单的关键事件时间戳）。
4.4 理赔主题域
理赔主题域用于追踪从出险、报案、立案、核赔到结案的完整链路。理赔数据是坏样本归因分析中“坏”的主要来源。
| 维度 | 典型字段 | 精算分析用途 |
|---|---|---|
| 理赔申请维度 | 理赔号、报案日期、出险原因、事故类型 | 区分疾病/意外/身故，计算发生率 |
| 核赔维度 | 核赔结论、拒赔原因、通融赔付标志 | 识别理赔质量，区分正常赔付与异常赔付 |
| 医院/机构维度 | 医院等级、地区、科室 | 医疗险反欺诈、就医行为分析 |
| 支付维度 | 支付金额、支付日期、收款人 | 赔付金额准确性校验，资金流追溯 |
理赔事实表的核心指标：赔付金额、未决赔款准备金、理赔费用、结案时长。在坏样本归因中，通常将“理赔金额超出预期区间”、“理赔频次异常高”、“理赔与保单生效间隔过短”等标记为坏样本候选。
4.5 客户主题域
客户主题域整合投保人、被保人、受益人的统一视图。精算分析中，客户维度的核心价值在于：
- 客户统一标识：通过身份证号、手机号、设备 ID 构建客户 360 视图，识别同一客户在不同渠道的投保行为。
- 客户画像维度：年龄、性别、职业、收入等级、健康告知等级、历史理赔次数。
- 客户行为维度：续期缴费习惯、保全变更频率、退保倾向。
数据质量注意： 客户主题域最常见的坏样本来源是“客户信息不一致”——同一客户在不同保单中使用不同姓名、不同出生日期，导致归因分析时无法准确聚合。建议在 ODS 层建立客户匹配规则，使用概率匹配算法生成客户代理键。
4.6 保险数据仓库主题域关系图
下图展示了保单、理赔、客户三大主题域之间的核心关联，以及事实表与维度表的典型连接方式：
4.7 坏样本归因视角下的数据仓库设计建议
从坏样本归因分析的实际需求出发，精算数据仓库在设计阶段应额外关注以下三点：
- 保留原始字段快照：在 DWD 层保留源系统的原始字段值，不进行业务转换。归因分析需要回溯“数据录入时的原始值”，而非转换后的标准值。
- 建立坏样本标签维度：在 ADS 层单独建立坏样本标签维度表，包含坏样本类型（理赔异常、退保异常、欺诈嫌疑）、严重等级、发现时间、归因责任人。避免在事实表中直接写死标签。
- 设计增量归因流水表：每次归因分析跑批后，将归因结果写入增量流水表，保留版本号。支持“同一坏样本在不同归因版本中的标签变化”追溯。
坏样本标签维度表 DDL 示例：
CREATE TABLE dim_bad_sample_label (
label_sk INT AUTO_INCREMENT PRIMARY KEY,
label_code STRING COMMENT '坏样本代码，如 LOSS_RATIO_ABNORMAL',
label_name STRING COMMENT '坏样本中文名称',
severity_level TINYINT COMMENT '严重等级 1-5',
label_category STRING COMMENT '大类：理赔/退保/欺诈/其他',
effective_date DATE,
expiry_date DATE,
current_flag TINYINT DEFAULT 1,
etl_create_time TIMESTAMP
) COMMENT '坏样本标签维度表，SCD Type 2';