简介本资料为52页PPT合集系统讲解华为企业数据架构、应用架构及技术架构的设计方法论适合企业架构师、数据治理人员及数字化转型项目成员参考学习。内容涵盖数据架构的五项原则、数据资产目录与概念/逻辑模型设计步骤、数据分布及整体蓝图构建方法并具体说明如何通过数据Owner机制、统一数据标准与数据服务化实现跨流程跨系统的数据同源共享。资源包共1个文件格式为pptx演示文稿整体大小约3.73MB便于直接阅读与二次修改。目前已有73人学习浏览可作为理解华为架构设计思路、开展企业级数据治理规划的有益资料。1. 企业数据架构那 52 页 PPT核心是让三张架构图变成一条决策链去年陪一家制造企业做数据平台规划业务、IT、数据团队各画各的架构图业务画流程节点IT 画系统拓扑数据团队画 ER 图。放到一张评审桌上谁都没法回答“订单数据到底由哪个系统负责、往哪里流转”。后来把方案推倒换成先定数据架构、再定应用架构、最后定技术架构的顺序重新过了一遍才把账算清楚。这份“52页PPT企业数据架构应用架构及技术架构设计方法”讲的方法论本质就是把三张图串成一条决策链数据怎么组织、应用怎么划分、技术怎么支撑每一步都以前一步的产出为输入。适合企业架构师、数据平台负责人和信息化规划人员用来组织评审与落地也适合想搞清楚“三架构到底先画哪张”的人。2. 数据架构设计主题域、分层与 CRUD 矩阵的落地方法我一般会把数据架构当作整个设计的锚点。先别急着选数据库、定集群规模而是回答四个问题企业有哪些关键数据、数据从哪里来、数据如何组织、谁在生产和消费。第四章应用架构和技术架构的每一个决定都得能从这四个问题里倒推出来。这一章按实际做方案时的顺序来展开。2.1 数据分层ODS 到 ADS 每层干什么、怎么取舍最常见的数据分层是四层ODS 贴源层、DWD 明细层、DWS 汇总层、ADS 应用层。四层不是装饰每一层解决一类问题。ODS 层把源系统的数据原样同步过来不做过多的逻辑清洗。它的作用是割裂源系统变更对下游的影响。源表字段删了、类型改了只要 ODS 层把快照留好下游还能追溯历史。DWD 层做清洗、去重、维度退化、统一编码把“能用”的数据变成“好用”的数据。DWS 层按主题做轻度汇总比如按客户、按商品、按门店的日汇总。ADS 层面向具体应用比如某张 BI 报表需要的那张宽表可以直接从 ADS 取。分层主要职责典型更新频率常见误区ODS原样接入、保留快照实时/准实时/小时级直接做清洗导致无法追溯源系统原始状态DWD清洗、标准化、维度退化小时级/天级不做维度退化宽表关联越来越重DWS按主题汇总、公共指标计算小时级/天级把业务口径写死在代码里指标难统一ADS面向报表与应用的专用数据按应用需要在 ADS 里做复杂清洗正确做法是在 DWD 完成四层不是必须全上。数据量小、报表就十几张的团队ODS DWD ADS 三层足够DWS 可以先不建。如果一开始就照着大厂模型铺四层大概率翻车——每一层都要运维、都要对口径、都要占用存储和计算。我给某公司做方案时就砍掉了 DWS直接让 ADS 基于 DWD 出宽表做了半年报表也没出过问题。分层的取舍标准是“有没有多个应用复用同一套汇总数据”有就建 DWS没有就跳过。2.2 主题域划分按业务域拆还是按数据域拆主题域是数据仓库的骨架。拆错主题域后面所有模型都别扭。常见有两种拆法按业务域拆比如客户、产品、渠道、交易、供应商按数据域拆比如主数据、交易数据、日志数据、配置数据。按业务域拆的好处是业务人员看得懂评审时容易过坏处是同一条数据会在多个域里重复出现比如订单既属于交易域又属于渠道域容易造成口径混乱。按数据域拆的好处是职责边界清楚技术团队好维护坏处是业务人员看不懂评审会上容易吵起来。拆分方式优点缺点适用场景按业务域业务人员友好、口径直观数据重复率高、跨域依赖多业务角色深度参与建模评审按数据域边界清晰、便于管理业务理解成本高技术团队主导、业务介入少混合拆分兼顾理解与边界需要额外维护映射关系大多数中大型企业我在实践里偏爱“业务域为主、数据域为辅”的混合方式。先划业务域让业务能对话再把主数据这类全局性强的东西单独拎出来。比如某制造企业我划了五个主主题域物料域、客户域、供应商域、订单域、财务域然后单独加一个主数据域放物料主数据、客户主数据。主数据是跨域共享的放在任何一个业务域下面都会导致其他域绕不开它。主题域定义完了要配上 owner——每个域有且只有一个负责人负责该域的口径解释和变更评审。没有 owner 的主题域过半年就是一堆没有人能说清的表。2.3 数据流向与 CRUD 矩阵把数据关系钉死在一张表上数据分层和主题域解决“数据怎么放”数据流向解决“数据怎么走”。画数据流图不要太早进入拓扑图先用一张 CRUD 矩阵把所有应用与核心数据实体的关系填清楚。矩阵的行放数据实体或主题域列放应用系统交叉格标注该应用对这个数据实体的操作类型C 创建、R 读取、U 更新、D 删除。这张表比任何架构图都更早暴露问题。数据实体订单系统客户中心支付系统财务系统报表平台订单数据C/R/URRRR客户主数据RC/R/URRR支付流水RC/R/URR科目余额C/R/UR填矩阵时有三条规则我比较坚持。第一每个数据实体至少要有一个 C创建方如果没有说明数据来源没落到位源头数据是黑匣子。第二一个数据实体的更新方 U 最好只有一个多个系统直接改同一份数据一定会有口径冲突。第三矩阵里出现“所有列都是 R、没有 C/U”的行说明这数据是外部导入或手工维护的得单独标注来源。CRUD 矩阵可以提前用表格做出来再转成数据流图。技术架构里消息队列、批任务的边界几乎都能从这张矩阵推导出来。注意CRUD 矩阵不是 ER 图不需要把字段级关系画出来。它的颗粒度到“系统 数据实体”即可太细的字段级映射留给后续建模阶段。3. 应用架构设计从业务流程到功能域与集成方式的映射数据架构定了应用架构就有了坐标系。我见过不少人上来就画应用拓扑把 ERP、CRM、MES 一个个框起来连线看起来整齐但实际上只是系统清单不是架构。应用架构要回答的问题是谁在产生数据、谁在消费数据、流程的每一步落到哪个应用、应用之间怎么协作。这一章的方法是以业务能力为轴心拆功能域再以数据关系定集成方式。3.1 功能域划分别按部门画应用按业务能力拆很多公司按部门画应用架构财务部一套、销售部一套、生产部一套。结果销售部门一调整整套应用架构跟着动评审会开成了部门边界讨论会。正确做法是按业务能力拆功能域。业务能力是“企业能做什么”相对稳定部门是“谁来负责做”经常变动。按能力拆应用架构的寿命会长得多。业务能力功能域对应应用模块关键数据实体获取订单订单域订单中心订单、订单明细管理客户客户域客户中心客户主数据、联系人履约交付履约域仓储/物流系统发货单、物流轨迹结算对账结算域财务/结算中心应收、实收、对账单具体步骤是先列业务流程清单三级流程就够用再把每个三级流程映射到一个功能域然后检查有没有流程找不到域或者一个域覆盖了太多不相关的流程。找不到域的流程通常意味着业务能力缺失或重复建设。我一般会把结果整理成一张“流程-功能域-应用模块”三列映射表评审时先看表再看图。表上没有的图线都是装饰线。这里还有个容易漏的坑主数据管理不要单独设一个功能域了事客户主数据要落到客户域、物料主数据落到供应链域但主数据的运维流程要单独标出来。主数据本身跨域共享不归任何单一业务域的流程管它在应用架构里通常体现为一个独立的“主数据管理平台”而不是塞进某个业务系统里。3.2 应用间集成同步接口、异步消息与批处理的选择逻辑功能域分完应用之间的线怎么画不是随便连线每条线代表一类数据交互方式。我选集成方式时有一个简化判断逻辑交易强一致用同步接口事件通知用异步消息大批量数据用批处理。把这个逻辑写进评审规则应用架构就不会被画成一团乱麻。同步接口下单时要实时校验库存用同步接口。特点是响应快、强依赖调用方需要处理超时和降级。异步消息订单创建成功后通知库存扣减用消息队列。特点是削峰、解耦但要考虑消息丢失和重复消费。批处理数据仓库每日从业务库拉取增量数据用批处理。特点是量大、延迟高按天或按小时调度。数据库直连仅在数据仓库内部层间使用应用系统之间不建议直连数据库。应用直连数据库是耦合后续技术架构没法做容灾和限流。交互场景推荐方式关键参数风险点实时校验库存同步接口超时 3s重试 1 次下游慢导致线程池耗尽订单状态通知异步消息分区数、消费组、重试次数消息积压、重复消费日增量入仓批处理调度周期、任务超时、失败重跑源表无更新时间字段导致漏数主数据分发异步消息批量拉取版本号、订阅方列表版本冲突、订阅方漏接这层决策直接影响技术架构选同步接口的地方要设计熔断降级选异步消息的地方要上消息队列选批处理的地方要准备调度平台。所以我在应用架构评审时会要求每一条连接线上面标注“接口类型 数据内容 大约频率”。标不出来的连接线就是拍脑袋画的。另外应用架构里还得标出每个应用的数据消费来源。一个应用如果依赖数据仓库出报表但数据链路里没有日志和变更捕获那这条链路就是断的。技术架构落地时最先要补的就是这些断点。4. 技术架构设计组件选型、容量估算与 SLA 分级的顺序技术架构经常是第一个开画的却是最后一个该画的。数据架构决定了要存什么、应用架构决定了要传什么技术架构只需要回答怎么存、怎么传、怎么算。顺序反了就会出现为了用某个组件硬改数据模型的事。这一章讲三个动作选型、估算、分级。4.1 计算与存储选型跟着数据特征走别跟热度走选型我先看数据特征而不是看技术热度。数据特征是数据量、实时性、查询模式、写入模式。DWD 层做大宽表关联典型场景是“多表 join 全表扫描”适合用 MPP 引擎ADS 层支撑高并发报表查询单次查询量不大但并发高适合用关系型数据库加合适索引ODS 层存历史快照、很少更新用对象存储加分区表就够了。日志类数据写入量大、读取以时间范围为主选择列式存储更划算。数据层面典型数据特征推荐选型方向选型参数ODS海量、少更新、按时间查对象存储/分区表保留周期、压缩格式、生命周期规则DWD多表关联、复杂清洗MPP 引擎节点数、并行度、内存与磁盘配比DWS固定维度汇总、吞吐高MPP 或列式存储预计算策略、物化视图频率ADS高并发、低延迟关系型数据库连接池、慢查询阈值、读写分离这里最容易犯的错是“一听分布式就上”。数据量只有几千万行、一天增量几百万条用单机关系型数据库加分区表完全能扛住运维成本却低一个数量级。我做方案时给过某团队一个判断标准日增数据小于 2000 万行、宽表 join 不超过三张先别引分布式组件等真的出现“单机 CPU 打满、加索引也救不回来”再升级后患小得多。选型评审要加一道“运维准入门槛”这个组件团队里有人能独立排查问题吗没有就选托管版或换简化方案。技术架构的复杂度是逐步叠加的不是一步到位的。4.2 容量估算与部署形态先把峰值和冗余算清楚再买机器容量估算不是拍脑袋是数据架构的量化结果。我养成的习惯是先算存储再算计算最后算网络。存储容量公式大概是日增数据量 × 保留周期 × 副本数 × 膨胀系数。膨胀系数考虑索引、临时文件和压缩率波动一般取 1.5 到 2。假设订单表日增 500GB保留 180 天副本 2 份膨胀系数 1.8那么存储需求约为 500GB × 180 × 2 × 1.8 324TB。这个数字用于决定集群规模评估周期是按三年算。计算项输入参数示例结果存储容量日增、保留周期、副本、膨胀系数500GB×180×2×1.8324TB计算资源高峰期作业并发、单任务资源、冗余20 作业×8GB×2 冗余320GB 内存网络带宽峰值同步数据量、时间窗口200GB/小时约 450Mbps部署形态上私有化与云原生的取舍要看数据主权和运维能力。私有化意味着自己扛机房、网络、硬件故障云原生则要接受依赖云厂商的运维边界。没有绝对对错只是取舍。SLA 分级反而比部署形态更能体现技术架构的成熟度ODS 层允许 T1 加载SLA 可以定为 99.9%ADS 层支撑实时报表SLA 要提到 99.99%。不同数据层用不同 SLA成本和运维精力才能花在刀刃上。我会在方案里给每类组件配一张“SLA 登记表”写清楚可用性要求、备份策略、恢复时间目标。这样后续故障演练才有的放矢。技术选型有些时候确实像玄学同样规模的数仓有人三台机器跑得欢有人二十台还在调优。差别往往不在组件本身而在容量算没算清楚。5. 三架构联合设计最容易翻车的五个场景与排查清单数据、应用、技术三条线分开看都好理解难在拉通。这一章是血泪经验五个翻车场景我都经历过或亲眼看过按“现象、原因、解决”写出来你可以直接当排查清单用。5.1 主题域按部门划分跨域打通成了口号现象数据仓库建好了营销域、生产域、财务域各自报表都能跑但一做跨域分析比如“某产品的交付成本与营销投入对比”数据就对不上。原因当初主题域是让各部门自己提需求“按部门切谁都满意”导致的后果。跨域数据没有主数据关联统一编码也没建立。解决先建主数据模型至少把客户、物料、供应商的编码统一再划主题域每个主题域指定 ownercross-domain 的模型变更必须过架构评审不允许部门自己说了算。5.2 应用架构只画系统框图不标数据关系现象评审会上几十个系统排得整整齐齐评审过了落地时却说不清“订单数据是哪个系统生产的”。原因沿用了老的拓扑图画法只表达系统间有连接不表达数据如何流转。框和线能画好看但没法验证。解决要求每张应用架构图配一张 CRUD 矩阵矩阵里每一行都要有产源。没有 CRUD 矩阵的应用架构图评审可以不通过。数据关系钉死了技术架构才知道哪些接口要重点保障。5.3 技术选型只看热度不看团队运维能力现象引入分布式组件后作业凌晨失败没人能处理业务第二天看不到报表。原因选型时被“大数据能力”打动没评估团队是否具备排障能力。组件本身没坏是没人养得起。解决加一道“运维准入门槛”——选每个组件前回答两个问题团队有没有人读过该组件的官方运维手册故障恢复步骤能不能写出来答不上来就选托管版或者暂时用成熟度更高的简化方案。5.4 数据架构和技术架构各改各的没人拉通现象技术架构升级消息队列下游消费端对接了新集群但数据架构里的数据流图还画着旧链路半年后新人不明白为什么实际链路和图对不上。原因数据架构和应用架构迭代节奏不一致变更没有统一入口。解决把三架构变更纳入同一个架构委员会评审任何一方的变更都要求输出“影响到的数据实体和应用模块”清单。这张清单不交变更不审批。5.5 直接套模板架构设计与业务规模脱节现象参考别家方案把每个组件都铺上对象存储、消息队列、MPP、OLAP、调度平台一应俱全资源开销巨大。原因没做裁剪把模板当标准答案。实际上业务规模、数据量、团队能力都不一样。解决给每个组件写“引入条件”不满足条件则不引入。比如数据量日增不超过多少、并发不超过多少就不上分布式组件。没有引入条件的组件清单不是架构设计是设备采购单。6. 用一张全景图验证三架构是否对齐并把它作为评审底稿最后一个技巧把所有数据实体、应用组件、技术组件塞进一张全景矩阵里验证。纵向是数据主题域与核心数据实体横向是应用模块和技术组件。交叉格里标注关系C 代表该应用生产此数据R 代表消费S 代表某个技术组件存储此数据。然后按三条规则逐行检查。规则一每个数据实体至少有一个 C、一个 R、一个 S。缺 C 说明数据源头没接缺 R 说明数据建了没人用缺 S 说明存储没落实。规则二每个应用模块至少涉及一个数据实体全是虚线关系的模块要问它存在的理由。规则三每个技术组件至少被一条数据链路引用完全没被引用的组件可以直接砍掉。这张矩阵比任何文字评审意见都讲得清问题。我自己最早做规划时习惯先画技术架构以为确定了选型再倒推数据模型结果画完返工三个月——每换一个组件数据流图就重画一遍应用集成方式也得跟着改。后来改成数据架构先行先填 CRUD 矩阵再定功能域最后做技术选型一次通过率高了很多。52 页的方法论里最值钱的不是某几个框架图而是“数据先行、应用承接、技术兜底”这个顺序。希望帮到你。本文还有配套的精品资源点击获取
简介本资料为52页PPT合集系统讲解华为企业数据架构、应用架构及技术架构的设计方法论适合企业架构师、数据治理人员及数字化转型项目成员参考学习。内容涵盖数据架构的五项原则、数据资产目录与概念/逻辑模型设计步骤、数据分布及整体蓝图构建方法并具体说明如何通过数据Owner机制、统一数据标准与数据服务化实现跨流程跨系统的数据同源共享。资源包共1个文件格式为pptx演示文稿整体大小约3.73MB便于直接阅读与二次修改。目前已有73人学习浏览可作为理解华为架构设计思路、开展企业级数据治理规划的有益资料。1. 企业数据架构那 52 页 PPT核心是让三张架构图变成一条决策链去年陪一家制造企业做数据平台规划业务、IT、数据团队各画各的架构图业务画流程节点IT 画系统拓扑数据团队画 ER 图。放到一张评审桌上谁都没法回答“订单数据到底由哪个系统负责、往哪里流转”。后来把方案推倒换成先定数据架构、再定应用架构、最后定技术架构的顺序重新过了一遍才把账算清楚。这份“52页PPT企业数据架构应用架构及技术架构设计方法”讲的方法论本质就是把三张图串成一条决策链数据怎么组织、应用怎么划分、技术怎么支撑每一步都以前一步的产出为输入。适合企业架构师、数据平台负责人和信息化规划人员用来组织评审与落地也适合想搞清楚“三架构到底先画哪张”的人。2. 数据架构设计主题域、分层与 CRUD 矩阵的落地方法我一般会把数据架构当作整个设计的锚点。先别急着选数据库、定集群规模而是回答四个问题企业有哪些关键数据、数据从哪里来、数据如何组织、谁在生产和消费。第四章应用架构和技术架构的每一个决定都得能从这四个问题里倒推出来。这一章按实际做方案时的顺序来展开。2.1 数据分层ODS 到 ADS 每层干什么、怎么取舍最常见的数据分层是四层ODS 贴源层、DWD 明细层、DWS 汇总层、ADS 应用层。四层不是装饰每一层解决一类问题。ODS 层把源系统的数据原样同步过来不做过多的逻辑清洗。它的作用是割裂源系统变更对下游的影响。源表字段删了、类型改了只要 ODS 层把快照留好下游还能追溯历史。DWD 层做清洗、去重、维度退化、统一编码把“能用”的数据变成“好用”的数据。DWS 层按主题做轻度汇总比如按客户、按商品、按门店的日汇总。ADS 层面向具体应用比如某张 BI 报表需要的那张宽表可以直接从 ADS 取。分层主要职责典型更新频率常见误区ODS原样接入、保留快照实时/准实时/小时级直接做清洗导致无法追溯源系统原始状态DWD清洗、标准化、维度退化小时级/天级不做维度退化宽表关联越来越重DWS按主题汇总、公共指标计算小时级/天级把业务口径写死在代码里指标难统一ADS面向报表与应用的专用数据按应用需要在 ADS 里做复杂清洗正确做法是在 DWD 完成四层不是必须全上。数据量小、报表就十几张的团队ODS DWD ADS 三层足够DWS 可以先不建。如果一开始就照着大厂模型铺四层大概率翻车——每一层都要运维、都要对口径、都要占用存储和计算。我给某公司做方案时就砍掉了 DWS直接让 ADS 基于 DWD 出宽表做了半年报表也没出过问题。分层的取舍标准是“有没有多个应用复用同一套汇总数据”有就建 DWS没有就跳过。2.2 主题域划分按业务域拆还是按数据域拆主题域是数据仓库的骨架。拆错主题域后面所有模型都别扭。常见有两种拆法按业务域拆比如客户、产品、渠道、交易、供应商按数据域拆比如主数据、交易数据、日志数据、配置数据。按业务域拆的好处是业务人员看得懂评审时容易过坏处是同一条数据会在多个域里重复出现比如订单既属于交易域又属于渠道域容易造成口径混乱。按数据域拆的好处是职责边界清楚技术团队好维护坏处是业务人员看不懂评审会上容易吵起来。拆分方式优点缺点适用场景按业务域业务人员友好、口径直观数据重复率高、跨域依赖多业务角色深度参与建模评审按数据域边界清晰、便于管理业务理解成本高技术团队主导、业务介入少混合拆分兼顾理解与边界需要额外维护映射关系大多数中大型企业我在实践里偏爱“业务域为主、数据域为辅”的混合方式。先划业务域让业务能对话再把主数据这类全局性强的东西单独拎出来。比如某制造企业我划了五个主主题域物料域、客户域、供应商域、订单域、财务域然后单独加一个主数据域放物料主数据、客户主数据。主数据是跨域共享的放在任何一个业务域下面都会导致其他域绕不开它。主题域定义完了要配上 owner——每个域有且只有一个负责人负责该域的口径解释和变更评审。没有 owner 的主题域过半年就是一堆没有人能说清的表。2.3 数据流向与 CRUD 矩阵把数据关系钉死在一张表上数据分层和主题域解决“数据怎么放”数据流向解决“数据怎么走”。画数据流图不要太早进入拓扑图先用一张 CRUD 矩阵把所有应用与核心数据实体的关系填清楚。矩阵的行放数据实体或主题域列放应用系统交叉格标注该应用对这个数据实体的操作类型C 创建、R 读取、U 更新、D 删除。这张表比任何架构图都更早暴露问题。数据实体订单系统客户中心支付系统财务系统报表平台订单数据C/R/URRRR客户主数据RC/R/URRR支付流水RC/R/URR科目余额C/R/UR填矩阵时有三条规则我比较坚持。第一每个数据实体至少要有一个 C创建方如果没有说明数据来源没落到位源头数据是黑匣子。第二一个数据实体的更新方 U 最好只有一个多个系统直接改同一份数据一定会有口径冲突。第三矩阵里出现“所有列都是 R、没有 C/U”的行说明这数据是外部导入或手工维护的得单独标注来源。CRUD 矩阵可以提前用表格做出来再转成数据流图。技术架构里消息队列、批任务的边界几乎都能从这张矩阵推导出来。注意CRUD 矩阵不是 ER 图不需要把字段级关系画出来。它的颗粒度到“系统 数据实体”即可太细的字段级映射留给后续建模阶段。3. 应用架构设计从业务流程到功能域与集成方式的映射数据架构定了应用架构就有了坐标系。我见过不少人上来就画应用拓扑把 ERP、CRM、MES 一个个框起来连线看起来整齐但实际上只是系统清单不是架构。应用架构要回答的问题是谁在产生数据、谁在消费数据、流程的每一步落到哪个应用、应用之间怎么协作。这一章的方法是以业务能力为轴心拆功能域再以数据关系定集成方式。3.1 功能域划分别按部门画应用按业务能力拆很多公司按部门画应用架构财务部一套、销售部一套、生产部一套。结果销售部门一调整整套应用架构跟着动评审会开成了部门边界讨论会。正确做法是按业务能力拆功能域。业务能力是“企业能做什么”相对稳定部门是“谁来负责做”经常变动。按能力拆应用架构的寿命会长得多。业务能力功能域对应应用模块关键数据实体获取订单订单域订单中心订单、订单明细管理客户客户域客户中心客户主数据、联系人履约交付履约域仓储/物流系统发货单、物流轨迹结算对账结算域财务/结算中心应收、实收、对账单具体步骤是先列业务流程清单三级流程就够用再把每个三级流程映射到一个功能域然后检查有没有流程找不到域或者一个域覆盖了太多不相关的流程。找不到域的流程通常意味着业务能力缺失或重复建设。我一般会把结果整理成一张“流程-功能域-应用模块”三列映射表评审时先看表再看图。表上没有的图线都是装饰线。这里还有个容易漏的坑主数据管理不要单独设一个功能域了事客户主数据要落到客户域、物料主数据落到供应链域但主数据的运维流程要单独标出来。主数据本身跨域共享不归任何单一业务域的流程管它在应用架构里通常体现为一个独立的“主数据管理平台”而不是塞进某个业务系统里。3.2 应用间集成同步接口、异步消息与批处理的选择逻辑功能域分完应用之间的线怎么画不是随便连线每条线代表一类数据交互方式。我选集成方式时有一个简化判断逻辑交易强一致用同步接口事件通知用异步消息大批量数据用批处理。把这个逻辑写进评审规则应用架构就不会被画成一团乱麻。同步接口下单时要实时校验库存用同步接口。特点是响应快、强依赖调用方需要处理超时和降级。异步消息订单创建成功后通知库存扣减用消息队列。特点是削峰、解耦但要考虑消息丢失和重复消费。批处理数据仓库每日从业务库拉取增量数据用批处理。特点是量大、延迟高按天或按小时调度。数据库直连仅在数据仓库内部层间使用应用系统之间不建议直连数据库。应用直连数据库是耦合后续技术架构没法做容灾和限流。交互场景推荐方式关键参数风险点实时校验库存同步接口超时 3s重试 1 次下游慢导致线程池耗尽订单状态通知异步消息分区数、消费组、重试次数消息积压、重复消费日增量入仓批处理调度周期、任务超时、失败重跑源表无更新时间字段导致漏数主数据分发异步消息批量拉取版本号、订阅方列表版本冲突、订阅方漏接这层决策直接影响技术架构选同步接口的地方要设计熔断降级选异步消息的地方要上消息队列选批处理的地方要准备调度平台。所以我在应用架构评审时会要求每一条连接线上面标注“接口类型 数据内容 大约频率”。标不出来的连接线就是拍脑袋画的。另外应用架构里还得标出每个应用的数据消费来源。一个应用如果依赖数据仓库出报表但数据链路里没有日志和变更捕获那这条链路就是断的。技术架构落地时最先要补的就是这些断点。4. 技术架构设计组件选型、容量估算与 SLA 分级的顺序技术架构经常是第一个开画的却是最后一个该画的。数据架构决定了要存什么、应用架构决定了要传什么技术架构只需要回答怎么存、怎么传、怎么算。顺序反了就会出现为了用某个组件硬改数据模型的事。这一章讲三个动作选型、估算、分级。4.1 计算与存储选型跟着数据特征走别跟热度走选型我先看数据特征而不是看技术热度。数据特征是数据量、实时性、查询模式、写入模式。DWD 层做大宽表关联典型场景是“多表 join 全表扫描”适合用 MPP 引擎ADS 层支撑高并发报表查询单次查询量不大但并发高适合用关系型数据库加合适索引ODS 层存历史快照、很少更新用对象存储加分区表就够了。日志类数据写入量大、读取以时间范围为主选择列式存储更划算。数据层面典型数据特征推荐选型方向选型参数ODS海量、少更新、按时间查对象存储/分区表保留周期、压缩格式、生命周期规则DWD多表关联、复杂清洗MPP 引擎节点数、并行度、内存与磁盘配比DWS固定维度汇总、吞吐高MPP 或列式存储预计算策略、物化视图频率ADS高并发、低延迟关系型数据库连接池、慢查询阈值、读写分离这里最容易犯的错是“一听分布式就上”。数据量只有几千万行、一天增量几百万条用单机关系型数据库加分区表完全能扛住运维成本却低一个数量级。我做方案时给过某团队一个判断标准日增数据小于 2000 万行、宽表 join 不超过三张先别引分布式组件等真的出现“单机 CPU 打满、加索引也救不回来”再升级后患小得多。选型评审要加一道“运维准入门槛”这个组件团队里有人能独立排查问题吗没有就选托管版或换简化方案。技术架构的复杂度是逐步叠加的不是一步到位的。4.2 容量估算与部署形态先把峰值和冗余算清楚再买机器容量估算不是拍脑袋是数据架构的量化结果。我养成的习惯是先算存储再算计算最后算网络。存储容量公式大概是日增数据量 × 保留周期 × 副本数 × 膨胀系数。膨胀系数考虑索引、临时文件和压缩率波动一般取 1.5 到 2。假设订单表日增 500GB保留 180 天副本 2 份膨胀系数 1.8那么存储需求约为 500GB × 180 × 2 × 1.8 324TB。这个数字用于决定集群规模评估周期是按三年算。计算项输入参数示例结果存储容量日增、保留周期、副本、膨胀系数500GB×180×2×1.8324TB计算资源高峰期作业并发、单任务资源、冗余20 作业×8GB×2 冗余320GB 内存网络带宽峰值同步数据量、时间窗口200GB/小时约 450Mbps部署形态上私有化与云原生的取舍要看数据主权和运维能力。私有化意味着自己扛机房、网络、硬件故障云原生则要接受依赖云厂商的运维边界。没有绝对对错只是取舍。SLA 分级反而比部署形态更能体现技术架构的成熟度ODS 层允许 T1 加载SLA 可以定为 99.9%ADS 层支撑实时报表SLA 要提到 99.99%。不同数据层用不同 SLA成本和运维精力才能花在刀刃上。我会在方案里给每类组件配一张“SLA 登记表”写清楚可用性要求、备份策略、恢复时间目标。这样后续故障演练才有的放矢。技术选型有些时候确实像玄学同样规模的数仓有人三台机器跑得欢有人二十台还在调优。差别往往不在组件本身而在容量算没算清楚。5. 三架构联合设计最容易翻车的五个场景与排查清单数据、应用、技术三条线分开看都好理解难在拉通。这一章是血泪经验五个翻车场景我都经历过或亲眼看过按“现象、原因、解决”写出来你可以直接当排查清单用。5.1 主题域按部门划分跨域打通成了口号现象数据仓库建好了营销域、生产域、财务域各自报表都能跑但一做跨域分析比如“某产品的交付成本与营销投入对比”数据就对不上。原因当初主题域是让各部门自己提需求“按部门切谁都满意”导致的后果。跨域数据没有主数据关联统一编码也没建立。解决先建主数据模型至少把客户、物料、供应商的编码统一再划主题域每个主题域指定 ownercross-domain 的模型变更必须过架构评审不允许部门自己说了算。5.2 应用架构只画系统框图不标数据关系现象评审会上几十个系统排得整整齐齐评审过了落地时却说不清“订单数据是哪个系统生产的”。原因沿用了老的拓扑图画法只表达系统间有连接不表达数据如何流转。框和线能画好看但没法验证。解决要求每张应用架构图配一张 CRUD 矩阵矩阵里每一行都要有产源。没有 CRUD 矩阵的应用架构图评审可以不通过。数据关系钉死了技术架构才知道哪些接口要重点保障。5.3 技术选型只看热度不看团队运维能力现象引入分布式组件后作业凌晨失败没人能处理业务第二天看不到报表。原因选型时被“大数据能力”打动没评估团队是否具备排障能力。组件本身没坏是没人养得起。解决加一道“运维准入门槛”——选每个组件前回答两个问题团队有没有人读过该组件的官方运维手册故障恢复步骤能不能写出来答不上来就选托管版或者暂时用成熟度更高的简化方案。5.4 数据架构和技术架构各改各的没人拉通现象技术架构升级消息队列下游消费端对接了新集群但数据架构里的数据流图还画着旧链路半年后新人不明白为什么实际链路和图对不上。原因数据架构和应用架构迭代节奏不一致变更没有统一入口。解决把三架构变更纳入同一个架构委员会评审任何一方的变更都要求输出“影响到的数据实体和应用模块”清单。这张清单不交变更不审批。5.5 直接套模板架构设计与业务规模脱节现象参考别家方案把每个组件都铺上对象存储、消息队列、MPP、OLAP、调度平台一应俱全资源开销巨大。原因没做裁剪把模板当标准答案。实际上业务规模、数据量、团队能力都不一样。解决给每个组件写“引入条件”不满足条件则不引入。比如数据量日增不超过多少、并发不超过多少就不上分布式组件。没有引入条件的组件清单不是架构设计是设备采购单。6. 用一张全景图验证三架构是否对齐并把它作为评审底稿最后一个技巧把所有数据实体、应用组件、技术组件塞进一张全景矩阵里验证。纵向是数据主题域与核心数据实体横向是应用模块和技术组件。交叉格里标注关系C 代表该应用生产此数据R 代表消费S 代表某个技术组件存储此数据。然后按三条规则逐行检查。规则一每个数据实体至少有一个 C、一个 R、一个 S。缺 C 说明数据源头没接缺 R 说明数据建了没人用缺 S 说明存储没落实。规则二每个应用模块至少涉及一个数据实体全是虚线关系的模块要问它存在的理由。规则三每个技术组件至少被一条数据链路引用完全没被引用的组件可以直接砍掉。这张矩阵比任何文字评审意见都讲得清问题。我自己最早做规划时习惯先画技术架构以为确定了选型再倒推数据模型结果画完返工三个月——每换一个组件数据流图就重画一遍应用集成方式也得跟着改。后来改成数据架构先行先填 CRUD 矩阵再定功能域最后做技术选型一次通过率高了很多。52 页的方法论里最值钱的不是某几个框架图而是“数据先行、应用承接、技术兜底”这个顺序。希望帮到你。本文还有配套的精品资源点击获取
![打卡信奥刷题（3642）用C++实现信奥题 P12024 [USACO25OPEN] It‘s Mooin‘ Time III B](http://pic.xiahunao.cn/yaotu/打卡信奥刷题（3642）用C++实现信奥题 P12024 [USACO25OPEN] It‘s Mooin‘ Time III B)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
