Press "Enter" to skip to content

围绕数据建模,谈金融数仓建设的核心

本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.

一、背景

 

自2018年以来,随着业务体系的不断丰富与发展,数据分析与应用需求越来越丰富,对金融数据仓库建设的要求也越来越迫切。

 

金融数据仓库建设需要解决的问题,主要包括如下几点:

 

 

数据存储和组织不成体系,数据集成的开发、维护及分析应用成本高。

 

数据质量缺乏定义,缺乏有效统一的数据质量监控体系。

 

缺失元数据规范管理,数据开发、表结构定义不统一,数据任务、数据表维护成本高。

 

 

综上,数据仓库的建设,将根据数仓建模方法论,构建一整套架构合理,并具有元数据管理和数据质量监控的现代数仓体系。

 

二、大数据领域建模综述

 

1、为什幺需要数仓建模

 

业界认为数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合。数据在数仓中进行有序、有结构地分类组织和存储。通过建立适合业务和基础数据存储环境的模型,可以带来以下优点:

 

成本降低: 减少数据冗余,计算结果复用;

 

性能提升: 快速查询数据,减少数据的I/O吞吐;

 

效率提高: 提高用户的使用数据体验,使用数据效率;

 

质量改善 :解决数据统计口径的不一致性,统一对外的数据发布。

 

2、数仓建模方法论选择

 

行业内,常用的数据仓库建模方法主要分为以下几种:

 

1) ER模型——站在企业角度面向主题的抽象

 

优点:ER模型从数据库的角度出发,结合业务系统的数据模型,能够非常方便的实现数仓建模。

 

缺点:由于建模限定在数据库结构之上,且是建立于企业角度,会限制整个数仓模型的灵活性,性能等,特别是对数仓的底层数据向数据集市的数据进行汇总时,需要开发复杂逻辑才能满足需求,所以更适合于小规模、逻辑简单的建模。

 

2) 维度模型——从分析决策的需求出发构建模型

 

优点:维度建模非常直观,紧紧围绕着业务流程,直观地反映业务模型中的业务问题。不需要经过特别的抽象处理,即可以完成维度建模。

 

缺点:构建星型模式之前需要进行大量的数据预处理,因此在数仓低层会有大量的数据处理工作;而且,当业务发生变化,需要重新进行维度的定义和预处理,而这些处理过程往往会导致大量的数据冗余。

 

3) Data Vault模型——出发点是为了实现数据的整合

 

优点:提出了一套设计原则和结构,在数仓中增加历史跟踪性能;数仓模型足够灵活,可以在迭代过程中的任何时间点采用这些结构,并且可以不需要熟悉业务并进行前瞻规划设计。

 

缺点:DV代表了对关系、业务键和属性的分解方法,因此与非规范化结构(如星型模式)相比,创建的表的数量更多,由于这个原因,需要许多  joins来查看DV中的数据,使用不太常规和方便。

 

比较三种建模方式优缺点,并经过对实际业务的分析,基本抽象出业务模型,同时,为了避免业务变化对上层报表产生较大影响。选择采用维度建模方法来搭建数仓,面对业务技术构建技术主题模型,面对业务需求构建分析主题模型,将业务变化消化在技术主题模型而不用修改分析主题模型,这样对用户的使用尽量透明化。

 

三、数仓体系建设

 

下图为数仓体系架构图:

 

 

图1 数据仓库架构

 

1、数据概述

 

业务数据主要包含车分期、房金融、消费金融等业务线上的运营概况、风险控制、营销转化、财务核算等数据集合。

 

2、数仓架构分层

 

数据仓库构建过程中,采用分层思想,各层功能及建模方式和原则如下。

 

1) I(Inbound)层

 

功能:

 

从原系统获取数据做的备份,一般不做其它逻辑处理。

 

建模方法:

 

数据保留时间根据实现业务需求而定;

 

源系统以增量或全量方式经过ETL到I层;

 

可以分表进行周期存储,存储周期不长。

 

2) C(Consolidation)层—-核心层

 

功能:

 

根据业务设计技术主题模型,目的是可灵活支持业务需求;

 

屏蔽业务底层复杂逻辑和变化,业务系统变化削弱在数据模型层;

 

简单、完整、集成的将数据暴露给高层。

 

建模方法:

 

按技术主题划分;

 

数据清洗转换;

 

维度建模。

 

方案特点:相比传统的三层(ODS-DW-APP)架构,当业务复杂时,业务的需求纷繁复杂,直接从DW满足需求:

 

DW可复用对象较少,开发和维护成本较高;

 

ODS的变化会极大可能影响到APP的数据计算,影响业务地使用。

 

而本方案构建了技术主题层(核心层),通过抽象各个相对独立的技术主题数据(比如订单、风控、放款模型),屏蔽和消化了I层的变化带来的影响,不至进一步影响上层模型的相对稳定。

 

3) S(Subject)层

 

功能:

 

面向业务需求设计分析主题,支持明细查询和指标计算。

 

建模方法:

 

面向业务过程、面向分析;

 

基于维度的宽表或指标。

 

方案特点:通过C层屏蔽I层的变化,S层的分析主题模型更加贴合用户的分析需求并可以保持相对稳定,同时也让分析主题模型的构建可以不用局限于业务数据库的设计,而可以根据实际业务需求来建模。

 

4) R(Report)层

 

功能:

 

报表指标层,存储根据业务需求计算后的维度指标数据。

 

建模方法:

 

面向决策;

 

保持数据量较小,支持快速查询、分析;

 

指标预先计算汇总。

 

