1. 为什么数据架构是数据管理体系的骨架
翻到《DAMA数据管理知识体系指南》数据架构这一章的时候，我第一反应是：终于讲到最容易被忽略、但又最要命的部分了。前面几章聊数据治理、数据质量，多少还能靠流程和制度去推动，但数据架构这个东西，一旦缺位，后面所有的数据管理动作都会变成打补丁。我见过太多团队，数据治理做得热热闹闹，元数据也采了，质量规则也配了，结果一问“我们的客户主数据到底以哪个系统为准”，全场沉默。这就是架构没立住。
数据架构在DAMA体系里的定位很特殊，它不像数据建模那样直接产出表结构，也不像数据存储那样关心用哪种数据库，它解决的是一个更高维度的问题：数据在企业里怎么组织、怎么流动、怎么被不同系统共享和复用。你可以把它理解成城市规划——不是去盖某一栋楼，而是决定道路怎么修、管网怎么铺、商业区和住宅区怎么划分。楼可以拆了重建，但路网一旦定型，改起来伤筋动骨。
这一章我读了三遍，第一遍觉得概念太多，第二遍开始把概念往自己做过的项目上套，第三遍才真正理解为什么DAMA把数据架构放在数据管理职能的第二位（仅次于数据治理）。因为数据治理定的是“谁说了算”，数据架构定的是“东西怎么摆”，这两件事定不下来，后面的开发、运维、分析全是空中楼阁。
适合读这部分内容的人，我觉得有三类：一是正在做数据中台或数据平台规划的技术负责人，二是被跨系统数据不一致折磨过的数据开发工程师，三是想从业务侧理解“为什么数据老对不上”的产品或运营同学。不管你属于哪一类，数据架构这一章都值得反复啃。
2. 数据架构的核心概念拆解
2.1 数据架构到底包含什么
DAMA给数据架构的定义是：识别企业的数据需求，并设计满足这些需求的主蓝图。这个定义听起来很虚，但拆开来看其实很实在。它包含几个层次的东西：
- 当前状态描述：企业现在有哪些数据、存在哪里、怎么流动、谁在用。这一步很多团队直接跳过，上来就画目标架构，结果目标架构跟现实脱节，落不了地。
- 目标状态设计：业务战略需要数据架构支撑什么能力，未来数据应该怎么组织。这一步要跟业务架构对齐，不能IT自己闭门造车。
- 演进路线图：从当前状态到目标状态，分几步走、每步做什么、优先级怎么排。没有路线图的目标架构就是一张废纸。
我自己的经验是，当前状态描述这一步最容易被低估。很多架构师觉得“我还不了解我们自己的系统吗”，但实际上，当你真的把数据流向图画出来，把每个系统的数据实体列出来，把接口关系标出来，你会发现大量“我以为我知道但其实不知道”的东西。比如某个字段到底是在源系统生成还是在中间层加工出来的，比如两个系统之间到底有没有实时同步，这些细节不落到纸面上，永远是一笔糊涂账。
2.2 数据架构与企业架构的关系
DAMA在这一章里反复强调一个观点：数据架构不是孤立存在的，它是企业架构的一部分。企业架构通常包括业务架构、数据架构、应用架构和技术架构四个层面。业务架构定的是“做什么”，数据架构定的是“用什么数据做”，应用架构定的是“用什么系统做”，技术架构定的是“用什么技术支撑”。
这四个层面的关系是：业务架构驱动数据架构和应用架构，数据架构和应用架构共同支撑业务架构，技术架构为上面三层提供基础设施。数据架构处在中间位置，承上启下。
我踩过的一个坑是：有一次做数据平台规划，我们只看了业务部门提的需求，没有去梳理业务架构的顶层设计，结果平台建好了，发现业务架构调整了，原来按老业务线设计的数据模型全部要改。后来我学乖了，做数据架构之前，一定先找业务架构的负责人聊，搞清楚未来两三年业务往哪个方向走，数据架构才有前瞻性。
2.3 数据架构的关键交付物
DAMA列了几类核心交付物，我结合实际项目经验说一下哪些是真正必须的：
| 交付物 | 必要性 | 实际用途 |
|---|---|---|
| 数据实体关系图 | 高 | 理清核心业务对象之间的关系，是后续建模的基础 |
| 数据流向图 | 高 | 追踪数据从产生到消费的全链路，排查问题时必备 |
| 数据分布矩阵 | 中 | 标明每个数据实体在哪些系统中存在，识别冗余和不一致 |
| 数据架构路线图 | 高 | 指导分阶段实施，避免一次性改造风险过大 |
| 数据标准与规范 | 中 | 统一命名、编码、格式，减少集成成本 |
数据流向图是我用得最多的。每次遇到“这个报表的数据为什么跟那个系统对不上”的问题，第一件事就是翻数据流向图，看数据在哪个环节被加工过、被过滤过、被转换过。很多时候问题就出在某个中间环节的逻辑上，没有流向图，你只能一个系统一个系统地猜。
提示：数据流向图不要只画系统级别，要细化到关键数据实体级别。系统级别的流向图只能告诉你“A系统给B系统传数据”，但传的是哪些数据、经过什么加工，才是排查问题的关键。
3. 数据架构的实操方法与落地步骤
3.1 从业务出发梳理数据需求
数据架构的起点一定是业务需求，不是技术选型。我见过太多团队一上来就讨论“用Hadoop还是用MPP”“建数据湖还是建数据仓库”，这些是技术架构的问题，不是数据架构的问题。数据架构首先要回答的是：业务需要什么数据、这些数据从哪来、要支撑什么决策和操作。
具体怎么做？我的方法是三步走：
第一步，梳理业务流程。把企业的核心业务流程列出来，比如订单到收款、采购到付款、线索到成交。每个流程里，识别关键的业务事件和业务对象。比如订单流程里，业务事件有“下单”“支付”“发货”“退货”，业务对象有“订单”“商品”“客户”“支付记录”。
第二步，识别数据需求。针对每个业务事件和业务对象，问几个问题：这个事件产生什么数据？这个对象需要什么属性？这些数据谁用、用来做什么？这一步的输出是一张数据需求清单，不需要很精细，但要覆盖核心业务。
第三步，映射到数据实体。把数据需求归类到数据实体上，比如“客户名称”“客户联系方式”“客户等级”都归到“客户”这个实体。这一步的输出是初步的数据实体清单和关系。
这三步做完，你就有了数据架构的“需求侧”输入。接下来才是“供给侧”的设计。
3.2 当前状态盘点：摸清家底
当前状态盘点是数据架构工作里最枯燥但最重要的环节。我一般从四个维度去盘：
- 系统维度：企业有哪些系统，每个系统负责什么业务功能，系统的技术栈是什么，系统的生命周期处于什么阶段（新建、维护、计划下线）。
- 数据维度：每个系统里有哪些核心数据实体，数据量级多大，数据更新频率如何，数据保留策略是什么。
- 集成维度：系统之间有哪些接口，接口是实时的还是批量的，传输的是什么数据，频率和延迟要求是什么。
- 使用维度：哪些角色在用这些数据，用来做什么（报表、分析、操作），使用频率和重要性如何。
盘点的过程中，我强烈建议用表格来记录，不要只靠脑子记。下面是我常用的一个简化模板：
| 系统名称 | 核心数据实体 | 数据量级 | 更新频率 | 下游系统 | 接口方式 |
|---|---|---|---|---|---|
| 订单系统 | 订单、客户、商品 | 千万级 | 实时 | 数据仓库、客服系统 | API |
| 客服系统 | 工单、客户 | 百万级 | 实时 | 数据仓库 | 消息队列 |
| 数据仓库 | 汇总指标 | 亿级 | 每日 | BI平台 | 批量导出 |
这个表看起来简单，但填起来会发现很多“不知道”。不知道某个系统的数据量级，不知道某个接口的更新频率，不知道某个数据实体有没有下游在用。这些“不知道”就是架构工作的切入点。
3.3 目标架构设计：从需求到蓝图
目标架构设计不是凭空画图，而是基于当前状态和业务需求，设计一个“应该是什么样”的蓝图。我一般从三个层面去设计：
数据分层设计。数据从产生到消费，通常要经过几个层次：贴源层（ODS）、明细层（DWD）、汇总层（DWS）、应用层（ADS）。每一层的职责不同，贴源层保持与源系统一致，明细层做清洗和规范化，汇总层做轻度聚合，应用层面向具体场景做定制。分层的目的是让数据流动有章可循，避免“一锅粥”式的加工。
数据主题域设计。把企业数据按主题域划分，比如客户域、产品域、交易域、财务域、供应链域。每个主题域有明确的数据边界和责任人。主题域划分的好处是，当业务部门提需求时，你能快速定位到相关数据在哪个域、由谁负责。
数据集成设计。定义系统之间的数据集成方式：哪些数据实时同步，哪些批量抽取，哪些通过消息队列异步传输。集成的原则是：能实时不批量，能推不拉，能标准化不定制化。但也要考虑成本和复杂度，不是所有数据都需要实时。
注意：目标架构设计不要追求“大而全”，要抓住核心矛盾。我见过一个项目，目标架构画了上百个数据实体、几十个集成关系，结果实施的时候根本推不动。后来砍到只做客户域和交易域，反而顺利上线了。架构是演进来的，不是一步到位的。
3.4 演进路线图：分步实施
从当前状态到目标状态，中间需要一条演进路线。路线图的核心是排优先级，我一般用两个维度来排：业务价值和实施难度。业务价值高、实施难度低的优先做，业务价值高但实施难度大的分阶段做，业务价值低的不做或延后。
路线图要具体到每个阶段的目标、交付物、时间窗口和责任人。比如：
- 第一阶段（1-3个月）：完成客户域数据整合，建立客户主数据管理，解决客户信息不一致问题。
- 第二阶段（4-6个月）：完成交易域数据整合，建立交易明细数据仓库，支撑交易分析。
- 第三阶段（7-12个月）：完成产品域和财务域整合，建立企业级数据仓库，支撑跨域分析。
每个阶段结束后要有明确的验收标准，比如“客户信息一致率达到95%以上”“交易报表出数时间从T+3缩短到T+1”。没有验收标准的路线图就是许愿池。
4. 数据架构落地中的常见坑与排查技巧
4.1 架构与开发脱节
这是最常见的问题。架构师画了一堆图，开发团队该怎么做还怎么做，架构文档写完就锁进柜子里。原因通常是：架构设计没有考虑开发的实际约束，或者架构师没有跟开发团队充分沟通。
我的解法是：架构设计阶段就让开发骨干参与，让他们提意见。架构评审的时候，不是架构师单方面宣讲，而是开发团队来挑刺。架构文档要轻量化，不要写几百页的Word，用几张核心图加关键说明就够了。最重要的是，架构要跟开发流程绑定，比如代码评审的时候要看是否符合数据架构规范，新系统上线的时候要检查数据流向是否与架构图一致。
4.2 数据流向图与实际不符
数据流向图是排查问题的关键工具，但如果图跟实际不符，反而会误导排查方向。我遇到过好几次，按流向图去查，查了半天发现图上标的接口早就改了，或者某个中间环节根本不存在。
保持流向图准确的唯一方法是：把维护流向图变成开发流程的一部分。每次接口变更、每次数据加工逻辑调整，都要同步更新流向图。可以指定一个人负责，但更靠谱的是把它写进变更流程里，不更新流向图就不让上线。听起来很麻烦，但比出了问题抓瞎强。
4.3 主题域划分争议
主题域划分经常引发争议，因为不同部门对“数据应该归谁管”有不同看法。比如客户数据，销售部门觉得归他们管，客服部门觉得归他们管，市场部门也觉得归他们管。
我的经验是：主题域划分不要按部门来分，要按数据本身的属性来分。客户域就是客户域，不管哪个部门用，数据的定义、标准、质量规则应该统一。至于谁负责维护，可以指定一个“数据管家”角色，但不改变主题域的划分。如果按部门分主题域，最后一定会出现“你的客户和我的客户不是同一个客户”的荒唐局面。
4.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 | 解决思路 |
|---|---|---|---|
| 跨系统数据不一致 | 数据源头不统一、同步延迟、加工逻辑差异 | 查数据流向图，定位差异环节 | 建立主数据管理，统一源头 |
| 报表出数慢 | 数据分层不合理、加工链路太长 | 查数据加工链路，看是否有冗余环节 | 优化分层，减少不必要的中间表 |
| 新需求响应慢 | 数据模型僵化、集成方式不灵活 | 查数据模型和集成设计 | 引入更灵活的数据建模方法 |
| 数据质量差 | 源头录入不规范、加工过程无校验 | 查数据质量规则和校验点 | 在关键环节增加质量校验 |
| 架构落地难 | 路线图太激进、缺乏业务支持 | 查路线图优先级和资源投入 | 调整优先级，先做高价值易落地的 |
提示：排查数据问题时，永远从源头开始查，不要从结果倒推。从源头顺着数据流向一路查下来，比从结果反推原因效率高得多。
5. 数据架构与其他数据管理职能的协同
5.1 与数据建模的关系
数据架构和数据建模是上下游关系。数据架构定的是“有哪些数据实体、它们之间是什么关系”，数据建模定的是“每个实体的属性是什么、主键外键怎么设计、范式怎么用”。架构是宏观的，建模是微观的。
实际工作中，这两个角色经常由不同的人担任。架构师关注全局，建模师关注细节。两者之间的衔接点是数据实体清单。架构师输出实体清单和关系，建模师基于此做逻辑模型和物理模型。如果衔接不好，就会出现“架构师说要有客户实体，建模师建出来的客户表跟架构图对不上”的情况。
5.2 与数据治理的关系
数据治理定的是“谁对数据负责、数据标准是什么、数据质量怎么管”，数据架构定的是“数据怎么组织、怎么流动”。两者是互补的。没有治理的架构，就像没有交通规则的马路，路修得再好也会堵。没有架构的治理，就像没有地图的交通管理，管得再严也管不到点子上。
我自己的体会是：数据治理和数据架构最好同步推进。治理定标准，架构落标准。比如治理说“客户名称必须统一”，架构就要设计客户主数据的存储和分发机制，确保所有系统用的都是同一份客户名称。
5.3 与数据存储、数据安全的关系
数据架构决定了数据存在哪里、怎么流动，数据存储决定了用什么技术来存，数据安全决定了谁能访问、怎么保护。三者是紧密关联的。架构设计的时候就要考虑存储的选型和安全的约束，不能等架构定完了再说“这个数据不能放那里”“那个数据不能传这里”。
我见过一个项目，架构设计的时候没考虑数据安全要求，把敏感数据放到了一个权限管控比较弱的系统里，后来安全审计发现了，不得不重新调整架构，浪费了大量时间。所以架构设计阶段一定要拉上安全和运维的人一起评审。
6. 我个人的实操心得
数据架构这件事，我最大的体会是：不要追求完美，要追求可用。我见过太多架构师，花几个月画了一张无比精美的目标架构图，结果没人看得懂，也没人用。架构的价值不在于图有多漂亮，而在于能不能指导实际工作、能不能解决实际问题。
另一个体会是：架构是长出来的，不是画出来的。你不可能一开始就设计出完美的架构，只能在演进中不断调整。所以路线图比目标架构更重要，因为路线图告诉你每一步怎么走，而目标架构只是一个方向。
还有一个很实在的建议：做数据架构一定要跟业务的人多聊。不要只跟IT的人聊，要跟真正用数据的人聊。他们可能不懂什么实体关系图、什么数据分层，但他们知道“我每天要花两个小时对数据”“这个报表的数跟我手工算的对不上”。这些痛点就是架构要解决的问题。
最后分享一个我常用的技巧：用“数据旅程”的方式来验证架构。选一个核心业务场景，比如“客户下单到收货”，然后追踪这个场景里数据从产生到消费的完整旅程。看看数据经过了哪些系统、被哪些人加工过、在哪些环节可能出问题。如果这个旅程走不通，说明架构还有漏洞。这个方法比看静态的架构图有效得多，因为它模拟了真实的数据流动。
数据架构这一章的内容远不止我上面写的这些，DAMA书里还有关于数据架构工具、数据架构治理、数据架构师角色等很多细节。但核心的东西我觉得就是这些：从业务出发、摸清家底、设计蓝图、分步实施、持续演进。把这五件事做好，数据架构就不会差到哪里去。
