数仓分层建模探索

欢迎大家来到IT世界,在知识的湖畔探索吧!

本文章通过真实案例讲述传统数仓实施的方案及需要注意的问题。在讲述具体案例前，首先回答以下几个问题。数仓为什么要分层，一般怎么分层？

分层目的

数仓分层是经过无数数据人多年经验总结出来的一套行之有效的数据组织和管理方法，使得数据结构层次分明，传承有序。首先数据分层，使得数据结构更清晰，每一层都有对应的作用和职责，使用时更方便定位和理解。其次，清晰的数据结构，规范的数据开发标准，可以开发中间层数据，能极大减少重复计算。再次，通过数据分层，可以统一数仓数据出口，提供统一且标准的数据口径，减轻下游数据核对工作。最后，数据分层，可以将复杂的计算简化，分步完成，每一层解决特定问题，使复杂问题简单化。

分层方法

一般怎么分层呢？这个问题需要根据数仓实施的行业，具体分析。一般通用的数仓分层为三层。ODS贴源层，DW整合层，APP下游应用层。但实际实施中，DW整合层又可再分层细化，ODS贴源层前也会衍生出临时存放数据的缓冲层。

通用数仓分层

欢迎大家来到IT世界,在知识的湖畔探索吧!

案例分析

接下来我们以某银行数仓架构为列，讲解数仓分层架构及设计原理。银行数仓架构图如下：

数仓分层架构

传统银行业务中，准实时接入，流式计算是很少有场景需要用到的。所以不在这篇文章中介绍。

TDM临时层

临时层也可以称为缓冲层，最靠近源系统的一层。通过Sqoop直接抽取或者通过ETL文本入库，一般保留最近七天的数据，最多不超过一个月。以TEXT文本格式保存数据。

ODS贴源层：

贴源层数据大多是按照源系统数据分类方式分类，原封不动的接入源数据。保留最原始的数据内容，方便数据追溯查询。数据一般永久保留。以ORCFILE的文件格式存储数据。一般按日分区。数据量较大或特定业务数据，可多级分区。

设计原则：

表名的设计一般是ODS_业务系统_表名_标记。这样设计表名，有清晰的层次结构，方便区分数据来源，还可识别源系统表名。而标记一般是数仓的特有属性。用于区分增量、全量或者处理时间天级或小时级。

SDM标准层：

标准层数据按业务主题分类，对数据进行清洗加工，建立各种主题模型。一般需要进行去重、去噪、异常值处理、值标准化、清洗脏数据垃圾数据、半结构化数据解析等操作。层内主题一般划分事件主题、协议主题、客户主题、财务主题、公共参数等主题。以ORCFILE的文件格式存储数据。一般按日分区。

设计原则：

表名的设计一般是SDM_主题名称_业务含义。在本层需要进行字段名归一，字段类型统一，字段值的标准化等。不同的表中，相同属性字段，字段名称、数据类型、数据内容必须保持一致，这样可以减少犯错概率，降低下游编码难度。标准层必须定义一致的指标和维度，按统一的规范进行设计，可以保证所有的数据按照统一的规范进行存储。

GDM整合层：

整合层数据按业务主题和维度进行分类，从业务理解或业务分析的角度组织数据。这一层数据在标准层的基础上，进行大量的整合汇总，形成分析业务主题的维度数据。以ORCFILE的文件格式存储数据。一般按日分区。

设计原则：

表名的设计一般是GDM_维度_业务含义。整合层设计的核心是维度建模。而维度是维度建模的基础和灵魂。所谓维度，是指观察事物的某一个角度。如‘谁，什么时候，什么地点，为了什么’而做了某一件事。具体而言，‘小王早上在食堂购买5元钱包子’。人物维度—小王，时间维度–早上，地点维度—食堂，商品维度—包子，而5元是事实的度量。以上可以看出，在维度建模时，设计维表，其核心是确定事物的维度。维度字段是查询约束条件(where)、分组条件(group)、排序(order)，与报表标签的基本来源。 注意：整合层设计时，隐含有一巨大工作量的任务，整分核对。

APP应用层：

应用层是面向业务定制的应用数据，主要提供给下游应用产品和业务数据分析。一般会将数据推送到关系型数据库。应用层直接面向需求，所以并没有太多规范，只需参照基本的命名规范即可。以ORCFILE的文件格式存储数据，一般按日分区或不分区。

设计原则：

表名的设计一般是APP_应用名称_需求名称。应用层主要面向需求，设计时需要了解需求所需数据、使用方式、使用频率，性能要求等。然后盘点数仓现有数据能否满足需求，有没有可复用的数据或接口。

数仓分层建模写到这，欢迎留言探索。