集团多事业部架构下数仓分层建模规范

✨博客主页： https://blog.csdn.net/m0_63815035?type=blog

💗《博客内容》：大数据、AI开发、Java、测试开发、Python、Android、Go、Node、Android前端小程序等相关领域知识
📢博客专栏：https://blog.csdn.net/m0_63815035/category_11954877.html
📢欢迎点赞 👍 收藏 ⭐留言 📝
📢本文为学习笔记资料，如有侵权，请联系我删除，疏漏之处还请指正🙉
📢大厦之成，非一木之材也；大海之阔，非一流之归也✨


目录

    • 一、背景与核心问题
      • 1.1 背景
      • 1.2 核心痛点
      • 1.3 设计原则
    • 二、整体分层架构
    • 三、各层详细设计
      • 3.1 ODS 原始数据层（Operational Data Store）
        • 定位
        • 设计规则
        • 为什么这么设计
        • 注意事项
      • 3.2 DWD 明细数据层（Data Warehouse Detail）
        • 定位
        • 设计规则
          • 强制统一项（所有事业部必须遵守）
          • 保留差异项
        • 为什么这么设计
        • 注意事项
      • 3.3 DIM 公共维度层
        • 定位
        • 设计规则
        • 为什么这么设计
      • 3.4 DWS 汇总数据层（Data Warehouse Summary）
        • 定位
        • 核心问题：各事业部口径完全不一样，如何处理？
        • 考虑1： 客观业务规则差异（不可强行统一）
        • 考虑2：人为不规范差异（治理可整改，必须统一）
        • 设计规则
          • 按事业部独立建表
          • 强制统一约束（防止建模孤岛）
          • 指标分类管控
        • 为什么这么设计
        • 注意事项
      • 3.5 DM 数据集市层（Data Market）
        • 定位
        • 设计规则
          • 事业部DM
          • 集团全局DM
        • 为什么这么设计
      • 3.6 ADS 应用数据层（Application Data Service）
        • 定位
        • 设计规则
          • 事业部专属ADS
          • 集团全局ADS
        • 为什么这么设计
        • 红线规则
    • 四、关键问题解决方案回顾
      • 4.1 如何从根源解决逻辑数据孤岛？
      • 4.2 为什么不强行统一所有DWS口径？
    • 五、落地管控规则

一、背景与核心问题

1.1 背景

企业下辖多个独立业务事业部，各事业部拥有独立的业务系统（订单、ERP、财务、供应链等），数据分散存储在不同数据库中，天然形成物理数据孤岛。
建设统一数据仓库后，通过数据同步将所有业务数据归集到同一存储底座，解决了物理层面的数据分散问题。但仅做数据归集，无法消除语义、口径、建模层面的差异，逻辑数据孤岛依然存在。

1.2 核心痛点

  1. 实体孤岛：各事业部编码体系独立，仓库、物料等核心实体ID不互通，跨事业部无法直接关联分析
  2. 口径孤岛：同名指标（如营收、毛利、订单量）各事业部计算逻辑差异大；强行统一不符合业务实际，放任不管则集团无法横向对比
  3. 建模孤岛：各事业部独立开发数仓，分层规则不统一、重复建表、字段命名杂乱，模型无法复用
  4. 出口分散：业务报表、后台系统直连底层明细数据，私自加工计算，持续产生新的逻辑孤岛

1.3 设计原则

  • 公共统一，私有隔离：主数据、公共维度、基础规范全局统一；事业部专属业务逻辑分层隔离
  • 分层解耦：每层职责单一，下层为上层提供标准化数据，上层不得反向修改底层规则
  • 兼容差异：不强行抹平事业部业务模式差异，在统一框架内保留差异化空间
  • 治理内嵌：建模规则与数据治理同步落地，从生产环节避免逻辑孤岛

二、整体分层架构

自底向上共五层核心架构，配套独立公共维度层：

ODS（原始数据层）→ DWD（明细数据层）→ DWS（汇总数据层）→ DM（数据集市层）→ ADS（应用数据层）
配套：DIM（公共维度层，全链路复用）

三、各层详细设计

3.1 ODS 原始数据层（Operational Data Store）

定位

业务系统原始数据的原样镜像层，保持与源系统结构完全一致，不做任何业务加工。

