作者 |  王富森

一、問題思考

在流量分析型產(chǎn)品的用戶分析模塊中，留存、互訪、新老客構(gòu)成等數(shù)據(jù)都是有效衡量用戶粘性與促活召回的關(guān)鍵性指標;但是，我們發(fā)現(xiàn)在很多流量運營的業(yè)務(wù)場景中，留存分析建模都顯著存在著設(shè)計和計算上的諸多問題，例如：各種歷史庫版本迭代的高額運維與存儲成本、暴力計算、頻繁計算、數(shù)據(jù)冷啟動等問題?？偨Y(jié)下來，有三個方面需要特別關(guān)注：

1.場景理解：在非常多的業(yè)務(wù)場景中，模型研發(fā)人員偏向于通過構(gòu)建用戶粒度的全量歷史庫，再去聚合用戶的新老標簽或歷史累計次數(shù)，但關(guān)鍵問題是，在這些場景中基于歷史行為計算的新老客標簽和歷史累計指標，并不適用于該業(yè)務(wù)場景下的精細化運營。比如，在用戶增長領(lǐng)域的流失召回等場景策略中，長周期外仍然未有回訪的用戶顯然不具備再運營的潛質(zhì)(如180天等);那么，相比基于歷史庫圈選新用戶，改為基于動態(tài)滑動窗口的圈選策略，更具有可運營的潛質(zhì)和解釋性;并且，這種計算模式還可以有效地規(guī)避歷史庫回刷與冷啟動問題。

2.計算模式：在計算模型的設(shè)計和模式構(gòu)建上，大多數(shù)同學(xué)普遍缺少模型抽象與精細化設(shè)計。就累計去重指標或周期留存指標的計算實現(xiàn)來講，大致有4種建模范式(想知道第5種請繼續(xù)看下去)：

• 歷史庫方式：基于T+1全量和當(dāng)日增量構(gòu)建全量歷史庫，基于歷史庫再聚合
• 輕度聚合后再聚合：構(gòu)建T+1的輕度聚合模型，多周期掃描再聚合
• 歷史周期計拉鏈：以固定時間窗口方式構(gòu)建用戶標簽表，計算時關(guān)聯(lián)標簽表再聚合
•  位圖模式計算：以滑動時間窗口方式構(gòu)建用戶標簽表，并以位圖存儲窗口周期信息

3.模型易用：以上模型的實現(xiàn)都存在一定的研發(fā)成本，需要有豐富的場景實踐和經(jīng)驗積累。如果能夠沉淀一套敏捷的標準化模型計算組件，讓新人可以在分鐘級就完成留存模型的智能研發(fā)，那么，就能以標準化的建模范式解決很多業(yè)務(wù)場景下的建模研發(fā)的效率問題。

此外，豐富的場景實踐和持續(xù)的技術(shù)思考對于建模范式的演進都是非常重要的。在某個節(jié)點之前，我們曾認為位圖設(shè)計已經(jīng)是最優(yōu)實踐了，但是之后又在業(yè)務(wù)實踐中發(fā)現(xiàn)很多場景中需要計算更長業(yè)務(wù)周期的用戶新老標簽或留存分析。這時候，由于基于二進制bigint存儲的位圖只能支持到64位，在180天等長周期留存計算時就會溢出，因此，就需要更加通用且高效的模型計算抽象?？傊?，能夠高效支撐業(yè)務(wù)是最好的實踐標準，驅(qū)動我們可以在建模范式上是不斷超越和顛覆。

二、用戶故事

螞蟻版生意參謀是面向支付寶商家的重要對客產(chǎn)品，當(dāng)時在20年12月份底，我們計劃在2月份全量上線B站，留給研發(fā)的時間非常吃緊。而由于是對客產(chǎn)品，在架構(gòu)設(shè)計、數(shù)據(jù)質(zhì)量、產(chǎn)出時效等各個方面都有更高標準的要求。此外，我們也必須基于新的數(shù)據(jù)資產(chǎn)架構(gòu)對螞蟻生意參謀的產(chǎn)品數(shù)據(jù)體系進行全盤的重構(gòu)與升級。其中，流量模塊就涉及到了上文中提到的留存/互訪/新老等關(guān)鍵指標的各類計算，我們需要在短時間內(nèi)快速消化和解決存量的應(yīng)用層鏈路中存在的很多問題。而最終我們通過用戶留存的建模組件，以“重設(shè)計、快實現(xiàn)”的方式，在不到2天的時間內(nèi)就高效完成了小程序、生活號和電子名片等整體數(shù)據(jù)鏈路的重構(gòu)與升級，而且在模型設(shè)計、模型存儲和模型治理等方面，也取得了很多核心改變。特別是，經(jīng)過模型重構(gòu)后，生意參謀的產(chǎn)品數(shù)據(jù)體系變得異常精簡、收斂和高效。那么，我們是怎么做到的呢?接下來，我們就詳細介紹留存建模組件的設(shè)計思路。

