金融数仓体系建设
导语
本文讲述了金融数据仓库从无到有的整体设计思路，以及对数据建模、质量控制、元数据管理及开发规范各方面的经验思考，希望对大家在数仓建设工作方面有所帮助。
背景
自2018年以来，随着业务体系的不断丰富与发展，数据分析与应用需求越来越丰富，对金融数据仓库建设的要求也越来越迫切。
金融数据仓库建设需要解决的问题，主要包括如下几点：
1、数据存储和组织不成体系，数据集成的开发、维护及分析应用成本高；
2、数据质量缺乏定义，缺乏有效统一的数据质量监控体系；
3、缺失元数据规范管理，数据开发、表结构定义不统一，数据任务、数据表维护成本高；
综上，数据仓库的建设，将根据数仓建模方法论，构建一整套架构合理，并具有元数据管理和数据质量监控的现代数仓体系。
大数据领域建模综述
业界认为数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合。数据在数仓中进行有序、有结构地分类组织和存储。通过建立适合业务和基础数据存储环境的模型，可以带来以下优点：
1） 成本降低：减少数据冗余，计算结果复用；
2） 性能提升：快速查询数据，减少数据的I/O吞吐；
3） 效率提高：提高用户的使用数据体验，使用数据效率；
4） 质量改善：解决数据统计口径的不一致性，统一对外的数据发布。
2、数仓建模方法论选择
行业内，常用的数据仓库建模方法主要分为以下几种：
1） ER模型——站在企业角度面向主题的抽象
优点：ER模型从数据库的角度出发，结合业务系统的数据模型，能够非常方便的实现数仓建模；
缺点：由于建模限定在数据库结构之上，且是建立于企业角度，会限制整个数仓模型的灵活性，性能等，特别是对数仓的底层数据向数据集市的数据进行汇总时，需要开发复杂逻辑才能满足需求，所以更适合于小规模、逻辑简单的建模；
2） 维度模型——从分析决策的需求出发构建模型
优点：维度建模非常直观，紧紧围绕着业务流程，直观地反映业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模；
缺点：构建星型模式之前需要进行大量的数据预处理，因此在数仓低层会有大量的数据处理工作；而且，当业务发生变化，需要重新进行维度的定义和预处理，而这些处理过程往往会导致大量的数据冗余；
3） Data Vault模型——出发点是为了实现数据的整合
优点：提出了一套设计原则和结构，在数仓中增加历史跟踪性能；数仓模型足够灵活，可以在迭代过程中的任何时间点采用这些结构，并且可以不需要熟悉业务并进行前瞻规划设计；
缺点：DV代表了对关系、业务键和属性的分解方法，因此与非规范化结构(如星型模式)相比，创建的表的数量更多，由于这个原因，需要许多 joins来查看DV中的数据，使用不太常规和方便；
比较三种建模方式优缺点，并经过对实际业务的分析，基本抽象出业务模型，同时，为了避免业务变化对上层报表产生较大影响。选择采用维度建模方法来搭建数仓，面对业务技术构建技术主题模型，面对业务需求构建分析主题模型，将业务变化消化在技术主题模型而不用修改分析主题模型，这样对用户的使用尽量透明化。
数仓体系建设
下图为数仓体系架构图：
图1 数据仓库架构
业务数据主要包含车分期、房金融、消费金融等业务线上的运营概况、风险控制、营销转化、财务核算等数据集合。
2、数仓架构分层
数据仓库构建过程中，采用分层思想，各层功能及建模方式和原则如下。
1） I(Inbound)层
功能：
从原系统获取数据做的备份，一般不做其它逻辑处理；
建模方法：
-
数据保留时间根据实现业务需求而定；
-
源系统以增量或全量方式经过ETL到I层；
-
可以分表进行周期存储，存储周期不长；
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 元数据管理执行方案
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金融技术中心数据平台部，数据高级开发工程师。
阅读推荐
About The Author
maynard
懒散，不想无聊