大数据平台-数据建模总结-技术方案

目录
1 仓库底层模型重构 ............................................................................................................................ １
1.1.1.1 数据仓库建模基本理论.......................................................................... １
1.1.1.2 大数据平台下数据仓库设计思路 ........................................................... ６
1.1.1.3 整合层数据处理思路.......................................................................... ２７
1.1.1.4 整合层主题模型设计关注点............................................................... ２８
1.1.1.5 整合层主题模型算法选择 .................................................................. ３０
1.1.2 核心模型改造方案......................................................................................................... ３１
1.1.
2.1 新核心模型重构设计思路 .................................................................. ３１
1.1.
2.2 新核心模型设计................................................................................. ３２
1.1.
2.3 老核心模型中历史数据迁移............................................................... ３４
1.1.
2.4 新老核心模型同步运行...................................................................... ３５
1.1.
2.5 下游应用切换到新核心模型............................................................... ３５
1.1.
2.6 老核心模型归档下线.......................................................................... ３５
1.1.3 共性加工层重构方案..................................................................................................... ３５
1.1.3.1 方案概述............................................................................................ ３５
1.1.3.2 分层设计方案..................................................................................... ３６
1.1.3.3 数据保留规则..................................................................................... ３６
1 仓库底层模型重构
针对新核心系统的数据表，重新进行整合层的主题域划分及模型设计，逐渐废除现有的新核心向老核心映射后的模型实体。

新设计的模型实体，可优先入模新核心的源系统，不要求外围系统的也按此模型入模（重保高时效应用依赖的外围表除外）。

但新设计的数据模型需考虑卡中心各外围系统，保持模型的稳定性，以及需考虑各源系统的数据到达时间，合理进行模型整合及拆分，保障下游应用的时效。

后续外围系统的模型新增及调整，均可以此模型作为参照。

整合成新的仓库模型，在设计上需与传统数仓模型有一定区分，能满足大数据平台的特性，从存储、使用、性能、稳定等角度综合考虑。

由于后续仓库拟不存储敏感信息，需酌情在底层新增敏感信息的弱化信息处理（如手机号是否有效，长度等）。

重构共性加工层的模型，梳理出来的重要指标维度，需在共性加工层进行实现。

将各集市及下游的共性指标维度（尤其是基础性指标）进行下沉，以及考虑到处理时效等，减少加工链路。

新核心新的业务特性，或者下游应用使用的一些重点主题，需合理考虑模型或指标维度的新增。

重构后的数据模型，必须能涵盖现有生产的所有下游应用，保障业务的延续性。

底层数据模型的重构，需充分考虑生产上新老两套模型的并行方案，以支持后续两套模型的平稳过渡。

重构后的数据模型，包括整合层及共性层，整体批次时效不得晚于现有生产时效。

数据仓库建模
1.1.1.1 数据仓库建模基本理论
一、数仓建模的目标
访问性能：能够快速查询所需的数据，减少数据I/O。

数据成本：减少不必要的数据冗余，实现计算结果数据复用，降低大数据系统中的存储成
本和计算成本。

使用效率：改善用户应用体验，提高使用数据的效率。

数据质量：改善数据统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台。

所以，大数据的数仓建模需要通过建模的方法更好的组织、存储数据，以便在性能、成本、效率和数据质量之间找到最佳平衡点。

二、四种建模方法
1、ER实体模型
在信息系统中，将事务抽象为“实体”（Entity）、“属性”（Property）、“关系”（Relationship）来表示数据关联和事物描述，这种对数据的抽象建模通常被称为ER实体关系模型。

实体：通常为参与到过程中的主体，客观存在的，比如商品、仓库、货位、汽车，此实体非数据库表的实体表。

属性：对主体的描述、修饰即为属性，比如商品的属性有商品名称、颜色、尺寸、重量、产地等。

