【深入MaxCompute】人力家：用MaxCompute 事务表2.0主键模型去重数据持续降本增效

简介：MaxCompute新增Transaction Table2.0（下文简称事务表2.0)表类型在2023年6月27日开始邀测，支持基于事务表2.0实现近实时的增全量一体的数据存储、计算解决方案。

作者：石玉阳人力家高级数据研发工程师

业务简介

人力家是由阿里钉钉和人力窝共同投资成立，帮助客户进入人力资源数字化，依靠产品技术创新驱动战略的互联网公司。公司主要提供包括人事管理、薪酬管理、社保管理、增值服务在内的人力资源SaaS服务，加速对人力资源领域赋能，实现人力资源新工作方式。目前已服务电子商务、零售服务等领域的多行业客户。

人力家是一家典型的创业公司，目前处于一个竞争激烈的市场环境中，公司具有多产品性质，每个产品的数据具有独立性，同时为了配合内部CRM数据需求，更好地把数据整合，对于数仓团队来说是一个不小的挑战，对于数仓团队要求的是稳，准，及时响应。需要数仓团队既要满足内部的数据需求，也需要在计算的成本上实现优化。

业务痛点

在使用阿里云大数据计算服务MaxCompute过程中发现随着存量数据增加，增量数据去重成本越来越大，具体分析发现有如下4个原因

 增量数据量级少

公司虽然是多产品，但每天新增的用户数据和历史变化的数据量相对于历史全量数据的量级（GB）比较下处于较小的数据量级（MB）。

 历史数据二次计算

对于增量数据去重，每天利用昨日历史全量+今日新增数据开窗去重计算，但历史全量数据需要更新的数据部分其实很少，每次都需要把历史数据拉出来进行开窗去重计算，这无疑一笔比较大的计算成本。

 开窗去重计算成本大

使用row_number函数开窗去重取得业务主键的最新数据需要把昨日历史数据+今日数据合并计算，用户表有亿级别大小，但为了数据去重节省存储成本和后续的建模运算，这部分成本是偏大的，其实大部分历史数据没有更新，本质上是不需要再次参与运算处理，每天一次的用户表去重单条SQL预估费用达到4.63元（按量付费）。

 全量拉取成本大

如果每天全量拉取业务库数据，数据量是亿级别，但其实更新的数据量级少，对于业务端的db压力大，严重影响业务端db性能。

 Transaction Table2.0数据去重改进

MaxCompute新增Transaction Table2.0（下文简称事务表2.0)表类型在2023年6月27日开始邀测，MaxCompute支持基于事务表2.0实现近实时的增全量一体的数据存储、计算解决方案。人力家数仓研发团队开始第一时间了解其特性和功能，人力家数仓团队发现其特性主键模型可以用来进行数据去重，减少开窗计算成本问题，主要实现方式如下。

每日增量用户基础信息开窗去重；由于主键表的主键不能为空，需要过滤出业务主键为空的数据；把每日增量数据开窗去重后的数据直接insert into 主键表，系统会自动进行按照业务主键进行去重计算。

 具体改进实践措施

整体对比

成本和计算时间对比

1、建表语句和插入更新语句

更新语句

2、成本和计算

分区表去重运行预估成本：