数据分层是数据仓库设计中非常重要的一个环节。优秀的分层设计可以让整个数据系统更容易理解和使用。

目前在网络上能检索到的相关文章,大多只是简单的提到了数据分层的设计,或者缺乏清晰详细的解释,或者缺乏可实施的方案,或者缺乏具体的实例。
因此,本文将指出一种通用的数据仓库分层方法,它包括以下内容:
介绍数据分层的作用。
提出了一种通用的数据分层设计和分层设计的原则。
举具体例子来说明
提出切实可行的意见
一、数据分层
1.为什么要设计数据分层?
这应该是数据仓库专业学生在设计数据分层时首先要面对的问题。类似的问题可能还有很多,比如“为什么要做数据仓库?”“为什么要做元数据管理?”“为什么要做数据质量管理?”。
当然,这里只说为什么要做设计数据分层。
作为数据规划者,我们肯定希望自己的数据能够有序流动,数据的整个生命周期能够被设计者和用户清晰感知。
直观来说如下:层次分明,依赖直观:
然而,在大多数情况下,我们已经完成的数据系统依赖于复杂和层次混乱。
如下图所示,不知不觉中,我们可能会做出一套混乱的表依赖结构,甚至循环依赖的数据系统:
因此,我们需要一套有效的数据组织和管理方法,使我们的数据系统更加有序,这就是所谓的数据分层。数据分层并不能解决所有的数据问题,但是可以给我们带来以下好处:
清晰数据结构:中的每个数据层次都有其范围和职责,这使得查找和理解表变得更加容易。
减少重复开发:规范了数据分层,开发了一些通用的中间层数据,可以减少庞大的重复计算。
通过统一数据口径:,的数据分层,提供统一的数据输出,统一对外输出的数据口径。
复杂问题简单化:将复杂的任务分解成几个步骤,每个步骤解决一个特定的问题。
二、一种通用的数据分层设计
为了满足上面提到的数据分层的好处,我们将数据模型分为三层:数据操作层(ODS)、数据仓库层(DW)和数据应用层(APP)。
如下图所示:
简单来说,我们可以理解为:
ODS层存储被访问的原始数据;
DW层用于存储我们要重点设计的数据仓库中间层的数据;
APP是为业务定制的应用数据。
这三层的设计详细描述如下:
1.数据操作层
“面向主题”,数据操作层,也叫ODS层(操作数据存储),是数据源中最接近数据的一层。数据源中的数据经过提取、清洗、传输,也就是说经过传说中的ETL,加载到这一层。
这一层的数据一般按照源业务系统的分类方法进行分类。
一般来说,为了考虑到后续可能需要追溯数据的问题,不建议对该层做过多的数据清洗,原封不动地访问原始数据即可,数据去噪、去重、离群点处理等过程可以在后DWD层完成。
2.数据仓库层
数据仓库层,DW(Data Warehouse),是我们做数据仓库时的核心设计层。这里,从ODS层获得的数据用于根据主题建立各种数据模型。
数据仓库层又分为DWD(数据仓库细节)层、数据仓库中间层和DWS(数据仓库服务)层。
1)数据明细层:DWD(Data Warehouse Detail)
该层一般保持与ODS层相同的数据粒度,并提供一定的数据质量保证。
同时,为了提高数据细节层的可用性,该层会采用一些维度降级方法,将维度降级到事实表中。
,减少事实表和维表的关联。另外,在该层也会做一部分的数据聚合,将相同主题的数据汇集到一张表中,提高数据的可用性,后文会举例说明。
2)数据中间层:DWM(Data WareHouse Middle)
该层会在DWD层的数据基础上,对数据做轻度的聚合操作,生成一系列的中间表,提升公共指标的复用性,减少重复加工。
直观来讲,就是对通用的核心维度进行聚合操作,算出相应的统计指标。
3)数据服务层:DWS(Data WareHouse Servce)
又称数据集市或宽表。按照业务划分,如流量、订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等。
一般来讲,该层的数据表会相对比较少,一张表会涵盖比较多的业务内容,由于其字段较多,因此一般也会称该层的表为宽表。
在实际计算中,如果直接从DWD或者ODS计算出宽表的统计指标,会存在计算量太大并且维度太少的问题,因此一般的做法是,在DWM层先计算出多个小的中间表,然后再拼接成一张DWS的宽表。
由于宽和窄的界限不易界定,也可以去掉DWM这一层,只留DWS层,将所有的数据在放在DWS亦可。
3、数据应用层(APP)
在这里,主要是提供给数据产品和数据分析使用的数据,一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用,也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。
比如我们经常说的报表数据,一般就放在这里。
4、维表层(Dimension)
最后补充一个维表层,维表层主要包含两部分数据:
至此,我们讲完了数据分层设计中每一层的含义,这里做一个总结便于理解,如下图:
三、举个栗子
趁热打铁,举个栗子说明一下,如下图,可以认为是一个电商网站的数据体系设计:
我们暂且只关注用户访问日志这一部分数据。
在ODS层中:由于各端的开发团队不同或者各种其它问题,用户的访问日志被分成了好几张表上报到了我们的ODS层。
为了方便大家的使用,我们在DWD层做了一张用户访问行为天表,在这里,我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面,统一字段名,提升数据质量,这样就有了一张可供大家方便使用的明细表了。
在DWM层:我们会从DWD层中选取业务关注的核心维度来做聚合操作,比如只保留人、商品、设备和页面区域维度。类似的,我们这样做了很多个DWM的中间表
然后在DWS层:我们将一个人在整个网站中的行为数据放到一张表中,这就是我们的宽表了,有了这张表,就可以快速满足大部分的通用型业务需求了。
最后在APP应用层,根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。
备注:例子只是为了简单地说明每一层的作用,并不是最合理的解决方案,大家辩证地看待即可。
四、技术实践
既然谈到了数据分层,那不同的层次中会用到什么计算引擎和存储系统呢,本节来简单分享一下。
数据层的存储一般如下:
计算引擎的话,可以简单参考图中所列就行,目前大数据相关的技术更新迭代比较快,本节所列仅为简单参考:
五、思考
本文将思考和总结一下数据分层的原则是什么?为什么要这样分层?每层之间的界限又是什么?
我个人从这几个角度来理解数据分层的划分:
六、总结
数据分层的设计,在某种程度上也需要通过数据命名来体现,本文的核心在于讲解数据分层的思想和方法,后面会有单独的文章来分享该如何根据数据分层来设计数据表的命名规范。
还木有评论哦,快来抢沙发吧~