关系：现实的物理事件是依附于实体的，比如商品入库事件，依附实体商品、货位，就会有“库存”的属性产生；用户购买商品，依附实体用户、商品，就会有“购买数量”、“金额”的属性产品。

实体之间建立关系时，存在对照关系：
1:1：即1对1的关系
1:n：即1对多的关系
n:m：即多对多的关系
在日常建模中，“实体”用矩形表示，“关系”用菱形，“属性”用椭圆形。

ER实体关系模型也称为E-R关系图。

应用场景：
1、ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式。

2、Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模。

3、BI架构提出分层架构，数仓底层ods、dwd也多采用ER关系模型进行设计。

2、维度建模
维度建模源自数据集市，主要面向分析场景。

Ralph Kimball推崇数据集市的集合为数据仓库，同时也提出了对数据集市的维度建模，将数据仓库中的表划分为事实表、维度表两种类型。

事实表：
在ER模型中抽象出了有实体、关系、属性三种类别，在现实世界中，每一个操作型事件，基本都是发生在实体之间的，伴随着这种操作事件的发生，会产生可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。

维度表：
维度，顾名思义，看待事物的角度。

比如从颜色、尺寸的角度来比较手机的外观，从cpu、内存等角度比较手机性能。

维度表一般为单一主键，在ER模型中，实体为客观存在的事务，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。

比如商品，单一主键：商品ID，属性包括产地、颜色、材质、尺寸、单价等，但并非属性一定是文本，比如单价、尺寸，均为数值型描述性的，日常主要的维度抽象包括：时间维度表、地理区域维度表等。

维度建模通常又分为星型模型和雪花模型。

星型模型：
雪花模型：
星型模型和雪花模型的主要区别在于对维度表的拆分，对于雪花模型，维度表的设计更加规范，一般符合3NF；而星型模型，一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率。

雪花、星型模型对比：
1、冗余：雪花模型符合业务逻辑设计，采用3NF设计，有效降低数据冗余；星型模型的维度表设计不符合3NF，反规范化，维度表之间不会直接相关，牺牲部分存储空间。

2、性能：雪花模型由于存在维度间的关联，采用3NF降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；星型模型反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能较雪花模型高。

3、ETL：雪花模型符合业务ER模型设计原则，在ETL过程中相对简单，但是由于附属模型的限制，ETL任务并行化较低；星型模型在设计维度表时反范式设计，所以在ETL过程中整合业务数据到维度表有一定难度，但由于避免附属维度，可并行化处理。

大数据和传统关系型数据库的计算框架不一样，例如对比mapreduce和oracle，在mapreduce里面，每多一个表的关联，就多一个job。

mapreduce的每个任务进来，要申请资源，分配容器，各节点通信等。

有可能YARN调度时长大于任务运行时间，例如调度需要5秒才能申请到资源，而表之间的join只需要2秒。

hive优化里面，要尽可能减少job任务数，也就是减少表之间的关联，可以用适当的冗余来避免低效的查询方式，这是和oracle等其他关系型数据库不同的地方。

（点此了解：MapReduce作业运行机制）
3、Data Vault模型
Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展，灵活应对业务变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理，并非针对分析场景所设计。

Data Vault模型是一种中心辐射式模型，其设计重点围绕着业务键的集成模式。

这些业务键是存储在多个系统中的、针对各种信息的键，用于定位和唯一标识记录或数据。

Data Vault模型包含三种基本结构：
1）中心表-Hub：唯一业务键的列表，唯一标识企业实际业务，企业的业务主体集合。

2）链接表-Link：表示中心表之间的关系，通过链接表串联整个企业的业务关联关系。

3）卫星表-Satellite：历史的描述性数据，数据仓库中数据的真正载体。

Data Vault是对ER模型更进一步的规范化，由于对数据的拆解更偏向于基础数据组织，在处理分析类场景时相对复杂，适合数仓底层构建，目前实际应用场景较少。

