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%以上”“交易报表出数时间从T3缩短到T1”。没有验收标准的路线图就是许愿池。4. 数据架构落地中的常见坑与排查技巧4.1 架构与开发脱节这是最常见的问题。架构师画了一堆图开发团队该怎么做还怎么做架构文档写完就锁进柜子里。原因通常是架构设计没有考虑开发的实际约束或者架构师没有跟开发团队充分沟通。我的解法是架构设计阶段就让开发骨干参与让他们提意见。架构评审的时候不是架构师单方面宣讲而是开发团队来挑刺。架构文档要轻量化不要写几百页的Word用几张核心图加关键说明就够了。最重要的是架构要跟开发流程绑定比如代码评审的时候要看是否符合数据架构规范新系统上线的时候要检查数据流向是否与架构图一致。4.2 数据流向图与实际不符数据流向图是排查问题的关键工具但如果图跟实际不符反而会误导排查方向。我遇到过好几次按流向图去查查了半天发现图上标的接口早就改了或者某个中间环节根本不存在。保持流向图准确的唯一方法是把维护流向图变成开发流程的一部分。每次接口变更、每次数据加工逻辑调整都要同步更新流向图。可以指定一个人负责但更靠谱的是把它写进变更流程里不更新流向图就不让上线。听起来很麻烦但比出了问题抓瞎强。4.3 主题域划分争议主题域划分经常引发争议因为不同部门对“数据应该归谁管”有不同看法。比如客户数据销售部门觉得归他们管客服部门觉得归他们管市场部门也觉得归他们管。我的经验是主题域划分不要按部门来分要按数据本身的属性来分。客户域就是客户域不管哪个部门用数据的定义、标准、质量规则应该统一。至于谁负责维护可以指定一个“数据管家”角色但不改变主题域的划分。如果按部门分主题域最后一定会出现“你的客户和我的客户不是同一个客户”的荒唐局面。4.4 常见问题速查表问题现象可能原因排查方向解决思路跨系统数据不一致数据源头不统一、同步延迟、加工逻辑差异查数据流向图定位差异环节建立主数据管理统一源头报表出数慢数据分层不合理、加工链路太长查数据加工链路看是否有冗余环节优化分层减少不必要的中间表新需求响应慢数据模型僵化、集成方式不灵活查数据模型和集成设计引入更灵活的数据建模方法数据质量差源头录入不规范、加工过程无校验查数据质量规则和校验点在关键环节增加质量校验架构落地难路线图太激进、缺乏业务支持查路线图优先级和资源投入调整优先级先做高价值易落地的提示排查数据问题时永远从源头开始查不要从结果倒推。从源头顺着数据流向一路查下来比从结果反推原因效率高得多。5. 数据架构与其他数据管理职能的协同5.1 与数据建模的关系数据架构和数据建模是上下游关系。数据架构定的是“有哪些数据实体、它们之间是什么关系”数据建模定的是“每个实体的属性是什么、主键外键怎么设计、范式怎么用”。架构是宏观的建模是微观的。实际工作中这两个角色经常由不同的人担任。架构师关注全局建模师关注细节。两者之间的衔接点是数据实体清单。架构师输出实体清单和关系建模师基于此做逻辑模型和物理模型。如果衔接不好就会出现“架构师说要有客户实体建模师建出来的客户表跟架构图对不上”的情况。5.2 与数据治理的关系数据治理定的是“谁对数据负责、数据标准是什么、数据质量怎么管”数据架构定的是“数据怎么组织、怎么流动”。两者是互补的。没有治理的架构就像没有交通规则的马路路修得再好也会堵。没有架构的治理就像没有地图的交通管理管得再严也管不到点子上。我自己的体会是数据治理和数据架构最好同步推进。治理定标准架构落标准。比如治理说“客户名称必须统一”架构就要设计客户主数据的存储和分发机制确保所有系统用的都是同一份客户名称。5.3 与数据存储、数据安全的关系数据架构决定了数据存在哪里、怎么流动数据存储决定了用什么技术来存数据安全决定了谁能访问、怎么保护。三者是紧密关联的。架构设计的时候就要考虑存储的选型和安全的约束不能等架构定完了再说“这个数据不能放那里”“那个数据不能传这里”。我见过一个项目架构设计的时候没考虑数据安全要求把敏感数据放到了一个权限管控比较弱的系统里后来安全审计发现了不得不重新调整架构浪费了大量时间。所以架构设计阶段一定要拉上安全和运维的人一起评审。6. 我个人的实操心得数据架构这件事我最大的体会是不要追求完美要追求可用。我见过太多架构师花几个月画了一张无比精美的目标架构图结果没人看得懂也没人用。架构的价值不在于图有多漂亮而在于能不能指导实际工作、能不能解决实际问题。另一个体会是架构是长出来的不是画出来的。你不可能一开始就设计出完美的架构只能在演进中不断调整。所以路线图比目标架构更重要因为路线图告诉你每一步怎么走而目标架构只是一个方向。还有一个很实在的建议做数据架构一定要跟业务的人多聊。不要只跟IT的人聊要跟真正用数据的人聊。他们可能不懂什么实体关系图、什么数据分层但他们知道“我每天要花两个小时对数据”“这个报表的数跟我手工算的对不上”。这些痛点就是架构要解决的问题。最后分享一个我常用的技巧用“数据旅程”的方式来验证架构。选一个核心业务场景比如“客户下单到收货”然后追踪这个场景里数据从产生到消费的完整旅程。看看数据经过了哪些系统、被哪些人加工过、在哪些环节可能出问题。如果这个旅程走不通说明架构还有漏洞。这个方法比看静态的架构图有效得多因为它模拟了真实的数据流动。数据架构这一章的内容远不止我上面写的这些DAMA书里还有关于数据架构工具、数据架构治理、数据架构师角色等很多细节。但核心的东西我觉得就是这些从业务出发、摸清家底、设计蓝图、分步实施、持续演进。把这五件事做好数据架构就不会差到哪里去。