通过本方案的层次和模型实际,整个数仓低层(I、C)可以完全面向技术建模,完成数据的整理、清洗和集成,高层(S、R)则可以完全面向需求建模,根据实际业务构建适用、好用的分析主题模型,而无需被技术层设计所约束。不仅完成了模型层次划分,同时也给后续数仓两段模型的并行设计和开发提供了基础。

 

3、数据质量监控

 

数据输出需要保证正确性,数据质量监控可以从技术手段辅助及时发现问题。

 

 

图2 数据质量监控系统结构图

 

目前涵盖自动生成基础校验、即时监控报警、人员打分及每周质量报告功能,以辅助监控数仓运行过程中出现的问题。

 

 

图3 数据质量监控流程

 

4、元数据规范管理

 

以减低数据任务开发、数据表维护及数据一致性保证的成本,辅助开发了元数据管理系统。

 

 

图4 元数据管理系统

 

通过技术约束和管理辅助的方案,保证了所有的线上开发都在元数据管理体系下进行:

 

1) 命名机制

 

① 词根:通过梳理金融业务常用维度和指标含义,建立和维护可收敛的词根库,提供数仓开发的字段组合使用。

 

:必须使用词根库里的词根构造字段,并保证不同表中同一含义的字段命名一致,方便数据开发传递的一致性,也为后续血缘分析提供基础。

 

在添加字段时,为了降低生成字段的工作量,会调用开源分词工具辅助开发人员初步生成合符词根规则的字段名。

 

③ 数据表:根据主题统一命名数据表名,字段必须来源于元数据管理系统中的维护字段,以方便开发、产品、业务对表的使用。

 

2) 审核机制

 

新增词根或字段需严格按照规定命名并经过多层审核。

 

3) 追责机制

 

实行追责机制,定位到责任人,提高所有人员的责任意识。

 

4) 一致性保证

 

一键建表功能可以自动在落地库建表,保证元数据表和落地库的表结构一致,表添加字段也可以直接同步到落地库。同时每天会进行一致性检测,并进行异常报警.

 

 

图5 元数据管理执行方案

 

5、数仓建设规范

 

58金融数仓建设过程中,从字段命名规范、表命名规范、编码规范来减低模型后续开发、维护成本。

 

1)字段命名规范

 

表字段采用下划线命名法,字段名必须使用小写字母或数字,禁止出现数字开头,禁止两个下划线中间只出现数字;

 

数仓所有字段名称必须从元数据字段命名库中获取,禁用保留字,如 desc、range、match、delayed 等;

 

元数据字段必须从词根库中组合获取;

 

字段命名库中不存在的名称,在翻译后首先添加到字段命名库中,然后在建表中使用。

 

2)表命名规范

 

① 通用前缀

 

分层:层次对应小写字母(i、c、s、r) 类型;

 

类型:t 表示表,v 表示视图;

 

数据类别:f 表示事实数据,d 表示维度数据,s 表示快照数据。

 

②  I 层自动抽取表命名规范

 

格式:分层类型数据类别_主题_原数据库名_原表名;

 

表示例: CRM用户表:itf_usr_db58_customercrm_customer;

 

视图示例: CRM用户表视图;

 

itf_usr_db58_customercrm_customer_view。

 

③ C、S、R 层表命名规范

 

格式:分层类型数据类别_主题_描述[__分区];

 

目标表示例:订单表:ctf_ord_order;

 

临时表:如果是临时表,则在的描述后面添加 temp 及序号,示例:订单临时表:ctf_ord_order_temp_001,从 001 递增;

 

视图命名:cvf_ord_order__car,注意描述跟分区之间使用2个下划线连接;

 

通用字典表:itd_表名。

 

汇总参考:

 

 

3)编码规范

 

SELECT 语句选择的字段按每行一个字段方式编排;

 

SELECT 单字后面一个空格后直接跟首个选择的字段,其它字段前与第一个选择的字段对齐,逗号放置字段名前面;

 

AS语句必须有,并且应与相应的字段在同一行;

 

同一级别的子句间要对齐,与相应的SELECT语句左对齐编排

 

子句后续的代码离子句首字母二个缩进量起编写;

 

where 子句下的逻辑判断符 and、or 等与 where 左对齐编排;

 

超过两个缩进长度的子句加空格后编写后续代码,如 order by 和 group by等;

 

CASE WHEN 语句使用如下对齐方式:WHEN 和 ELSE 对齐,CASE 和 END 对齐;

 

每行宽度不超过 250 字符,超过行宽的代码可换行与上行对齐编排;

 

代码编写完成后,统一先使用 plsql 工具进行美化,再进行微调。

 

四、总结和展望

 

在数据仓库建设过程中:

 

 

初步构建相对合理的数据体系结构,能够快速支持数据的集成,降低了业务迭代变化对数据模型的冲击。

 

业务知识体系初步建立,降低数据使用成本。

 

元数据管理体系初步建立,能够对核心字段和数据指标进行管理监控,基本覆盖核心数据应用分析场景。

 

 

后续将围绕以下几点继续进行数据建设:

 

 

易用性:推进S层、R层数据对外易用性迭代,不断降低用户使用数据的成本。

 

时效性:围绕数据产出稳定性与时效性,持续优化已有数据作业。

 

 

> > > >

 

参考资料

 

《大数据之路-阿里巴巴大数据实践》

 

《数据仓库工具书-维度建模权威指南》

 

作者丨 胡明昊,58金融技术中心数据平台部,数据高级开发工程师。

 

来源丨 58技术(architects_58)

 

dbaplus社群欢迎广大技术人员投稿,投稿邮箱: [email protected]

Be First to Comment

发表评论

电子邮件地址不会被公开。 必填项已用*标注