数据架构设计的8个核心模块，终于整理全了

很多人第一次接触数据架构，会觉得这件事特别“技术”。

架构图上密密麻麻全是数据库、消息队列、ODS、DWD、DWS、数据湖、数据仓库、API、BI……

但真正做过企业数据项目就会发现：

数据架构最难的，从来不是把这些技术名词画进一张图，而是让数据从产生、流动、加工到最终使用的整条链路真正跑通。

否则很容易出现一种情况：

系统接了一堆，数据也搬了很多，数仓表越来越多，但业务真正要数据的时候，还是找不到、算不准、用不快。

所以设计数据架构之前，最好先理解一个核心逻辑：

数据架构，本质上是在回答“企业的数据应该如何组织和流动”。

• 数据从哪里产生？
• 通过什么方式进入平台？
• 进入以后放在哪里？
• 经过什么规则加工？
• 按照什么模型沉淀？
• 怎样保证口径和质量？
• 最后又通过什么方式提供给业务？

如果你最近正在做数据集成、数据仓库或者数据治理，也可以先看看这套《数据仓库建设解决方案》。

里面覆盖了数据集成、数仓建设、数据治理、数据应用等不少实际场景。尤其是面对企业系统多、数据源杂、链路长的情况，可以对照下面这8个模块去看：每一个技术组件到底解决了哪一层问题，上下游之间又应该怎么衔接。

需要自取：数据仓库建设解决方案 - 帆软数字化资料中心

真正成熟的数据架构，通常绕不开下面8个核心模块。

一、数据源层：先搞清楚“企业到底有哪些数据”

数据架构的起点，从来不是数仓。

而是业务系统。

• ERP里有采购和财务数据；
• CRM里有客户数据；
• MES里有生产数据；
• WMS里有库存数据；

除此之外，还有数据库、API、Excel、CSV、消息队列、日志、IoT设备等各种来源。

所以这一层首先要做的，不是急着接数据，而是建立企业的数据源地图。

至少要回答几个问题：

• 数据来自哪个系统？
• 哪个系统才是权威源？
• 谁负责维护？
• 更新频率是多少？
• 数据量有多大？
• 是否存在唯一主键？
• 哪些数据可以直接读取？
• 哪些数据涉及敏感权限？

尤其要注意“权威源”。

一个客户可能同时存在于CRM、ERP、订单系统和财务系统里。

如果架构设计阶段没有明确到底以谁为准，后面所有关联、统计和指标计算都会埋下冲突。

因此第一层真正要解决的是：

确定数据从哪里来，以及什么数据值得被纳入平台。

当企业的数据源从几个系统扩展到几十个甚至更多以后，数据接入也不能再靠“来一个做一个”。

数据库、API、文件、消息等来源如果各自维护一套采集方式，连接配置、任务管理和后续排查都会越来越分散。FineDataLink 5.0可以把这些不同类型的数据源统一接入，再根据业务对时效的要求配置批量、增量或实时同步。

这样后面新增系统时，重点就从“重新开发怎么接”，转向“这批数据应该以什么方式进入现有数据体系”。

二、数据集成层：解决“数据怎么持续流动”

找到数据源，下一步才是真正让数据流起来。

很多人会把这一层理解成：

把A库的数据搬到B库。

但真正的数据集成远不止复制数据。

首先要决定采用什么方式。

业务基础资料一天同步一次可能就够；

订单、库存等数据可能要求分钟级；

交易、风控等场景甚至需要接近实时。

所以全量、增量、CDC、实时消息，本质上是在解决不同场景对数据新鲜度的要求。

其次还要处理变化。

• 原数据被修改怎么办？
• 删除数据如何识别？
• 同步到一半任务失败，从哪里继续？
• 源表突然新增字段，下游会不会直接报错？

再往后还要考虑业务系统本身的压力。

如果每天凌晨几百张表同时扫全量，数据平台还没建好，生产数据库先被拖慢了。

所以成熟的数据集成架构，至少要同时考虑：

时效、完整性、资源占用、网络压力和失败恢复。

真正难的不是“同步一次成功”，而是每天都能稳定地同步成功。

三、数据存储层：不是所有数据都应该塞进一个库

数据进来以后，下一个问题是：

存在哪里？

