数据的搬运工—数据集成

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

在大数据平台中,是不生产数据的,或者说原始数据都是来源于业务系统。所以,我们需要做的第一件事,就是将业务系统的数据搬运到数据平台。改用那句耳熟能详的话,我不生产数据,我只是数据的搬运工。这个数据的搬运工,就是数据平台的第一个模块--数据集成。

搬运工都有哪些称呼

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

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

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

💡 数据集成:指的是将不同数据源、不同数据类型以及不同格式的数据整合到一起,形成一个统一的数据视图或数据仓库,以便后续的分析和处理。数据集成通常涉及到数据的抽取、转换、清洗和加载等多个步骤,同时也需要解决数据格式转换、数据质量问题以及数据安全性等问题。
数据同步:则是将数据从一个数据源复制或传输到另一个数据源,以保持两个数据源中的数据一致性。数据同步通常涉及到实时或准实时的数据传输和复制,可以用于分布式系统中的数据复制、备份以及容灾等场景。

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

💡 在大数据领域,数据采集和数据集成是两个密切相关的概念,但它们在数据处理过程中扮演的角色和目的有所不同。
数据采集主要是通过工具或技术,从系统外部获取数据并输入到系统内部的过程。它可以是手工的,也可以是自动化的。在这个过程中,获取的数据可能需要进行清洗、格式转换等预处理,以便后续的数据集成和使用。
数据集成则是将不同来源、不同格式、不同性质的数据在逻辑上或物理上有机地集中起来,形成一个全面、统一的数据视图或数据仓库的过程。数据集成通常涉及到数据的抽取、转换、清洗和加载等多个步骤,它的主要目的是为企业提供全面的数据共享和数据分析能力。

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

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

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

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

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

搬运过程中的处理

在进行数据同步的过程中,需不需要进行处理,虽然数据同步常常和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的,这类需要进行数据平台有元数据管理能力,在当我们谈元数据的时候,我们在谈什么 中会介绍这一部分。这类有表结构的在交互时,以二维表格的形式在向导、或者拖拽中进行交互了。

  • 没有表结构

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

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

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,928评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,192评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,468评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,186评论 1 286
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,295评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,374评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,403评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,186评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,610评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,906评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,075评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,755评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,393评论 3 320
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,079评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,313评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,934评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,963评论 2 351

推荐阅读更多精彩内容