1 前言
我在上一篇中介绍了实时集成与离线集成该怎么选择，接着介绍一下离线集成中的增量与全量的选择问题。
要设计方案，我们先分析一下数据产生的方式。我们把音视频流这种非结构化的数据集成从这里排除出去，因为这种音视频流一般都是专业的厂商和系统来处理。我们围绕数据分析领域常见的半结构化、结构化数据来看。
结构化和半结构化数据主要来源于各种设备和系统中运行的软件，包括写入各种数据库的数据、服务器中的日志。如果数据本身可以实时传输过来，那么我们就尽可能采用这种方式，但是实际工作中更多的场合是离线。尤其是项目的一期，更容易使用离线集成。
实时集成就相当于收快递，需要商家和物流企业先期投入大量建设，才能让快递便捷的传输到你手里。而这种什么都准备好的情况，大部分时候都是企业IT建设相对成熟的情况下才有。
日志这种文件流，如果采用实时采集，就属于实时集成范围。如果离线传输，就是传个文件，本身就没有太多需要讲述的。下面我们就讨论下从数据库中实施离线集成的方法。
2 数据库的数据
一提到传统数据库，就想到了结构化数据。但是数据库其实可以存储各种能存储的下的数据，比如音视频文件其实可以存储到LOB类型的二进制大对象字段中。
而半结构化数据，可以存储到string、text、CLOB等字符型二进制大对象字段中。工业控制系统产生的时序数据，也可以存储到数据库中。而数据库中的数据操作有插入、更新、删除，不同种类的操作会对集成有影响。
如果要对一个数据库做全库的集成，首先要决定哪些表是我们要入仓的。一定不要不经分析就把数据集成到数据仓库或者数据中台中。按照维度建模的理念，需要以需求为导向去构建模型，所以，集成的数据表一定是要明确有需求。这样我们就能确定一个范围，而不是全部。
划定范围，我们就会遇到非结构化数据入库的问题，因为MaxCompute本身是不支持大字段的，最长的字段长度是string，只有8M。至于数据库的LOB存储什么，五花八门，我见过照片、音频、Word文档、这些要集成，统统都需要传输到OSS，而不是MaxCompute。目前这种数据，还需要单独开发程序去集成到OSS。
剩下的我们就可以理解为结构化和半结构化数据了，一般能用string存的下的都可以集成到MaxCompute。例如一些XML、JSON半结构化数据，之前在数据库是存储在CLOB类型的字段中的，但是本身并不是超过8M。
接下来我们就需要评估该如何集成数据了-增量还是全量。
3 增量还是全量
回顾之前在实时还是离线的章节总结的集成原则。
集成原则：
1 费用紧张，资源有限，尽可能使用离线集成。
2 批处理数据（主要指源端数据是批量产生，或者双十一式爆发式产生）集成，尽量走离线。如果确实预算非常充足，资源非常丰富，也可以走实时集成（很多时候，源端都可能扛不住）。
3 交易型数据集成，尽量走实时，如果资源有限可以走离线。
4 大表，例如数据超过200W、存储超过1G，尽量走实时，这种表一般在业务系统中数量不会超过表数量的20%。离线集成时效性很难满足要求，当然也不是不行。一般离线集成的表在1-10亿这个级别也是可以一战（与系统资源相关）。再大基本上就很难了，集成时间过久，业务系统没有足够的快照空间，事务会报错，集成就会失败。
5 小表，例如常年不动的代码表，10W以下的小表，大概都能在30秒-3分钟内完成，建议走离线。毕竟实时挺贵，这些小表，还是打包搞过来比较适合。
我们看到我把数据分为“批处理”、“交易型”、“大表”、“小表”。很明显，“批处理”和“交易型”是一个对照组，“大表”和“小表”是一个对照组。
先看下什么是“批处理”，主要是指数据并不是由业务系统的业务事件产生，而是由数据库或者应用后台运行的数据运行，其特点是一次操作的数据或者产生的数据是多条（几万到数亿）记录。“批处理”操作主要在做后台数据库版本发布的批量运维，夜间批量做数据处理，几个表关联生成一张新的表。这种操作瞬时产生大量的数据操作，少则几万，多则数亿，且发生时间相对短暂。对应的“交易型”则是实时发生，是由实际的业务发生时产生。并不是定时任务和运维人员提交到数据库的，是由应用提交到数据库的。
“大表”和“小表”需要画一条线，根据数据库系统的能力来评估。一般按照二八原则，或者一九。就是说一般数据库中90%表都是小表，根据数据库的规模，可以是10万也可以是100万。
1.全量集成
先说大小表，这个比较简单，一旦划定了大小表。就可以确定，小表是可以全部使用全量集成的。所以，这个边界是全量离线集成的边界。剩下的大表，就困难了。大表的意思就是全量集成不能完成，或者对数据库的负载过大，搞不定。这部分就需要考虑增量集成了。
2.增量集成
因为小表全量集成很暴力了，无所谓什么，都能集成过来。而大表的增量要怎么获取呢？真的很难。我有一句总结：没有一个业务系统的时间戳字段是可信的。大家可以去证明我是错误的，我的见识是浅薄的，但是这就是从业十多年的我的见识。
首先，增量集成需要数据库表不能有物理删除，这很难实现。即便业务系统在设计之初有这种设计，也难以避免后台人工运维引入非正常操作问题。
其次，标识数据被更新和插入的时间字段（时间戳）不可信。除了业务系统可能并不更新这个字段外，还同样存在人工运维引入非正常操作的问题。
3.批处理表的增量集成
即便如此，仍然有表，是可以容易实现增量识别的，而这种表往往还是大表。我们前面提到的“批处理”表就是这种表，因为这类表是批量写入的，操作频次是有限且是批量的（常见的数据交换表也是这种表）。这种表的数据，较为容易获得增量。
方法：
- 找到主键。因为增量数据需要与全量合并，所以主键非常重要。
- 了解数据写入特征。数据变动的范围多大，哪个字段是每日生成新数据的业务日期字段，这关系到增量集成的增量时区范围多大。例如，会更新当前月的数据，会更新最近N天的数据。
- 了解业务。为什么会产生这样的数据，业务是什么，数据该如何使用。
- 调研数据。从数据中验证之前得到的信息，是否完全正确，这非常重要。最经常的问题就是数据变动的范围，与描述不一致。这是因为调研总是短暂的，而数据不会骗人。例如运行了一个历史日期的数据，例如过了一个假期才处理问题。
- 事件表的增量集成
还有另外一种表，自然就可以做到增量识别。这类表就是事件型表，这类表只有insert，没有update和delete。例如刷了一次门禁卡。
到这里，我其实并没有解决所有表的集成。我只解决了小表、部分大表（批量表、事件表），这就是现实。大部分时候，我们只能采取加大离线集成的并行度，并忍受数个小时离线集成时长。而离线集成很难解决的这些表的集成，往往也是最适合实时集成的表。这就是我给的答案，离线集成不完美，解决不了我们获取数据的完整性的问题。
4 总结
全量和增量都是一种选择，如果表都很小，我们整个库都可以全量集成。而增量则更多的时候是一种奢望，系统运行的越久，离线增量集成的问题就会暴露的越多。在这个时候，我要说：选择要大于努力，建议去看看实时集成是不是可以帮助到你。另外一个方面，我们回顾上一章节，实时集成集成小表并不划算，集成批量表会导致进程崩溃。
所以，没有完美的工具，只有完美的方案。只有针对客户现场的实际情况，做出最适合客户的现场方案才是我们的最终选择。
本文为阿里云原创内容，未经允许不得转载。