当前位置: 首页 > news >正文

(三)数仓人必看!ODS 到 DWS 各层设计规范全解析,含同步/存储/质量核心要点

《新兴数据湖仓设计与实践手册·数据湖仓建模及模型命名规范(2025年)》 由四篇递进式指南组成,以“模型架构—公共规范—分层规范—命名规范”为主线,系统构建可演进、可治理、可共享的现代数据湖仓。

本文为系列文章第三篇,详细剖析了数仓各层的设计规范,包含同步、存储、质量等核心要点。

最后一篇将在此框架内,依次剖析数仓各层的命名规范,帮助企业用一套方法论完成从数据入湖到价值变现的全链路建设,敬请期待完整版。

1. ODS层设计规范

同步规范:

  1. 一个系统源表只允许同步一次;
  2. 全量初始化同步和增量同步处理逻辑要清晰;
  3. 以统计日期和时间进行分区存储;
  4. 目标表字段在源表不存在时要自动填充处理。

表分类与生命周期:

1. ods流水全量表:

  • 不可再生的永久保存;
  • 日志可按留存要求;
  • 按需设置保留特殊日期数据;
  • 按需设置保留特殊月份数据;

2. ods镜像型全量表:

  • 推荐按天存储;
  • 对历史变化进行保留;
  • 最新数据仓储在最大分区;
  • 历史数据按需保留;

3. ods增量数据:

  • 推荐按天存储;
  • 有对应全量表的,建议只保留14天数据;
  • 无对应全量表的,永久保留;

4. ods的etl过程中的临时表:

  • 推荐按需保留;
  • 最多保留7天;
  • 建议用完即删,下次使用再生成;

5. BDSync非去重数据:

通过中间层保留,默认用完即删,不建议保留。

数据质量:

  1. 全量表必须配置唯一性字段标识;
  2. 对分区空数据进行监控;
  3. 对枚举类型字段,进行枚举值变化和分布监控;
  4. ods表数据量级和记录数做环比监控;
  5. ods全表都必须要有注释;

2. 公共维度层设计规范

1) 设计准则

  1. 一致性
    共维度在不同的物理表中的字段名称、数据类型、数据内容必须保持一致(历史原因不一致,要做好版本控制)
  2. 维度的组合与拆分
  • 组合原则
    将维度与关联性强的字段进行组合,一起查询,一起展示,两个维度必须具有天然的关系,如:商品的基本属性和所属品牌。
    无相关性:如一些使用频率较小的杂项维度,可以构建一个集合杂项维度的特殊属性。
    行为维度:经过计算的度量,但下游当维度处理,例:点击量 0-1000,100-1000等,可以做聚合分类。
  • 拆分与冗余
    针对重要性,业务相关性、源、使用频率等可分为核心表、扩展表。
    数据记录较大的维度,可以适当冗余一些子集。

2) 存储及生命周期管理

建议按天分区。

  1. 3个月内最大访问跨度<=4天时,建议保留最近7天分区;
  2. 3个月内最大访问跨度<=12天时,建议保留最近15天分区;
  3. 3个月内最大访问跨度<=30天时,建议保留最近33天分区;
  4. 3个月内最大访问跨度<=90天时,建议保留最近120天分区;
  5. 3个月内最大访问跨度<=180天时,建议保留最近240天分区;
  6. 3个月内最大访问跨度<=300天时,建议保留最近400天分区;

3. DWD明细层设计规范

1) 存储及生命周期管理

建议按天分区。

  1. 3个月内最大访问跨度<=4天时,建议保留最近7天分区;
  2. 3个月内最大访问跨度<=12天时,建议保留最近15天分区;
  3. 3个月内最大访问跨度<=30天时,建议保留最近33天分区;
  4. 3个月内最大访问跨度<=90天时,建议保留最近120天分区;
  5. 3个月内最大访问跨度<=180天时,建议保留最近240天分区;
  6. 3个月内最大访问跨度<=300天时,建议保留最近400天分区;

2) 事务型事实表设计准则

  • 基于数据应用需求的分析设计事务型事实表,结合下游较大的针对某个业务过程和分析指标需求,可考虑基于某个事件过程构建事务型实时表;
  • 一般选用事件的发生日期或时间作为分区字段,便于扫描和裁剪;
  • 冗余子集原则,有利于降低后续IO开销;
  • 明细层事实表维度退化,减少后续使用join成本。

3) 周期快照事实表

  • 周期快照事实表中的每行汇总了发生在某一标准周期,如某一天、某周、某月的多个度量事件。
  • 粒度是周期性的,不是个体的事务。
  • 通常包含许多事实,因为任何与事实表粒度一致的度量事件都是被允许的。

