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

1 评论 5048 浏览 17 收藏 16 分钟

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

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

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

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

一、搬运工都有哪些称呼

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、搬运过程中的处理

在进行数据同步的过程中,需不需要进行处理,虽然数据同步常常和**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. 没有表结构

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

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

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

本文由 @数据小吏 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 整体读下来感觉还比容易让人理解的,有些概念的内容介绍的较为清晰,有一点可能对于小白来说在阅读顺序上有难受。因为不了解拖拽式和向导式,所以在前面读到这两个名词时就有点疑惑,到后面介绍清楚后在回头看便理解了

    来自山东 回复