数据是怎么进入数据平台的?一文搞懂数据采集与数据同步

文章来源声明: 原文作者:前端小小栈; 来源站点:掘金; 原文链接:https://juejin.cn/post/7689065487934717998; 本文基于上述来源整理/加工,觅优补充点评,仅供技术学习交流。版权归原作者所有。
觅优短评

从入门视角把数据入仓链路讲得清晰,适合数据平台初学者建立全局认知,也可作为团队科普材料。

上一篇我们介绍了数据平台到底是什么。简单来说,数据平台就是把分散在各种业务系统中的数据采集过来,经过处理和存储,最终提供给数据分析和业务使用。

那么问题来了:数据平台里的数据到底是怎么来的?

这其实是数据平台需要解决的第一个问题。因为数据平台本身通常并不负责产生业务数据,真正产生数据的是各种业务系统,比如用户系统、订单系统、支付系统、商品系统等。数据平台需要做的第一件事情,就是把这些系统中的数据“搬”进来。

一、数据平台的数据从哪里来?

我们平时使用的各种互联网应用,其实每时每刻都在产生数据。

用户注册会产生用户数据,登录会产生登录记录,浏览商品会产生行为数据,下单会产生订单数据,支付会产生支付数据。除此之外,还有服务器日志、设备数据、第三方 API 等。

所以一个真实的数据平台,面对的数据源可能非常多:

MySQL
PostgreSQL
Oracle
MongoDB
日志文件
第三方 API
业务系统
IoT 设备
用户行为数据

例如一个电商公司可能是这样的:

用户系统 → MySQL
订单系统 → MySQL
商品系统 → MySQL
支付系统 → PostgreSQL
日志系统 → 日志文件

这些数据分散在不同系统中,如果想进行统一分析,就需要把它们汇聚到数据平台。

这就是数据采集要解决的问题。

二、什么是数据采集?

数据采集可以简单理解成:把不同数据源中的数据获取到数据平台。

例如订单系统中有一张订单表:

<span>CREATE</span> <span>TABLE</span> orders (
    id <span>BIGINT</span>,
    user_id <span>BIGINT</span>,
    amount <span>DECIMAL</span>(<span>10</span>,<span>2</span>),
    status <span>VARCHAR</span>(<span>20</span>),
    created_at DATETIME
);

数据平台可能需要把这张表中的数据同步到自己的数据存储系统中。

最简单的方式,就是定时执行查询:

<span>SELECT</span> <span>*</span>
<span>FROM</span> orders
<span>WHERE</span> created_at <span>>=</span> <span>'2026-09-01'</span>;

然后把查询结果写入目标数据库。

这种方式虽然简单,但如果数据量越来越大,就会遇到很多问题。

比如每天有几千万条订单,如果每次都把全部数据查询一遍,不仅浪费资源,还可能给业务数据库带来很大的压力。

所以实际的数据平台通常不会简单地“反复查询整张表”,而是会根据数据变化进行更加高效的数据同步。

三、全量同步是什么?

数据同步中最容易理解的一种方式就是全量同步。

所谓全量同步,就是把数据源中的所有数据一次性同步到目标系统。

例如现在 MySQL 中有 100 万条订单:

MySQL
100 万条订单
<span>     ↓
全量同步
     ↓
数据平台
100 万条订单
</span>

这种方式特别适合第一次建立数据链路的时候。

例如一个公司刚刚搭建数据平台,原来的订单数据已经积累了三年,那么首先就需要把过去三年的历史数据同步过来。

这个过程通常就是全量同步。

但是全量同步有一个明显的问题:数据量越大,成本越高。

如果订单表已经有 10 亿条数据,每天只新增 100 万条订单,你不可能每天都把 10 亿条数据重新同步一遍。

所以我们还需要另外一种方式。

四、什么是增量同步?

增量同步的核心思想非常简单:

只同步发生变化的数据。

比如昨天数据库里有 100 万条订单,今天新增了 1 万条订单。

全量同步是:

100 万 + 1 万
全部重新同步

增量同步则是:

只同步新增的 1 万条

这样效率就会高很多。

除了新增数据之外,真实业务中还可能存在更新和删除。

例如:

<span>INSERT</span>  新增订单
<span>UPDATE</span>  修改订单
<span>DELETE</span>  删除订单

增量同步需要能够感知这些变化,然后把变化同步到数据平台。

这也是现代数据平台中非常重要的一项能力。

五、CDC 是什么?

说到增量同步,就不得不提一个非常常见的概念:

CDC(Change Data Capture)

中文一般叫做变更数据捕获。

它的核心思想就是:

捕获数据库中的数据变化。

例如 MySQL 中执行:

UPDATE orders
SET <span>status</span> = <span>'paid'</span>
WHERE <span>id</span> = <span>10001</span><span>;</span>

CDC 系统需要知道:

id = 10001 这条订单发生了变化。

然后把这个变化发送给数据平台。

MySQL 本身提供了 Binlog,也就是二进制日志。数据库执行 INSERT、UPDATE、DELETE 等操作时,会产生对应的 Binlog 记录。

