怎么进入追信魔盒网站开发软件,深圳产品网站建设,找建设网站公司哪家好,上海网络优化方法简介#xff1a; ods层数据同步时经常会遇到增全量合并的模型#xff0c;即T-1天增量表 T-2全量表 T-1全量表。可以通过full outer join脚本来完成合并#xff0c;但是数据量很大时非常消耗资源。本文将为您介绍在做增量数据的增加、更新时如何通过full outer join改写lef…简介 ods层数据同步时经常会遇到增全量合并的模型即T-1天增量表 T-2全量表 T-1全量表。可以通过full outer join脚本来完成合并但是数据量很大时非常消耗资源。本文将为您介绍在做增量数据的增加、更新时如何通过full outer join改写left anti join来实现的最佳实践。 背景 ods层数据同步时经常会遇到增全量合并的模型即T-1天增量表 T-2全量表 T-1全量表。可以通过full outer join脚本来完成合并但是数据量很大时非常消耗资源。 insert overwrite table tb_test partition(ds${bizdate}) select case when a.id is not null then a.id esle b.id end as id ,if(a.name is not null, a.name, b.name) as name,coalesce(a.age, b.age) as age --这3种写法一样都是优先取delta表的字段from (select * from tb_test_delta where ds${bizdate} ) a full outer join (select * from tb_test where ds${bizdate-1} ) b on a.id b.id; 这种写法可实现新增和更新操作 新增是指增量表中新出现的数据而全量表中没有更新是指增量表和全量表中都有的数据但优先取增量表的数据覆盖历史表的数据。 如下图所示R2_1是增量表当天去重后增量数据M3是全量表前一天的数据而J4_2_3则是full outer join的执行图。将J4_2_3展开会发现里面将增量和全量进行了merge join当数据量很大1288亿条时会产生很大的shuffle开销。此时优化方案就是将full outer join改成 union all从而避免join shuffle。 优化模型 结论full outer join改成hash cluster left join union all可以有效地降低计算成本且有两种应用场景。先将模型进行抽象假设有a和b两个表a是增量表b是全量表 with a as ( select * from values (1,111),(2,two),(7,777) as (id,name) ) --增量,b as ( select * from values (1,),(2,222),(3,333),(4,444) as (id,name) ) --全量 场景1:只合并新增数据到全量表 left anti join相当于not in增量not in全量,过滤后只剩下完全新增的id对全量中已有的id不修改 --查询完全新增的id select * from a left anti join b on a.idb.id ; --结果如下 ------------------ | id | name | ------------------ | 7 | 777 | ------------------ --完全新增的合并全量表 select * from a --增量表 left anti join b on a.idb.id union all select * from b --全量表 --结果如下 ------------------ | id | name | ------------------ | 1 | | | 2 | 222 | | 3 | 333 | | 4 | 444 | | 7 | 777 | ------------------ 场景2:合并新增数据到全量表且更新历史数据 全量not in增量,过滤后只剩下历史的id然后union all增量既新增也修改 --查询历史全量数据 select * from b left anti join a on a.idb.id; --结果如下 ------------------ | id | name | ------------------ | 3 | 333 | | 4 | 444 | ------------------ --合并新增数据到全量表且更新历史数据 select * from b --全量表 left anti join a on a.idb.id union all select * from a ; --增量表 --结果如下 ------------------ | id | name | ------------------ | 1 | 111 | | 2 | two | | 7 | 777 | | 3 | 333 | | 4 | 444 | ------------------ 优化实践 步骤1表属性修改 表、作业属性修改,对原来的表、作业进行属性优化可以提升优化效果。 set odps.sql.reducer.instances3072; --可选。默认最大1111个reducer,1111哈希桶。 alter table table_name clustered by(contact_id) sorted by(contact_id) into 3072 buckets;--必选 步骤2按照上述模型的场景1 或者 场景2进行代码改造。 这里先给出代码改造后的资源消耗对比 原来的full outer jionleft anti join初始化原来的full outer jionleft anti join第二天以后时间消耗8h30min38s1h4min48s7h32min30s32min30scpu消耗29666.02 Core * Min65705.30 Core * Min31126.86 Core * Min30589.29 Core * Minmem消耗109640.80 GB * Min133922.25 GB * Min114764.80 GB * Min65509.28 GB * Min 可以发现hash cluster分桶操作在初始化有额外的开销主要是按主键进行散列和排序但是这是值得的可一劳永逸后续的读取速度非常快。以前每天跑需要8小时现在除了分桶初始化需要1小时以后每天实际只需要30分钟。 初始化执行图 图1 M2是读全量表。 M4是读取增量表,在场景2的模型中增量表被读取了两次其中 R5_4是对主键去重row_number后用于后面的union all里面包含了所有的增量数据R1_4是对主键去重row_number后用于left anti join里面只包含了主键。J3_1_2是left anti join,将它展开后看到这里还是有mergJoin但是这只是初始化的操作后面每天就不会有了。展开后如图2。R6_3_5是将增量和全量进行union all展开后如图3。R7_6则是将索引信息写入元数据如图3的MetaCollector1会在R7_6中sink。 因此图1中除了R5_4和R1_4是去重必须的有shuffle。还有J3_1_2和R6_3_5这两个地方有shuffle。 图2 图3 第二天以后的执行图 图1 同上图1中的R3_2和R1_2是对增量去重必要对操作有shuffle这里忽略。 初始化执行图的J3_1_2和R6_3_5已经被合并到了M4_1_3将其展开后如图2。即left anti join 和 union all这两步操作在一个阶段完成了且这个阶段是Map 任务M4_1_3而不是Join任务或Reduce任务。而且全量表不在单独占用一个Map任务也被合并到了M4_1_3因此整个过程下来没有shuffle操作速度提升非常明显。也就是说只需要一个M4_1_3就能完成所有到操作直接sink到表。 R5_4则是将索引信息写入元数据如图2的MetaCollector1会在R5_4中sink。 图2 原文链接 本文为阿里云原创内容未经允许不得转载。