三 、設(shè)計實現(xiàn)

• 目標抽象：用戶留存模型的建模抽象與組件構(gòu)建(支持超過64位圖的1/7/30/180天等周期性PV-UV、留存、互訪、新老客等指標的一站式計算);
• 解決問題：存在大量的暴力掃描、低效計算、高昂歷史回刷成本、數(shù)據(jù)冷啟動等問題，而高效的留存模型的設(shè)計和研發(fā)門檻高(位圖計算方式等)、缺少標準化的模型沉淀;
• 解決方案：提煉窗口滑動計算的建模范式、沉淀留存建模組件，顯著提升研發(fā)效率(0.5人日)，支持留存/互訪/新老客等一站式計算;

1.模型抽象

• 維度抽象：用戶留存模型是典型的輕度聚合模型DWS，顯然要有聚合維度列。
• 設(shè)計抽象：滑動窗口設(shè)計：首先需要記錄時間窗口內(nèi)的用戶行為分布(UV或PV)，并通過某種數(shù)據(jù)結(jié)構(gòu)來保存(如bit的Long值存儲或者是Array);其次要設(shè)計好窗口滑動的更新邏輯;
• 信息抽象：關(guān)鍵聚合信息，如新客的判斷(N+1的時間窗口內(nèi)，第N天首次訪問就是新用戶);last_date的數(shù)值化信息保留(累計多少天未訪問，有效減少存儲);累計訪問天數(shù)(支持訪問天數(shù)分布的人群分析);

2.模型組件

建模組件的設(shè)計就是將模型抽象的結(jié)果參數(shù)化與模板化實現(xiàn)，具體實現(xiàn)細節(jié)不詳述。

Dataworks任務(wù)節(jié)點參考：

• 節(jié)點ID：發(fā)布后的ODPS任務(wù)節(jié)點號
• 節(jié)點名稱：留存模型的表名(可自定義指定)
• 節(jié)點類型：ODPS SQL

節(jié)點任務(wù)配置：

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" <輸出表的表名: 即構(gòu)建的留存模型> "--stat_date" ${bizdate} "--window" 180;

3.下游使用

基于留存建模組件，基礎(chǔ)的模型結(jié)構(gòu)和計算范式都是標準且統(tǒng)一的，能夠在一個參數(shù)化邏輯中一站式實現(xiàn)所有指標的計算，非常便捷;而下游相關(guān)的數(shù)據(jù)模型也變得異常精簡、收斂和高效。

通過參數(shù)化視圖統(tǒng)一封裝指標的一體化計算邏輯，下游不需要關(guān)注計算中的復(fù)雜邏輯，直接面向消費，簡潔易用，如：

--報表引用
insert overwrite table <留存矩陣_接口表> partition (dt='${bizdate}') 
select spm,
     date_row,
     date_col, 
     retn_vst_uv_1d
from 留存矩陣分析_參數(shù)化視圖(留存模型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 基礎(chǔ)留存分析_參數(shù)化視圖(留存模型table_name,'20211208')
where spm = 'XXX'
;

四、簡要總結(jié)

核心改變：基于模型組件，可高效構(gòu)建用戶留存模型(0.5人日降低至2分鐘)，且支持超過64位圖的留存/互訪/新老指標的標準化計算、避免下游多周期掃描與重復(fù)計算，尤其相比歷史庫表可減少4倍存儲(前：62字節(jié) vs 后后：16字節(jié))。

建標準：構(gòu)建了基于滑動窗口實現(xiàn)的標準化留存模型，實現(xiàn)模型設(shè)計和數(shù)據(jù)計算上的改進，有效解決了歷史庫版本迭代的高額運維與存儲成本、下游的多周期掃描、頻繁計算和歷史庫冷啟動等一系列問題。

提效率：研發(fā)效率顯著提升(分鐘級實現(xiàn)用戶流量模型的標準化構(gòu)建)，讓我們在及實現(xiàn)。

提效率：30min左右即可完成100億的留存模型計算。

降存儲：相比歷史庫設(shè)計可有效降低4倍存儲、且信息更完備。