4、Anchor
Anchor是对Data Vault模型做了更进一步的规范化处理，初衷是为了设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于是设计出的模型基本变成了K-V结构的模型，模型范式达到了6NF。

由于过度规范化，使用中牵涉到太多的join操作，目前没有实际案例，仅作了解。

四种基本建模方法对比：
当前主流建模方法为：ER模型、维度建模。

1）ER模型
ER模型应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性进行合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。

问题：
a）需要全面梳理企业所有的业务和数据流；
b）实施周期长；
c）对建模人员要求高。

2）维度模型
维度建模是面向分析场景而生，针对分析场景构建数仓模型，重点关注快速、灵活的解决
分析需求，同时能够提供大规模数据的快速响应性能。

针对性强，主要应用于数据仓库构建和OLAP引擎底层数据模型。

模型选择和设计的原则：
a）数仓模型的选择是灵活的，不局限于某一种模型方法；
b）数仓模型的设计也是灵活的，以实际需求场景为导向；
c）模型设计要兼顾灵活性，可扩展，而对终端用户透明性；
d）模型设计要考虑技术可靠性和实现成本。

总结
数据仓库建模中维度建模和3NF建模并不是OR的关系，它们更像是上下层的关系。

3NF基础模型更注重源数据怎么放，它是一个重在数据存放的数据仓库模型，基本特性为主题，标准化，集成、相对稳定、反应数据的历史变化。

维度模型更注重数据怎么用，它是一个面向数据分析型的数据仓库，基于事实表关联维度表进行多维分析。

传统数据仓库建设层级基本是
贴源层-> 3NF基础模型->维度模型层
1.1.1.2 大数据平台下数据仓库设计思路
1.1.1.
2.1 总体概述
1.1.1.
2.1.1 总体架构
在大数据背景下数据仓库模型包括基础层、共享层、应用层，其中基础层又包括ODS层和整合层，而ODS层又可以进一步根据需要分为增量贴源层和ODS历史层。

1.1.1.
2.1.2 基础层
基础层通常包括贴源层、ODS历史层、整合层。

贴源层
通过Hive外部表搭建，存储每日增全量数据无需保留历史。

ODS历史层
ODS历时层保留初始全量数据以及每日增量数据，通过数据日期搭建分区表。

ODS历史层是大数据平台下数据仓库模型架构中的一个新增层，也是数据仓库中非常关键的一层，它简单粗放的保留了原始数据历史轨迹，为平台下游应用的多维度，多视角分析挖掘提供数据保证。

ODS 历史层设计特点是冗余的，贴源的，可追溯的。

在传统的数据仓库模型架构中由于存储的限制，ODS历史层没有落地。

整合层
整合层是整个数据仓库的核心层。

数据经过ODS历时层之后再这里进行加工整合。

我们通常所说的ER、DM、DV等建模方法在这里落地。

整合层的设计因客户具体的数据情况而异。

基础层设计以数据为驱动。

1.1.1.
2.1.3 共享层
共享层根据应用需求存储共性加工数据，避免数据集市的烟囱式开发。

共享层采用维度模型设计思想。

共享层设计以应用为驱动。

1.1.1.
2.1.4 应用层
应用层通常按主题划分为财务，风险、客户、绩效等主题指标。

应用层设计以业务需求为驱动。

1.1.1.
2.2 设计范围
数据仓库建设由下而上，从基础层开始，我们首先需要梳理平台涉及到的数据范围。

1.1.1.
2.3 设计目标
数据仓库基础层建设包括贴源层、ODS历史层、整合层的建设。

其中贴源层、ODS历史层建设逻辑比较简单，在此不再多讲。

下面着重描述整合层的建设。

整合层的定位，整合层的设计目标主要包括：
中性的，共享的：整合层的设计不针对某个特别的应用而设计，能涵盖银行业的业务范围，且满足金融机构不断产生的业务发展需求。

灵活的，可扩展的：能存放最详尽的历史数据，业务发生变化时易于扩展，适应复杂的实际业务情况。