设计规则
  1. 按「事业部+业务系统」分表命名，如ods_bu_a_order、ods_bu_b_erp_merchant
  2. 字段、编码、枚举值完全保留源系统原貌，不做转换、不做裁剪
  3. 同步策略：维度小表每日全量快照，流水大表按增量/CDC同步，保留完整历史数据
为什么这么设计
  • 保留最原始的数据形态，用于数据溯源、问题排查、口径核对
  • 不改造源系统结构，最大程度适配各事业部系统差异
  • 作为数仓最底层，为上层标准化加工提供完整的原始素材
注意事项
  • ODS层不对外开放业务查询，仅数仓开发人员可访问
  • 必须保留历史快照，禁止直接覆盖更新

3.2 DWD 明细数据层（Data Warehouse Detail）

定位

经过清洗、标准化后的明细层，是数仓统一标准的第一道关口，承担「消除实体孤岛」的核心职责。

设计规则
强制统一项（所有事业部必须遵守）
  1. 主数据编码统一：关联全局主数据映射表，将各事业部自有业务ID，统一转换为全局唯一ID（覆盖商户、商品、门店、组织四大核心实体）
  2. 基础字段规范：统一日期分区字段dt、统一金额单位、统一时间戳字段命名、统一通用状态枚举值
  3. 清洗规则统一：去重逻辑、空值处理、异常数据过滤规则全局一致
保留差异项
  • 各事业部独有的业务字段、单据类型、业务属性全部保留，不做强制裁剪
  • 按事业部独立建表，如dwd_bu_a_order_detail
为什么这么设计
  • 主数据ID统一是解决逻辑孤岛的基础：只有实体编码对齐，跨事业部数据才能关联、对比、汇总
  • 只统一公共关联字段，不干涉业务私有字段，兼顾标准化与业务灵活性
  • 明细层打好统一基础，上层所有汇总才能基于同一套维度体系
注意事项
  • 主数据映射关系由主数据中心统一维护，各事业部不得私自建立映射规则
  • DWD层保留最细粒度明细，不做任何聚合计算

3.3 DIM 公共维度层

定位

全局唯一的公共维度主表层，是所有分层共用的基础数据资产。

设计规则
  1. 全公司仅一套：商户、商品、门店、组织、时间等公共维度全局唯一，不允许各事业部重复建设
  2. 每日全量原子刷新：使用INSERT OVERWRITE机制更新，保证维度数据一致性
  3. 表内包含：全局唯一ID、各业务系统编码映射、完整维度属性字段
为什么这么设计
  • 统一维度是消除逻辑孤岛的核心基石：所有事实表关联同一套维度，才能保证跨业务、跨事业部分析的一致性
  • 集中维护维度，避免各部门重复建设，减少冗余与口径差异

3.4 DWS 汇总数据层（Data Warehouse Summary）

定位

按业务主题域构建的汇总宽表层，承载核心指标计算，是数仓的核心资产层。

核心问题：各事业部口径完全不一样，如何处理？
考虑1： 客观业务规则差异（不可强行统一）

不强行合并为一张全局DWS，采用**「按事业部拆分DWS + 公共维度统一复用」** 方案。

原因：不同事业部商业模式不同（直营、加盟、渠道等），核心经营指标的业务定义天然不同，强行统一口径会导致指标失去业务意义。

考虑2：人为不规范差异（治理可整改，必须统一）

同一件指标，只是各事业部开发随意写 SQL 导致口径五花八门：有人排除测试单、有人不排除、时间范围筛选不同。
这类属于逻辑孤岛根源，通过数据治理强制收敛到统一标准。

设计规则
按事业部独立建表
  • 命名规范：dws_{主题}_{粒度}_bu_{事业部标识}，如dws_shop_day_bu_a
  • 各事业部DWS可使用自身业务口径，计算营收、毛利等核心经营指标
强制统一约束（防止建模孤岛）
  1. 必须关联全局公共维度表（DIM层），禁止事业部自建维度映射逻辑
  2. 汇总粒度统一：统一支持日、月、季三级标准汇总粒度
  3. 指标命名规范：同名不同口径的指标必须加事业部标识，禁止重名异义
  4. 分区规则、分桶策略、存储格式全局统一
