编辑导语：本篇作者是给我们讲述了数据组成及其表现形式，重点讲解了“数据分层”这个概念的意义、背景、逻辑和其应用等，一起来看一下。

上一节讲述了数据的基本定义，按正常流程应该来为大家介绍数据的采集和处理，但是这一节主要来说明数据组成以及表现形式。因为这对一个数据产品而言是至关重要的一部分，好比必须要学好数学，你掌握了阿拉伯数字之后必须要掌握四则运算一样。现在咱们来讲一下数据的“四则运算”。

讲到这里，咱们就要引入一个概念“数据分层”。讲数据分层之前，咱们先来说一个贴近现实生活的例子，帮助大家更好地理解数据分层：

如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。

简单来说，数据分层是把现实世界中收集到的有效信息用更加合理的方式表现出来，从而可以更快速的去解决问题。

一、数据分层的意义

还记得上篇文章中，我们如何定义数据的吗？

数据：是通过观测得到的数字性的特征或信息。

所以，数据只是我们对客观世界的记录，而数据建模是我们对数据的抽象，为什么要对数据进行抽象呢？

设想一下这样的场景，数据爆炸的时代，数据的体量每天、每小时、甚至每秒都在激增。当这样的数据不断的出现，没有一套科学的方法去对这些数据进行整理和归档，我们永远无法从海量数据中获取到有价值的数据。

所以数据分层的意义在于：

1. 降低存储成本：减少不必要的数据冗余，从而极大地降低存储和计算成本，更好且有效的利用数据。
2. 提高使用效率：当业务发生变化时，可以更加方便的进行扩展，提高数据稳定性和连续性。
3. 保障数据质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

数据模型能够促进业务与技术进行有效沟通，形成对主要业务定义和术语的统一认识，具有跨部门、中性的特征，可以表达和涵盖所有的业务。

二、数据分层的背景

当企业发展到一定阶段，传统的数据库无法承载大量的数据承载，尤其在数据多而繁杂的情况下，对于使用者，需要数可以更加清晰且有逻辑的适用；对于维护者可以高效有序的进行维护，分层数据设计，即数据仓库dw应运而生。

说起数据仓库，不得不提到创造他的人，比尔.恩门（Bill Inmon）。他在自己的著作《建立数据仓库》一书中所提出的数据仓库的定义：“数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。”

简单来解释，就是把大量数据更有逻辑的组合在一起，并且同时方便使用者和创建者进行操作与应用。

三、数据分层的逻辑

上面两个图可以很清晰的看出分层后的好处，把一团乱麻的数据表进行分层和整理。数仓分层的价值在于：

• 方便使用：将多而繁杂的数据表通过一定的结构进行规范，便于使用方进行使用。
• 追溯源头：分层后的数据血缘非常明确，可以快速获取上游数据的来源。
• 易于维护：规范后数据可以减少数据开发，节约各类计算存储资源，方便维护人员进行维护。
• 简化工作：当发生变化时，可以针对单点进行针对处理，大大简化工作量。

那我们如何进行数据分层呢？大概需要分几层呢？

其实这个问题需要根据实际的业务状况以及需要处理的数据体量来进行划分，介绍分层之前，咱们先来了解下会有哪些分层，每层的作用和目的是啥。

1.第一层：操作数据存储层 ODS

ODS层中的数据是从各类业务系统中（销售系统、客户关系管理系统等等）直接汇入本层。本层数据本身的特点是基本上最大程度还原业务系统中的数据。接入之前需要进行清洗等操作，保证接入本层的数据尽可能是洁净可用的。

ODS层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。

特点：分层中最细粒度的数据，整体数仓中最底层的数据，进行简单加工后直接从业务系统接入。

数据来源：

1）业务库

• 经常会使用sqoop来抽取，例如每天定时抽取一次。
• 实时方面，可以考虑用canal监听mysql的binlog，实时接入即可。

2）埋点日志

• 日志一般以文件的形式保存，可以选择用flume定时同步。
• 可以用spark streaming或者Flink来实时接入。
• kafka。

消息队列：即来自ActiveMQ、Kafka的数据等。

2. 第二层：数据仓库层 DW

1）第一类：公共维度汇总层 DIM（Dimension）

主要由维度表（维表）构成。维度是逻辑概念，是衡量和观察业务的角度。维表是根据维度及其属性将数据平台上构建的物理化的表，采用宽表设计的原则。

2）第二类：数据仓库层DW（Data Warehouse）

