数仓架构怎样比较合理（数仓到底要分多少层）

数仓架构怎样比较合理（数仓到底要分多少层）所以要分几层 取决于公司是业务有多复杂 变化有多频繁 我们对应的就需要对业务和原始数据之间做多少层的解耦。数据架构上也是一样 有ODS层是为了保存原始数据 有明细层是为了保证后续数据的干净和统一 有汇总层是为了减少运算 有宽表层/维度建模层是为了使用方便 有DM层是为了某个领域使用方便。这也是不停的在解耦、再解耦。那按数据处理的逻辑 一个中间表拆一层行么?行啊。但是你这样链条太长 不仅流程管控难度提升 而且一旦发生问题 追溯几乎变得不可能。所以 既不能不分 又不能分的太多。那应该怎么弄呢?你看信息系统的架构发展历程 就是从单体-->水平分层/垂直拆分-->微服务-->服务网格 都是不停的拆 这是在干啥?就是在解耦 再解耦。但是也没有无限的往下拆 拆到服务网格 就开始合并了 这就是中台的逻辑。

01 为什么要分层

想要知道数仓要分几层 那就必须得先回答另一个问题:就是数据仓库为什么要分层?分层思想到底是在干什么?

直接上结论:分层是为了解耦。请把这句话刻在脑子里。因为这决定了你的数据架构到底要分几层。

我们直接读取数据源出报表不行么?行!但是你的前台业务、中间的数据处理逻辑和后端的数据库会完全绑死 任何一个点发生变化 都得修改整个设计。

那按数据处理的逻辑 一个中间表拆一层行么?行啊。但是你这样链条太长 不仅流程管控难度提升 而且一旦发生问题 追溯几乎变得不可能。

所以 既不能不分 又不能分的太多。那应该怎么弄呢?

你看信息系统的架构发展历程 就是从单体-->水平分层/垂直拆分-->微服务-->服务网格 都是不停的拆 这是在干啥?就是在解耦 再解耦。但是也没有无限的往下拆 拆到服务网格 就开始合并了 这就是中台的逻辑。

数据架构上也是一样 有ODS层是为了保存原始数据 有明细层是为了保证后续数据的干净和统一 有汇总层是为了减少运算 有宽表层/维度建模层是为了使用方便 有DM层是为了某个领域使用方便。这也是不停的在解耦、再解耦。

所以要分几层 取决于公司是业务有多复杂 变化有多频繁 我们对应的就需要对业务和原始数据之间做多少层的解耦。

02 一般有哪些层

操作数据层(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层又可以根据业务需求再次拆分。

03 如何设计数仓分层架构

还是回到最开始的那句话:看你的业务复杂度和实际情况。假如说 时间紧任务重 一周就要看结果 那就别说了 直接连业务数据库是最合适的。要啥分层?没那个时间。

如果说公司业务简单 且相对比较固定 数据来源不多 结构也很清晰 需求也不多 可以ODS DWD DWS 三层足矣。ODS起到解耦业务数据库 异构数据源的问题 DWD解决数据脏乱差的问题 DWS直接面向前台业务需求。够了。

如果说公司业务一般复杂 每年都要跟着战略变 那就中规中矩的设计4层 多一层DWB层做汇总 多一层解耦 业务变化的时候 我们只改DWS层就好了 最多穿透到DWB层。每年按照战略调整一次 工作量也不会太大 最重要的是能保证底层结构的稳定和数据分析的可持续性。

如果说公司业务非常复杂 业务线众多 那就在4层基础上加一层DM 每条业务线一个单独的DM。如果是集团型的 DM还可以设置在汇总层下面。放在那里 取决于组织结构。

如果说公司业务变化非常频繁 仨月变一次业务方向 后台数据每天都改数据库 说实话 没啥好办法。要么用人力堆 要么提取相对比较固定的内容去建设数仓 变化太快的直接做固定报表吧。前后都变 中间的没法干活 怎么解耦都没用。谁有好办法 可以告诉我 我去学习一下。

至于DIM层 不管哪一种方式 都需要。

互联网模式加一层标签层。

大数据环境可以用宽表层替换DWS层(其实都一样)。

04 数仓分层示例参考

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、数据整合层、多维明细层、汇总层、主题层、应用层。每一层的目的非常清晰。

• ODS:汇聚原始数据;

• 数据整合层:对数据进行清洗、筛选、整合等操作;

• 多维明细层:进行维度建模;

• 汇总层:进行各级汇总;

• 主题层:按照业务领域 切分主题域 提供面向业务主题的数据集;

• 应用层:面向前端应用汇聚数据。

  
  

另外 美团的这张图 也体现了架构的另外一个重点:架构是需要不断的优化调整的 不能超前太多 也不能脱离业务。按照Inmon和Kimball吵了十几年的经验上看 建议架构设计时 按超越当前实际情况1~1.5年的设计是比较合适的。超越太长会导致建设期过长或者条件不成熟而失败 太短则修改太过频繁。

05

总结

数据仓库分层的核心逻辑是解耦。需要在有限时间、资源等条件下满足业务需求 同时又要兼顾业务的快速变化。所以作为数据架构师 需要兼顾业务的复杂变化 以及开发的复杂度和可维护性 在两者之间做一个平衡和取舍。

至于分几层 建议按照目前的业务和建设现状 进行合理解构和分层设计 一般刚开始做 建议3、4层。规划1-1.5年的架构 然后不断的建设、优化、再优化。不断逼近满足所有需求。

CIO之家 www.ciozj.com imciow