（三）数仓人必看！ODS 到 DWS 各层设计规范全解析，含同步/存储/质量核心要点

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

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

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

同步规范：

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

表分类与生命周期：

1. ods流水全量表：

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

2. ods镜像型全量表：

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

3. ods增量数据：

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

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

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

5. BDSync非去重数据：

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

数据质量：

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

1) 设计准则

1. 一致性
   共维度在不同的物理表中的字段名称、数据类型、数据内容必须保持一致（历史原因不一致，要做好版本控制）
2. 维度的组合与拆分

• 组合原则：
  

• 拆分与冗余：
  

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) 累积快照事实表

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

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

1) 聚集的基本原则

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

2) 聚集的基本步骤

第一步：确定聚集维度

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

第二步：确定一致性上钻

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

第三步：确定聚集事实

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

3) 公共汇总层设计原则

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

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

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

下文预告：数仓命名规范

用户案例

天翼云Zoom网易邮箱

每日互动 惠生工程 作业帮

博世智驾 蔚来汽车 长城汽车

集度长安汽车思科网讯

食行生鲜联通医疗联想

新网银行唯品富邦消费金融

自如有赞伊利当贝大数据

珍岛集团传智教育Bigo

YY直播 拈花云科太美医疗

Cisco Webex兴业证券

迁移实战

发版消息

加入社区

• GitHub: https://github.com/apache/dolphinscheduler
• 官网：https://dolphinscheduler.apache.org/en-us
• 订阅开发者邮件：dev@dolphinscheduler@apache.org（向邮箱发送任意内容，收到邮件后回复同意订阅即可）
• X.com：@DolphinSchedule
• YouTube：https://www.youtube.com/@apachedolphinscheduler
• Slack：https://join.slack.com/t/asf-dolphinscheduler/shared_invite/zt-1cmrxsio1-nJHxRJa44jfkrNL_Nsy9Qg

同样地，参与Apache DolphinScheduler 有非常多的参与贡献的方式，主要分为代码方式和非代码方式两种。

非代码方式包括：

完善文档、翻译文档；翻译技术性、实践性文章；投稿实践性、原理性文章；成为布道师；社区管理、答疑；会议分享；测试反馈；用户反馈等。

‍代码方式包括：

查找Bug；编写修复代码；开发新功能；提交代码贡献；参与代码审查等。

贡献第一个PR(文档、代码) 我们也希望是简单的，第一个PR用于熟悉提交的流程和社区协作以及感受社区的友好度。

社区汇总了以下适合新手的问题列表：https://github.com/apache/dolphinscheduler/pulls?q=is%3Apr+is%3Aopen+label%3A%22first+time+contributor%22

优先级问题列表：https://github.com/apache/dolphinscheduler/pulls?q=is%3Apr+is%3Aopen+label%3Apriority%3Ahigh

如何参与贡献链接：https://dolphinscheduler.apache.org/zh-cn/docs/3.2.2/%E8%B4%A1%E7%8C%AE%E6%8C%87%E5%8D%97_menu/%E5%A6%82%E4%BD%95%E5%8F%82%E4%B8%8E_menu

如果你❤️小海豚，就来为我点亮Star吧！

https://github.com/apache/dolphinscheduler

你的好友秀秀子拍了拍你

并请你帮她点一下“分享”