数据的搬运工——数据集成

大数据平台并不生产数据，大多数原始数据其实都来源于业务系统，所以，我们需要做好数据“搬运”动作。而这就牵扯到了“数据集成”这个概念。这篇文章里，作者就谈了谈他的见解和感受，一起来看看吧。

我不生产数据，我只是数据的搬运工。

在大数据平台中，是不生产数据的，或者说原始数据都是来源于业务系统。所以，我们需要做的第一件事，就是将业务系统的数据搬运到数据平台。

改用那句耳熟能详的话，我不生产数据，我只是数据的搬运工。这个数据的搬运工，就是数据平台的第一个模块——数据集成。

一、搬运工都有哪些称呼

在进行产品设计的过程中，对于同一个产品，经常会遇到各种各样的名称，这些名称好像可以指代同一个产品，如果细究起来，好像也有些区别。

在数据集成产品设计时，也会遇到类似的问题。这些相同的名称主要是数据集成、数据同步、数据采集。有时候也可能听到数据管道、数据传输等等。

我通过大模型搜索了一下区别。

💡 数据集成：指的是将不同数据源、不同数据类型以及不同格式的数据整合到一起，形成一个统一的数据视图或数据仓库，以便后续的分析和处理。数据集成通常涉及到数据的抽取、转换、清洗和加载等多个步骤，同时也需要解决数据格式转换、数据质量问题以及数据安全性等问题。

数据同步：则是将数据从一个数据源复制或传输到另一个数据源，以保持两个数据源中的数据一致性。数据同步通常涉及到实时或准实时的数据传输和复制，可以用于分布式系统中的数据复制、备份以及容灾等场景。

似乎，数据集成更注重数据的整合和数据处理，而数据同步更注重数据的传输和一致性。

💡 在大数据领域，数据采集和数据集成是两个密切相关的概念，但它们在数据处理过程中扮演的角色和目的有所不同。

数据采集主要是通过工具或技术，从系统外部获取数据并输入到系统内部的过程。它可以是手工的，也可以是自动化的。在这个过程中，获取的数据可能需要进行清洗、格式转换等预处理，以便后续的数据集成和使用。

数据集成则是将不同来源、不同格式、不同性质的数据在逻辑上或物理上有机地集中起来，形成一个全面、统一的数据视图或数据仓库的过程。数据集成通常涉及到数据的抽取、转换、清洗和加载等多个步骤，它的主要目的是为企业提供全面的数据共享和数据分析能力。

因此，可以说数据采集是数据集成的基础和前提，数据集成则是数据采集的后续处理和结果。没有数据采集，数据集成就缺乏数据来源；没有数据集成，则无法有效利用和管理大数据资产。

在这个定义里面数据采集是数据集成之前的一个步骤。个人感觉在实时领域是这样的，实时获取到数据的变更相当于数据的采集。

B端产品经理如何快速上手新业务？

在入职新公司或需要负责新业务时，B端产品经理要如何快速上手新业务，从而更顺畅地进入工作流程？

查看详情 >

以上都是通过大语言模型给出的结论。对这些名称有一个基本概念之后，结合实际的公司习惯、部门历史使用习惯、以及上下文语境来做具体的区分。

个人习惯数据集成和数据同步这两个词大部分情况下会混用。如果要做区分的话，当有向导式和拖拽式两种形式的时候。拖拽式的可以称之为数据集成，因为拖拽式的重数据的转换和整合。向导式的可以称之为数据同步，因为向导式的重数据的传输和一致性。而数据采集，个人相对混用少些，个人主要理解为将数据库的变化采集上来。

再次说明，完全是个人角度的划分。

二、搬运过程中的处理

在进行数据同步的过程中，需不需要进行处理，虽然数据同步常常和**ETL（提取（extract）、转换（transform）、加载（load））**放在一起做比较，但是实际上是不是需要在同步过程中进行转换是可以进行商榷的。

1. 一比一同步

同步数据的目的是保留业务的数据历史，如果要保留历史那么错误的历史也是历史。所以这种同步就是完全和业务系统数据一比一的同步，即使同步过来的数据是有异常的或者说不标准的。只有这样才能真正的如实的保留了业务的历史，当发生数据异常进行数据追溯的时候，才能够找到最原始的业务数据。

个人认为这个想法很好，能够完全的保留业务历史数据。但是有一个问题就是错误的数据业务系统可以随时改的。但是在离线场景下的同步不会随时进行的。而且感觉这种太极端，对人员，程序要求都比较高。

2. 在同步过程中进行转换清洗

第二种就显的要求没有那么的严格，相对宽松些。可以在这个过程中进行行级别的增减、规范化。也可以进行字段的聚合、关联、转换等等操作。

其实对产品设计来说，支持了这种形式，就支持了一比一的同步。在同步过程中有这个转换、聚合的能力，不使用的话就是一比一同步了。这样说来一比一同步更多的似乎是一个规范、一个要求。

三、搬运的目标表类型

将业务数据搬运到数据平台的目标就是保留历史、做到数据可追溯。但是业务系统的数据是时时都在变化的，那么怎么保留变化的数据的历史就是一个目标表建表结构的问题。

这其实算是数据仓库建模领域的内容，为什么在这里说？先说一下目标表常见的几种形式。全量表、切片表、拉链表。

1. 全量表

全量表和名字一样，就是数据全量同步到目标端。试用于同步码表等数据变动不大的表。

