简介这是一份以数字化转型为背景的数据架构设计方法论PPT共51页面向数字化转型规划者、企业架构师、数据治理人员及需要理解企业级数据架构的信息技术管理者。内容从数据架构是什么切入比较DAMA、IBM等不同定义并说明数据架构在企业架构中的位置以及与业务架构、应用架构、技术架构的关系随后围绕数据资产目录、数据模型、数据标准、数据分布四大组件展开包含数据分层结构、数据标准样例与案例分析等落地内容。压缩包内仅含1个PPT文件大小2.84MB轻量易用。已有74人学习浏览。借助这51页图示读者可掌握一套从厘清数据资产、统一业务术语到明确数据分布与系统落位的规划路径理解数据架构如何支撑消除数据孤岛、提升数据质量和辅助决策适合作为企业数字化转型内训或方案设计的参考材料。1. 数据架构设计方法论不是“画图”是给数据资产定规矩标题里“数字化转型”打了两次看完只剩一个印象这种事如果没被逼到墙角不会有人愿意把方法论做成几十页PPT。真正在项目里推过数据架构的工程师都知道方法论不是用来装饰汇报的而是在系统林立、口径混乱、业务部门彼此说不清楚的现状里找到一条能落地的路。它解决的问题很朴素企业到底有哪些数据谁产生、谁使用、谁负责未来系统建设时数据放在哪儿、按什么规矩流动。这套方法论适合正在做数据平台、数据中台或数据仓库改造的团队也适合那些被业务方拿着“你画的架构图凭什么让我们改系统”来质问的架构师。下面按最常见的推导主线拆开讲每一层都给可评审的交付物和可套用的表格最后把我在项目里反复踩过的坑一并列出来。2. 从业务能力到数据模型五层推导的主线怎么走通这类方法论PPT做到五六十页核心内容其实就一条主线业务战略怎么一步步翻译成数据架构。我习惯把它拆成五层——业务能力地图、数据域、概念模型、逻辑模型、数据分布。五层每一层都有明确的输入和输出上一层的产出是下一层的输入顺序不能跳。2.1 业务能力地图数据域边界的唯一合法来源数据架构最容易犯的错是跳过业务直接对着现有系统表结构梳理数据。这样做出来的数据域划分本质上是把旧系统的边界原样搬了一遍过去烟囱式建设的病根也一起搬了过去。我一般会先要求业务方给出公司级的业务能力清单哪怕一开始很粗制造类企业通常能列出销售、研发、生产、采购、供应链、财务、人力零售类企业则是会员、商品、门店、交易、营销、履约。这张清单不需要多精确它的作用是给数据域画边界。有了业务能力清单就可以做第一版数据域映射。每个业务能力域对应一个一级数据域业务流程里的核心对象再作为二级域。这一步的关键是让业务负责人点头而不是让架构师自己拍板。常见做法是开两三轮访谈第一轮请业务讲清楚日常工作里处理哪些核心数据对象第二轮拿整理好的域清单去对第三轮单独过争议项。数据域清单出来后要产出一张简单的表这张表就是后续一切设计的地基一级数据域对应业务能力域二级数据域示例核心数据对象示例客户域市场与销售客户主数据、销售线索、商机客户、联系人、商机、合同产品域产品研发产品主数据、产品配置、BOM产品、物料、BOM、工艺路线生产域计划与生产生产计划、生产执行、质量生产订单、工单、报工记录、质检单供应链域采购与履约采购、库存、物流供应商、采购单、入库单、发货单财务域财务与合规总账、应收、应付、成本凭证、发票、付款单、成本中心这张表是后续概念模型的骨架也是跟业务方确认边界的沟通工具。注意粒度控制在一级域和二级域就好不要第一步就钻进属性细节。粒度太细业务方看不懂评审会开十次也定不下来。2.2 数据域划分的三条原则高内聚、端到端、可演进域划分不是拍脑袋三条原则我在每个项目里都会反复强调。第一条是高内聚低耦合一个数据域内部的实体之间关系紧密跨域实体的引用尽量少。第二条是端到端完整性一条业务流程的主数据能在一个域里串起来“合同”从创建、审核、履约到开票不应该被拆散到三个域里。第三条是可演进性域划分要为未来业务扩展留位置通常预留“基础域”承接组织、人员、权限这类全局对象。实际操作中域划分的常见分歧出现在“共享对象归谁管”。比如客户销售域说是它建的服务域说它也更新客户状态财务域还指着客户信用等级。我不追求客户只在一个域而是采用“一个主域负责权威源其他域只引用”的方式客户主数据归客户域负责创建和维护交易域、财务域只建立引用关系。这样既保证高内聚又不至于让一个域把上下游的数据全部包揽。域划分还有两个容易踩的细节。一是“分析域是否独立”面向报表、指标的分析类数据要不要单独划出来业界有不同做法但架构初期不要在分析域上花太多精力先让业务系统域的边界稳定下来。二是“公共编码数据”地区、币种、订单状态枚举这类参考数据建议统一划到基础数据域维护否则每个域都建一套自己的字典后面做数据集成就是一场灾难。2.3 概念模型到逻辑模型实体、关系、属性一次定清楚数据域边界定了接下来就是实体级建模。概念模型阶段只做两件事列出核心实体画出实体间关系。实体来源有三个业务流程里的名词客户、订单、发票、业务方日常使用的表单字段合同编号、收货地址、对存量系统表结构的逆向分析。前两个来源为主存量系统只做验证不要让旧系统的不规范命名污染新模型。关系处理上有两个高频问题。第一个是N:N关系一个订单包含多个产品一个产品出现在多个订单里需要在中间加一个订单明细实体把N:N拆成两个1:N。第二个是非必要的关系属性“客户—所属区域”和“区域—负责人”这类属性型关系尽量不要单独建模用属性表达就好。概念模型阶段关系越多后面维护越痛苦克制建模才是对的。逻辑模型阶段要对每个实体补充关键属性、主外键和唯一约束。交付物不要做成几百页的巨型数据字典一个实体一行、每行带关键属性说明的清单就够用了实体编号实体名称所属数据域关键属性业务负责人备注E-C-001客户客户域customer_id, customer_name, credit_level销售部数据专员全局主数据E-T-001销售订单交易域order_id, order_date, customer_id销售运营引用客户E-T-002订单明细交易域item_id, order_id, product_id, qty, price销售运营N:N拆分注意概念模型阶段的实体清单每个域控制在20到40个比较合适。数量再往上走先收缩域边界不要急着展开逻辑模型。这份清单既是建模的结果也是后续数据分布图和数据标准的输入。做到这一步一套数据架构的核心骨架就立住了。3. 目标架构从四张清单开始数据分类、数据分布、数据分层与流转概念模型回答“业务上有哪些数据”接下来要回答“这些数据在系统里以什么形态存在、放在哪、怎么流动”。我习惯用四张清单把目标架构定下来数据分类清单、数据分布矩阵、数据分层方案、数据流转关系。四张清单定完目标架构里“有什么、在哪、怎么走”就都清楚了。3.1 数据先分类主数据、参考数据、事务数据、分析数据数据分类是数据架构里最容易被忽略却最关键的一步。我一般把数据分成四类主数据、参考数据、事务数据、分析数据。这四类的特征差别很大混淆了它们后面做数据分布和系统归属时会打架。主数据是跨部门、跨系统共享的基础数据客户、产品、物料、供应商、组织、人员。核心特征是全局唯一、相对稳定、变更是低频高影响。参考数据是枚举和标准地区、币种、订单状态特征是业务含义强但结构简单。事务数据是业务过程产生的流水订单、工单、采购单、出入库记录特征是高频增长、只增不改、量大。分析数据是面向分析加工出来的结果指标宽表、标签、模型打分特征是派生性强、可回放、可重建。四类数据的治理重点不一样。主数据要管权威源和分发链路参考数据要管版本和发布审批事务数据要管保留周期和归档策略分析数据要管加工链路和口径说明。如果一张表在数据分类表里没法归入这四类通常说明建模有问题。分类没做对后面数据分布和标准制定都会跟着偏。3.2 数据分布矩阵一张表说清“谁创建、谁更新、谁引用”数据分类定了每类数据的角色数据分布矩阵则把每个数据实体和系统节点的关系固定下来。矩阵的横轴是系统节点纵轴是数据实体格子里标的是这个系统对实体的操作类型C代表创建、U代表更新、R代表读取、D代表删除。以订单、客户、工单三个实体为例矩阵长这样数据实体订单系统客户系统生产系统数仓整合层分析应用客户RC/U权威源RRR销售订单C/U权威源RRRR工单R-C/U权威源RR这个矩阵的价值在于一眼看出两个问题。第一权威源是否唯一一个实体只能有一个C/U的格子出现第二个就是多系统写数据不唯一的根源。第二读取关系是否清晰R的格子可以很多但每一个R都要有明确的获取路径要么走接口、要么走数据同步不能出现“直接连生产库读”这种无法管控的方式。提示数据分布矩阵里的“权威源”列评审会上讨论最多。做矩阵前先和业务方单独对齐不要直接上大评审会。矩阵做到实体级就够了。系统级和接口级的数据流属于技术实现细节放数据开发文档里管不需要进架构评审。3.3 数据分层数据仓库的四层逻辑也是架构层的决策数据分层在架构层面要回答两个问题分几层、每层保留多久。常见做法是四层贴源层ODS、整合层DWD、汇总层DWS、应用层ADS。每层的用途不同存储成本和数据质量要求也不同架构评审时要当成一组参数来约定而不是由建模团队各自定分层定位时效质量要求保留建议ODS/贴源层原样保存业务系统数据保留历史痕迹准实时到T1完整性、幂等性优先长期保留5年起DWD/整合层清洗、标准化、统一口径T1按数据标准执行可追溯2到5年DWS/汇总层面向主题的汇总和指标加工T1到分钟级指标口径一致链路可解释2到3年ADS/应用层面向报表、标签、模型输出小时级到分钟级准确性最高权限控制6到12个月随应用调整分层的架构决策里最大的坑是把ODS当成“数据垃圾桶”。所有源表原样全量拷贝以为留得越全越好结果存储成本和维护成本同时暴涨。源系统里真正需要长期留痕的数据并没有那么多ODS的保留策略应当由数据架构师和业务方一起逐类确认而不是一刀切“五年全留”。另外分层不是越细越好。中小规模团队把四层跑全往往要额外养一半数据开发人力。一开始只保留贴源、整合、汇总三层应用层直接基于汇总层出结果等指标复杂度上来再拆出ADS这个顺序我验证过很多次能省不少人力和存储成本。4. 让架构落进日常元数据、数据标准与架构评审机制数据架构设计方法论只要做到上一章图纸层面已经完整了。但架构要真正活起来必须有配套机制否则半年后架构文档就和线上系统对不上账。这一章讲三件事元数据怎么驱动架构更新、数据标准按什么顺序落、架构评审机制怎么搭。4.1 元数据不是概念让架构图从“墙上”回到“线上”很多团队做数据架构交付物就是PPT和Visio图项目一结束图再也没有人更新。真正常态化运转的架构必须把元数据作为载体。元数据分成三层技术元数据指表结构、字段、数据源、同步频率业务元数据指字段的业务含义、口径说明、负责人管理元数据指数据质量规则、生命周期、归属信息。方法论里如果只有图没有元数据那它终究是挂在墙上的一幅画。落地时不一定要上多复杂的元数据平台先用Excel或者wiki把关键信息管起来也比图躺在文件夹里强。我见过一个团队用一张表维护元数据核心字段包括数据实体、所属域、系统来源、负责人、数据标准编号、质量责任人、最近更新日期。每季度由数据治理组照着表核对一次发现线上新增表没有映射到数据域就发起一次架构偏差评审架构才不会失控。技术元数据的采集可以做半自动。主流元数据管理平台能扫出表结构、血缘、调度依赖这些作为技术层基底业务元数据仍需要人工补齐。注意血缘不是一次性跑完就结束的数据开发流程里应当规定每张新表上线前必须把血缘关系登记进元数据系统。这一步不做三个月后改任何一层模型你都无法评估影响范围。4.2 数据标准落地顺序先主数据再公共代码最后才是业务字段数据标准全量铺开是做不完的。每个项目都有一堆字段要统一长度、统一含义真正常态化运转的做法是抓重点。第一步先定主数据标准客户ID的编码规则、产品编码规则、组织编码规则。这些标准直接影响跨系统集成不统一的话后面做数据同步时光映射关系就要写几百行。第二步是公共代码标准订单状态枚举、币种代码、地区代码。这类东西通常是参考数据表不需要大动干戈订好一张代码表模型就可以。第三步才是业务字段标准金额字段统一用decimal(20,4)、日期字段统一格式等。业务字段标准的优先级很低不要陷进去先把前两类做扎实。标准落地阶段的常见失误是把标准做成“设计文档”而不是“检查项”。数据标准要能写进系统建设规范里比如新建接口时强制校验返回的时间字段格式入库前强制校验客户ID满足编码正则。我一般把标准整理成一个可勾选的检查清单放进开发规范的发版检查项里数据治理组按清单做上线前检查比任何宣讲都管用。注意数据标准不要一次性全量发布每年发布两批优先级最高的就够了发布一批、执行一批、回顾一批。4.3 架构评审机制谁来评、多久评、看什么数据架构能不能持续发挥作用取决于有没有一个常态化的评审机制。三个问题必须回答。谁来评业务负责人、数据负责人、数据架构师三方都要到场纯IT内部的评审解决不了业务边界问题。多久评季度级全面评审加项目级立项评审二者缺一不可。看什么新增系统或新增表有没有遵守数据域边界、有没有跳过标准、有没有破坏分层。项目级评审的触发点是建新表、新接接口、新起数据链路。评审时的核心是“数据实体落在哪个域、权威源是谁、要不要改旧系统”。很多场景里架构师坚持一个系统数据不能跨域乱写业务方觉得没有必要这时就把数据分布矩阵拿出来指出跨域写入会破坏单一数据源后续数据口径必然混乱。用矩阵说话比用原则说话有效得多。评审机制还有一个设计注意点评审不是审批卡点而是共识建立过程。不要试图用架构评审卡业务上线那样架构会被当成摆设。我通常把评审结论分成三类通过、带条件通过、不通过。带条件是绝大多数条件是补文档、补标准映射或者整改旧数据这比简单打回更实际业务方也更愿意配合。5. 数据架构设计避坑五个高频翻车现场设计方法论在纸上看起来很顺一落到真实企业里就状况百出。下面五个坑是我在多个项目里反复见到的高频场景每个都按“现象、原因、解决”的顺序说清楚给后面做架构设计的团队打打预防针。5.1 推不动业务部门把数据架构当成IT的事现象数据域划分、数据标准评审业务方代表全程不发言会后说“这是技术活你们定就行”。或者答应当负责人的业务同事等到项目需要拍板时各种借口缺席数据域边界拖三个月定不下来。原因数据架构的收益在跨部门、在中长期而业务方当前的考核里没有这一项。业务方天然看不到投入时间整理数据实体对本月KPI的贡献动力自然为零。解决把业务方拉进来的方法不是宣讲而是“让他们点评”。评审数据域边界时不先展示架构师自己画的图而是拉出一张空表让他们填自己负责的核心数据对象清单再逐条追溯到线上系统。当数据问题具象到“你的报表为什么和销售对不上”“为什么多一个系统就要重新导一遍数据”时业务方才有实感。另外把每个数据域的业务负责人注记清楚每季度由数据治理组做一次责任进展通报比单纯开会催进度有用得多。5.2 画不准模型粒度失控架构图成了黑匣子现象概念模型阶段就铺开全量字段实体清单从一个迭代的50个膨胀到500个每个实体的属性都细化到极致系统间关系画成蛛网状最后没有任何人敢改动其中一个环节架构图变成谁都不敢碰的黑匣子。原因画不准的核心是缺少“层级”的概念。不同角色需要不同粒度的架构图决策层看数据域和主要分布中层看实体级数据流开发层看字段级映射。把三层画成一张图不可维护也看不明白。解决把架构图分成三层归档每层的更新频率和审批人不同。数据域级图每季度更新由数据治理组负责实体级图随项目变动更新由数据架构师确认字段级模型图放进数据开发工具里维护不入架构评审范围。承认不同粒度的存在才不会让一层的问题污染另一层。逻辑模型阶段也要有数量意识概念模型只保留跨域关键实体单域实体数量控不住就先收缩边界。5.3 落不下目标架构与现有系统差距过大改不动现象方法论设计出来的数据架构非常理想所有主数据统一管理、所有系统数据入湖、所有标准统一执行。但现有系统是多年沉淀的老旧结构和各种Excel手工加工没有合理的过渡路径架构就永远停留在PPT阶段。原因目标架构忽略了现状迁移评估。迁移代价巨大的时候不是架构目标错了而是缺少分阶段演进策略。把全量统一作为终点却没有设计中间态新架构和旧系统完全断层。解决在目标架构前先做现状差距分析。差距大的环节拆成三阶段第一阶段维持旧体系运转在新系统里落实新模型做好同步映射第二阶段把关键主数据收归权威源替换旧临时表第三阶段才停掉旧链路。每个阶段都要有业务收益支撑比如“收拢客户主数据”对应“减少一次客户信息重复录入”。架构推进不是一次大爆炸而是一连串可落地的迁移步骤。5.4 管不住架构基线无人维护两张图各说各话现象半年后再翻架构文档发现和线上系统对不上。新开发的表没有登记到数据域某系统悄悄新建了一套客户信息表。架构规范文档发下去到交付节点大家都默认忽略新团队接手后各写各的。原因缺少基线管理机制。架构文档没有和线上比对也没有把变更登记纳入流程很多项目按合同交付交付节点上架构师的签字不是必经环节。解决建立架构基线管理把“表注册”作为硬性流程前置。每个新增表或新接接口在设计阶段先注册到元数据系统系统自动指派所属数据域并触发数据标准检查项没有注册标记的不允许申请生产权限。这类检查在数据开发平台的审批流里可以配置。基线还要在季度评审中抽检比对发现未注册的表要回填登记后再处理数据问题。5.5 验不了架构设计跟业务指标对不上账现象架构设计做完业务负责人提了一个问题“你说客户数据归一个域统一管那客户流失率到底是什么口径为什么数据层建完了报表指标还是对不上”架构师面对口径问题只能含糊带过没法沿着链路定位断点。原因架构设计过程中没有与指标建立映射。数据架构管的是“数据在哪里、怎么流动”业务指标管的是“每个数字怎么来的”。两者没有绑定架构做得再规范对业务方来说也是空中楼阁。解决在架构设计文档里增加一张“指标到实体”映射视图每个核心业务指标拆解到原子指标原子指标落到数据实体和字段实体属于哪个数据域、权威源在哪、链路上缺了哪一段。评审时直接过这张视图架构设计有没有漏洞一望即知。这个做法不增加太多工作量但能让架构验收从“看图”变成“看链路”。6. 用指标反推架构让架构评审从“看画”变成“看数”架构图和业务方之间的信任危机通常发生在“你讲完了我还是不知道这对我有什么帮助”的时刻。我的习惯后来改了接到数据架构相关的项目或复盘不急着翻PPT先要业务方最关心的三个指标然后从指标一路反推到数据模型再反推到架构层。这个动作能暴露架构设计里最隐蔽的问题——实体归属看着没问题但指标口径在应用层对不上。具体做法是画一张映射表指标 → 原子指标 → 依赖实体/字段 → 所属数据域 → 权威系统 → 当前状态。“客户复购率”拆解后落到“销售订单”实体的客户ID和订单日期字段所属交易域权威源在订单系统下游经整合层再做汇总。任何一个环节缺失指标链路就是断的。我曾在评审一个业务架构时发现完整链路里的商品ID权威源居然有两个系统导致所有价格类指标在应用层都无法对齐这张表当场就定位了问题。评审前把检查清单发出去让与会的人先自查一遍检查项说明结果数据域边界新增实体是否已归属数据域归属是否经业务负责人确认是/否/待定权威源每个核心实体的权威源唯一跨域引用是否只有读取关系是/否/待定指标链路核心指标能否从原子指标一路到达数据实体和权威源通过/有断点标准执行数据标准检查项是否已纳入本次需求的开发规范通过/未执行血缘登记新表血缘关系是否登记到元数据系统是/否/待定过渡方案与旧系统的兼容迁移方案是否明确阶段收益可否量化有/无/待定经历过太多次架构评审从“各说各话”到最后“拿链路图说话”我对数据架构设计方法论的态度务实了很多它的价值不在那几十页PPT而在能不能让排项目、投资源、追责任时有据可依。画得再漂亮落不下去就不是好架构。每次接到新的架构任务我还是会先问对方最想要的那个数字是什么顺着它把链路走一遍。链路走通了架构方案自然站得住脚。希望帮到你。本文还有配套的精品资源点击获取