前言

很多人第一次接触数据架构，最先学到的往往是几个缩写：

ODS、DWD、DWS、ADS。

于是很容易产生一种错觉：

数据架构设计，不就是把业务系统的数据抽出来，然后按照这四层一层层往下放吗？

真正做过企业数据项目以后就会发现，远没有这么简单。

因为从一张业务表，到管理层经营看板上的一个指标，中间至少还要经过：

数据接入、同步、存储、清洗、建模、汇总、指标定义、数据服务、质量校验和任务运维。

其中任何一个环节没有设计好，后面都可能出现问题。

• 数据源没有梳理清楚，同一个客户可能在三个系统里有三套编码；

• ODS留存不完整，业务口径一变，历史数据就没办法重新计算；

• DWD粒度没有统一，到了DWS以后同一个指标可能越算越乱；

• 指标没有统一管理，即使大家都在看同一个数仓，最终仍然可能

• 现“财务一个数、业务一个数、老板又看到第三个数”的情况。

所以，ODS、DWD、DWS、ADS只是数据架构中最容易被看见的四层，真正的数据架构是一整条数据生产链路。

它需要回答：

• 数据从哪里来？

• 怎么进入平台？

• 原始数据怎么保存？

• 业务事实怎么统一？

• 公共指标怎么沉淀？

• 最终又怎么提供给不同应用使用？

下面我们就不只讲ODS、DWD、DWS、ADS，而是按照一条数据真正从业务系统流向最终应用的过程，把企业数据架构中最核心的10个组件一次讲清楚。

一、数据源：先回答“企业到底有哪些数据”

数据架构的第一层，从来不是ODS，而是数据源。

一个稍微复杂一点的企业，数据可能同时存在于：

ERP、CRM、MES、WMS、OA、财务系统、电商平台、数据库、Excel、API、日志平台以及消息队列中。

真正麻烦的地方并不是系统数量多，而是这些系统之间存在四种差异。

第一，数据结构不同。

同样是客户，CRM里可能按照客户ID管理，ERP里却按照往来单位编码管理。

第二，更新方式不同。

订单每秒都在变化，组织架构可能一个月才调整一次。

第三，数据规模不同。

基础配置表只有几千行，交易表可能已经达到几十亿行。

第四，时效要求不同。

库存预警可能需要分钟级甚至秒级更新，月度财务分析一天同步一次已经足够。

所以架构设计的第一步，不应该急着问：

“用不用实时数仓？”

而应该先做一次数据源盘点：

数据在哪里、谁是权威来源、怎么变化、多久需要更新一次。

这也是为什么数据接入最好先统一管理。

在数据平台工具中，可以先建立数据连接，把不同数据库、接口等来源纳入同一套数据开发和数据管道体系，再根据数据特点决定后续采用定时还是实时方式。

这样增加一个新系统时，不需要重新从“这套数据到底怎么接”开始设计，而是先把它放回整条数据链路里判断。

数据源解决的是：

数据从哪里来。

但知道数据在哪里还不够，接下来还要解决它怎么稳定进入数据平台。

二、数据集成层：决定数据以什么方式流动

第二个核心组件，是数据集成层。

它连接业务系统和数据平台。

这一层最重要的工作并不是简单的“复制数据库”，而是根据不同数据特征选择不同采集策略。

常见方式主要有三种：

全量同步

每次把源表全部读取一遍。

适合数据量小、变化频率低的基础表，例如地区编码、商品分类和部分配置表。

增量同步

通过更新时间、递增ID等条件，只读取发生变化的数据。

适合有明确增量标识的业务表。

CDC

直接捕获数据库中的增删改变化。

对于订单、库存、交易等高频变化数据，如果要求实时或准实时，CDC通常会更加合理。

这里有一个很重要的设计原则：

不要先选同步技术，再让所有数据适应它。

真正合理的顺序应该是：

先看数据