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

目录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：表示中心表之间的关系，通过链接表串联整个企业的业务关联关系。