如何选择离线数据集成方案-全量&增量

简介: 如何选择数据离线集成方式,哪些表适合全量集成,哪些表适合增量集成

1前言

我在上一篇中介绍了实时集成与离线集成该怎么选择,接着介绍一下离线集成中的增量与全量的选择问题。

要设计方案,我们先分析一下数据产生的方式。我们把音视频流这种非结构化的数据集成从这里排除出去,因为这种音视频流一般都是专业的厂商和系统来处理。我们围绕数据分析领域常见的半结构化、结构化数据来看。

结构化和半结构化数据主要来源于各种设备和系统中运行的软件,包括写入各种数据库的数据、服务器中的日志。如果数据本身可以实时传输过来,那么我们就尽可能采用这种方式,但是实际工作中更多的场合是离线。尤其是项目的一期,更容易使用离线集成。

实时集成就相当于收快递,需要商家和物流企业先期投入大量建设,才能让快递便捷的传输到你手里。而这种什么都准备好的情况,大部分时候都是企业IT建设相对成熟的情况下才有。

日志这种文件流,如果采用实时采集,就属于实时集成范围。如果离线传输,就是传个文件,本身就没有太多需要讲述的。下面我们就讨论下从数据库中实施离线集成的方法。

2数据库的数据

一提到传统数据库,就想到了结构化数据。但是数据库其实可以存储各种能存储的下的数据,比如音视频文件其实可以存储到LOB类型的二进制大对象字段中。而半结构化数据,可以存储到stringtextCLOB等字符型二进制大对象字段中。工业控制系统产生的时序数据,也可以存储到数据库中。

而数据库中的数据操作有插入、更新、删除,不同种类的操作会对集成有影响。

如果要对一个数据库做全库的集成,首先要决定哪些表是我们要入仓的。一定不要不经分析就把数据集成到数据仓库或者数据中台中。按照维度建模的理念,需要以需求为导向去构建模型,所以,集成的数据表一定是要明确有需求。这样我们就能确定一个范围,而不是全部。

划定范围,我们就会遇到非结构化数据入库的问题,因为MaxCompute本身是不支持大字段的,最长的字段长度是string,只有8M。至于数据库的LOB存储什么,五花八门,我见过照片、音频、Word文档、这些要集成,统统都需要传输到OSS,而不是MaxCompute。目前这种数据,还需要单独开发程序去集成到OSS

剩下的我们就可以理解为结构化和半结构化数据了,一般能用string存的下的都可以集成到MaxCompute。例如一些XMLJSON半结构化数据,之前在数据库是存储在CLOB类型的字段中的,但是本身并不是超过8M

接下来我们就需要评估该如何集成数据了-增量还是全量。

3增量还是全量

回顾之前在实时还是离线的章节总结的集成原则。

集成原则:

1-费用紧张,资源有限,尽可能使用离线集成。

2-批处理数据(主要指源端数据是批量产生,或者双十一式爆发式产生)集成,尽量走离线。如果确实预算非常充足,资源非常丰富,也可以走实时集成(很多时候,源端都可能扛不住)。

3-交易型数据集成,尽量走实时,如果资源有限可以走离线。

4-大表,例如数据超过200W、存储超过1G,尽量走实时,这种表一般在业务系统中数量不会超过表数量的20%。离线集成时效性很难满足要求,当然也不是不行。一般离线集成的表在1-10亿这个级别也是可以一战(与系统资源相关)。再大基本上就很难了,集成时间过久,业务系统没有足够的快照空间,事务会报错,集成就会失败。

5-小表,例如常年不动的代码表,10W以下的小表,大概都能在30-3分钟内完成,建议走离线。毕竟实时挺贵,这些小表,还是打包搞过来比较适合。

我们看到我把数据分为“批处理”、“交易型”、“大表”、“小表”。很明显,“批处理”和“交易型”是一个对照组,“大表”和“小表”是一个对照组。

先看下什么是“批处理”,主要是指数据并不是由业务系统的业务事件产生,而是由数据库或者应用后台运行的数据运行,其特点是一次操作的数据或者产生的数据是多条(几万到数亿)记录。“批处理”操作主要在做后台数据库版本发布的批量运维,夜间批量做数据处理,几个表关联生成一张新的表。这种操作瞬时产生大量的数据操作,少则几万,多则数亿,且发生时间相对短暂。对应的“交易型”则是实时发生,是由实际的业务发生时产生。并不是定时任务和运维人员提交到数据库的,是由应用提交到数据库的。

“大表”和“小表”需要画一条线,根据数据库系统的能力来评估。一般按照二八原则,或者一九。就是说一般数据库中90%表都是小表,根据数据库的规模,可以是10万也可以是100万。

  1. 全量集成

先说大小表,这个比较简单,一旦划定了大小表。就可以确定,小表是可以全部使用全量集成的。所以,这个边界是全量离线集成的边界。剩下的大表,就困难了。大表的意思就是全量集成不能完成,或者对数据库的负载过大,搞不定。这部分就需要考虑增量集成了。

  1. 增量集成

因为小表全量集成很暴力了,无所谓什么,都能集成过来。而大表的增量要怎么获取呢?真的很难。我有一句总结:没有一个业务系统的时间戳字段是可信的。大家可以去证明我是错误的,我的见识是浅薄的,但是这就是从业十多年的我的见识。

首先,增量集成需要数据库表不能有物理删除,这很难实现。即便业务系统在设计之初有这种设计,也难以避免后台人工运维引入非正常操作问题。