稳定的，经得起考验的：数据模型能够在很长时间内保持稳定性，回答不断产生、不断变化且无法预先定义的业务问题。

当未来新增源系统入仓或是大量新增源系统表，主题模型依然保持稳定，不会对模型进行大幅度的重构操作。

规范的，易懂的：使用业务语言进行模型设计，易于让业务人员理解和使用，有助于IT和业务部门人员的沟通。

1.1.1.
2.4 总体设计原则
中信银行信用卡中心主题模型层逻辑数据模型设计将本着以博易公司 FS-LDM产品整合层模型为核心骨架，结合博易公司 FS-LDM在其他银行同业客户化的实施经验，后期参考中信银行信用卡中心大数据架构提升项目高阶模型现状和数据标准现状，同时充分考虑源系统的各种数据信息项以及信息调研的结果，搭建中信银行信用卡中心主题模型层高阶模型。

主题设计原则
博易公司 FS-LDM包含10大主题。

在进行具体的数据调研后，会根据具体的业务调研分析进行一一对应且保证业务含义相同。

同时也会梳理每个主题涉及到数据标准情况并进行一一对应。

在高阶逻辑数据模型设计阶段可能不对现有主题进行裁减，在详细设计阶段将结合信息调研分析结果，决定逻辑数据模型主题是否物理化。

核心实体设计原则
以FS-LDM中的现有实体为基础，结合FS-LDM在其他银行同业客户化的实施经验，参考中信银行信用卡中心数据仓库高阶模型现有成果和数据标准成果，形成中信银行信用卡中心高阶设计模型中的实体。

结合源系统信息调研分析的结果和最终应用的需求，再对高阶模型进行完善。

1.1.1.
2.5 整合层主题说明
1.1.1.
2.5.1 当事人（PARTY）
当事人PARTY：一个人或者一组人，指金融机构所服务的任意对象和感兴趣进行分析的各种对象。

如：个人或公司客户、潜在客户、代理机构、雇员、分行、部门等。

一个当事人（Party）可以同时是这当中的许多角色。

它们之间存在许多关系，如银行机构与客户（管理机构、开户机构等），内部机构之间（上下级等），企业之间（集团客户、担保人等），企业与个人（雇佣、担保等），个人之间（父子、夫妻、联络人等），这些在模型中都可以体现。

1.1.1.
2.5.1.1 数据准入原则
符合当事人定义的数据都进入当事人主题，但只有满足如下准入原则的当事人才会进入当
事人主实体：
符合当事人定义。

具有唯一标识和有效鉴别信息的当事人。

基本信息较为完备的当事人。

除客户外与银行有紧密的业务或服务关系、且银行对其绩效或行为非常关注的当事人。

例如：银行员工、商户。

内部机构作为当事人主题中一类特殊信息予以纳入。

不满足上述条件或满足下述例外情况之一者，则不入当事人主实体：
由于柜员或用户可能是一个自然人，也可能是为了业务操作需要而建立的虚拟用户，以及柜员或用户的属性信息具有角色性、专有性、信息不完整性等不同于当事人定义的特征属性，所以柜员或用户不入当事人主实体，而作为独立实体进行存放。

业务系统中无独立的唯一标识的当事人如无特殊原因不入主实体，而将该类当事人作为主实体当事人的重要关联人存放，例如：当事人的委托人、第二联系人、监护人、法人等。

1.1.1.
2.5.1.2 实体分类原则
参照FS-LDM模型架构，数据仓库逻辑模型中当事人层级分类如下：
第一层：分为个人当事人和机构当事人，个人当事人下存放所有个人的信息。

第二层：机构当事人分为单位客户、内部机构、商户，单位客户主要存放对公客户信息，内部机构下主要存放中信银行信用卡中心的内部组织机构信息，商户主要存放商户相关信息。

