本项目教程笔记源自多易教育《Titan综合数据仓库与数据运营系统》,在CSDN学院有相关视频教程购买链接,大数据企业级项目实战–Titan大型数据运营系统
本项目课程是一门极具综合性和完整性的大型大数据项目实战课程,课程项目的业务背景源自各类互联网公司对海量用户浏览行为数据和业务数据分析的需求及企业数据管理、数据运营需求。
学完本课程,你将很容易就拿到大数据数仓建设或用户画像建设等岗位的OFFER
本课程项目涵盖数据采集与预处理、数据仓库体系建设、用户画像系统建设、数据治理(元数据管理、数据质量管理)、任务调度系统、数据服务层建设、OLAP即席分析系统建设等大量模块,力求原汁原味重现一个完备的企业级大型数据运营系统。
跟随项目课程,历经接近100+小时的时间,从需求分析开始,到数据埋点采集,到预处理程序代码编写,到数仓体系搭建…逐渐展开整个项目的宏大视图,构建起整个项目的摩天大厦。
次日留存率定义:
1)次日留存用户:T日新增的用户,在T+1日再次出现的人,就叫T日的次日留存的用户
2)次日留存率:(次日留存人数/T日新用户数)就叫
N日留存定义:
1)T日新增的用户,在T+N日再次出现的人,就叫T日的N日留存用户
报表示例1
思路分析
经过分析,发现,新鲜度计算其实本质上就是留存计算!只不过这个报表中,要求算:
1日后留存 2日后留存 3日后留存 … 30日后留存
计算时,上述梯形报表,其实不需要一次性计算所有数据格子,每天只要算梯形中的斜边上数据格子
比如,在2019-06-15号的数据出来后,就计算
14号的 1日留存
13号的 2日留存
12号的 3日留存
11号的 4日留存
.......
DWS_APL_NRT_REC:新用户留存明细表
如果直接按照OLAP平台上的可视化形式建表(横表),计算不方便
我们设计出如下竖表模型,可以同样表达留存数据,但计算会更加方便:
用户留存明细表
日期 | 新增数 | 留存天数 | 留存人数 |
---|---|---|---|
6.5 | 4 | 1 | 3 |
6.5 | 4 | 2 | 3 |
6.6 | 2 | 1 | 2 |
6.5 | 4 | 3 | 3 |
6.5 | 2 | 2 | 1 |
6.5 | 2 | 1 | 2 |
-- 留存明细表
drop table if exists ads_apl_nrt_rec;
create table ads_apl_nrt_rec(
first_time string, -- 首登日
dnu_cnts int, -- 当日新增用户总数
nrt_days int, -- 留存天数
nrt_cnts int -- 留存人数
)
stored as parquet;
代码实现:
INSERT INTO TABLE ADS_USR_NRT
SELECT
first_time as dt,
count(1) as new_cnts,
datediff('2019-10-29',first_time) as rt_days,
count(if(end_time ='2019-10-29',1,null)) as rt_cnts
FROM DWS_USR_HSL WHERE dt='2019-10-29'
AND datediff('2019-10-29',first_time)<=30
AND datediff('2019-10-29',first_time)>=1
GROUP BY first_time
;
可视化报表所需求的数据是:
当日所有活跃用户中,分别属于1天前、2天前、n天前的新用户的占比;
通过分析需求中原型页面,撇去表象,发现本真:
无非就是需要计算某个日期上的活跃用户中的“不同日期新增用户”占比
然后,发现可以用两种形式的模型来为页面提供数据支持:
方式一:横表
日期 | 当日活跃总数 | 0天新增占比 | 1天新增占比 | 2天新增占比 | 3天新增占比 | … |
---|---|---|---|---|---|---|
2019/6/15 | 2014 | 65% | 70% | 48% | 66% | … |
方式二:竖表
计算日期 | 活跃总数 | 新鲜天数 | 人数 |
---|---|---|---|
2019/6/15 | 100 | 1天前新增占比 | 10 |
2019/6/15 | 100 | 2天前新增占比 | 20 |
2019/6/15 | 100 | 3天前新增占比 | 25 |
2019/6/15 | 100 | 4天前新增占比 | 30 |
2019/6/15 | 100 | 5天前新增占比 | 2 |
2019/6/15 | 100 | 6天前新增占比 | 3 |
2019/6/15 | 100 | 7天前新增占比 | 5 |
2019/6/15 | 100 | … | … |
2019/6/15 | 100 | 30天前新增占比 | … |
“占比”可以转换成“数”来计算,更灵活
竖表建模
CREATE TABLE ads_apl_ufs (
dt string
,act_amt INT
,frs_days INT
,frs_cnts INT
) stored AS parquet;
本报表,基于用户登录历史记录明细表dws_usr_hsl,可轻松得出!
计算逻辑:
从上图可以看出,新鲜度数据,其实可以从留存明细表中直接提取得出;
比如,要得到12.18号的新鲜度:
比如,要得到12.18号的新鲜度:
12.18号的活跃用户中,有几个是1天前新增的 ==> 等价于 12.17号的1日留存数
12.18号的活跃用户中,有几个是2天前新增的 ==> 等价于 12.16号的2日留存数
12.18号的活跃用户中,有几个是3天前新增的 ==> 等价于 12.15号的3日留存数
12.18号的活跃用户中,有几个是4天前新增的 ==> 等价于 12.14号的4日留存数
12.18号的活跃用户中,有几个是5天前新增的 ==> 等价于 12.13号的5日留存数
..........
而右边等价数据,可以从新用户留存明细中直接查询而得!
而查询的条件应该是: 日期+留存天数 =》 当前
《详见项目代码》
分析可得,
本报表需求的数据为:每天的活跃用户中,连续活跃了1天、2天、N天的用户的占比;
实质是:统计用户的连续活跃行为;
连续活跃记录:dws_apl_uac_rec连续活跃区间记录表
Uid | 首登日 | 活跃区间起始 | 活跃区间结束 |
---|---|---|---|
U001 | 2019-06-02 | 2019-06-02 | 2019-06-04 |
U001 | 2019-06-02 | 2019-06-07 | 2019-06-04 |
U001 | 2019-06-02 | 2019-06-10 | 9999-12-31 |
U002 | 2019-06-12 | 2019-06-12 | 9999-12-31 |
U003 | 2019-06-15 | 2019-06-15 | 9999-12-31 |
/*
ETL 开发
计算逻辑:
1.源表:活跃记录拉链表 dws_usr_rac
2.逻辑:先过滤出当日活跃的记录,然后分别累计(连续1天的,连续2天的....)人数即可
*/
用户活跃度报表
日期 | 当日总活跃数 | 活跃天数类别 | 类别人数 | 人数占比 |
---|---|---|---|---|
16 | 2000 | 1 | 600 | |
16 | 2000 | 2 | 1000 |
建表语句:
drop table if exists ads_usr_cta;
create table ads_usr_cta(
dt string,
act_cnts int comment '当日活跃总数',
continuos int comment '连续天数',
cnts int comment '人数',
per double comment '人数占比'
)
stored as parquet;
《详见项目代码》
访问间隔分布报表:ADS_APL_UAI
截止日期 | 隔几天 | 发生过多少人次 |
---|---|---|
2020-01-18 | 0 | 500 |
2020-01-18 | 2 | 400 |
2020-01-18 | 3 | 800 |
… |
sql语句:
/*
方式2:用sql实现
*/
with tmp as
(select
uid,
datediff(if(end_dt='9999-12-31','2019-06-19',end_dt),begin_dt) as day1_cnts,
end_dt,
lead(begin_dt,1,null) over(partition by uid order by begin_dt) as jump_dt
from dws_user_active_zip
where dt='2019-06-19')
select
uid,
interval_type,
sum(cnts)
from
(
select
uid,
interval_type,
cnts
from
(
select
uid
,map('隔1天',day1_cnts,if(jump_dt is null,"NA",concat('隔',datediff(jump_dt,end_dt),'天')),1) as m
from tmp
)o
lateral view
explode(m) t as interval_type,cnts
) o2
where interval_type!='NA'
group by uid,interval_type
/*
活跃用户留存分析表
建模:竖表
ads_apl_art_rec
*/
create table ads_apl_art_rec(
dt string,
act_cnts int,
retention_days string,
retention_cnts int
)
stored as parquet;
每日都只要以当日为基数
往前推1天、2天、3天、4天、5天、……的留存数计算
/*
方案1:简单粗暴的日活逐日join
计算逻辑:
1. 源表: 各天的日活表
2. 逻辑: 滚动计算,计算前N天到当天的,活跃留存数
比如,6.6号,算6.5-6.6的1日留存
6.7号,算6.5-6.7的2日留存,算6.6-6.7的1日留存
6.8号,算6.5-6.8的3日留存,算6.6-6.8的2日留存,算6.7-6.8的1日留存
......
将 6.5的日活 join 6.8的日活,求count --》 得到6.5号的3日后活跃留存
6.6的日活 join 6.8的日活,求count --》 得到6.6号的2日后活跃留存
6.7的日活 join 6.8的日活,求count --》 得到6.7号的1日后活跃留存
*/
/*
方案2:通过“用户活跃区间记录”表来计算
计算逻辑:
1. 源表: dws_usr_cta
2. 逻辑
一方面:
过滤出区间end_dt = 9999-12-31的且记录(这些是当日有活跃的,也才是所谓留存的)
按照 end_dt - start_dt 差来分组(这个差就是 “留存天数”,>7则为7),求人数
(这里即得出 “留存天数,留存人数”两个字段) tmp1
另一方面:
从日活统计表中,查询7天内的,每天日期及活跃总数 tmp2
最后:
用 tmp2 LEFT JOIN tmp1 on DATE_SUB(当日,tmp1.留存天数)=tmp2.日期
*/
《详见项目代码》
本报表的实质就是:
按照各种维度:联网方式、运营商、app版本
统计“新用户数”和“活跃用户数”和“启动次数”等
上述需求,都可以通过查询 日活/日新 多维报表 即可得出
《详见项目代码》
本报表的实质就是:
按照app版本维度,来统计“新用户数”和“活跃用户数”和“启动次数”等
上述需求,都可以通过查询 日活/日新 多维报表 即可得出
《详见项目代码》
本项目教程笔记源自多易教育《Titan综合数据仓库与数据运营系统》,在CSDN学院有相关视频教程购买链接,大数据企业级项目实战–Titan大型数据运营系统
本项目课程是一门极具综合性和完整性的大型大数据项目实战课程,课程项目的业务背景源自各类互联网公司对海量用户浏览行为数据和业务数据分析的需求及企业数据管理、数据运营需求。
学完本课程,你将很容易就拿到大数据数仓建设或用户画像建设等岗位的OFFER
本课程项目涵盖数据采集与预处理、数据仓库体系建设、用户画像系统建设、数据治理(元数据管理、数据质量管理)、任务调度系统、数据服务层建设、OLAP即席分析系统建设等大量模块,力求原汁原味重现一个完备的企业级大型数据运营系统。
跟随项目课程,历经接近100+小时的时间,从需求分析开始,到数据埋点采集,到预处理程序代码编写,到数仓体系搭建…逐渐展开整个项目的宏大视图,构建起整个项目的摩天大厦。