因此很多 CDC 方案都会利用 Binlog 来实现数据同步。

常见的技术包括 Canal、Debezium 等。

可以简单理解成:

MySQL
  ↓
Binlog
  ↓
CDC
  ↓
数据平台

这样就不需要不断扫描整个数据库,而是可以根据数据库产生的变化进行数据同步。

六、为什么数据同步还需要消息队列?

当数据规模越来越大之后,数据平台往往还会在数据源和数据处理系统之间增加一个消息队列。

最典型的就是 Kafka。

整体链路可能变成:

MySQL
  ↓
CDC
  ↓
Kafka
  ↓
数据处理
  ↓
数据仓库

为什么需要 Kafka?

一个很重要的原因就是解耦。

如果 MySQL 发生数据变化之后,直接调用后面的数据处理程序,那么数据库和数据处理系统就会产生比较强的依赖。

有了 Kafka 之后,CDC 只负责把变化的数据写入 Kafka,后面的消费者再从 Kafka 获取数据。

这样数据采集和数据处理就可以相对独立。

例如:

<span>             ┌→ 实时计算
MySQL → CDC → Kafka
             ├→ 数据仓库
             └→ 数据分析
</span>

同一份数据还可以被不同的系统消费。

这也是 Kafka 在数据平台中非常常见的原因之一。

七、数据同步最难的是什么?

刚开始学习数据同步的时候,很容易认为它就是:

把 A 数据库的数据复制到 B 数据库。

但真正做数据平台时,最麻烦的往往不是“复制”,而是如何保证数据可靠地复制过去。

例如网络突然断了怎么办?

Kafka 宕机了怎么办?

同步程序突然重启怎么办?

一条数据重复发送怎么办?

目标数据库写入失败怎么办?

如果数据同步到一半程序挂了,重新启动之后应该从哪里继续?

这些问题都会涉及数据同步的可靠性。

例如:

MySQL
  ↓
CDC
  ↓
Kafka
  ↓
数据处理
  ↓
ClickHouse

如果 Kafka 已经收到数据,但是 ClickHouse 写入失败,那么这条数据应该怎么办?

如果重新处理,会不会产生重复数据?

如果不重新处理,会不会导致数据丢失?

这些问题最终都会涉及消息确认、Offset、重试、幂等、事务等概念。

所以数据同步实际上是一个非常值得深入研究的领域。

八、数据平台为什么需要数据同步?

理解到这里,我们就可以重新看一下数据平台的整体架构。

业务系统负责产生数据,数据同步负责把数据从业务系统带出来,数据平台再负责后续的数据处理和分析。

可以简单理解成:

┌─────────────┐
│   业务系统   │
│ MySQL / PG  │
└──────┬──────┘
<span>       ↓
   数据采集
       ↓
   全量 / CDC
       ↓
┌─────────────┐
│    Kafka    │
└──────┬──────┘
       ↓
   数据处理
       ↓
┌─────────────┐
│ 数据仓库/数据湖 │
└─────────────┘
</span>

这里面每一层解决的问题其实都不一样。

业务系统负责产生数据,CDC 负责捕获数据变化,Kafka 负责数据传输和解耦,数据处理系统负责清洗和转换,数据仓库或者数据湖负责存储。

当你把这些环节放在一起之后,数据平台的整体结构就开始清晰起来了。

九、数据采集和数据同步有什么区别?

这两个概念在实际工作中经常被混在一起。

简单来说,数据采集更强调“把数据获取过来”,数据同步更强调“让两个系统之间的数据保持一致或者及时传递”。

例如每天凌晨从 MySQL 导出一份数据到数据仓库,可以看作一种数据采集。

而通过 CDC 持续捕获 MySQL 的 INSERT、UPDATE、DELETE,然后实时传递到下游系统,则更偏向数据同步。

不过在实际项目中,两者并没有非常严格的边界,很多时候也会直接统称为数据同步。

对于入门阶段,可以先记住一个核心概念:

数据平台首先要解决的,就是如何稳定、高效地把数据从业务系统搬出来。

十、总结

数据平台并不是凭空产生数据,而是建立在各种业务系统产生的数据之上。

数据进入平台通常需要经历数据采集和数据同步。最基础的方式是全量同步,把历史数据一次性搬过来;当数据量越来越大之后,就需要增量同步,只处理发生变化的数据;而 CDC 则提供了一种更加实时的数据变化捕获方式,MySQL Binlog 又是实现 CDC 的重要基础。

当数据规模进一步扩大之后,还可以引入 Kafka 等消息队列,对数据采集和数据处理进行解耦。

所以整个数据链路可以先记成:

业务系统
   ↓
数据采集
   ↓
全量 / 增量 / CDC
   ↓
Kafka
   ↓
数据处理
   ↓
数据仓库 / 数据湖

理解这条链路之后,再去学习 Canal、Debezium、Kafka、Binlog 等技术,就会容易很多。

数据平台的第一步,不是分析数据,而是先把数据可靠地拿进来。