1.1.1.
2.5.1.3 ID生成规则
当事人信息来自于多个源系统，如果直接使用源系统当事人编号，则入仓时有可能造成编号重复；如果对每个源系统的当事人通过一定编码规则来区分不同系统间的不同当事人，则有可能造成仓库内以及仓库下游系统使用当事人编号时不便。

1.1.1.
2.5.1.4 数据整合原则
当事人主题的当事人信息来源于各个系统，而各个源系统间又存在着客户信息的交互，当不同源系统站在不同业务角度使用客户信息时，则造成了源系统对客户信息保存的侧重点不同。

当事人主题数据整合原则如下：
来源不同系统的不同当事人编号，分别单独入仓。

例如，核心业务系统、对公信贷业务系
统。

使用其他系统原生数据作为本系统数据的源系统，在字段名称（业务含义）完全一致的情况下，字段取值一致的情况下，则以原生系统的数据为准进行入仓；
使用其他系统原生数据作为本系统数据的源系统，在原生数据基础上修改字段取值，并增加字段的情况下，该系统客户信息单独入仓。

例如，理财产品销售系统通过联机交易向核心系统发起客户信息查询，并可以对除客户号以外的其它字段值进行修改，并在核心系统查询客户信息基础上添加客户客户风险等级、客户经理等字段保存在本系统的客户信息表中。

1.1.1.
2.5.1.5 历史处理原则
针对当事人主题中各当事人的不同特征，在数据仓库中会考虑对当事人的重要的可能会变化的属性保留其变化的历史轨迹，即对其进行数据的历史拉链处理，以达到使用者可以追溯到任意时点当事人的关键属性信息的目的。

考虑进行历史拉链处理的内容主要涉及如下：当事人名称历史
当事人鉴别信息历史
当事人地址关系历史
当事人重要关联人历史
当事人统计信息历史
当事人评分历史
当事人评级历史
当事人关系历史
当事人状态历史
1.1.1.
2.5.1.6 例外处理原则
无例外处理。

1.1.1.
2.6 产品（PRODUCT）
产品是银行及其关联的当事人提供给市场、能单独销售并满足客户的某种需求，可以从中赚取各种实际或潜在收入的有形商品或无形服务。

产品可以通过产品特征加以描述，产品特征是金融机构提供的所有可以应用于产品的有效产品特征，它标识了金融机构在提供产品时的限制或附加条件。

在银行业的例子有手续费、期限、允许的展期和提前通知的要求等。

为满足银行内部管理的需要和适应不断变化的业务需求，可以根据实际情况结合产品特性将产品分组，即“产品组”，用于提供信息进行分析比较。

如个人定期存款是产品组，而个人人民币通知存款、个人外币通知存款是可销售的产品，都属于个人定期存款产品组。

产品组可以有多个分组标准，也支持多个产品标准分类。

出于市场竞争的需要，或作为市场营销的结果，将一些产品打包、捆绑销售，称其为“产品包”。

产品包的产品没有相似性，如抵押贷款与财产保险可以组成产品包。

产品与当事人、协议与渠道之间存在多种关系。

1.1.1.
2.6.1 数据准入原则
符合产品定义的数据将进入产品主题，但只有满足如下准入原则的产品才会进入产品主实体：
符合产品的定义。

多个系统对同类产品有描述，取最细粒度的系统的产品数据。

符合以上条件的数据，将进入产品主实体。

1.1.1.
2.6.2 实体分类原则
依据博易公司的FS-LDM对产品的分类方法逻辑模型中产品划分为：银行产品、保险产品、投资产品等等。

在银行产品下细分为：
1.1.1.
2.6.3 ID生成规则
产品的唯一标识通常是产品编号，有的根据实际情况加上银行号，源系统号等前缀。

1.1.1.
2.6.4 数据整合原则
源系统产品信息通常以不同形式分布在各源系统中，且不会根据产品目录进行数据的调整，根据数据准入原则将各源系统与产品有关的数据保存在不同的实体中，公共信息存放在产品主实体表中，其他属性信息在不同实体中进行保存。

