『 懒人10分钟—大数据篇（一）』数据建模是什么？

• 2019 年 10 月 8 日
• 筆記

数据模型是什么？带你了解大数据技术架构。 —— 23号老板

0

1

概念

原创：lianxiaobao

文章概览

|— 概念

|— 建模方法

|— 模型层次划分

|— 数据模型规范

|— 建模指导 ODS

|— ODS常用的设计方法

|— 应用场景

1、什么是数据模型？

数据模型就是数据的组织和存储方法。主要关注的是从业务、数据存取和使用角度合理存储数据。

2、典型数据仓库建模方法

– 范式模型

– ER实体关系模型

– 纬度模型

建模四步曲：确定业务流程->确定粒度->确定纬度->确定事实表

3、模型层次划分

ADS

该层为应用数据层，根据业务需求组织数据 该层支持百花齐放、尽可能都依赖DWS，特殊情况可依赖DWD的数据， 该层定期需要定期review，将公共指标沉淀到DWS中

DWS

该层按不同粒度、维度对明细数据进行统计汇总产生或算法产生的各类标签数据，包括用于减少数据量的多维分析子层、单粒度单维度的基础标签子层，和多粒度多维度易用性更强的宽表标签子层

DWD

该层对分来源明细数据进行数据清洗、过滤、记历史等操作， 并完成多来源同类明细数据的融合操作，包括分来源基础数据子层和融合数据子层

ODS

如果下游有stage层，则该层在stage层的基础上仅完成源数据格式到标准数据格式转换工作 如果下游无stage层，则业务源系统数据接入到此层，此层数据不做任何加工，禁止重复进入。

STG

业务源系统数据接入到此层，此层数据不做任何加工，禁止重复进入。

DIM

该层为公共维表层，该层独立于DWD、DWS、ADS，为DWD、DWS、ADS提供维度字段说明。

EVL

该层为数据质量评估层，该层独立于ODS、DWD、DWS、ADS、DIM以外，对ODS、DWD、DWS、ADS、DIM的数据质量进行评估，存储评估指标数据。

4、数据模型规范

– 物理、逻辑模型设计规范

– 标准编码规范

– 中英文缩写规范

0

2

理解

下面我就对如何建模做一些简单的介绍，如果想更细致的学习数仓知识推荐《阿里巴巴——大数据之路》。

建模指导

ODS，全称是Operational Data Store 操作数据存储。根据“数据仓库之父” 的BIll.Inmon《数据仓库》中对ODS的定义：

数据仓库是一个面向主题的、集成的、随时间变化的、当前的细节数据集合，用于支持企业对于即时性、操作性、集成的全体信息的需求；

而Kimball 在《数据仓库工具箱》中是这样定义ODS：

a、操作型系统的集成，用于当前、历史以及其他细节查询（业务系统的一部分）；

b、为决策支持提供当前细节数据（数据仓库的一部分）；

因此ODS是用于支持企业日常的全局应用的数据集合，ODS的数据具有面向主题、集成的、可变的以及数据是当前的或是接近当前的这4个基本特征。 同样也可以看出ods 是基于DB和DW之间的一种数据存储技术。

需要注意的是Kimball所说的ODS落地在操作系统（即 关系型数据库），但是在实际生产中，ODS往往是物理落在数据仓库中。

ODS和业务系统（DB）、数据仓库（DW）的关系

ods和业务系统的主要差异在于两者之间面向业务需求是不同的，业务系统是面向多并发读写同时具有满足数据的一致性，而ODS数据是面向数据报表等批量数据查询需求。

(1)集成方式不同，ODS不像业务系统会因为性能压力需要对同一个逻辑表进行分库操作，也不会根据业务划分在物理上进行分库分表。ODS会将业务系统中同一个逻辑表统一到一个物理实体中存储，并且会对重复冗余、不符合业务规则对脏数据清洗、统一编码。

(2)业务系统在数据上需要严格遵循三范式、并且需要创建相对复杂的索引结构来提升系统效率，而ODS在数据主外键和索引上不需要投入大量的系统资源。

(3)两者存储系统不一样 业务系统通常都是Oracle、Mysql、DB2等以食物处理见长的数据型系统，ODS往往落在Hadoop等分布式系统

与原来面向应用等分散的业务系统相比，ODS中的数据组织方式和DW 一样也是面向主题和集成的，所以对进入ODS的数据也进入数据仓库的数据一样进行集成处理。面向主题和集成性得ODS数据在静态特征上很接近DW中的数据但两者之间还是存在许多基本和重要的区别的：

ODS只是存放当前或者接近当前的数据，如果需要的话还可以对ODS中的数据进行增删更新等操作。

但DW中的数据一般不进行修改，所以两者的区别主要体现在可变性、当前性、稳定性、汇总性上。

0

3

ODS常用设计

1、ods表的抽取一般分为三部分

文件抽取、数据库抽取和原始日志的抽取

文件同步的系统架构图：

数据库直连同步：

数据库日志抽取：

原始日志的抽取一般是采用logfile或者前端js代码的方式直接在后端部署日志采集不同的业务采用不同的形式就不再做图。

2、数据质量处理

(1) 数据质量的基本要求是数据的五大特性：准确性，及时性，一致性，完整性，逻辑性。

(2) 数据监控

一般是串行或者并行。串行适用于比较重要的稽核，需要打断ETL任务的继续执行并行使用与部署很重要的稽核指标 不会影响ETL的继续执行。

(3) 数据清洗

在落库之前需要做额外的加工处理后在做入库操作。数据清洗的主要对象是那些不符合要求的数据，具体为不合格的数据，错误的数据，重复的数据。

3、ods表设计

(1) 命名规则：不管是表命名还是字段命名尽量保持和业务系统一致，但是要通过标示来区分增量和全量表

(2) 存储方式：为满足历史数据分析需求我们需要在ods中增加一个时间维度，这个维度我们通常在ods表中作为分区字段

增量存储：按天为单位的增量存储，即用业务日期作为分区，没个分区存放日增量的业务数据

全量存储：以天为单位的全量存储，即用业务日期作为分区，没个分区存放截止到业务日期未知的全量的业务数据

历史拉链数据：是指利用维度模型中缓慢变化的处理方式，真宗方式是通过新增两个时间戳字段（start_dt和end_dt）将所有的以天为单位的变更数据都记录下来。

极限数据：全量数据对于下游使用方存在一定的理解障碍，另一方面全量存储随着时间的推移分区数据会极度膨胀，而现行的系统都有分区数量限制所以为解决上述两个问题，提出极限存储的方式处理。

a、透明化处理也就是通过在hive中添加hook或者视图的方式分析语法对sql分析转换为对应的极限hql；

b、分月做拉链数据。

0

4

小结

ods表的设计方案主要从以下几个角度考虑：

1、应用需求 （是否为全量存储，生命周期的考虑）

2、产出性能（抽取方式会带来不同的性能）

3、存储成本

4、数据质量

未完待续……

下篇将对ods中一些问题和挑战以及数仓中dwd，dws等维度分析进行总结介绍。