其次,标识数据被更新和插入的时间字段(时间戳)不可信。除了业务系统可能并不更新这个字段外,还同样存在人工运维引入非正常操作的问题。

  1. 批处理表的增量集成

即便如此,仍然有表,是可以容易实现增量识别的,而这种表往往还是大表。我们前面提到的“批处理”表就是这种表,因为这类表是批量写入的,操作频次是有限且是批量的(常见的数据交换表也是这种表)。这种表的数据,较为容易获得增量。

方法:

  1. 找到主键。因为增量数据需要与全量合并,所以主键非常重要。
  2. 了解数据写入特征。数据变动的范围多大,哪个字段是每日生成新数据的业务日期字段,这关系到增量集成的增量时区范围多大。例如,会更新当前月的数据,会更新最近N天的数据。
  3. 了解业务。为什么会产生这样的数据,业务是什么,数据该如何使用。
  4. 调研数据。从数据中验证之前得到的信息,是否完全正确,这非常重要。最经常的问题就是数据变动的范围,与描述不一致。这是因为调研总是短暂的,而数据不会骗人。例如运行了一个历史日期的数据,例如过了一个假期才处理问题。
  1. 事件表的增量集成

还有另外一种表,自然就可以做到增量识别。这类表就是事件型表,这类表只有insert,没有updatedelete。例如刷了一次门禁卡。

 image.png

到这里,我其实并没有解决所有表的集成。我只解决了小表、部分大表(批量表、事件表),这就是现实。大部分时候,我们只能采取加大离线集成的并行度,并忍受数个小时离线集成时长。而离线集成很难解决的这些表的集成,往往也是最适合实时集成的表。这就是我给的答案,离线集成不完美,解决不了我们获取数据的完整性的问题。

4总结

全量和增量都是一种选择,如果表都很小,我们整个库都可以全量集成。而增量则更多的时候是一种奢望,系统运行的越久,离线增量集成的问题就会暴露的越多。在这个时候,我要说:选择要大于努力,建议去看看实时集成是不是可以帮助到你。另外一个方面,我们回顾上一章节,实时集成集成小表并不划算,集成批量表会导致进程崩溃。

       所以,没有完美的工具,只有完美的方案。只有针对客户现场的实际情况,做出最适合客户的现场方案才是我们的最终选择。


目录
相关文章
|
4天前
|
SQL DataWorks NoSQL
DataWorks报错问题之datax mongodb全量迁移报错如何解决
DataWorks是阿里云提供的一站式大数据开发与管理平台,支持数据集成、数据开发、数据治理等功能;在本汇总中,我们梳理了DataWorks产品在使用过程中经常遇到的问题及解答,以助用户在数据处理和分析工作中提高效率,降低难度。
|
6天前
|
缓存 分布式计算 Apache
Apache Hudi与Apache Flink更好地集成,最新方案了解下?
Apache Hudi与Apache Flink更好地集成,最新方案了解下?
42 0
|
8天前
|
数据采集 DataWorks NoSQL
DataWorks问题之离线数据集成调用http接口进行数据采集如何解决
DataWorks是阿里云提供的一站式大数据开发与管理平台,支持数据集成、数据开发、数据治理等功能;在本汇总中,我们梳理了DataWorks产品在使用过程中经常遇到的问题及解答,以助用户在数据处理和分析工作中提高效率,降低难度。
34 1
|
9天前
|
分布式计算 DataWorks Java
DataWorks问题之数据集成导出分区表的全量数据如何解决
DataWorks是阿里云提供的一站式大数据开发与管理平台,支持数据集成、数据开发、数据治理等功能;在本汇总中,我们梳理了DataWorks产品在使用过程中经常遇到的问题及解答,以助用户在数据处理和分析工作中提高效率,降低难度。
23 0
|
2月前
|
SQL 关系型数据库 MySQL
基于 Flink CDC 打造企业级实时数据集成方案
基于 Flink CDC 打造企业级实时数据集成方案
|
3月前
|
消息中间件 关系型数据库 MySQL
Kafka Connect :构建强大分布式数据集成方案
Kafka Connect 是 Apache Kafka 生态系统中的关键组件,专为构建可靠、高效的分布式数据集成解决方案而设计。本文将深入探讨 Kafka Connect 的核心架构、使用方法以及如何通过丰富的示例代码解决实际的数据集成挑战。
|
3月前
|
消息中间件 DataWorks NoSQL
dataworks离线数据集成,源库或目标库是MC时,走的是Tunnel? 还是走的是datax啊?
dataworks离线数据集成,源库或目标库是MC时,走的是Tunnel? 还是走的是datax啊?
107 0
|
3月前
|
设计模式 缓存 Java
干翻Mybatis源码系列之第七篇:Mybatis提供的集成缓存方案
干翻Mybatis源码系列之第七篇:Mybatis提供的集成缓存方案
|
3月前
|
存储 DataWorks NoSQL
在DataWorks的数据集成中,对于Tablestore数据源的增量同步,你可以按照以下步骤进行配置:
在DataWorks的数据集成中,对于Tablestore数据源的增量同步,你可以按照以下步骤进行配置:
28 2
|
3月前
|
运维 BI 调度
新增离线集成任务列表,支持快速筛选任务并进行批量操作 【V3.13】
离线集成任务列表提供了一个展示集成任务详细信息的页面,便于查看集成任务的各类信息。同时还支持根据任务的各类属性进行筛选。还支持根据来源与目标数据源或数据表进行任务的查找与筛选。便于在一些业务变更的时候,能快速筛选到所有任务,进行查看或批量修改的操作,提高开发与运维的效率。

相关产品

  • 云原生大数据计算服务 MaxCompute