本文介绍了数仓的分层结构和分层的原因。通过分层,可以使数据处理更加规范、高效,提供可靠的数据支持。让我们一起学习一下~
一、数仓一般分哪些层?操作数据层:ODS(Operational Data Store)
把操作系统数据几乎无处理地存放在数据仓库系统中。
(相关资料图)
事实明细层:DWD(Data Warehouse Detail)
DWD 层是在ODS层基础上,根据业务过程建模出来的事实明细层。
公共汇总层:DWS(Data Warehouse Summary)
一般根据维表数据和明细事实数据加工生成,作为通用的数据模型使用。
应用数据层:ADS(Application Data Store)
存放数据产品个性化的统计指标,根据明细层、汇总层及维表数据加工生成。
关于啥是数仓分层这里就不多介绍了。
首先我们先了解数仓分层现状:
各大企业数仓都是咋分的?有啥区别?
经过整理各大企业的数仓分层情况,经过对比可以发现:
不同点:
命名有些不同,有的叫“a”,有的叫“A”。所以当我们遇到看不懂听不懂的命名时,就可以轻松识破啦。分层数不同,有些4层,有些5层,每层对数据处理有些许差异,比如在贴源层会进行3NF建模,猜测是接入业务系统太多,有些系统的表设计不符合规范,难以理解,在这层进行统一梳理。相同点:
都包括贴源层、明细层、汇总层、应用层。都遵循维度建模理论,数据处理的流程本质上一样的,先拆分梳理再聚合汇总。
二、数仓为什么分层?回答这个问题前,我们可以先思考如果不分层会怎么样?不分那么多层会怎么样?
1. 如果不分层会怎么样?假设我们把数仓里的表都拍平,没有分层概念,业务源数据经过简单的数据清洗,加载到数据仓库中,直接应用于数据分析。
好处:数仓与业务系统隔离,数据分析不会直接影响到业务系统。
坏处:
分析难:集成系统的开发规则,规范程度、统计口径都不一致。你还要去做数据关系映射,了解原业务系统的数据逻辑。无法对数理逻辑进行沉淀,每次分析都要重头准备数据。分析慢:由于业务系统是遵循范式建模的,发现关联了一堆表才能完成分析需求,分析效率极低。2. 不分那么多层会怎么样?看情况,当数据少,分析需求少,可以不去分dw层,ods直接加工到ads层,我们刚开始就是这样干的。
发现好像也不是不行啊,数据直接加工到ads层,上层应用查询效率也够用哈。
此时的好处:省事,成本很低,效率很高,数据出错改的也很快。
此时的坏处:
没有公共逻辑沉淀,口径不统一,维度不统一,单个需求处理起来依然很麻烦。会造成重复开发,当有口径变动时,需要改动多处。无法满足更多的分析需求,拓展性极差,随时面临重构的风险。由此我们可以推演出为啥要进行数仓分层?
隔离原始数据:将业务数据与统计分析数据解耦,屏蔽相互之间的影响。清晰数据职能(把数据条理化):让每个数据层都有自己的作用和职责,将一个复杂的任务拆解成多个步骤来分步骤完成,每个层只解决特定的问题,在使用和维护的时候能够更方便和理解。(ODS层与业务数据保持一致即可,方便溯源数据问题,不影响业务数据库;DWD基于业务过程拆分数据,清洗数据,适当冗余维度;DWS层为了减少重复开发,沉淀可复用型指标;ADS面向应用提供数据)提高数据获取的效率:将海量数据的复杂关联查询结果提前计算好,提高计算效率。减少重复开发:规范数据分层,开发通用的中间层,可以极大地减少重复计算的工作。既然有好处,那肯定也会有坏处,鱼和熊掌不可兼得!
它需要更多的人力成本和时间成本来设计和实现。它对模型的维护提出了更高的要求。比如层级越多,溯源就越麻烦。数据的重复存储,数据需要在各个层级进行计算存储。三、我们怎么去更好的理解数仓分层?以卖早餐为例:
如果你在一个小巷子里,客户就是周边的邻居,你从选购食材,清洗食材,烹饪食材,然后摆出各种类型的早餐去售卖。
数据产品经理在这个过程中,就扮演着厨师的角色,如果我么要做一个韭菜盒子,就需要去了解哪些食材是我们需要的,“韭菜+粉丝+豆腐+面粉”对吧,韭菜别买成芹菜了,豆腐要买老豆腐,韭菜买回来得洗一下,粉丝得先泡一泡,豆腐要切成豆腐碎,还得和面。准备工作完成,就开始剁菜馅,切得碎碎,然后在包起来,下锅炸,最后摆盘售卖。
按部就班的将原材料加工成客户需求的产品。
【拓展思考】
分层也是一种分工协作,把一件复杂的事情模块化,简单化,提高可管理性,可维护性。
还是以卖早餐为例:
如果你是在陆家嘴地铁口售卖早餐,那么你最多就是卖包子,卖豆浆,其他环节可能都交给中央厨房去统一处理了。你只需要卖好包子就行。
本文由 @清小墨 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。