进入产品的数据是最原始的底层的产品，依据ID生成原则给每个产品分配一个ID，以区分产品的唯一性，但对数据不做整合。

产品重要属性及与其它主题的关系都将保存历史信息，便于追踪其历史变化轨迹。

根据这一原则，产品主题的主要历史信息如下：
产品状态历史
产品产品组关系历史
产品当事人关系历史
协议产品关系历史：为方便分析使用，一些账户可能会对应多个产品，或者产品的编码会发生变化。

产品渠道历史
1.1.1.
2.6.6 例外处理原则
无例外处理。

1.1.1.
2.7 协议（AGREEMENT）
协议（AGREEMENT）是当事人之间签立的契约关系，它的形式可以是多样化的，如账户、客户使用银行服务所签订的合同等，当金融机构与客户之间针对某种产品或服务的约束和条件达成契约时，一个协议（AGREEMENT）就会被开立，因此协议是客户和银行往来的重要载体。

协议主题的设计主要借鉴FS-LDM的设计框架，并将充分考虑中信银行信用卡中心业务系统的个性特点；数据仓库整合时会尽量保留各业务系统的协议信息原貌和历史变更记录，只有部分完全由基础数据衍生加工汇总的数据及冗余的数据会考虑进行舍弃。

协议主题的模型结构主要存储中信银行信用卡中心和客户签订的各种形式的协议内容，包含协议的签约信息、协议的主要属性历史变迁记录、协议主题与其它主题的关系变化历史，协议的明细记录和协议相关的限额、违约、风险评级记录。

1.1.1.
2.7.1 数据准入原则
符合协议定义的数据将进入协议主题，但只有满足如下准入原则的协议才会进入协议主实体：
符合协议定义的对象。

银行重点关注的业务对象内容。

参照FS-LDM模型架构，数据仓库逻辑模型中协议的分类方法如下：
协议主要分为金融协议、保险协议等其他协议：
金融协议：银行与当事人签订的协议，以及银行内部管理及投资协议。

保险协议：包括组织和个人的保险，包括财产险、伤亡险、人寿险等。

（由于中信银行信用卡中心不存在独立的保险业务产品，所以在中信银行信用卡中心保险协议仅是逻辑分类）金融协议依据不同类型逐层细分，第一层：
账户借据类协议：该实体是指涉及金额、期限、利率等的具体协议细项的银行传统账户，一般为银行客户的账户，如对公存款账户、对公贷款账户、储蓄账户等，也可以是内部核算的内部账户和表外账户。

账户借据类协议有两部分，一部分的账户是会计核算的主要构成单位，主要来自核心系统；另一部分的是来自外围系统，涉及到余额，份额信息的账户，为了统计方便通常虚拟为账户信息，存放在账户借据类协议中。

由于实际业务分析中经常存在针对各类账户信息进行的统计和分析，所以把账户借据类协议独立划分为一类。

银行账户主要涉及信息：
账户与当事人的关系：开户机构、所属机构、开户柜员、审批用户等
账户的状态：基本状态，挂失状态，冻结状态等
账户的计息方式、利率代码
账户的重要日期：开户日期、起息日期、到期日期等
账户的余额、限额：账户余额、圈存金额、透支额度
帐户的凭证、科目信息
银行账户下又可划分为：存款账户、贷款借据、信用卡账户、内部账户、同业存放账户、投资理财账户。

合同类协议：银行与当事人针对特定的服务或产品而签订的契约，以及银行出于融资、投资的目的而与第三方或银行自身内部机构之间签立的契约内容，合同类协议与账户借据类协议在数据存储上是排他的分类。

合同类协议下按照协议中涉及到的产品，可以有以下分类：
贷款协议：针对银行为客户提供的信贷产品而签立的契约内容，包含对公贷款合同，零售。