本文介绍了数仓的分层结构和分层的原因。通过分层，可以使数据处理更加规范、高效，提供可靠的数据支持。让我们一起学习一下~

一、数仓一般分哪些层？

操作数据层：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 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。