47

金融数仓体系建设

 3 years ago
source link: http://mp.weixin.qq.com/s?__biz=MzI1NDc5MzIxMw%3D%3D&%3Bmid=2247488697&%3Bidx=1&%3Bsn=fd82b4f5d0dc37d9a9ba23f8b040d25b
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

导语

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

背景

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

大数据领域建模综述

1、为什么需要数仓建模

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

1） 成本降低：减少数据冗余，计算结果复用；

2） 性能提升：快速查询数据，减少数据的I/O吞吐；

3） 效率提高：提高用户的使用数据体验，使用数据效率；

4） 质量改善：解决数据统计口径的不一致性，统一对外的数据发布。

2、数仓建模方法论选择

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

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

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

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

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

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

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

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

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

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

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

数仓体系建设

下图为数仓体系架构图：

ZJFVFv2.png!web

图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、数据质量监控 数据输出需要保证正确性，数据质量监控可以从技术手段辅助及时发现问题。

N32Yver.png!web

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

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

2ya2Uzv.png!web

图3 数据质量监控流程

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

uIjiEnm.png!web

图4 元数据管理系统

通过技术约束和管理辅助的方案，保证了所有的线上开发都在元数据管理体系下进行：
1） 命名机制：
① 词根：通过梳理金融业务常用维度和指标含义，建立和维护可收敛的词根库，提供数仓开发的字段组合使用；
② 字段：必须使用词根库里的词根构造字段，并保证不同表中同一含义的字段命名一致，方便数据开发传递的一致性，也为后续血缘分析提供基础；
*在添加字段时，为了降低生成字段的工作量，会调用开源分词工具辅助开发人员初步生成合符词根规则的字段名。
③ 数据表：根据主题统一命名数据表名，字段必须来源于元数据管理系统中的维护字段，以方便开发、产品、业务对表的使用；
2） 审核机制：新增词根或字段需严格按照规定命名并经过多层审核
3） 追责机制：实行追责机制，定位到责任人，提高所有人员的责任意识；
4） 一致性保证：一键建表功能可以自动在落地库建表，保证元数据表和落地库的表结构一致，表添加字段也可以直接同步到落地库。同时每天会进行一致性检测，并进行异常报警；

mQryeaN.png!web

图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_表名
    汇总参考：

mqaUBvy.png!web

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金融技术中心数据平台部，数据高级开发工程师。

阅读推荐


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK