金融数据仓库建模与演化
一、背景
刚到公司时，部门主要是通过原始数据给产品、业务、老板出报表，当时业务线共有2条主要业务线，但随着业务不断增长，业务线不断扩大，业务迭代次数过多，原有数据逻辑修改困难，同时底层数据组织杂乱，除本人制作报表外，其他人很难知道详细逻辑和当前业务过程，从而难以维护。故此推动了离线数仓的建设。有幸负责了数仓模型设计、元数据建设、监控系统设计等工作，与同事们一起将金融数仓不断加固完善。经过多次数仓模型演进，主键形成了2套多层级数仓模型方案。1.用DV模型+维度模型融的多层级数据模型，2.维度模型多层级数据模型。
二、离线数仓设计初步
目前公司主要业务为贷款业务，涉及到2套主要业务车贷和消费金融贷款，涉及到公司订单系统、风控系统、核心系统、支付系统、催收系统、电销系统等多套独立数据系统。
先亮出维度建模来通用图，虽然多见，但是真的好用
维度建模流程
由于上层用户为分析使用，故而上层的数据组织形式使用维度建模，故而先构建层数据模型。
1.选定业务过程
金融业务，车贷和消费金融2大金融业务、
业务共性：
1.都为贷款业务
2.都有抵押物，车贷为车，消费金融为个人信誉
3.都有借款还款催收
4.都要经过多套审核
抽象业务主要业务逻辑：
贷款抽象流程
数据总线：
| 编号 | 时间日期 | 产品 | 用户 | 员工 | 城市 | 供应商 | 银行 | |
| 1 | 申请 | √ | √ | √ | √ | √ | √ | √ |
| 2 | 申请审核 | √ | √ | √ | √ | √ | ||
| 3 | 提现 | √ | √ | √ | √ | √ | √ | √ |
| 4 | 提现审核 | √ | √ | √ | √ | √ | ||
| 5 | 费用支付 | √ | √ | √ | √ | √ | √ | √ |
| 6 | 商品发放 | √ | √ | √ | √ | √ | ||
| 7 | 用户还款 | √ | √ | √ | ||||
| 8 | 公司催收 | √ | √ | √ | ||||
| 9 | 结清/回购 | √ | √ |
2.确定需要构建的基本流程
一个大概的贷款业务流程的主要阶段，针对不同的业务细节将有不同的业务过程，但是针对于贷款行业来说，通用的业务流程如下
| 阶段 | 动作项 | 车贷 | 消费金融 |
| 申请 | 用户进店 | √ | |
| 销售扫码 | √ | ||
| 选择商品 | √ | √ | |
| 身份核实 | √ | √ | |
| 提出申请 | √ | √ | |
| 授信开始 | √ | √ | |
| 授信额度 | √ | √ | |
| 授信结束 | √ | √ | |
| 提现 | 提出申请 | √ | √ |
| 提现审核 | √ | √ | |
| 审核完成 | √ | √ | |
| 支付首付 | √ | ||
| 生成账单与还款计划 | √ | √ | |
| 公司支付金额 | √ | √ | |
| 交付 | 申请交付时间 | √ | |
| 交付结果 | √ | ||
| 交付物 | √ | ||
| 抵押物 | √ | ||
| 还款 | 还款时间 | √ | √ |
| 还款金额 | √ | √ | |
| 还款状态 | √ | √ | |
| 催收 | 催收时间 | √ | √ |
| 催收结果 | √ | √ | |
| 催收金额 | √ | √ | |
| 催收方式 | √ | √ |
3.基本模块确定
通过 1 和 2 内容我们能看出来，在公司贷款业务中，细节流程各不相同，但是各业务线都有相同的阶段，只是阶段中可能会有不同的操作，如车业务中，在身份核实的阶段，分为验二、验四、活体，而消费金融业务只有活体验证，在授信审核阶段，车业务分为自动审核、人工一审、人工二审，而消费金融只有自动审核，所主题流程一致，但是内部细节不同，故而对数仓建设带来困难。不仅如此若是业务线重构，增加新的细节部分依旧对底层数仓结构是个不小的挑战。
所以在这里对贷款业务进行上层抽象分成 5个 模块即申请、提现、交付、还款、催收 作为上层数据仓库的5个主要模块进行数据仓库构建
DWD层数据结构
三.维度模型设计反思
针对以上几部分对业务流程的梳理上看，若是进行维度建模有以下几点问题：
1.不同业务抽象一套逻辑模型，数据如何组织存储以保证数仓在业务多次重构后保证数据稳定性
2.如何在多业务线存的情况下保证数据是可追溯和可审计的
3.如何保证数仓中数据对外的易用性与学习成本降低
4.在业务重构后如何以最小的成本迭代数仓，加入业务新变化
5.数仓设计 数仓多层设计中，如何起到起到预计算和屏蔽差异作用
所以针对以上问题，设计如下数仓设计模型：
数仓模型架构图
四.离线数仓设计细节
1.ODS层
ODS层主要是存储原始数据，存储数据库同步数据、日志数据、爬虫数据等。为了缩短数据同步时间，我们单独做了一套数据同步工具，用作数据同步，单库100张表配置时间可压缩到10分钟以内（详见数据同步平台设计与开发章节）。
2.DWD层
DWD层是整个数据仓库的核心，用来屏蔽底层数据的差异，所以DWD层模型设计至关重要，直接决定后期因为底层数据变动导致上层修改的工作量，同时也直接影响了数据往底层追溯的能力。所以往往DWD采用建模方式多种多样，故而针对使用维度模型还是DV模型，有两套不同标准（维度模型与DV模型详细内容参考第三章节，数据建模理论）。
1.维度模型，针对简单业务，可以对期进行抽象，使用维度建模，有利于上层数据使用，单数据可追溯与可审计能力变差，但业务相对简单，故而不会造成太大影响，模型设计参考上节内容。
2.DV模型，若数据流程复杂，且需要有对数据进行追溯与审计，同时底层业务逻辑变化较快，则采用DV模型更为稳妥。
如下部分涉及DV模型建模方案。建立了申请域和提现域，涵盖贷款部分贷前、贷中和贷后部分。将数据分成多个概念域，目的是每个概念域管理自己的模型，而采用DV模型最大的优势是模型扩展能力强，如若底层发生变化，则只需要修改对应卫星表中的数据即可，如若数据新增新的业务流程，则可新加概念或新增卫星表即可。而且DV构建模型易于理解，降低使用学习成本。
DWS层
DWS层，轻度汇总层，主要是用作对DWD层数据的轻度汇总，用做缓冲和预计算，由于DWD层已经有效的屏蔽了底层业务变化，从而保证数据相对稳定，所以推荐DWD层按主题划分，并用维度建模对DWD数据进行轻度汇总。
DW层
DW层，数据集市层，主要用宽表形式进行数据组织，使用累计事实表进行构建，形成宽表形式有利于上层数据分析使用。
四.离线数仓使用效果
构建后使用一年感受（按照上述方案分别构建了2套数仓模型，分别应用在不同业务上）：
1.车贷和消费金融数仓模型（纯维度模型）
背景:一年中车贷和消费金融贷款修改无数，分别重构一版
结论：由于业务复杂每次重构都会引起DWD大改，因为每次需求都不同，需要各种刁钻数据，重构2次，最后不得不增加一个扩展字段（全是KV）防止增加特殊字段，同时上层修改较为频繁。
2.金融风控数据仓库模型（DV模型+维度模型）
背景:风控主要描述中车贷和消费金融贷款贷前和贷中进入风控审核数据，包含贷前和贷中的全部数据，车贷和消费金融贷款重构对公司风控系统也有相应重构
结论：DWD层模型修改次数为0，没有任何重构，但凡增加新的逻辑修改DV模型卫星表即可，保证与底层数据的全面性，而DWS和DM层在DWD层未有大动的情况下，基本没变动，充分体现了DV模型屏蔽底层细节的优良性。