58 技术 | 金融数仓体系建设

文章作者:胡明昊 58 金融
内容来源:58 技术

导语: 本文讲述了金融数据仓库从无到有的整体设计思路,以及对数据建模、质量控制、元数据管理及开发规范各方面的经验思考,希望对大家在数仓建设工作方面有所帮助。

背景

自 2018 年以来,随着业务体系的不断丰富与发展,数据分析与应用需求越来越丰富,对金融数据仓库建设的要求也越来越迫切。
金融数据仓库建设需要解决的问题,主要包括如下几点:
1、数据存储和组织不成体系,数据集成的开发、维护及分析应用成本高;
2、数据质量缺乏定义,缺乏有效统一的数据质量监控体系;
3、缺失元数据规范管理,数据开发、表结构定义不统一,数据任务、数据表维护成本高;
综上,数据仓库的建设,将根据数仓建模方法论,构建一整套架构合理,并具有元数据管理和数据质量监控的现代数仓体系。

大数据领域建模综述

1、为什么需要数仓建模
业界认为数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合。数据在数仓中进行有序、有结构地分类组织和存储。通过建立适合业务和基础数据存储环境的模型,可以带来以下优点:
1) 成本降低:减少数据冗余,计算结果复用;
2) 性能提升:快速查询数据,减少数据的 I/O 吞吐;
3) 效率提高:提高用户的使用数据体验,使用数据效率;
4) 质量改善:解决数据统计口径的不一致性,统一对外的数据发布。

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 金融数仓建设过程中,从字段命名规范、表命名规范、编码规范来减低模型后续开发、维护成本。
5.1 字段命名规范
1) 表字段采用下划线命名法,字段名必须使用小写字母或数字,禁止出现数字开头,禁止两个下划线中间只出现数字;
2) 数仓所有字段名称必须从元数据字段命名库中获取,禁用保留字,如 desc、range、match、delayed 等;
3) 元数据字段必须从词根库中组合获取;
4) 字段命名库中不存在的名称,在翻译后首先添加到字段命名库中,然后在建表中使用;
5.2 表命名规范
1) 通用前缀:

  • 分层:层次对应小写字母(i、c、s、r) 类型
  • 类型:t 表示表,v 表示视图
  • 数据类别:f 表示事实数据,d 表示维度数据,s 表示快照数据

2) I 层自动抽取表命名规范
格式:分层类型数据类别_主题_原数据库名_原表名
表示例:CRM 用户表:itf_usr_db58_customercrm_customer
视图示例:CRM 用户表视图:
itf_usr_db58_customercrm_customer_view
3) C、S、R 层表命名规范

  • 格式:分层类型数据类别_主题_描述[__分区]
    目标表示例:订单表:ctf_ord_order
    临时表:如果是临时表,则在的描述后面添加 temp 及序号,示例:订单临时表:ctf_ord_order_temp_001,从 001 递增。
  • 视图命名:cvf_ord_order__car,注意描述跟分区之间使用 2 个下划线连接。
  • 通用字典表:itd_表名
    汇总参考:

5.3 编码规范
1) SELECT 语句选择的字段按每行一个字段方式编排
2) SELECT 单字后面一个空格后直接跟首个选择的字段,其它字段前与第一个选择的字段对齐,逗号放置字段名前面
3) AS 语句必须有,并且应与相应的字段在同一行
4) 同一级别的子句间要对齐,与相应的 SELECT 语句左对齐编排
5) 子句后续的代码离子句首字母二个缩进量起编写
6) where 子句下的逻辑判断符 and、or 等与 where 左对齐编排
7) 超过两个缩进长度的子句加空格后编写后续代码,如 order by 和 group by 等
8) CASE WHEN 语句使用如下对齐方式:WHEN 和 ELSE 对齐,CASE 和 END 对齐
9) 每行宽度不超过 250 字符,超过行宽的代码可换行与上行对齐编排
10) 代码编写完成后,统一先使用 plsql 工具进行美化,再进行微调

总结和展望

在数据仓库建设过程中,
1、初步构建相对合理的数据体系结构,能够快速支持数据的集成,降低了业务迭代变化对数据模型的冲击;
2、业务知识体系初步建立,降低数据使用成本;
3、元数据管理体系初步建立,能够对核心字段和数据指标进行管理监控,基本覆盖核心数据应用分析场景;
后续将围绕以下几点继续进行数据建设:
1、易用性:推进 S 层、R 层数据对外易用性迭代,不断降低用户使用数据的成本;
2、时效性:围绕数据产出稳定性与时效性,持续优化已有数据作业。

参考文献

1、《大数据之路-阿里巴巴大数据实践》
2、《数据仓库工具书-维度建模权威指南》

作者简介

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


本文地址:https://www.6aiq.com/article/1595550166928
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出