这一层是基于ODS和DIM层的数据做轻度汇总。所谓轻度汇总就是按照一定的主题去组合这些数据，例如：作者信息表、用户信息表、稿件信息表。

数据仓库层从上到下，又可以分为3个层：数据细节层DWD、数据中间层DWM、数据服务层DWS。

1. 数据细节层：data warehouse details，DWD：这层目的在于将ODS层进行和DW层进行隔离。进入DW层之前同样需要把数据进行处理和清洗，例如：除去空数据和脏数据等等。
2. 数据中间层：Data Warehouse Middle，DWM；该层是在DWD层的数据基础上，对数据做一些轻微的聚合操作，生成一些列的中间结果表，提升公共指标的复用性，减少重复加工的工作。
3. 数据服务层：Data Warehouse Service，DWS；该层是基于DWM上的基础数据，整合汇总成分析某一个主题域的数据服务层，一般是宽表，用于提供后续的业务查询，OLAP分析，数据分发等。一般来说，该层的数据表会相对较少；一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。

3. 第三类：应用数据服务层 ADS

Application Data Service。该层主要是提供数据产品和数据分析使用的数据，一般会存放在ES、MySQL等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。

ADS层数据是数据仓库的最后一层数据，以DWS层数据为基础进行数据处理。

那常见的分层结构有哪些呢？如何去应用这些分层呢？

四、常见的数据分层应用

这3大类5层的数据层，是层层递进，并非每一层都是必不可少的，想要建设一套较为标准的数仓，现在市面上都是如何进行构建呢？

1. 三级数仓分层

我们先来看下简单的三级分层，三级分层氛围ODS、DWD、DWM层这三层。每一层的目的和作用如下：

1）第一层：ODS层

用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。

下面是两个例子，分别适用于传统行业和互联网行业：

• 传统行业ODS层：各业务系统对接来的数据。拿交易源数据来说（每次订单的记录，一个订单有多个记录）。例如：交易源数据、用户源数据、货物源数据
• 互联网行业ODS层：除业务系统外，还会对接日志采集系统。拿app日志埋点来说，本层会记录用户每次登陆、app内的行为数据，一个用户会有多条记录）。例如：APP日志数据、小程序日志数据、用户登录数据等等

2）第二层：DWD层

主要存档从ODS层汇总上来的数据，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可将某些重要属性字段做适当冗余，也即宽表化处理。从ODS层汇总上来的数据。最大限度保证与ODS层数据一致。

下面是两个例子，分别适用于传统行业和互联网行业：

• 传统行业DWD层：拿订单数据来说，本层会记录订单粒度的支付情况，一个订单仅有一条记录。例如：订单交易表、用户表、活动表、货物表。
• 互联网行业DWD层：拿用户登录表来说，本层记录用户在。

3）第三层：DWM层

是对DWD层的生产数据进行轻度综合和汇总统计(可以把复杂的清洗，处理包含，如根据PV日志生成的会话数据)。轻度综合层与DWD的主要区别在于二者的应用领域不同，DWD的数据来源于生产型系统，并未满意一些不可预见的需求而进行沉淀;轻度综合层则面向分析型应用进行细粒度的统计和沉淀。例如：按照天粒度去汇总某一主题的数据情况。

• 传统行业DWM层：从DWD层交易表（天粒度）、用户表（天粒度）、货物表（天粒度）。
• 互联网行业DWM层：用户登录行为表（天粒度）、订单表（天粒度）。

2. 四级数据分层

在上述三层的基础之上，增加第四层DWS层。

1）第四层：DWS层

DWS=DWD+DWM

通过由轻度汇总层和明细层数据计算生成。又称数据集市或大宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表， 用于提供后续的业务查询，OLAP分析，数据分发等。

• 传统行业DWS层：用户主题宽表、货物主题宽表、店铺主题宽表。
• 互联网行业DWS层：用户主题宽表、店长主题宽表。

3. 五级数据分层

在上述四层的基础上，增加第五层ADS层。

1）第五层：ADS层

ADS层可以理解为对业务的“专属定制表”。ADS ≈ DWD+DWS，而且和DWD、DWS的表名侧重于object或用户行为不同的是，ADS的表名可以看出有特定的业务特征。

• 传统行业ADS层：爆款商品排行表、高价值用户表、用户近30天留存表。
• 互联网行业ADS层：业务大盘表、用户生命周期表、用户近7天留存表。

本文由 @业务数智化 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于CC0协议