![]()
一 问题思考
在流量分析型产品的用户分析模块中，留存、互访、新老客构成等数据都是有效衡量用户粘性与促活召回的关键性指标；但是，我们发现在很多流量运营的业务场景中，留存分析建模都显著存在着设计和计算上的诸多问题，例如：各种历史库版本迭代的高额运维与存储成本、暴力计算、频繁计算、数据冷启动等问题。总结下来，有三个方面需要特别关注：
1、场景理解：在非常多的业务场景中，模型研发人员偏向于通过构建用户粒度的全量历史库，再去聚合用户的新老标签或历史累计次数，但关键问题是，在这些场景中基于历史行为计算的新老客标签和历史累计指标，并不适用于该业务场景下的精细化运营。比如，在用户增长领域的流失召回等场景策略中，长周期外仍然未有回访的用户显然不具备再运营的潜质（如180天等）；那么，相比基于历史库圈选新用户，改为基于动态滑动窗口的圈选策略，更具有可运营的潜质和解释性；并且，这种计算模式还可以有效地规避历史库回刷与冷启动问题。
2、计算模式：在计算模型的设计和模式构建上，大多数同学普遍缺少模型抽象与精细化设计。就累计去重指标或周期留存指标的计算实现来讲，大致有4种建模范式（想知道第5种请继续看下去）：
-
1. 历史库方式：基于T+1全量和当日增量构建全量历史库，基于历史库再聚合
-
2. 轻度聚合后再聚合：构建T+1的轻度聚合模型，多周期扫描再聚合
-
3. 历史周期计拉链：以固定时间窗口方式构建用户标签表，计算时关联标签表再聚合
-
4. 位图模式计算：以滑动时间窗口方式构建用户标签表，并以位图存储窗口周期信息
3、模型易用：以上模型的实现都存在一定的研发成本，需要有丰富的场景实践和经验积累。如果能够沉淀一套敏捷的标准化模型计算组件，让新人可以在分钟级就完成留存模型的智能研发，那么，就能以标准化的建模范式解决很多业务场景下的建模研发的效率问题。
此外，丰富的场景实践和持续的技术思考对于建模范式的演进都是非常重要的。在某个节点之前，我们曾认为位图设计已经是最优实践了，但是之后又在业务实践中发现很多场景中需要计算更长业务周期的用户新老标签或留存分析。这时候，由于基于二进制bigint存储的位图只能支持到64位，在180天等长周期留存计算时就会溢出，因此，就需要更加通用且高效的模型计算抽象。总之，能够高效支撑业务是最好的实践标准，驱动我们可以在建模范式上是不断超越和颠覆。
二 用户故事
蚂蚁版生意参谋是面向支付宝商家的重要对客产品，当时在20年12月份底，我们计划在2月份全量上线B站，留给研发的时间非常吃紧。而由于是对客产品，在架构设计、数据质量、产出时效等各个方面都有更高标准的要求。此外，我们也必须基于新的数据资产架构对蚂蚁生意参谋的产品数据体系进行全盘的重构与升级。其中，流量模块就涉及到了上文中提到的留存/互访/新老等关键指标的各类计算，我们需要在短时间内快速消化和解决存量的应用层链路中存在的很多问题。而最终我们通过用户留存的建模组件，以“重设计、快实现”的方式，在不到2天的时间内就高效完成了小程序、生活号和电子名片等整体数据链路的重构与升级，而且在模型设计、模型存储和模型治理等方面，也取得了很多核心改变。特别是，经过模型重构后，生意参谋的产品数据体系变得异常精简、收敛和高效。那么，我们是怎么做到的呢？接下来，我们就详细介绍留存建模组件的设计思路。
三 设计实现
-
目标抽象：用户留存模型的建模抽象与组件构建（支持超过64位图的1/7/30/180天等周期性PV-UV、留存、互访、新老客等指标的一站式计算）；
-
解决问题：存在大量的暴力扫描、低效计算、高昂历史回刷成本、数据冷启动等问题，而高效的留存模型的设计和研发门槛高（位图计算方式等）、缺少标准化的模型沉淀；
-
解决方案：提炼窗口滑动计算的建模范式、沉淀留存建模组件，显著提升研发效率（0.5人日），支持留存/互访/新老客等一站式计算；
1 模型抽象
-
维度抽象：用户留存模型是典型的轻度聚合模型DWS，显然要有聚合维度列。
-
设计抽象：滑动窗口设计：首先需要记录时间窗口内的用户行为分布（UV或PV），并通过某种数据结构来保存（如bit的Long值存储或者是Array<Bigint>）；其次要设计好窗口滑动的更新逻辑；
-
信息抽象：关键聚合信息，如新客的判断（N+1的时间窗口内，第N天首次访问就是新用户）；last_date的数值化信息保留（累计多少天未访问，有效减少存储）；累计访问天数（支持访问天数分布的人群分析）；
2 模型组件
建模组件的设计就是将模型抽象的结果参数化与模板化实现，具体实现细节不详述。
|
|
|
|
|
|
|
生意参谋等1/7/30/180天PV-UV、留存、互访、新老、交叉留存矩阵等指标的一站式计算
|
|
|
使用说明：你只需要配置基础信息，在作业中配置好【输入表】、【输出表】、【统计日期】和【时间窗口】4个参数，就可以自动实现你的用户留存模型，无需定义DDL、无需写留存模型的复杂代码。
jar -classpath 云端文件/res?id=xxx 类名.tools.OdpsCltWrapper "--class" <留存模型的jar包>"--properties-file" 云端文件/res?id=xxx "--conf" <spark配置文件> "--conf" "spark.executor.extraJavaOptions=-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8" "--conf" "spark.driver.extraJavaOptions=-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8""--master" yarn-cluster 云端文件/res?id=xxx "--rTable" <输入表的表名> "--wTable" <输出表的表名: 即构建的留存模型> "--stat_date" ${bizdate} "--window" 180;
3 下游使用
基于留存建模组件，基础的模型结构和计算范式都是标准且统一的，能够在一个参数化逻辑中一站式实现所有指标的计算，非常便捷；而下游相关的数据模型也变得异常精简、收敛和高效。
通过参数化视图统一封装指标的一体化计算逻辑，下游不需要关注计算中的复杂逻辑，直接面向消费，简洁易用，如：
insert overwrite table <留存矩阵_接口表> partition (dt='${bizdate}') select spm, date_row, date_col, retn_vst_uv_1dfrom 留存矩阵分析_参数化视图(留存模型table_name,'20211208')where spm = 'XXX';insert overwrite table <留存概览_接口表> partition (dt='${bizdate}') select vst_uv_1d,vst_uv_7d,vst_uv_30d,fst_uv_1d,retn_vst_uv_matrix,...from 基础留存分析_参数化视图(留存模型table_name,'20211208')where spm = 'XXX';
四 简要总结
核心改变：基于模型组件，可高效构建用户留存模型（0.5人日降低至2分钟），且支持超过64位图的留存/互访/新老指标的标准化计算、避免下游多周期扫描与重复计算，尤其相比历史库表可减少4倍存储（前：62字节 vs 后后：16字节）。
-
建标准：构建了基于滑动窗口实现的标准化留存模型，实现模型设计和数据计算上的改进，有效解决了历史库版本迭代的高额运维与存储成本、下游的多周期扫描、频繁计算和历史库冷启动等一系列问题。
-
提效率：研发效率显著提升（分钟级实现用户流量模型的标准化构建），让我们在及实现。
-
提效率：30min左右即可完成100亿的留存模型计算。
-
降存储：相比历史库设计可有效降低4倍存储、且信息更完备。
我们是蚂蚁集团商家数据团队，致力于构建支付宝商家生态的的实时/离线数据架构与资产管理、推进蚂蚁全局数据的合规治理与资产统一建设，我们在离线计算、实时计算、图计算等数据技术上都有深度实践，欢迎对有兴趣的同学加入我们！邮箱：fusen.wangfs@antgroup.com
想不想用代码做一些酷炫的事情？2022年，码上公益联合阿里巴巴公益基金会、阿里云开发者学堂、InfoQ发起“第益课”大学生技术公益实践计划，为高校大学生提供免费的技术课程及公益项目实践机会（等同于实习经验）。让我们一起用技术的力量，做公益的侠客，给世界带来一点点温暖的改变。点击阅读原文查看详情！