指标分类管控
  • 集团通用指标（商户数、门店数、订单量等）：强制统一口径，可全局复用
  • 事业部专属指标（营收、结算毛利等）：允许差异化，但必须完整归档口径说明
为什么这么设计
  • 尊重业务客观差异，不做无意义的强行统一，保证指标的业务价值
  • 维度统一保证了跨事业部数据可关联、可对比，不会形成完全割裂的建模孤岛
  • 分表设计降低耦合，各事业部可独立迭代，互不影响
注意事项
  • 禁止绕过DWS，直接从DWD明细层计算汇总指标
  • 所有DWS指标必须录入指标平台，标注口径定义与归属事业部

3.5 DM 数据集市层（Data Market）

定位

面向特定分析主题的整合层，分为「事业部私有集市」和「集团全局集市」两类，承接差异化需求与集团大盘需求。

设计规则
事业部DM
  • 数据源：本事业部DWS宽表
  • 用途：叠加事业部私有业务标签、细分场景聚合、部门专属分析加工
  • 规则：仅做二次筛选、轻量聚合，不重新计算核心经营指标
集团全局DM
  • 数据源：各事业部DWS数据合并
  • 用途：按集团统一统计规则，对各事业部差异化指标做对齐、折算、汇总，生成集团统一视图
  • 规则：专门负责口径对齐、跨事业部合并、大盘级汇总
为什么这么设计
  • 隔离事业部私有逻辑与集团公共逻辑，避免互相干扰
  • 集团DM专门解决「各事业部口径不一，总部无法看整体大盘」的问题，作为口径对齐的中间层
  • 分层处理，避免DWS层职责过重、模型臃肿

3.6 ADS 应用数据层（Application Data Service）

定位

直接面向前端应用的结果层，为报表、看板、数据API提供成品数据，是数仓对外的统一出口。

设计规则
事业部专属ADS
  • 数据源：事业部DM / 事业部DWS
  • 适用场景：事业部内部运营报表、门店后台、部门个性化看板
  • 规则：完全沿用事业部口径，仅做字段裁剪、预聚合、格式适配，不修改核心指标口径
集团全局ADS
  • 数据源：集团全局DM
  • 适用场景：集团经营大屏、高管看板、跨事业部对比报表
  • 规则：输出集团对齐后的统一标准指标
为什么这么设计
  • 贴近应用需求做预聚合，大幅提升查询性能，适配OLAP引擎（如StarRocks）
  • 收口数据出口，所有业务应用统一读取ADS，避免直连底层造成口径混乱
  • 分层隔离，前端应用需求变更不会影响底层核心模型
红线规则
  • 禁止ADS直接读取DWD及以下层级
  • 禁止在ADS层重新定义核心指标口径
  • 禁止在ADS层做主数据编码转换

四、关键问题解决方案回顾

4.1 如何从根源解决逻辑数据孤岛？

  1. 解决实体孤岛：DWD层统一主数据编码 + DIM层全局公共维度，所有表共用一套ID体系，跨事业部可自由关联
  2. 解决口径孤岛：通过指标平台统一归档所有指标口径，区分通用指标与专属指标；集团DM层对齐大盘口径，支撑总部分析
  3. 解决建模孤岛：统一分层规范、命名规范、开发规范，公共逻辑集中收敛，避免重复建设
  4. 防止产生新孤岛：ADS层统一数据出口，管控应用读取权限，禁止业务私自导出数据二次加工

4.2 为什么不强行统一所有DWS口径？

  • 业务模式差异是客观存在的，强行统一会导致指标失真，失去业务指导意义
  • 合理方案是「底层维度统一，上层指标分层」，既保证数据可关联、可对比，又尊重业务实际差异
  • 通过集团DM层做二次对齐，满足总部大盘需求，同时不干扰事业部日常经营分析

五、落地管控规则

  1. 权限管控：ODS/DWD仅数仓开发可访问；DWS/DIM开放给数据分析师；ADS面向所有业务应用
  2. 新增评审：新增DWS表、核心指标必须经过数据治理评审，避免重复建设
  3. 血缘巡检：定期巡检数据血缘，排查绕过DWS直接计算指标、私建维度映射等违规行为
  4. 口径文档：所有指标必须附带完整口径说明，纳入指标字典统一管理
今天这篇文章就到这里了，大厦之成，非一木之材也；大海之阔，非一流之归也。感谢大家观看本文