2. 切片表

切片表又分为增量切片，和全量切片。全量切片就是将每天的全量业务数据放在当天分区中。增量切片就是仅仅把当天的增量放在当天的分区中。

3. 拉链表

拉链表式最复杂的。需要有一个唯一键，需要知道业务数据是否变化，变化之后，就在目标表中新增一条，记录变化数据的开始时间、结束时间，有的还会有版本、是否当前状态等字段（拉链表也依赖于同步的时间粒度，细于时间粒度，可能会存在无法将数据同步到目标端情况）。

为什么要在这里说，因为数据集成产品需要在功能上支持这些目标表的建表类型。全量表的全量同步。切片表的增量切片，需要能够过滤出来每日的增量数据。拉链表的复杂逻辑，是否需要进行逻辑固化（我只在Powercenter中看到过拉链表的逻辑固化。自己也设计过向导式的拉链表逻辑固化）。这些都需要在数据同步过程中考虑到。不仅仅能够将数据搬运到目标端，而且还需要以一种合理的目标端表结构需要将数据搬运到目标端。

四、搬运的交互形式

在搬运过程中，交互形式一般有三种形式，脚本式、拖拽式、向导式。

1. 脚本式

顾名思义，脚本式就是写一个脚本来进行数据同步。这种形式更多的是偏技术，在产品设计中一般不会过多涉及。

常见的脚本式同步：

古老的是Sqoop了，他实现了结构化数据和Hadoop之间的批量数据迁移，最初由Apache软件基金会开发，但是在2016年，该项目已经被终止了。

在阿里云Dataworks中的数据集成DataX，也会有的脚本界面的数据同步。是因为有些非结构化的数据源，没有表结构类型，在脚本界面中能够更加灵活。

2. 拖拽式

拖拽类的数据集成类产品，就是在一个画布中拖拽各个算子，组成一个ETL的DAG图，从而实现数据的同步。

常见的拖拽式的同步：

最有名的算是Informatica Powercenter，这款产品在国外似乎知名度很高，常年在Genter象限的领导这位置。但在国内似乎只有一些银行、等金融行业使用多些，在互联网公司更是近乎没什么声量。

IBM Datastage 一款和powercenter类似的软件。

Kettle一款开源的免费的数据ETL工具。

如果有拖拽式的数据同步需求，这三个产品也常常会被拉在一起做比较。各有各的特点吧。

单独提一句，当使用拖拽式的数据集成时，其实多少有了一些数据开发的性质。但是如果细划分的话，和拖拽式的数据开发还是有些区别的。这个在《常见的数据开发形式》中的拖拽式数据开发中说下区别。

3. 向导式

向导式的数据集成，主要是指通过输入框或者选择配置框，就可以完成任务的创建。不需要写代码，也不需要拖拽算子，这种开发形式我定义为向导式。

大部分的云厂商的数据集成/数据同步类产品均是向导式的模式。这里就不过多说了。

五、时效性

个人理解数据集成只分为两大类，离线数据集成和实时的数据集成。至于全量同步、增量同步等等，只是这两种大形式下的一种选项。而这两种形式，又均可以使用脚本式、拖拽式或者向导式来实现。形式不重要，本质是实时还是离线才重要，当然设计页面的时候也会多少有些配置区别。

在失效性上，实时数据越来越受重视，还有一些批流一体的概念，所以实时的数据集成需求也越来越多。

但是个人不认为离线的数据集成会被完全干掉。一方面——成本，显然实时的成本要比离线的成本要高。一方面——技术，实时集成之后一系列的技术和离线集成是完全不同的，现有的技术架构不一定都做好了准备。

还有一方面就是历史习惯，以上面介绍为例，切片表、拉链表等等均是离线场景下的，在后续介绍中会发现有大量的概念在离线场景下很顺畅，但是往往会自动的忽略实时场景。这可能也是因为实时的历史相对较短。在其他概念出现的时候，并没有考虑实时的场景。

六、支持的数据源类型

数据集成支持的数据源多少是一个平台能力的体现，支持的越多，可以理解为能力越强。不同数据源可能支持实时的形式、可能支持离线形式，也可能两种均支持。数据源大类上也有不同的划分：关系型数据库、大数据存储、消息队列、文本文件等等。

这是从类型上划分，如果从接入数据源之后的操作上来分，就两类：有表结构的和没有表结构的。

1. 有表结构

有表结构的可以是关系型数据库、HIVE、Doris等等这类本身有表结构的。也可以是固定格式的文本、JSON这类可以赋予一个固定scheam的，这类需要进行数据平台有元数据管理能力，在《当我们谈元数据的时候，我们在谈什么》中会介绍这一部分。这类有表结构的在交互时，以二维表格的形式在向导、或者拖拽中进行交互了。

2. 没有表结构

没有表结构的相对会复杂些，有时候可以强制给这种没有表结构的授予一个表结构。有的时候也只能转换成脚本的形式来实现映射。这个具体数据源具体分析了。

数据源支持多少体现能力强弱。同样，作为产品每种数据源可能都有其自身的特性，也需要进行个性化的设计，而产品经理又会将各种类型的数据源都熟悉到，个人感觉也是数据集成类产品设计的一个麻烦的点。

至于各种非结构化的文档、图片、音视频等等。都不在大数据平台这个范畴内。之前也会提非结构化的大数据平台，非结构化的大数据治理。但是目前个人没有接触到特别好的产品。