简介：回到十多年前，增量加工这个办法并不是一种须要特地须要提出的办法，因为关系数据库的存储与计算性能非常无限（即使是 MPP 数据库平台也不是全都是做全量加工），增量加工是最广泛的形式。本文讲述了如何在 MaxCompute 上用与关系数据库的不同的形式做增量数据的加工。
1. 增量加工
回到十多年前，增量加工这个办法并不是一种须要特地须要提出的办法，因为关系数据库的存储与计算性能非常无限（即使是 MPP 数据库平台也不是全都是做全量加工），增量加工是最广泛的形式。
数据库系统是反对事务的，ACID（原子性、一致性、隔离性、持久性）四大个性能够完满的反对在一个数据表上同时做更新、删除、插入操作。数据库系统的数据存储是到每一个 4K 或者 8K 这种大小的数据块上的，具体的统计信息与索引构造都容许咱们高效来做增量数据处理。
1.1. 问题简述
在以后的 MaxCompute 这种分布式文件系统上，这些操作都变得不容易了。咱们的数据块曾经是 64MB，不是 KB 这个量级。咱们也没有索引这种减速从一千万数据中找到五十行数据的构造。
那么咱们怎么在 MaxCompute 做增量加工呢？说实话，不太好做。因为没有索引构造，咱们每一次的解决都是全量数据检索。如果还是跟之前在关系数据库一样频繁的提交，岂但无奈体现增量加工的性能与资源优势，反而成为了劣势。（如果咱们还想应用关系数据库反对的 delete、update 这些个性，能够看下 MaxCompute 公共云近期上线的新个性“Transactional 表”。）
那么咱们要不要做呢？总结一句话：能做的中央还是能够做一下，然而不要勉强，不要大规模的去做，毕竟做增量加工不容易。
2. 解决方案
增量加工的前提是咱们获取到了增量数据，相比全量数据增量数据是一个更小的汇合，而后咱们心愿利用这个小增量汇合来实现数据加工的过程而不是应用全量，这样就能够更疾速、更节约的实现整个数据加工过程。
然而增量加工在 MaxCompute 总结为两个场景：
场景一，全量加工所需资源无奈满足时效性要求，性能急需优化；
场景二，增量加工逻辑简略，相比全量加工性能劣势显著；
2.1. 加工准则
而后咱们须要确立一些应用增量加工的准则，冲破或者不恪守这些准则都是不合理或者不正确的。
一、增量表（增量状态[U\D\I\K]，数据更新工夫）；
二、2 张增量表不能间接关联，必须要有至多一张表是全量；
三、增量加工产出的后果表，还须要记录增量状态和数据更新工夫；
四、多个表关联状况下，须要取多个表的增量标识，只有某一个表的关联行是增量就应用该表增量标识；
五、只有主表或则 INNER JOIN 的表的 INSERT 和 DELETE 状态能够传递到下一层，其余表的增量状态都是 UPDATE；
2.2.MERGE 逻辑
增量集成到 MaxCompute 平台的数据落地后，须要做一次 MERGE 才会产生 ODS 层的全量数据。所以，MERGE 逻辑是最简略和经典的增量加工逻辑。最简略的 MERGE 逻辑如下：
INSERT OVERWRITE TABLE table_old PARTITION(ds=’${ds}’)
SELECT (ds)?+.+
FROM table_old a – 全量表
LEFT ANTI JOIN
table_new b – 增量表
ON a.pk = b.pk
AND b.ds = ‘${ds}’
WHERE a.ds = ‘${lastdate}’
UNION ALL
SELECT b.*
FROM table_new b
WHERE b.ds = ‘${ds}’
— AND b.operation not in(‘D’)
;
这个逻辑应用了一个 JOIN 加上一个 UNION 实现了一个 MERGE 逻辑，把增量合并成一份全量。这里有一个选项【– AND b.operation not in(‘D’)】，是否要把物理删除从以后全量表中删除，能够依据理论业务需要抉择。
2.3.
业务计算逻辑
MERGE 逻辑是最简略的一个波及到增量的逻辑，然而理论业务计算逻辑要比这个场景更加简单一些。
2.3.1.2 张增量表的解决
咱们在 MERGE 外面尽管也是 2 张表，然而其实这是一张表的增量与全量。如果是 2 张增量表，那么该如何解决呢。基于两张增量表无奈关联的准则，咱们必须引入全量表。
1. 咱们须要利用 2 张表的当日增量与全量，也就是说有 4 张表参加计算。
2. 如果不想让全量间接关联，那么就须要先找到两个增量表的主键的并集。而后从两个表的全量中拆出这个并集的汇合，再去关联。
逻辑如下：
— ta_add ta 表的增量表
— ta_all ta 表的全量表
— tb_add tb 表的增量表
— tb_all tb 表的全量表
— 留神这个场景应用了 mapjoin，增量表的数据量是有限度的
with tx_add as(
select distinct pk from(
select pk from ta_add where ds = ‘${ds}’
union all
select pk from tb_add where ds = ‘${ds}’)t)
,ta_add2(
select /+mapjoin(t2)/ t1.*
from ta_all t1 join tx_add t2 on t1.pk=t2.pk
where t1.ds = ‘${ds}’
)
,tb_add2(
select /+mapjoin(t2)/ t1.*
from tb_all t1 join tx_add t2 on t1.pk=t2.pk
where t1.ds = ‘${ds}’
)
insert overwrite table tc_add partition (ds=’${ds}’)
select *
from ta_add2 t1 join tb_add2 t2 on t1.pk=t2.pk
;
这个逻辑利用了增量表比拟小，能够利用了 MAPJOIN 的个性，能够疾速的产出两个能够关联的并集再去关联。因为防止了大表的重散布，所以，能够大幅晋升运行效率，升高资源耗费。（在这里增量的意义是表真的很大，如果全量是两张百万级的表，倡议测试一下性能，可能间接关联更简略效率更高。所以，在 MaxCompute 做增量加工计算很多场景是没必要的。）
2.3.2.2 张以上增量表的解决
咱们个别说的增量加工的表还是指业务表，而不是代码表、参数表这种小表。这种万级的小表，增量与全量关联计算的性能差距能够疏忽。百万级这种量级的表，增量计算也是意义不大的。咱们看下上一大节那段简短的逻辑，其实本来只须要 2 行就能够，当初曾经变得如此的简单。2 张以上的表，如果应用同一 PK 关联，2 张以上表的这个逻辑还是能够沿用的。如果有多个不同的关联 PK，这个问题就从一维搞成了二维，除非切实不得已，不倡议再去搞增量加工了。
我在这个优化工作的过程中遇到的场景，就是远远大于 2 张以上的表的增量加工，并且关联的 PK 也是多个。原来开发者选取了主表作为增量表，其余的表都是全量表的计算逻辑。因为这是一个分钟级的工作，原来的开发者应该还是心愿从性能的角度做一些高效的设计。
然而在这个场景，第一主表并不是太大（百万级），相同左关联的表有上千万的。所以，我并未看到这个增量加工带来微小性能晋升的意义。第二主表的增量是通过一个指定的工夫区间来辨认近一个工夫片段的，这种在集成的源是源零碎的时候是可行的。然而这里刚好是一个不稳固的备库的备库，所以，应用固定工夫区间可能会因为数据提早导致未被辨认为增量。
索性，我就间接改为全量加工了，这样就没问题了。然而这样就无奈辨认出哪些数据是加工都的增量了，这就波及到上面要提到的增量推送的问题。
2.4. 增量推送逻辑
有两种思路能够获取须要推送的增量，一种是从原始增量开始就始终保留增量标记字段，另一种是从最终后果中利用 T 和 T + 1 两个全量比对出增量。在下面提到的场景，咱们就遇到了第一个场景，咱们须要在加工环节放弃增量辨认标记，并对这个字段在关联后的后果进行计算。
2.4.1. 增量标记计算
增量标记要用来计算，肯定是能够计算的。在上一节我提到零碎有提早业务的数据工夫是不牢靠的了，那如何来判断增量呢？咱们的集成工作其实很难去从数据库的备库获取牢靠的工夫戳，然而咱们本次集成的增量数据肯定是一个确定的增量汇合，所以，这个 ETL_DATE（个别是咱们 dataworks 的 bizdate 或者 yyyymmddhhmiss）就是咱们在 MaxCompute 批量做加工可用的增量工夫戳。数据库同步工具辨认进去的数据的变动状态有增、删、改、主键更新（I、D、U、K）四种，咱们是能够间接利用的。
所以，咱们在这里应用的逻辑如下:
select …
,case when a.etl_partition =’${ds}’ then a.etl_partition
when b.etl_partition ='${ds}' then b.etl_partition
...
else a.etl_partition end as etl_date
,case when a.etl_partition =’${ds}’ then a.operation
when b.etl_partition ='${ds}' then 'U'
...
else a.operation end as operation
from tablea a
left join tableb on a.pk=b.pk
…
where …;
所以这种形式是能够把增量状态放弃上来的，然而因为这个计算后的后果其实一次次的叠加后，可能就不晓得对不对了。所以，在具体的业务场景还要具体的去看。
2.4.2. 全字段比对
全字段比对是一种暴力的计算方法，不须要增量加工，我也能够计算出增量。并且这种计算结果还是实在牢靠的，绝对于一个通过多层计算后的业务后果表来说，更是如此。
全字段比对逻辑如下：
一、T+ 1 日表比 T 日表多的记录，INSERT 状态；
二、T 日表比 T + 1 日表多的记录，DELETE 状态；
三、T+ 1 日表比 T 日表，关联后雷同主键的非主键字段值不统一的，UPDATE 状态；
这个比对非常耗费计算资源，尤其是一些最细业务粒度的交易表、事件表。然而对一些用户表这种表来说，问题倒是不大。比对逻辑如下：
— I
select a.*,’I’ as operation
from table1 a
left join table1 b on a.pk = b.pk and b.ds=’${lastdate}’
where a.ds=’${ds}’
and b.pk is null
;
— D
select a.*,’D’ as operation
from table1 a
left join table1 b on a.pk = b.pk and b.ds=’${ds}’
where a.ds=’${lastdate}’
and b.pk is null
;
— U
select a.*,’U’ as operation
from table1 a
join table1 b on a.pk = b.pk and b.ds=’${ds}’
where a.ds=’${lastdate}’
and(coalesce(b.col,”)<>coalesce(b.col,”) — 字符
or coalesce(b.col,0)<>coalesce(b.col,0) — 数值
or coalesce(b.col,’0001-01-01′)<>coalesce(b.col,’0001-01-01′)) — 日期
;
全字段比对看起来其实并不柔美，切实是有点粗犷。当然你兴许会有更容易辨认增量的形式，能够多试试，这将是你保底的办法。
3. 实际总结
通过下面的内容，咱们对增量加工的办法有了肯定理解。心愿我文中提到的办法能帮忙大家在日后在我的项目中正确的应用增量加工的办法，并通过这个办法在局部场景取得显著的性能改良。另外我还是要提到一点，就是增量加工逻辑比全量加工更加简单，并且还会遇到更为简单的异样排查、补数据等保护等问题。大家在理论我的项目中，肯定要衡量好利弊，再定夺计划。
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。