很多人第一次接触数据架构，会觉得这件事特别“技术”。
架构图上密密麻麻全是数据库、消息队列、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个问题都能回答清楚，一套数据架构才真正形成闭环。
因为数据架构真正重要的，从来不是图画得有多复杂。
而是企业的数据能不能沿着一条清晰、稳定、可治理的链路持续流动。
数据进得来、流得稳、算得清、沉淀得下、找得到、说得明白、最终还能真正用出去，这才是一套能落地的数据架构。
热门跟贴