很多人第一次做数据架构，最容易犯的错误，就是一上来先画技术图。 左边放 ERP、CRM、MES、OA，中间放 Kafka、Flink、Spark、数据仓库，右边再接 BI、大屏、AI。 看上去很完整。 但真正开始建设以后，很快就会遇到一堆问题： 为什么订单要实时，财务凭证却可以 T+1？ 为什么客户数据要统一，日志数据却可以直接进湖？ 为什么有的数据要进入 DWD，有的数据可以直接提供给应用？ 为什么同样叫"销售额"，财务、销售和经营看板算出来不一样？ 这些问题，靠多画几个技术组件解决不了。 因为数据架构真正要回答的是： 企业产生了哪些核心数据，这些数据应该如何组织、流动、加工、管理和使用。 所以真正的数据架构设计，通常应该沿着这样一条路径展开： 业务架构 → 应用架构 → 数据架构 → 技术架构。 技术其实应该放在最后。
一、数据架构的起点，不是数据库，而是业务架构 很多数据架构做不好的根源，是一开始视角就放错了。 技术人员习惯问： "企业现在有哪些数据库？" 但真正应该先问的是： "企业到底在做哪些业务？" 假设是一家制造企业。 从业务上看，可能存在： 研发、采购、生产、库存、销售、交付、售后、财务。 继续往下拆，采购又可以分成： 采购申请 → 询价 → 采购订单 → 到货 → 入库 → 对账 → 付款。 这条流程运行过程中，会不断产生业务对象： 供应商、物料、采购订单、入库单、发票、付款单。 到了这里，数据架构真正的基础才开始出现。 所以设计数据架构时，第一张图更应该是一张： 业务能力—业务流程—业务对象关系图。
比如： 客户产生订单； 订单关联商品； 商品带来库存变化； 发货形成销售收入； 采购和生产形成成本； 最终进入财务核算和经营分析。 这条链路梳理清楚以后，你会发现： 系统是会变化的，业务对象相对稳定。 CRM 可以换，ERP 可以升级，WMS 可以重新建设。 但客户、商品、订单、库存这些对象不会因为系统替换就消失。 因此成熟的数据架构通常还会进一步划分数据域。 零售企业可以拆成： 客户域、商品域、交易域、库存域、供应链域、财务域。 以后再接入一套新系统时，首先要判断的就不再是"这张表放哪里"，而是： 它属于哪个业务域？描述哪个业务对象？与现有数据是什么关系？ 这一步做完，才真正进入数据接入。 因为现实里的业务对象往往散落在 ERP、CRM、数据库、API、Excel 文件等不同位置。通过 FineDataLink 5.0 可以先把这些分散来源接入，再按照前面已经划分好的客户域、交易域、供应链域继续处理。这样源系统再多，后面的数据组织方式仍然能够沿着同一套业务逻辑展开。
二、第二步：找到每个业务对象的"唯一解释权" 业务对象找出来以后，还远远不够。 因为现实企业里最常见的情况是： 同一个对象，在五套系统里有五个版本。 例如同一家客户。 CRM 记录的是： 上海某某科技有限公司 ERP 里可能叫： 某某科技 合同系统保存的是统一社会信用代码； 销售自己维护的 Excel 里又简称为： 上海某某。 如果直接把这些数据汇总起来，系统很可能认为这是四个客户。 所以数据架构必须继续回答一个关键问题： 同一个业务对象，到底以谁为准？ 这就是权威数据源。
例如： 客户基础信息 → CRM； 商品基础信息 → ERP； 库存数量 → WMS； 支付状态 → 支付系统； 会计凭证 → 财务系统。 这里真正需要设计的，不只是"数据存在哪里"。 还包括： 谁创建？ 谁修改？ 谁审批？ 谁负责质量？ 哪个系统具有最终解释权？ 发生冲突时按照什么规则处理？ 很多所谓的数据质量问题，最后追下去会发现，其实是数据责任没有划清。 比如客户地址不一致。 技术当然可以写规则判断哪个为空、哪个更新时间更晚。 但更关键的问题是： 哪个系统有资格修改客户正式地址？ 如果这个问题没有答案，再复杂的数据清洗也只能暂时修补。 所以完整的数据架构里，还应该有一层： 数据责任架构。 核心数据至少要明确： 业务归属、权威来源、责任人、更新机制、质量规则和使用范围。 这一步做得越清楚，后面的主数据、数据治理和指标统一越容易推进。
三、第三步：不要急着分 ODS、DWD，先确定数据模型 很多企业一建数仓，第一句话就是： 我们按照 ODS、DWD、DWS、ADS 四层建。 然后开始建表。 但分层其实不应该成为数据架构的第一步。 在分层之前，更重要的是明确： 企业到底有哪些事实、维度和业务关系。 仍然以销售业务为例。 核心事实可能包括： 订单事实、支付事实、发货事实、退款事实。 核心维度可能包括： 客户、商品、门店、组织、区域、渠道、日期。
一张订单产生以后，它并不是孤立的一条记录。 它可能继续关联： 客户是谁 → 买了什么商品 → 来自哪个渠道 → 哪个门店成交 → 是否发货 → 是否退款 → 最终贡献多少收入和毛利。 如果这些业务关系没有梳理清楚，仅仅按照源系统复制表，就很容易得到一个非常典型的数据仓库： 表很多，但分析很难。 因为源系统的数据模型通常服务于交易。 数据仓库的数据模型则需要服务： 统计、分析、追溯和决策。 因此数据进入平台以后，通常还要经历： 字段标准化、类型转换、空值处理、编码映射、表关联、过滤、拆分、聚合以及业务规则计算。 到了这一步，FineDataLink 5.0 里的 ETL/ELT 开发就可以继续接上前面的数据接入，把来自不同系统的客户、订单、商品数据逐步整理到统一模型里。源表结构依然可以保留，后面的分析层则按照业务事实重新组织，数据仓库也不会被源系统表结构牵着走。
这时候再看 ODS、DWD、DWS、ADS，就会清楚很多。 ODS 解决的是：原始数据留存 DWD 解决的是：统一业务事实。 DWS 解决的是：主题数据复用。 ADS 解决的是：具体应用交付。 四层真正要控制的是不同处理阶段的数据职责。 如果一张表放进 DWS，却没人知道它服务哪个主题； 或者一张 ADS 表被十几个系统反复依赖； 那说明分层已经开始失去边界。 所以成熟的数仓设计，除了定义"这一层放什么"，还要定义： 这一层不应该放什么。
四、第四步：数据架构必须同时设计"数据流" 只设计数据模型还不够。 因为企业里的数据一直在流动。 因此完整的数据架构，至少应该同时画两类图： 数据静态结构图 + 数据流向图。 静态结构图告诉你： 客户、订单、商品、库存之间是什么关系。 数据流向图则回答： 这些数据从哪里产生，经过哪里，最后去了哪里。
例如一笔线上订单： 订单系统生成数据 ↓ 采集订单变化 ↓ 进入 ODS ↓ 清洗形成订单事实 ↓ 关联客户、商品、渠道 ↓ 计算销售额、成本、毛利 ↓ 进入销售主题域 ↓ 提供给 BI、经营系统和算法模型 画到这里以后，很多技术问题才能真正判断。 比如： 哪些数据需要实时？ 不要先问： "我们要不要上实时数仓？" 应该先问： "这个业务最多允许数据晚多久？" 库存预警可能只能接受分钟级延迟； 订单监控可能要求秒级； 经营日报小时级就够； 财务月报 T+1 也完全能够满足需求。 所以实际项目里，经常是实时和批量两种节奏同时存在。 订单、库存、支付状态这类变化频繁的数据，可以在 FineDataLink 5.0 里通过实时管道持续获取变化；组织架构、基础配置、历史明细等更新频率较低的数据，则按照固定周期同步。不同类型的数据按照自己的时效要求进入后续加工链路，整套架构也更容易控制复杂度和运行成本。
而且实时架构真正难的，其实不只是"快"。 它还要面对很多长期运行问题： 任务失败怎么办？ 网络中断以后从哪里继续？ 源表结构发生变化怎么办？ 数据积压怎么发现？ 错过的数据怎么补？ 所以数据流设计里，还必须把： 调度、监控、重试、断点恢复、补数、校验 一起考虑进去。 这些能力如果等到系统上线以后再补，成本往往会非常高。
五、第五步：指标体系其实也是数据架构的一部分 很多企业的数据架构图里只画： 数据库、数仓、数据湖、接口。 很少画指标。 但到了企业真正使用数据的时候，最容易产生争议的往往恰恰是指标。 例如： 销售额。 销售部门可能按订单金额计算； 财务按照确认收入计算； 经营分析剔除退款订单； 电商部门又按支付金额统计。 于是出现一个非常常见的场景： 数据库没有坏； ETL 没有报错； 报表也成功刷新。 但四个部门看到的销售额就是不一样。
原因就在于： 底层数据统一以后，业务语义仍然可能没有统一。 所以数据架构还需要继续往上设计一层： 统一指标和语义。 一个核心指标至少应该明确： 指标名称； 业务定义； 计算公式； 统计粒度； 时间口径； 维度范围； 数据来源； 责任部门； 更新频率。
例如"客户数"不能只写： COUNT(customer_id)。 真正需要定义的是： 注册客户？ 交易客户？ 活跃客户？ 付费客户？ 统计自然月还是滚动 30 天？ 客户去重按照手机号、客户 ID 还是统一客户编码？ 这些规则如果不明确，SQL 写得再正确，数字也可能没有统一意义。 更进一步，指标之间还需要建立关系。 比如： 利润 = 收入 - 成本 - 费用 收入继续拆成： 销量 × 单价 销量再往下拆： 客户数 × 购买频次 × 单次购买量。 到了这一层，数据架构已经开始和经营分析体系真正连接起来。 因为业务人员看到利润下降时，可以沿着指标关系继续定位到： 收入下降？ 成本增加？ 客户减少？ 销量下降？ 价格变化？ 这才是统一数据模型真正发挥作用的地方。
六、第六步：数据不能停在数仓里，还要设计"怎么出去" 很多数据平台建设到数仓完成就结束了。 数据已经： 采集了； 清洗了； 建模了； 指标也算出来了。 但业务系统突然提出： "我想实时获取客户等级。" 于是技术人员再写一个接口。 供应链系统又说： "我要查询供应商评分。" 再写一个接口。
营销系统说： "我要每天拿一批高价值客户。" 再开发一个同步任务。 几年以后就会形成大量： 系统对系统、库对库、表对表的点对点链路。 而且没人敢轻易修改。 所以数据架构还有一个经常被忽视的环节： 数据出口。 企业的数据消费者可能包括： BI； 经营大屏； 业务系统； 移动应用； AI Agent； 算法模型； 外部合作方。 不同对象需要的数据交付方式并不一样。 有的需要直接查询数据集； 有的需要批量同步； 有的需要 API； 有的需要消息订阅。 因此数据平台从一开始就应该把消费方式设计进去。 前面经过 FineDataLink 5.0 清洗和加工的数据，到这里还可以继续通过数据服务发布成 API，供 CRM、业务应用或者其他下游系统调用。这样从数据源、加工链路到最终业务使用之间能够形成相对连续的链路，也能减少后来不断补写点对点接口的情况。
当数据服务越来越多以后，还要继续考虑： 接口由谁使用？ 哪些字段允许暴露？ 调用频率有没有限制？ 上游字段变化会影响哪些接口？ 一个服务下线会影响哪些业务？ 做到这里，数据架构才真正形成完整闭环： 数据生产 → 数据采集 → 数据加工 → 数据管理 → 数据服务 → 数据消费。
七、最后一步，才是真正的技术架构 前面的业务对象、数据域、模型、数据流、指标和消费方式都确定以后，最后才轮到： 技术选型。 这时候很多问题自然会有答案。 需不需要 Kafka？ 看有没有高吞吐实时数据和消息解耦需求。 需不需要 Flink？ 看有没有复杂实时计算。 需不需要 ClickHouse？ 看分析查询规模和响应要求。 需不需要数据湖？ 看企业有没有大量日志、文件、半结构化数据，以及历史原始数据保存需求。 需不需要湖仓一体？ 看企业的数据规模、使用场景和团队能力。 技术架构最怕的一种设计方式，就是： 先确定技术，再寻找场景。 别人都在用 Kafka，我们也上一套。 现在流行湖仓，我们也做湖仓。 AI 时代强调实时，所以全部改实时。 这样的架构看上去先进，最后却可能带来： 维护成本高； 组件依赖复杂； 故障定位困难； 人员学习成本增加； 真正使用率却不高。
所以技术选型至少要同时考虑五个变量。 数据规模 百万级和百亿级数据，不需要使用同一套架构。 时效要求 T+1、小时级、分钟级、秒级，对应的是不同链路。 查询特征 明细查询、聚合分析、全文检索、实时计算、机器学习，对底层能力要求都不同。 稳定性 不能只考虑系统正常运行时怎样工作。 还要提前设计： 任务失败、服务宕机、数据异常、备份恢复和灾难切换。 团队能力 一套理论上很先进、但团队长期维护不了的架构，很难真正发挥作用。 因此好的技术架构应该做到： 今天能够稳定运行，业务增长后还能扩展，出现问题时也能够快速定位和恢复。
写在最后 如果把整个数据架构设计过程压缩下来，其实可以变成这样一条路线： 业务战略 ↓ 业务能力与业务流程 ↓ 核心业务对象 ↓ 数据域与权威数据源 ↓ 统一数据模型 ↓ 数仓分层与数据加工 ↓ 数据流与时效策略 ↓ 指标与业务语义 ↓ 数据服务与消费 ↓ 技术架构 这也是为什么真正的数据架构设计，很少是技术部门关起门来画一张图就能完成的。 它同时涉及： 业务、应用、数据和技术。 业务架构告诉我们： 企业到底在做什么。 应用架构告诉我们： 这些事情目前由哪些系统支撑。 数据架构继续回答： 这些系统产生的数据应该怎样重新组织。 最后技术架构才解决： 用什么技术把这一整套体系真正跑起来。 如果顺序反过来，一开始就围绕数据库、中间件、实时计算和各种技术组件设计，最终很容易得到一套"技术上什么都有"的平台。 但业务真正问起： 客户到底有多少？ 这个销售额为什么和财务不一致？ 一笔订单从哪里来？ 这个指标变化以后影响哪些报表？ 新的业务系统接进来应该放在哪里？ 依然没人能够很快说清楚。 所以衡量一套数据架构好不好，不能只看架构图复杂不复杂，也不能只看用了多少流行技术。 更应该看几个实际问题： 业务对象能不能统一识别？ 核心数据有没有明确来源？ 指标口径能不能解释清楚？ 数据链路出了问题能不能追踪？ 新的业务变化能不能继续接入？ 如果这些问题都能回答清楚，这套架构才真正具备长期使用价值。 因为数据架构最终解决的，是让企业的业务事实、数据流转和技术体系，能够沿着同一套逻辑持续运转。
