文章作者：胡明昊 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） 命名机制：

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

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

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

③ 数据表：根据主题统一命名数据表名，字段必须来源于元数据管理系统中的维护字段，