4) 累积快照事实表

  • 多个业务过程联合分析而构建的事实表,如采购单的流转环节。
  • 用于分析事件时间和时间之间的间隔周期。
  • 少量的且当前事务型不支持的,如关闭、发货等相关的统计。

4. DWS公共汇总层设计规范

数据仓库的性能是数据仓库建设是否成功的重要标准之一。聚集主要是通过汇总明细粒度数据 来获得改进查询性能的效果。通过访问聚集数据,可以减少数据库在响应查询时必须执行的工作量,能够快速响应用户的查询,同时有利于减少不同用访问明细数据带来的结果不一致问题。

1) 聚集的基本原则

  • 一致性。聚集表必须提供与查询明细粒度数据一致的查询结果。
  • 避免单一表设计。不要在同一个表中存储不同层次的聚集数据。
  • 聚集粒度可不同。聚集并不需要保持与原始明细粒度数据一样的粒度,聚集只关心所需要查询的维度。

2) 聚集的基本步骤

第一步:确定聚集维度

在原始明细模型中会存在多个描述事实的维度,如日期、商品类别、卖家等,这时候需要确定根据什么维度聚集,如果只关心商品的交易额情况,那么就可以根据商品维度聚集数据。

第二步:确定一致性上钻

这时候要关心是按月汇总还是按天汇总,是按照商品汇总还是按照类目汇总,如果按照类目汇总,还需要关心是按照大类汇总还是小类汇总。当然,我们要做的只是了解用户需要什么,然后按照他们想要的进行聚集。

第三步:确定聚集事实

在原始明细模型中可能会有多个事实的度量,比如在交易中有交易额、交易数量等,这时候要明确是按照交易额汇总还是按照成交数量汇总。

3) 公共汇总层设计原则

除了聚集基本的原则外,公共汇总层还必须遵循以下原则:

  • 数据公用性。汇总的聚集会有第三者使用吗?基于某个维度的聚集是不是经常用于数据分析中?如果答案是肯定的,那么就有必要把明细数据经过汇总沉淀到聚集表中。
  • 不跨数据域。数据域是在较高层次上对数据进行分类聚集的抽象。如以业务
  • 区分统计周期。在表的命名上要能说明数据的统计周期,如 _Id表示最近1天,_td 表示截至当天,_nd 表示最近N天。

🫱 前文回顾:
(一)数据模型架构原则:四层七阶,数据湖仓建模的“第一块基石”
(二)一文读懂数仓设计的核心规范:从层次、类型到生命周期

🫱 下文预告:数仓命名规范

http://www.hskmm.com/?act=detail&tid=17104

相关文章:

  • 【shell】系统资源不足fork: retry: Resource temporarily unavailable
  • 【语文训练】女乃龙?田力乃龙?
  • 抖动分为3个方面
  • 第20章 Day24 原型链
  • python自动化操作邮件
  • zabbix配置mysql监控
  • redis实现定期关单
  • 第18章 Day22 高阶混淆ast进阶
  • 关于ubuntu 用户切换的细节 su - user 和su user
  • 用 SeaTunnel 同步 MySQL 到 Doris:全量增量 + SQL 过滤
  • 在CodeBolcks下wxSmith的C++编程教程——使用自定义绘制和鼠标处理创建项目
  • trae 配置mysql_mcp
  • Apache NiFi 1.28.1 集群 + Kerberos 认证 + 多租户模式部署
  • 基于Java+SpringBoot+SSM,Flask福聚苑社区团购体系(源码+LW+调试文档+讲解等)/福聚苑社区/团购系统/社区团购/福聚苑/团购/社区/环境/福聚苑小区/在线团购/社区购物
  • 按需引入echarts
  • 软件构造的用户交互设计 4章
  • 自定义制作docker容器自动自愈容器镜像
  • 如何利用海外 NetNut 网络代理与 AICoding 实战获取 iPhone 17 新品用户评论数据?
  • 第一次编码器测试
  • 04-FreeRTOS的概述及编程规范
  • 10_ select/poll/epoll实现服务端的io多路复用
  • 模拟实战配置实验
  • 国标GB28181公网直播EasyGBS如何构建全域覆盖的应急管理与安全生产解决方案?
  • Serilog.AspNetCore与Serilog的区别
  • 基于MATLAB S函数实现多智能体间歇通信仿真
  • 我天,前端岗要消亡了吗?
  • 闲话
  • java8的集合新API - --
  • 基于MATLAB/Simulink的500kW三相光伏逆变器仿真
  • Docker Compose启动多个镜像实例