本文共 2204 字，大约阅读时间需要 7 分钟。
在电子商务公司（如淘宝），对用户的数据分析的角度和思路可谓是应有尽有、层出不穷。所以在电商数据仓库和商业分析场景里，经常需要计算最近N天访客数、最近N天的购买用户数、老客数等等类似的指标。这些指标有一个共同点：都需要根据用户在电商平台上（或网上店铺）一段时间积累的数据进行计算（这里讨论的前提是数据都存储在MaxCompute上）。
一般情况下，这些指标的计算方式就是从日志明细表中计算就行了，如下代码计算商品的最近30天访客数：select item_id --商品id ,count(distinct visitor_id) as ipv_uv_1d_001 from 用户访问商品日志明细表 where ds <= ${bdp.system.bizdate} and ds >=to_char(dateadd(to_date(${bdp.system.bizdate},'yyyymmdd'),-29,'dd'),'yyyymmdd') group by item_id 但是当每天的日志量很大时，上面代码存在一个严重的问题，需要的Map Instance个数太多，甚至会超过99999个Instance个数的限制，Map Task就没有办法顺利执行，更别说后续的操作了。为什么Instance个数需要那么多呢？原因：每天的日志数据很大，30天的数据量更是惊人。这时候Select 操作需要大量的Map Instance，结果查过了Instance的上限，代码无法运行
如何计算长周期的指标，又不影响性能？
1. 多天汇总的问题根源是数据量的问题，如果把数据量给降低了，就可以解决这个问题了。
2. 减少数据量最直接的办法是把每天的数据量都给减少，因此需要构建临时表，对1d的数据进行轻度汇总，这样就能去掉很多重复数据，减少数据量。
1. 构建中间表，每天汇总一次，比如对于上面的例子，构建一个item_id+visitor_id粒度的中间表
2. 计算多天的数据，依赖中间表进行汇总
例子如下：
step1:构建item_id+visitior_id粒度的日汇总表，记作A
insert overwrite table mds_itm_vsr_xx(ds='${bdp.system.bizdate} ')select item_id,visitor_id,count(1) as pvfrom （ select item_id,visitor_id from 用户访问商品日志明细表 where ds =${bdp.system.bizdate} group by item_id,visitor_id ）a setp2:对A进行30天汇总
select item_id ,count(distinct visitor_id) as uv ,sum(pv) as pv from mds_itm_vsr_xx where ds <= '${bdp.system.bizdate} ' and ds >= to_char(dateadd(to_date('${bdp.system.bizdate} ','yyyymmdd'),-29,'dd'),'yyyymmdd') group by item_id 上面讲述的方法，对每天的访问日志明细数据进行单天去重，从而减少了数据量，提高了性能。缺点是每次计算多天的数据的时候，都要N个分区的数据，那么能不能有一种方式，不需要读取N个分区的数据，而是把N个分区的数据压缩合并成一个分区的数据，让一个分区的数据包含历史数据的信息。业务上是有类似场景的，有如下方式：
例子：求最近1天店铺商品的老买家数，老买家数的算法定义为：过去一段时间有购买的买家（比如过去30天）。
一般情况下，老买家数计算方式：select item_id --商品id ,buyer_id as old_buyer_idfrom 用户购买商品明细表 where ds < ${bdp.system.bizdate} and ds >=to_char(dateadd(to_date(${bdp.system.bizdate},'yyyymmdd'),-29,'dd'),'yyyymmdd') group by item_id ,buyer_id 改进思路：
1. 维护一张店铺商品和买家购买关系的维表记作表A，记录买家和店铺的购买关系，以及第一次购买时间，最近一次购买时间，累计购买件数，累计购买金额等等信息 2. 每天使用最近1天的支付明细日志更新表A的相关数据 3. 计算老买家时，最需要判断最近一次购买时间是否是30天之内就行了，从而做到最大程度上的数据关系对去重，减少了计算输入数据量转载地址：http://nochx.baihongyu.com/