简介《中国电信企业数据模型3.0》是中国电信CTG-MBOSS中EDA分总体规范的一个分册面向电信数据架构、数据治理及BSS系统设计与开发人员目标是统一企业数据标准提升数据的一致性、准确性和可用性。压缩包内为1个doc格式文件大小4.45MB已有299人浏览学习。文档从编制说明与概述入手系统讲解概念数据模型、逻辑数据模型、物理数据模型的分层设计并围绕参与人、产品、帐务、市场营销、事件和地域六大主题域展开重点描述BSS部分的数据模型修订涵盖主题域LEVEL0/LEVEL1/LEVEL2逐级分解以及建模原则、维护原则。适合需要落地EDM/EDW/ODS数据架构、开展数据标准化治理或进行系统改造的实践者作为案头参考。1. 从「各说各话」到「一张数据地图」企业数据模型3.0在解决什么做数据的人最怕的一件事就是同一个「用户」在计费系统里叫「客户标识」在客服系统里叫「用户号码」在经营分析系统里又叫「主叫号码」。跨域取数的时候数仓团队要拿着口径清单逐个跟业务确认一确认就是两三天等数据拿到手业务已经改需求了。某个大型电信运营商内部分析师有个说法数据团队一半的时间不是在做分析是在跟上游对口径。这种事经历几次你就明白企业级数据模型不是一个文档而是数据资产的「宪法」——它定义的是全公司统一怎么说数据而不是某个系统自己怎么存数据。中国电信企业数据模型3.0正是围绕这个矛盾展开的它是一套覆盖客户、产品、订单、账务、资源、服务等核心主题域的企业级数据模型规范目标是把散落在各业务系统中的数据按照一套统一的实体、属性、关系重新组织起来让数据在跨系统、跨域流转时口径一致、能对得上。这套模型适合正在做数据仓库、数据中台或集团级数据汇聚的人尤其是那些每天被跨域取数、口径核对、模型评审折磨的开发者。它不解决具体某个报表怎么写它解决的是报表背后的数据从哪来、怎么定义、跟谁关联。2. 模型3.0的核心架构从概念到物理的三层拆解2.1 概念模型层主题域划分与业务对象边界先看概念层它是整个模型的「目录骨架」。3.0将企业核心业务抽象为若干主题域常见划分包括客户域、产品域、订单域、账务域、服务域、资源域、渠道域等。每个主题域对应一组高内聚的业务对象例如客户域包含客户、客户账户、客户联系人产品域包含产品、产品套餐、产品资费。做主题域切分时最关键的判断标准不是系统边界而是业务对象的生命周期和归属关系。比如「客户」和「用户」在很多老系统里是混着用的一个自然人在前台办了宽带是「客户」后台分配了一个宽带账号是「用户」。概念模型里这两个必须分开因为客户是签约主体用户是产品事实上的使用者二者的变更频率、数据量级、隐私等级完全不同。这个区分直接影响后续逻辑模型里的主键设计和数据分布策略。概念模型层的产物是一张业务对象全景图和一个术语表。团队在做数据资产盘点时第一步要做的就是拿这套术语表去对现状系统的字段名凡是出现「同义不同名」或「同名不同义」的字段全部登记为待治理项。这个过程不建议手动过最好用元数据工具把各系统表结构批量拉出来做字段级比对靠人工逐张表看会漏掉大量隐蔽的不一致。2.2 逻辑模型层实体、属性与关系的标准化逻辑模型层是把概念模型翻译成可落地的结构定义核心产出是实体清单、每个实体的属性集、实体间的关系1:1、1:N、M:N以及外键约束。3.0在这里做了件比较重要的调整强调属性定义必须「就高不就低」即同一个业务属性在集团层面只保留一个权威定义省分或专业公司在本地扩展时不允许另起一套。举个例子「客户星级」这个属性在渠道域里可能是1到5的整数在客服域里是字符串「钻石/金/银」在营销域里又变成了区间段。逻辑模型层会统一定义为标准枚举值并提供映射规则各地系统可以保留自己的存储形式但对外提供数据时必须转换为标准编码。这个约束带来的直接好处是跨域Join时不再需要写一堆 CASE WHEN 做枚举转换。逻辑模型层另一个容易忽略的细节是关系字段的命名规范。很多系统习惯用「创建人」「创建时间」这类审计字段放在每个表里逻辑模型会统一为「创建人ID」「创建时间戳精确到毫秒」并在关系定义中明确哪些字段可以被多个实体共享哪些只能在所属实体中存在。这个看似细碎的约定在实际做数据血缘分析时能省下大量排查时间。2.3 物理模型层从逻辑到库表的落地策略物理层是把逻辑模型映射为具体的表结构、索引、分区方式和存储策略。3.0在物理层的落地并不强制一张逻辑实体对应一张物理表而是允许按数据规模、访问频率做分表或合并。常见做法是高变更频率、高并发写入的实体比如订单、话单按时间分区相对稳定的字典类实体比如地区编码、产品目录做成维表存放在通用的维度库中。这里有一个实践中的选型取舍物理表命名是否要跟逻辑实体名保持一致。我见过不少团队在物理层重新发明了一套简洁表名理由是原逻辑名太长或太啰嗦结果后续做数据血缘和元数据追踪时处处碰壁反向追溯成本极高。建议物理表名保留逻辑实体名的关键语义只在后缀上区分分层ODS、DWD、DWS例如客户主题对应的明细表命名用 dwd_cust_customer_info_di 这类风格看到名字就能猜到它来自哪个实体。物理模型落地时还要考虑编码问题。电信领域大量使用组合编码比如地区编码、网元编码、套餐编码这些编码在逻辑模型里有标准定义但老旧系统实际存储的可能是不定长的前缀码。物理层建议统一按标准编码建列同时保留一个「原始编码」列便于溯源不要直接覆盖源头系统的值否则数据审计时会有麻烦。3. 从2.0到3.0这次升级到底改了什么3.1 架构思路的转变从面向系统到面向业务2.0时代的数据模型常见问题是跟着系统走的计费系统有自己的一套表结构客户关系管理系统有自己的一套实体模型只是把各系统的表收集起来做了一个「大杂烩视图」。3.0的核心转变是倒过来先抽象业务对象和业务过程再反向要求各系统对齐到模型定义的实体和关系上。这个转变带来一个实质性影响数据模型的维护者从「各系统DBA的汇总人」变成了「业务数据标准的制定者」。在具体落地时项目组需要先做一遍业务调研梳理出企业级的核心业务对象清单再跟各系统的现状模型做差距分析。这个过程是3.0实施中工作量最大的部分也是后面所有工作的地基。做差距分析时有一个经验值得参考不要一上来就追求所有系统完全对齐先把各系统里数据量最大、跨域共享需求最频繁的TOP 20实体拿出来对齐其余实体可以分批次推进。大部分跨域取数的需求都集中在这20个实体上先把这些理顺业务方的体感会非常明显。3.2 数据标准的强化命名、类型、编码与口径3.0在数据标准方面的要求比之前明显加强覆盖了字段命名、数据类型、编码规则、默认值、必填性、口径描述六个维度。其中最容易被低估的是「字段命名」和「口径描述」两类标准。字段命名标准的难点不在定规则而在历史系统的存量治理。比如某计费系统的账期字段叫 BILL_CYCLE某渠道系统的月份字段叫 MONTH_ID在3.0标准下统一叫 BILLING_CYCLE_ID如果要改物理表字段名风险很大。常见做法是逻辑模型和共享层DWD/DWS严格用标准字段名源系统贴源层ODS保留原始字段名在ETL映射时完成转换。这样既不影响源系统运行又能让上层应用面对统一的标准字段。口径描述是另一个容易被忽略但影响面极大的点。同一个「收入」是含税还是不含税是应收还是实收统计范围是集团内还是含合营公司如果没有在标准里明确写清楚下游数据分析师就会各猜各的。3.0的标准设计中每个关键指标都有完整的业务口径描述包括统计范围、剔除规则、时间口径、币种、税率说明这个描述不是写给人看的而是作为元数据的一部分结构化存储方便后续做指标管理和数据服务时自动带出。3.3 引入数据资产目录从模型到可检索、可消费3.0比较实用的一处演进是引入了数据资产目录机制把模型实体、表、字段、指标、标签关联起来形成一套可检索的资产地图。过去模型文档躺在某个共享网盘里一年都没人下载一次现在资产目录把模型的每一个实体关联到对应的物理表、加工任务、下游报表和数据责任人。实际落地资产目录时建议不要一上来就追求全自动。先做最小可用版本以逻辑模型的实体清单为骨架把核心物理表和加工任务手工关联上去数据责任人落实到具体的人。这个最小目录能跑通之后再考虑用元数据采集工具做自动补全。直接上自动化工具的后果通常是自动采集出一堆没人维护的orphan元数据资产目录反而变成一个新的数据沼泽。资产目录还有一个实际价值新人培训。过去新同事入职后了解数据只能靠老员工口口相传有了资产目录可以直接从模型实体出发沿着血缘链路看数据流向。这个收益平时不明显但每当有人离职或转岗它的价值就会凸显出来。4. 落地实施从模型文件到生产环境的完整路径4.1 第一步模型解读与本地化映射别急着建表拿到3.0模型文档后第一件事不是建表而是做本地化差异分析。标准模型是全集团通用的一套理想框架但本地系统往往存在历史遗留字段、区域特色业务和外部接口带来的非标数据。直接照搬建表后续数据灌不进去或者语义对不上时再返工代价远高于前期仔细比对。我建议的起步方式是先把本地所有系统的表清单汇总按主题域归类然后逐表和模型实体做映射输出一张「现状表 ↔ 模型实体 ↔ 差异说明」的三列清单。差异说明里写清楚是字段缺失、字段冗余、名称不一致还是类型不一致。这一步可以借助元数据管理工具做辅助但核心的判断还是要靠熟悉业务的人来完成。差异分析完成之后把差异项分成两类「必须治理」和「允许挂起」。必须治理的是指那些直接阻塞跨域数据共享的差异比如主键不一致、核心业务对象缺失允许挂起的则包括一些不影响主流数据流通的冗余字段、历史遗留编码。分类时不要贪多治理范围控制得越小落地成功率越高。4.2 第二步按主题域分批贯标合理设定优先级贯标顺序的决策不能按技术难度来要按业务收益来。推荐的做法是优先贯标「客户域 产品域 订单域」因为这个组合覆盖了绝大多数跨域分析场景比如分析某个套餐产品有多少客户客户在使用、使用后订单变更趋势如何。把这几个域跑通业务方就能在数据服务上直观感受到变化后续推动其他域的时候阻力会小很多。每一个主题域的贯标过程建议分四个动作字段映射、转换逻辑开发、数据校验、发布上线。字段映射就是把源系统字段与模型标准字段一一对应转换逻辑负责把非标格式翻译为标准格式数据校验是跑数据质量规则确认无重大偏差最后才是正式上线。整个流程以一个主题域为单位独立推进避免多个域同时改造导致问题难以定位。数据校验这一步尤其不能省。常见做法是选择最近三个月的实际数据跑一批对照测试用标准模型加工出的结果跟老口径加工出的结果对比差异率超过阈值就要回头查转换逻辑。阈值建议设在万分之五以下超过这个比例说明有系统性偏差不是零星脏数据。这个步骤做完才能对下游使用者承诺数据质量。4.3 第三步模型管控与持续演进防止模型烂尾模型3.0不是一次性项目它需要长期维护否则半年之后模型文档和数据现状又会脱节。管控机制里最核心的一条是所有新建数据表、新增字段、修改口径都必须先过模型评审。具体操作上数仓团队可以设置一个「数据模型变更申请」流程任何新增或变更都要提交影响分析关联到对应模型实体和资产目录条目评审通过后才能动工。这个流程看起来增加了开发负担但它防止的是更贵的返工。实践中最常见的反例是开发图省事在已有的宽表里随手加了一个字段没有登记到模型里。一次两次没问题积累到几十次之后模型文档和数据现状完全对不上资产目录失去可信度大家又重新回到靠口头问数据从哪来的老路上。持续演进还要求设定周期性审视机制。建议每季度做一次模型与现状的差异扫描重点看有没有新出现的表没有被模型覆盖、有没有字段赋值逻辑发生了隐性变更。把这些变化纳入下一版本的模型修订计划模型才能保持活的状态而不是变成一份「象征性文档」。4.4 关键角色与协作流程谁来保证模型落地模型3.0落地过程中最棘手的往往不是技术而是组织协作。数据模型不是数仓团队自己关起门来就能定的它需要业务专家提供术语解释、系统负责人提供现状表结构、数据质量团队参与规则确认、应用开发团队反馈消费需求。如果只有数仓团队自己跑做出来的模型没有人认落地必然受阻。建议的协作组织是每个主题域设一个模型Owner由熟悉该域业务和数据的人担任负责该域的实体定义、争议裁决和演进方向数仓团队负责模型的技术实现和标准执行业务分析师作为最终用户参与需求反馈。三个角色缺一不可。模型Owner的授权要落实到具体事项上比如有权确认某个字段的标准定义、有权要求下游系统按标准接入数据而不是一个挂名角色。协作流程上要注意一个容易被忽略的点模型评审会议不能只拉技术人。新增一个实体或修改一个属性如果业务口径的变更没让业务方确认评审通过了也是埋雷。实际操作中我会在评审会之前先把需要业务确认的口径项列成清单请业务方提前书面确认评审会上只处理有分歧的问题这样可以大幅压缩评审时长。5. 避坑指南模型3.0落地最常见的5个翻车点5.1 把逻辑模型直接当成建表脚本去建库现象团队拿到3.0逻辑模型文档后按实体定义直接生成建表语句一口气建了上百张表然后发现数据根本灌不进去部分表存在大量空列部分表的数据量和预期完全不符。原因逻辑模型描述的是业务结构不含物理存储设计。它不区分这个实体在源系统是一张真实表还是一个视图也不考虑数据量级、更新频率和访问模式直接落库自然水土不服。解决在物理设计阶段必须针对每个实体单独做评估。高并发大表做分区和归档策略低频字典表做维表处理跨域共享数据做统一的编码和主键设计。建议先拿三到五个核心实体做物理建模试点验证通了再批量铺开。5.2 试图把所有老系统一次性改造齐现象某项目组立了一个大目标要把所有存量系统半年内全部对齐3.0模型。推进到第三个月进度不到三分之一各系统负责人开始消极回应有的不再参加评审会议。原因存量系统改造牵涉的不仅是数据层还有上游接口、应用逻辑、报表配置影响面太大。一次性全量改造的组织阻力大到基本不可能成功。解决按第4章的方式分主题域分批推进。先从客户、产品、订单三个高价值域开始老系统里非核心的业务保持现状通过数仓的转换层完成适配。核心原则是「先让数据流通起来再逐步收缩非标面积」。5.3 维表与事实表的主数据拆分没做好查询失控现象贯标完成后业务人员反馈「查一个客户的信息要关联七八张表根本跑不动」「同一个客户在宽表里出现两条记录到底信哪个」。原因逻辑模型严格按范式拆分了实体物理层没有做合理的汇总和宽表设计。分析师面对上百张规范化表既难写查询性能也扛不住。解决在逻辑模型之上面向典型分析场景设计一套汇总层宽表。比如客户主题的宽表把客户基本信息、账户信息、主要产品订阅信息、最近一次订单时间等高频查询字段合并到一张宽表。宽表字段来源于标准模型但物理形态经过合并优化两者不矛盾。5.4 编码与历史数据不兼容上线后才发现对不上现象某省将本地套餐编码映射到标准编码后上线次日发现大量历史订单的套餐字段变成了空值或未知原因是映射规则漏了一类老套餐编码。原因映射规则评审时只覆盖了当前在用套餐历史套餐编码被遗漏。源系统里这类编码实际占订单表的比例约8%不算低。解决映射规则开发完成后必须用至少一年的历史数据做回刷验证专门查「标准编码为NULL或UNKNOWN」的记录比例阈值高于0.5%就要回头补映射。上线前再做一轮全量编码覆盖率统计确保覆盖所有存在的编码值。5.5 模型评审流于形式业务方不参与现象项目组坚持每周开模型评审会但业务方经常缺席或者派人来但不懂数据只会点头。会后的模型定义我行我素数据服务上线后业务方不认账。原因模型评审被定义成了技术会议业务方参与感低不知道这些实体定义和口径会直接影响他们的分析结果。解决把评审会的重心从「表结构评审」转向「业务口径评审」。每次会议前置发布「业务口径确认清单」里面用业务语言描述什么是客户、什么是有效订单、收入的口径是什么。让业务负责人逐条确认或提出修改。业务方确认过的口径记录在案后续有分歧时有据可查。6. 进阶技巧用模型3.0反推数据质量与血缘自动化的实战手法模型3.0落地稳定之后它的价值远不止「能对上口径」这么简单。一套完整的实体关系网络天然可以作为数据质量规则和数据血缘的基准。这里分享两个我自己用着顺手的进阶手法。第一个是用逻辑模型自动生成数据质量规则清单。模型里定义了每个属性的数据类型、长度、是否必填、枚举值域、主外键关系这些约束可以直接翻译成质量规则。比如客户域的「客户名称」属性定义了必填且长度不超过128字符对应的质量规则就是「该字段NULL率必须为0超长字段数量为0」。我见过一个做法是把模型的Excel导入质量平台脚本自动为每个实体生成一套基础质量规则覆盖率能达到手工编写的大概七成剩余三成需要人工补充业务级规则比如「同一客户ID不能同时存在两个不同的星级」。这个方法能快速建立质量基线后续再逐步细化。第二个是用模型实体关系辅助构建数据血缘。传统血缘靠解析SQL来追踪有很多局限存储过程里动态SQL解析不了、跨系统数据同步的链路靠SQL根本看不全。如果以模型为骨架先把「实体 → 物理表 → 加工任务 → 下游应用」这条链路的拓扑搭出来再把SQL解析出来的表级血缘挂载到这个骨架上血缘关系会清晰很多。具体做法是在资产目录里以逻辑实体为单位画一条主链路比如「客户实体 → 客户ODS贴源表 → 客户DWD明细表 → 客户DWS汇总表 → 客户标签服务」然后让每个节点的具体加工SQL血缘作为辅助信息挂在这个节点下面。这样数据问题的排查路径会非常直观某个报表数据不对先看它挂在哪个实体链路上顺着链路逐级检查而不是在一堆SQL里人肉找。这两个手法的共同思路是不要等出了问题再靠人肉排查而是把模型作为基础设施反哺数据治理。数据质量问题能自动发现血缘链路能快速定位模型的价值才会从「规范文档」变成「生产力工具」。我自己在项目里养成的习惯是每周跑一次质量规则扫描每月做一次血缘链路的完整性核对发现新增表没有挂到模型上就马上补登记避免链路断掉。模型数据对不上时就回头查元数据登记从源头解决问题。希望帮到你。本文还有配套的精品资源点击获取