集团多事业部架构下数仓分层建模规范
✨博客主页 https://blog.csdn.net/m0_63815035?typeblog《博客内容》大数据、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 核心痛点实体孤岛各事业部编码体系独立仓库、物料等核心实体ID不互通跨事业部无法直接关联分析口径孤岛同名指标如营收、毛利、订单量各事业部计算逻辑差异大强行统一不符合业务实际放任不管则集团无法横向对比建模孤岛各事业部独立开发数仓分层规则不统一、重复建表、字段命名杂乱模型无法复用出口分散业务报表、后台系统直连底层明细数据私自加工计算持续产生新的逻辑孤岛1.3 设计原则公共统一私有隔离主数据、公共维度、基础规范全局统一事业部专属业务逻辑分层隔离分层解耦每层职责单一下层为上层提供标准化数据上层不得反向修改底层规则兼容差异不强行抹平事业部业务模式差异在统一框架内保留差异化空间治理内嵌建模规则与数据治理同步落地从生产环节避免逻辑孤岛二、整体分层架构自底向上共五层核心架构配套独立公共维度层ODS原始数据层→ DWD明细数据层→ DWS汇总数据层→ DM数据集市层→ ADS应用数据层配套DIM公共维度层全链路复用三、各层详细设计3.1 ODS 原始数据层Operational Data Store定位业务系统原始数据的原样镜像层保持与源系统结构完全一致不做任何业务加工。设计规则按「事业部业务系统」分表命名如ods_bu_a_order、ods_bu_b_erp_merchant字段、编码、枚举值完全保留源系统原貌不做转换、不做裁剪同步策略维度小表每日全量快照流水大表按增量/CDC同步保留完整历史数据为什么这么设计保留最原始的数据形态用于数据溯源、问题排查、口径核对不改造源系统结构最大程度适配各事业部系统差异作为数仓最底层为上层标准化加工提供完整的原始素材注意事项ODS层不对外开放业务查询仅数仓开发人员可访问必须保留历史快照禁止直接覆盖更新3.2 DWD 明细数据层Data Warehouse Detail定位经过清洗、标准化后的明细层是数仓统一标准的第一道关口承担「消除实体孤岛」的核心职责。设计规则强制统一项所有事业部必须遵守主数据编码统一关联全局主数据映射表将各事业部自有业务ID统一转换为全局唯一ID覆盖商户、商品、门店、组织四大核心实体基础字段规范统一日期分区字段dt、统一金额单位、统一时间戳字段命名、统一通用状态枚举值清洗规则统一去重逻辑、空值处理、异常数据过滤规则全局一致保留差异项各事业部独有的业务字段、单据类型、业务属性全部保留不做强制裁剪按事业部独立建表如dwd_bu_a_order_detail为什么这么设计主数据ID统一是解决逻辑孤岛的基础只有实体编码对齐跨事业部数据才能关联、对比、汇总只统一公共关联字段不干涉业务私有字段兼顾标准化与业务灵活性明细层打好统一基础上层所有汇总才能基于同一套维度体系注意事项主数据映射关系由主数据中心统一维护各事业部不得私自建立映射规则DWD层保留最细粒度明细不做任何聚合计算3.3 DIM 公共维度层定位全局唯一的公共维度主表层是所有分层共用的基础数据资产。设计规则全公司仅一套商户、商品、门店、组织、时间等公共维度全局唯一不允许各事业部重复建设每日全量原子刷新使用INSERT OVERWRITE机制更新保证维度数据一致性表内包含全局唯一ID、各业务系统编码映射、完整维度属性字段为什么这么设计统一维度是消除逻辑孤岛的核心基石所有事实表关联同一套维度才能保证跨业务、跨事业部分析的一致性集中维护维度避免各部门重复建设减少冗余与口径差异3.4 DWS 汇总数据层Data Warehouse Summary定位按业务主题域构建的汇总宽表层承载核心指标计算是数仓的核心资产层。核心问题各事业部口径完全不一样如何处理考虑1 客观业务规则差异不可强行统一不强行合并为一张全局DWS采用**「按事业部拆分DWS 公共维度统一复用」** 方案。原因不同事业部商业模式不同直营、加盟、渠道等核心经营指标的业务定义天然不同强行统一口径会导致指标失去业务意义。考虑2人为不规范差异治理可整改必须统一同一件指标只是各事业部开发随意写 SQL 导致口径五花八门有人排除测试单、有人不排除、时间范围筛选不同。这类属于逻辑孤岛根源通过数据治理强制收敛到统一标准。设计规则按事业部独立建表命名规范dws_{主题}_{粒度}_bu_{事业部标识}如dws_shop_day_bu_a各事业部DWS可使用自身业务口径计算营收、毛利等核心经营指标强制统一约束防止建模孤岛必须关联全局公共维度表DIM层禁止事业部自建维度映射逻辑汇总粒度统一统一支持日、月、季三级标准汇总粒度指标命名规范同名不同口径的指标必须加事业部标识禁止重名异义分区规则、分桶策略、存储格式全局统一指标分类管控集团通用指标商户数、门店数、订单量等强制统一口径可全局复用事业部专属指标营收、结算毛利等允许差异化但必须完整归档口径说明为什么这么设计尊重业务客观差异不做无意义的强行统一保证指标的业务价值维度统一保证了跨事业部数据可关联、可对比不会形成完全割裂的建模孤岛分表设计降低耦合各事业部可独立迭代互不影响注意事项禁止绕过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 如何从根源解决逻辑数据孤岛解决实体孤岛DWD层统一主数据编码 DIM层全局公共维度所有表共用一套ID体系跨事业部可自由关联解决口径孤岛通过指标平台统一归档所有指标口径区分通用指标与专属指标集团DM层对齐大盘口径支撑总部分析解决建模孤岛统一分层规范、命名规范、开发规范公共逻辑集中收敛避免重复建设防止产生新孤岛ADS层统一数据出口管控应用读取权限禁止业务私自导出数据二次加工4.2 为什么不强行统一所有DWS口径业务模式差异是客观存在的强行统一会导致指标失真失去业务指导意义合理方案是「底层维度统一上层指标分层」既保证数据可关联、可对比又尊重业务实际差异通过集团DM层做二次对齐满足总部大盘需求同时不干扰事业部日常经营分析五、落地管控规则权限管控ODS/DWD仅数仓开发可访问DWS/DIM开放给数据分析师ADS面向所有业务应用新增评审新增DWS表、核心指标必须经过数据治理评审避免重复建设血缘巡检定期巡检数据血缘排查绕过DWS直接计算指标、私建维度映射等违规行为口径文档所有指标必须附带完整口径说明纳入指标字典统一管理今天这篇文章就到这里了大厦之成非一木之材也大海之阔非一流之归也。感谢大家观看本文