0、前言
初学数仓的同学都喜欢问一个很有意思的问题:数据仓库到底要分几层?我一般的回答都是:你想分几层就分几层。很显然, 虽然我是很认真的在回答,但是提问题的人会感觉非常不认真。还是完完整整的阐述一下数仓分层的基础逻辑吧。
一、分层的意义
想要知道数仓要分几层,那就必须得先回答另一个问题:就是数据仓库为什么要分层?分层思想到底是在干什么?
直接上结论:分层是为了解耦。请把这句话刻在脑子里。因为这决定了你的数据架构到底要分几层。
我们直接读取数据源出报表不行么?行!但是你的前台业务、中间的数据处理逻辑和后端的数据库会完全绑死,任何一个点发生变化,都得修改整个设计。
那按数据处理的逻辑,一个中间表拆一层行么?行啊。但是你这样链条太长,不仅流程管控难度提升,而且一旦发生问题,追溯几乎变得不可能。
所以,既不能不分,又不能分的太多。那应该怎么弄呢?
你看信息系统的架构发展历程,就是从单体-->水平分层/垂直拆分-->微服务-->服务网格,都是不停的拆,这是在干啥?就是在解耦,再解耦。但是也没有无限的往下拆,拆到服务网格,就开始合并了,这就是中台的逻辑。
数据架构上也是一样,有ODS层是为了保存原始数据,有明细层是为了保证后续数据的干净和统一,有汇总层是为了减少运算,有宽表层/维度建模层是为了使用方便,有DM层是为了某个领域使用方便。这也是不停的在解耦、再解耦。
所以要分几层,取决于公司是业务有多复杂,变化有多频繁,我们对应的就需要对业务和原始数据之间做多少层的解耦。
二、一般有哪些层
2.1 ODS
ODS(Operation Data Store)操作数据层,即原始数据层,又叫贴源层,与业务系统基本同构(可能会增加管理字段),目的是保留历史,解耦业务数据库,这样整个数据平台只需要访问一次业务数据库即可。
所以ODS层存在的意义是尽可能减少对业务数据库的访问压力。ODS层有些时候会细分为两层,一个STG数据缓冲层,存原始数据,一个ODS,存简单清洗的数据。
2.2 DWD
DWD(Data Warehouse Detail),明细数据层,对数据进行清洗、代码统一、字段统一、格式统一、简单聚合等工作。DWD层存在的意义是做数据的标准化,为后续的处理提供干净、统一、标准的数据。
2.3 DWB
DWB(Data Warehouse Base),基础数据层,又叫轻度汇总层,遵照维度模型的原理,将数据拆成维度和事实,进行维度、事实的统一。对数据进行轻度汇总,形成指标结果。
2.4 DWS
DWS(Data Warehouse Service),服务数据层,按照业务目标,对已经处理好的数据进行横向汇聚、纵向汇总。按照宽表模型进行数据冗余和预计算,以空间换时间。
2.5 宽表层
大数据环境下的DWS层。存储各种宽表。
2.6 DIM层
DIM层,即dimension,维度,即存储所有维度(可以理解为码表)。其实DIM不应该单独作为一层,因为从DWD层开始向上的所有层都需要用到DIM中的内容,所以他是横跨多层的。
2.7 标签层
标签工厂生产的各种标签,用户标签、商品标签等等,一般在DWD层之上,DWB层之下,互联网业务特有,现在也慢慢扩展到其他领域。
2.8 DM层
DM层,又叫主题层,与主题域不一样,这是在企业级数仓之上,对某个单独业务或者部门专门设立的小型数据集市。DM层又可以根据业务需求再次拆分。
三、应该如何设计数仓分层架构
3.1 时间紧任务重
还是回到最开始的那句话:看你的业务复杂度和实际情况。假如说,时间紧任务重,一周就要看结果,那就别说了,直接连业务数据库是最合适的。要啥分层?没那个时间。
3.2 业务简单+数据源少且简单
如果说公司业务简单,且相对比较固定,数据来源不多,结构也很清晰,需求也不多,可以ODS+DWD+DWS,三层足矣。
ODS起到解耦业务数据库+异构数据源的问题,DWD解决数据脏乱差的问题,DWS直接面向前台业务需求。够了。
3.3 业务一般复杂+公司战略变化不大
如果说公司业务一般复杂,每年都要跟着战略变,那就中规中矩的设计4层,多一层DWB层做汇总,多一层解耦,业务变化的时候,我们只改DWS层就好了,最多穿透到DWB层。每年按照战略调整一次,工作量也不会太大,最重要的是能保证底层结构的稳定和数据分析的可持续性。
3.4 业务多非常复杂
如果说公司业务非常复杂,业务线众多,那就在4层基础上加一层DM,每条业务线一个单独的DM。如果是集团型的,DM还可以设置在汇总层下面。放在那里,取决于组织结构。
3.5 业务变化频繁
如果说公司业务变化非常频繁,仨月变一次业务方向,后台数据每天都改数据库,说实话,没啥好办法。要么用人力堆,要么提取相对比较固定的内容去建设数仓,变化太快的直接做固定报表吧。前后都变,中间的没法干活,怎么解耦都没用。谁有好办法,可以告诉我,我去学习一下。
3.6 其他注意
- 至于DIM层,不管哪一种方式,都需要。
- 互联网模式加一层标签层。
- 大数据环境可以用宽表层替换DWS层(其实都一样)。
四、数仓分层示例参考
4.1 三层数仓架构(方案一):
3层数据仓库建设的架构一般指的是ODS、DW(数仓)、DM(数据集市),其中DW和DM又可以再拆成N层。不过我没有找到大厂的这种架构分享,大抵是因为这么各大厂不屑于画这么简单的分层架构图吧。
4.2 三层数仓架构(方案二):
另外一种3层数仓是ODS+DWD+DWS,这样就能满足解耦业务数据库、数据标准化+统一化和面向应用等基础功能。同样也没有找到大厂的3层分享案例。
4.3 美团大交通4层实时数仓架构
特意放上实时数仓的架构图,就是想说明一下无论是实时数仓还是离线数仓,架构都是一样的,该分几层分几层。只不过实时数仓用的是Kafka等MQ作为实时存储介质。
4.4 搜狐5层数据仓库架构
这是搜狐的5层数据仓库架构。之所以放搜狐的案例,是因为这里有一个STG层。这边把ODS细分为STG和ODS。STG是数据缓冲层,相当于贴源层,就是跟业务系统保持一致的结构,而这个架构中的ODS是经过简单清洗的明细数据。
4.5 美团酒旅6层数仓架构
这是美团酒旅业务的数仓架构,业务足够复杂,所以分成6层了。以第3代为例,ODS、数据整合层、多维明细层、汇总层、主题层、应用层。每一层的目的非常清晰。
-
ODS:汇聚原始数据;
-
数据整合层:对数据进行清洗、筛选、整合等操作;
-
多维明细层:进行维度建模;
-
汇总层:进行各级汇总;
-
主题层:按照业务领域,切分主题域,提供面向业务主题的数据集;
-
应用层:面向前端应用汇聚数据。
另外,美团的这张图,也体现了架构的另外一个重点:架构是需要不断的优化调整的,不能超前太多,也不能脱离业务。按照Inmon和Kimball吵了十几年的经验上看,建议架构设计时,按超越当前实际情况1~1.5年的设计是比较合适的。超越太长会导致建设期过长或者条件不成熟而失败,太短则修改太过频繁。
五、总结
数据仓库分层的核心逻辑是解耦。需要在有限时间、资源等条件下满足业务需求,同时又要兼顾业务的快速变化。所以我们作为数据架构师,需要兼顾业务的复杂变化,以及开发的复杂度和可维护性,在两者之间做一个平衡和取舍。
至于分几层,建议按照目前的业务和建设现状,进行合理解构和分层设计,一般刚开始做,建议3、4层。规划1-1.5年的架构,然后不断的建设、优化、再优化。不断逼近满足所有需求。
参考资料:微信公众号(大数据左右手)-《数仓到底要分多少层?一文告诉你》