云享团——基于大数据开发套件的增量同步策略

“云享团”开团了，不是团购哦，是满满的技术干货，在接下来的日子云享团的技术成员会为技术爱好者持续带来技术干货分享。请大家奔走相告，一起关注起来

因为近期遇到用户在做ETL操作导入数据到MaxCompute的时候，对如何设置数据同步策略有疑惑，所以今天第一波我们来聊一下数据的同步策略，根据数据的特性，看看哪些数据适合增量同步，哪些适合全量同步，又是如何实现的？请认真看完下面的介绍，这些问题都不是事儿。

我们把需要同步的数据，根据数据写入后是否会发生变化分为：会变化的数据（人员表比如说，人员的状态会发生变化）和不会发生变化的数据（一般是日志数据）。针对这两种场景，我们需要设计不同的同步策略。这里以把业务RDS数据库的数据同步到MaxCompute为例做一些说明，其他的数据源的道理是一样的。根据等幂性原则（也就是说一个任务，多次运行的结果是一样的，这样才能支持重跑调度。如果任务出现错误，也比较容易清理脏数据），我每次导入数据都是导入到一张单独的表/分区里，或者覆盖里面的历史记录。

备注说明：本文的测试时间是2016-11-14，全量同步是在14号做的，同步历史数据到ds=20161113这个分区里。至于本文涉及的增量同步的场景，配置了自动调度，把增量数据在15号凌晨同步到ds=20161114的分区里。数据里有一个时间字段optime，用来表示这条数据的修改时间，从而判断这条数据是否是增量数据。

不变的数据

对应这种场景，因为数据生成后就不会发生变化，我们可以很方便地根据数据的生成规律进行分区，比较常见的是根据日期进行分区，比如每天一个分区。以下是测试数据：

这里有2条数据，当成历史数据。我先做一次全量数据同步，到昨天的分区里。配置方法如下：

先在MaxCompute创建好表:

然后配置了历史数据数据同步：

11

因为只需要跑一次，做以下测试就可以了。测试后到数据开发里把任务的状态改成暂停（最右边的调度配置了）并重新发布，免得明天他继续跑了。之后到MaxCompute里看一下结果：

测试通过后。往Mysql里多写一些数据作为增量数据：

然后配置同步任务如下。需要特别注意的是数据过滤这的配置，通过这个配置，可以在15号的凌晨的同步的时候，把14号全天新增的数据查询出来，然后同步到增量分区里。

这个任务需要发布，设置调度周期为每天调度，第二天过来一看，MaxCompute里的数据变成了：

会变的数据

如人员表、订单表一类的会发生变化的数据，根据数据仓库的4个特点里的反映历史变化的这个特点的要求，我们建议每天对数据进行全量同步。也就是说每天保存的都是数据的全量数据，这样历史的数据和当前的数据都可以很方便地获得。不过如果真实的场景下因为某些特殊情况，需要每天也只做增量同步，因为MaxCompute不支持Update语句来修改数据，只能用别的一些方法来实现。两种同步策略的具体方法如下：

首先我们需要造一些数据:

• 每天全量同步

每天全量同步同步比较简单:

然后配置同步为：

测试后结果为

因为每天都是全量同步，没有全量和增量的区别，所以第二天就能看到数据结果为

如果需要查询的话，就用where ds =‘20161114’来取全量数据即可了。

• 每天增量同步

非常不推荐用这种方法，只有在极特殊的场景下才考虑。首先这种场景不支持delete语句，因为被删除的数据无法通过SQL语句的过滤条件查到。当然实际上公司里的代码很少直接有直接删除数据的，都是使用逻辑删除，那delete就转化成update来处理了。但是这里毕竟限制了一些特殊的业务场景不能做了，当出现特殊情况可能导致数据不一致。另外还有一个缺点就是同步后要对新增的数据和历史数据做合并。具体的做法如下：

首先需要创建2张表，一张写当前的最新数据，一张写增量数据:

然后全量数据可以直接写入结果表：

结果如下：

这个只要跑一次的，记得跑好后要暂停掉。

然后把增量数据写入到增量表里：

结果如下

然后做一次合并

最终结果是：

可以看到，delete的那条记录没有同步成功。

对比以上两种同步方式，可以很清楚看到两种同步方法的区别和优劣。第二种方法的优点是同步的增量数据量比较小，但是带来的缺点有可能有数据不一致的风险，而且还需要用额外的计算进行数据合并。如无必要，会变化的数据就使用方法一即可。如果对历史数据希望只保留一定的时间，超出时间的做自动删除，可以设置Lifecycle。

本文的作者技术专家“传学”，一直从事大数据技术支持工作，后续会持续带来大数据的干货分享，如果有什么疑问可以留言或者通过在线工单联系哦。（敏感业务信息不要公开评论哦）