大数据平台并不生产数据，大多数原始数据其实都来源于业务系统，所以，我们需要做好数据“搬运”动作。而这就牵扯到了“数据集成”这个概念。这篇文章里，作者就谈了谈他的见解和感受，一起来看看吧。
我不生产数据，我只是数据的搬运工。
在大数据平台中，是不生产数据的，或者说原始数据都是来源于业务系统。所以，我们需要做的第一件事，就是将业务系统的数据搬运到数据平台。
改用那句耳熟能详的话，我不生产数据，我只是数据的搬运工。这个数据的搬运工，就是数据平台的第一个模块——数据集成。
在进行产品设计的过程中，对于同一个产品，经常会遇到各种各样的名称，这些名称好像可以指代同一个产品，如果细究起来，好像也有些区别。
在数据集成产品设计时，也会遇到类似的问题。这些相同的名称主要是数据集成、数据同步、数据采集。有时候也可能听到数据管道、数据传输等等。
我通过大模型搜索了一下区别。
💡 数据集成：指的是将不同数据源、不同数据类型以及不同格式的数据整合到一起，形成一个统一的数据视图或数据仓库，以便后续的分析和处理。数据集成通常涉及到数据的抽取、转换、清洗和加载等多个步骤，同时也需要解决数据格式转换、数据质量问题以及数据安全性等问题。
数据同步：则是将数据从一个数据源复制或传输到另一个数据源，以保持两个数据源中的数据一致性。数据同步通常涉及到实时或准实时的数据传输和复制，可以用于分布式系统中的数据复制、备份以及容灾等场景。
似乎，数据集成更注重数据的整合和数据处理，而数据同步更注重数据的传输和一致性。
💡 在大数据领域，数据采集和数据集成是两个密切相关的概念，但它们在数据处理过程中扮演的角色和目的有所不同。
数据采集主要是通过工具或技术，从系统外部获取数据并输入到系统内部的过程。它可以是手工的，也可以是自动化的。在这个过程中，获取的数据可能需要进行清洗、格式转换等预处理，以便后续的数据集成和使用。
数据集成则是将不同来源、不同格式、不同性质的数据在逻辑上或物理上有机地集中起来，形成一个全面、统一的数据视图或数据仓库的过程。数据集成通常涉及到数据的抽取、转换、清洗和加载等多个步骤，它的主要目的是为企业提供全面的数据共享和数据分析能力。
因此，可以说数据采集是数据集成的基础和前提，数据集成则是数据采集的后续处理和结果。没有数据采集，数据集成就缺乏数据来源；没有数据集成，则无法有效利用和管理大数据资产。
在这个定义里面数据采集是数据集成之前的一个步骤。个人感觉在实时领域是这样的，实时获取到数据的变更相当于数据的采集。
以上都是通过大语言模型给出的结论。对这些名称有一个基本概念之后，结合实际的公司习惯、部门历史使用习惯、以及上下文语境来做具体的区分。
个人习惯数据集成和数据同步这两个词大部分情况下会混用。如果要做区分的话，当有向导式和拖拽式两种形式的时候。拖拽式的可以称之为数据集成，因为拖拽式的重数据的转换和整合。向导式的可以称之为数据同步，因为向导式的重数据的传输和一致性。而数据采集，个人相对混用少些，个人主要理解为将数据库的变化采集上来。
再次说明，完全是个人角度的划分。
在进行数据同步的过程中，需不需要进行处理，虽然数据同步常常和**ETL（提取（extract）、转换（transform）、加载（load））**放在一起做比较，但是实际上是不是需要在同步过程中进行转换是可以进行商榷的。
同步数据的目的是保留业务的数据历史，如果要保留历史那么错误的历史也是历史。所以这种同步就是完全和业务系统数据一比一的同步，即使同步过来的数据是有异常的或者说不标准的。只有这样才能真正的如实的保留了业务的历史，当发生数据异常进行数据追溯的时候，才能够找到最原始的业务数据。
个人认为这个想法很好，能够完全的保留业务历史数据。但是有一个问题就是错误的数据业务系统可以随时改的。但是在离线场景下的同步不会随时进行的。而且感觉这种太极端，对人员，程序要求都比较高。
第二种就显的要求没有那么的严格，相对宽松些。可以在这个过程中进行行级别的增减、规范化。也可以进行字段的聚合、关联、转换等等操作。
其实对产品设计来说，支持了这种形式，就支持了一比一的同步。在同步过程中有这个转换、聚合的能力，不使用的话就是一比一同步了。这样说来一比一同步更多的似乎是一个规范、一个要求。
将业务数据搬运到数据平台的目标就是保留历史、做到数据可追溯。但是业务系统的数据是时时都在变化的，那么怎么保留变化的数据的历史就是一个目标表建表结构的问题。
这其实算是数据仓库建模领域的内容，为什么在这里说？先说一下目标表常见的几种形式。全量表、切片表、拉链表。
全量表和名字一样，就是数据全量同步到目标端。试用于同步码表等数据变动不大的表。
切片表又分为增量切片，和全量切片。全量切片就是将每天的全量业务数据放在当天分区中。增量切片就是仅仅把当天的增量放在当天的分区中。
拉链表式最复杂的。需要有一个唯一键，需要知道业务数据是否变化，变化之后，就在目标表中新增一条，记录变化数据的开始时间、结束时间，有的还会有版本、是否当前状态等字段（拉链表也依赖于同步的时间粒度，细于时间粒度，可能会存在无法将数据同步到目标端情况）。
为什么要在这里说，因为数据集成产品需要在功能上支持这些目标表的建表类型。全量表的全量同步。切片表的增量切片，需要能够过滤出来每日的增量数据。拉链表的复杂逻辑，是否需要进行逻辑固化（我只在Powercenter中看到过拉链表的逻辑固化。自己也设计过向导式的拉链表逻辑固化）。这些都需要在数据同步过程中考虑到。不仅仅能够将数据搬运到目标端，而且还需要以一种合理的目标端表结构需要将数据搬运到目标端。
在搬运过程中，交互形式一般有三种形式，脚本式、拖拽式、向导式。
顾名思义，脚本式就是写一个脚本来进行数据同步。这种形式更多的是偏技术，在产品设计中一般不会过多涉及。
常见的脚本式同步：
古老的是Sqoop了，他实现了结构化数据和Hadoop之间的批量数据迁移，最初由Apache软件基金会开发，但是在2016年，该项目已经被终止了。
在阿里云Dataworks中的数据集成DataX，也会有的脚本界面的数据同步。是因为有些非结构化的数据源，没有表结构类型，在脚本界面中能够更加灵活。
拖拽类的数据集成类产品，就是在一个画布中拖拽各个算子，组成一个ETL的DAG图，从而实现数据的同步。
常见的拖拽式的同步：
最有名的算是Informatica Powercenter，这款产品在国外似乎知名度很高，常年在Genter象限的领导这位置。但在国内似乎只有一些银行、等金融行业使用多些，在互联网公司更是近乎没什么声量。
IBM Datastage 一款和powercenter类似的软件。
Kettle一款开源的免费的数据ETL工具。
如果有拖拽式的数据同步需求，这三个产品也常常会被拉在一起做比较。各有各的特点吧。
单独提一句，当使用拖拽式的数据集成时，其实多少有了一些数据开发的性质。但是如果细划分的话，和拖拽式的数据开发还是有些区别的。这个在《常见的数据开发形式》中的拖拽式数据开发中说下区别。
向导式的数据集成，主要是指通过输入框或者选择配置框，就可以完成任务的创建。不需要写代码，也不需要拖拽算子，这种开发形式我定义为向导式。
大部分的云厂商的数据集成/数据同步类产品均是向导式的模式。这里就不过多说了。
个人理解数据集成只分为两大类，离线数据集成和实时的数据集成。至于全量同步、增量同步等等，只是这两种大形式下的一种选项。而这两种形式，又均可以使用脚本式、拖拽式或者向导式来实现。形式不重要，本质是实时还是离线才重要，当然设计页面的时候也会多少有些配置区别。
在失效性上，实时数据越来越受重视，还有一些批流一体的概念，所以实时的数据集成需求也越来越多。
但是个人不认为离线的数据集成会被完全干掉。一方面——成本，显然实时的成本要比离线的成本要高。一方面——技术，实时集成之后一系列的技术和离线集成是完全不同的，现有的技术架构不一定都做好了准备。
还有一方面就是历史习惯，以上面介绍为例，切片表、拉链表等等均是离线场景下的，在后续介绍中会发现有大量的概念在离线场景下很顺畅，但是往往会自动的忽略实时场景。这可能也是因为实时的历史相对较短。在其他概念出现的时候，并没有考虑实时的场景。
数据集成支持的数据源多少是一个平台能力的体现，支持的越多，可以理解为能力越强。不同数据源可能支持实时的形式、可能支持离线形式，也可能两种均支持。数据源大类上也有不同的划分：关系型数据库、大数据存储、消息队列、文本文件等等。
这是从类型上划分，如果从接入数据源之后的操作上来分，就两类：有表结构的和没有表结构的。
有表结构的可以是关系型数据库、HIVE、Doris等等这类本身有表结构的。也可以是固定格式的文本、JSON这类可以赋予一个固定scheam的，这类需要进行数据平台有元数据管理能力，在《当我们谈元数据的时候，我们在谈什么》中会介绍这一部分。这类有表结构的在交互时，以二维表格的形式在向导、或者拖拽中进行交互了。
没有表结构的相对会复杂些，有时候可以强制给这种没有表结构的授予一个表结构。有的时候也只能转换成脚本的形式来实现映射。这个具体数据源具体分析了。
数据源支持多少体现能力强弱。同样，作为产品每种数据源可能都有其自身的特性，也需要进行个性化的设计，而产品经理又会将各种类型的数据源都熟悉到，个人感觉也是数据集成类产品设计的一个麻烦的点。
至于各种非结构化的文档、图片、音视频等等。都不在大数据平台这个范畴内。之前也会提非结构化的大数据平台，非结构化的大数据治理。但是目前个人没有接触到特别好的产品。
本文由 @数据小吏 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。