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