传统数仓、MPP数据库、数据湖、湖仓一体，看起来像不同的技术路线，背后其实是在解决不同的数据存储和计算需求。

真正设计时，一般要看三个维度：

数据类型、使用频率、计算方式。

• 结构化经营数据需要频繁查询和聚合；
• 日志、文件、图片等数据更强调大规模、低成本保存；
• 大量历史明细虽然需要保留，却未必每天都要参与计算。

因此存储架构不应该追求“所有数据统一扔到一个地方”，而应该进一步做冷热分层和生命周期管理。

最近三个月的数据每天都要查，可以放在高频计算区域；

几年前的历史数据一年只访问几次，就没有必要一直占用昂贵的高性能资源。

还有一个经常被忽略的问题：

数据进入哪个位置，应该在数据流动阶段就设计好。

哪些源数据先进入ODS，哪些实时数据直接进入目标明细层，哪些历史数据需要长期归档，实际上都和前面的同步链路连在一起。

在FineDataLink 5.0里配置数据同步时，也可以按照这套分层思路去组织数据流向：不是简单地从一个数据库复制到另一个数据库，而是让不同来源的数据按照既定的数据架构进入对应的数据层。

这样“数据搬到哪里”本身，就成为数仓分层设计的一部分。

四、数据加工层：把“原始数据”变成“可计算的数据”

数据进入平台，并不意味着已经能直接使用。

真实业务数据往往非常乱：

• 订单状态可能是代码；
• 时间格式可能不统一；
• 客户名称可能重复；
• 同一个商品在不同系统里的编码可能完全不同；
• 金额甚至可能一个系统用元，一个系统用万元。

所以数据加工层真正解决的是：

清洗、转换、关联和标准化。

通常包括：

• 字段映射、
• 空值处理、
• 重复值处理、
• 类型转换、
• 编码统一、
• 多表关联、
• 业务规则计算、
• 维度补充。

但数据加工还有一个非常重要的原则：

不要把所有逻辑都塞进一个任务里。

更合理的方式，是把加工过程拆开。

第一层处理技术问题：

统一格式、字段类型、编码和单位。

第二层处理业务问题：

订单状态、客户关系、组织映射、业务规则。

第三层再处理公共计算和汇总。

这样以后业务规则发生变化，才能快速知道应该改哪一层。

否则几千行SQL运行半年以后，经常会进入一种状态：

没人敢动。

因为没人知道改一个字段，会影响下面多少张表。

五、数据建模层：决定数据最终怎样组织

如果加工解决的是“怎么处理”，那么建模解决的是：

处理后的数据应该以什么结构长期沉淀。

这也是ODS、DWD、DWS、ADS真正有意义的地方。

• ODS主要承接接近源系统的数据；
• DWD沉淀标准化业务事实；
• DWS围绕主题形成公共汇总；
• ADS再面向具体业务场景提供结果。

但真正做架构时，最重要的并不是背这些缩写。

而是理解一个原则：

越靠近底层，越强调稳定和复用；越靠近上层，才越靠近具体业务需求。

很多企业数仓越建越乱，根本原因就是公共逻辑没有沉淀。

• 销售想看客户销售额，建一张表；
• 财务要算客户利润，再建一张表；
• 经营分析想看客户贡献度，又重新加工一遍。

最后几十张表其实都在重复处理“客户”和“订单”。

更合理的方式，是先把核心事实和公共维度沉淀下来，让上层分析尽可能复用。

而模型设计完成以后，还有一个经常被忽略的问题：

这些模型每天怎么稳定产出？

ODS的数据什么时候到，DWD什么时候开始加工，DWS又依赖哪些上游结果，这些任务之间通常都有明确的先后关系。

这里可以通过FineDataLink 5.0把数据清洗、转换、SQL处理和任务调度串起来，并按照上下游依赖组织整个加工流程。

这样模型之间的关系就不只是画在架构图上，而是真正落实到每天的数据生产过程中：上游没有完成，下游不会盲目执行；某个环节出现异常，也更容易顺着任务链路定位问题。

六、数据治理层：解决“为什么大家算出来都不一样”

很多企业做到这里会发现：

• 系统通了，
• 数仓也建了，
• 但数据还是不好用。

最典型的场景就是：

• 财务算收入1.2亿；
• 销售算1.3亿；
• 经营分析又算出1.25亿。

大家的数据可能都来自同一个系统，但最终答案却不一样。

这时候问题已经不是技术，而是治理。

治理层至少要解决五件事：

元数据、主数据、指标口径、数据质量、数据血缘。

元数据回答：

这张表是什么？

这个字段代表什么？

主数据解决：

到底哪个客户编码、商品编码、组织编码才是统一标准？

指标体系回答：

收入、利润、复购率到底怎么算？

数据质量解决：

• 哪些字段不能为空？
• 哪些数据不能重复？
• 哪些结果超出范围应该报警？

数据血缘则回答：

这个指标到底来自哪个系统、哪张表，又经过了哪些加工。

所以治理真正做的，是让数据变得：

有定义、有标准、有责任人、有来源、可追溯。

如果没有这一层，企业数据平台越大，理解成本反而越高。

七、数据服务层：让数据真正走出数仓

很多数据项目做到ADS层就觉得结束了。

但站在业务角度来看：

数据躺在数仓里，本身不会产生价值。

它最终还要被：

• BI使用，
• 报表查询，
• 业务系统调用，
• 算法模型读取，
• AI应用消费。

因此成熟的数据架构还必须考虑一个问题：

数据怎么出去？

很多企业早期的做法非常简单：

需要数据？

给你一个数据库账号，自己查。

系统少的时候还能用。

但调用方越来越多以后，问题很快就会出现：

• 权限越来越难管；
• 下游直接依赖底层表；
• 表结构稍微一调整，一堆系统跟着修改；
• 甚至没人知道某张表到底被多少应用使用。

所以数据服务层真正要解决的是：

把底层数据结构和上层数据消费解耦。

已经加工好的数据，可以通过FineDataLink 5.0进一步发布成API，并统一管理接口认证、调用和运行情况。

这样上层系统依赖的是相对稳定的数据接口，而不是直接绑定底层库表。后续即使存储结构或者加工逻辑有所调整，也不至于让所有下游系统一起跟着修改。

对于数据架构来说，这一步非常重要。

因为只有数据真正能够稳定地被消费，前面做的数据集成、存储和建模才算真正形成价值闭环。

八、调度、运维与安全层：决定架构能不能长期稳定运行

最后一层，经常是架构图里最不起眼，却真正决定系统能不能跑下去的一层。

因为企业的数据平台每天可能运行几百、几千甚至更多任务。

A依赖B，

B依赖C，

C又依赖一个凌晨才能生成的业务表。

其中任何一个节点失败，都可能造成第二天经营报表延迟。

所以这一层至少要考虑：

• 任务依赖；
• 调度周期；
• 任务优先级；
• 超时控制；
• 失败重试；
• 异常告警；
• 运行日志；
• 权限管理；
• 敏感数据控制；
• 开发、测试、生产环境隔离。

真正成熟的平台，并不是“任务从来不会失败”。

这几乎不现实。

更重要的是：

失败以后能不能快速发现、快速定位、快速恢复。

同样，安全也不能等平台上线以后再补。

• 哪些人能看哪些数据？
• 哪些字段需要脱敏？
• 哪些接口允许外部调用？
• 谁修改过关键任务？

这些问题都应该在架构阶段一起设计。

因为当数据平台真正成为企业基础设施以后，稳定性和安全性已经不是附加能力，而是整个数据架构的一部分。

把这8层放在一起，其实就是一条完整的数据生命周期：

数据源 → 数据集成 → 数据存储 → 数据加工 → 数据建模 → 数据治理 → 数据服务 → 调度运维与安全。

以后再看一张企业数据架构图，可以先别急着看它用了多少先进技术。

先问8个问题：

• 数据从哪里来？
• 怎么稳定进入平台？
• 应该放在哪里？
• 怎样被加工？
• 按照什么模型沉淀？
• 如何保证质量和口径？
• 怎样提供给业务？
• 出了问题以后，谁能发现、怎么恢复？

如果这8个问题都能回答清楚，一套数据架构才真正形成闭环。

因为数据架构真正重要的，从来不是图画得有多复杂。

而是企业的数据能不能沿着一条清晰、稳定、可治理的链路持续流动。

数据进得来、流得稳、算得清、沉淀得下、找得到、说得明白、最终还能真正用出去，这才是一套能落地的数据架构。