本項目教程筆記源自多易教育《Titan綜合數據倉庫與數據運營系統》，在CSDN學院有相關視頻教程購買鏈接，大數據企業級項目實戰–Titan大型數據運營系統
本項目課程是一門極具綜合性和完整性的大型大數據項目實戰課程，課程項目的業務背景源自各類互聯網公司對海量用戶瀏覽行爲數據和業務數據分析的需求及企業數據管理、數據運營需求。
學完本課程，你將很容易就拿到大數據數倉建設或用戶畫像建設等崗位的OFFER
本課程項目涵蓋數據採集與預處理、數據倉庫體系建設、用戶畫像系統建設、數據治理（元數據管理、數據質量管理）、任務調度系統、數據服務層建設、OLAP即席分析系統建設等大量模塊，力求原汁原味重現一個完備的企業級大型數據運營系統。
跟隨項目課程，歷經接近100+小時的時間，從需求分析開始，到數據埋點採集，到預處理程序代碼編寫，到數倉體系搭建…逐漸展開整個項目的宏大視圖，構建起整個項目的摩天大廈。
一、【App分析】app版本升級分析
1、需求分析
源表: dws_flw_agg_s
gid,sessionid,appver,dt
gid01,s01,1.01,2019-11-27
gid01,s01,1.01,2019-11-27
gid01,s01,1.01,2019-11-27
gid01,s01,1.01,2019-11-27
gid01,s02,2.01,2019-11-27
gid01,s02,2.01,2019-11-27
gid01,s02,2.01,2019-11-27
gid01,s02,2.01,2019-11-27
gid02,s21,2.01,2019-11-27
gid03,s31,2.01,2019-11-27
gid03,s32,2.01,2019-11-27
gid03,s33,2.5,2019-11-27
gid04,s41,1.01,2019-11-27
gid04,s42,2.01,2019-11-27
gid04,s43,2.5,2019-11-27
==> 預期的結果：
gid01,1.01,2.01
gid03,2.01,2.5
gid04,1.01,2.01
gid04,2.01,2.5
解釋：只要一個用戶在一天之內發生了一次升級，則在升級報表中有一條記錄：
日期，用戶id，升級前版本，升級後版本
6.09 ，a , 1.0 1.2
6.09 ，a ， 1.2 2.0
2、ADS模型：ADS_APP_UPG
3、計算
1)、計算邏輯
將後一行記錄中的版本，提升到前一行，來進行版本比較
create table t2(uid string,day string,ver string)
row format delimited fields terminated by ',';
load data local inpath '/root/t2.dat' into table t2;
uid, day, ver
a,2019-06-20,1.02
a,2019-06-20,1.02
a,2019-06-20,1.02
a,2019-06-20,2.0
a,2019-06-20,2.0
a,2019-06-20,2.5
a,2019-06-20,2.5
b,2019-06-20,1.2
b,2019-06-20,1.2
b,2019-06-20,2.5
c,2019-06-20,2.0
c,2019-06-20,2.0
==> 期待的結果
uid, 日期 升級前 升級後
a ,2019-06-20 ,1.02 ,2.0
a ,2019-06-20 ,2.0 ,2.5
b ,2019-06-20 ,1.2 ,2.5
with tmp as(
select
uid,
day,
ver,
lead(ver,1,null) over(partition by uid order by ver) as ver2
from t2
)
select * from tmp where ver2>ver
2)、ETL計算開發
《詳見項目代碼》
二、【事件分析】交互事件概況分析
1、交互事件概念介紹
交互事件： 就是用戶在app上或者網頁上所做的交互行爲
比如：點贊，收藏，評分，轉發，點擊，添加購物車，提交訂單，去支付……………
2、交互事件分析整體建模
我們可以在DWD層設計一個交互事件明細表dwd_apl_itr_dtl（已建好，見8.2節）
在DWS層做兩個聚合表（一個按會話聚合，一個按用戶聚合）
3、DWD交互事件明細表：DWD_APL_ITR_DTL
1)、建模
交互事件明細表: DWD_APL_ITR_DTL在8.2節已經完成
4、DWS聚合表：DWS_APL_ITR_AGS
按會話聚合的交互事件數據表
| gid | sessionid | eventid | 次數 | 省 | 市 | 區 | osname | osver | appver | release_ch |
|---|---|---|---|---|---|---|---|---|---|---|
| g01 | s01 | favor | 2 | 山西 | 呂梁 | 高粱 | ios | 10.02 | 2.05 | applestore |
| g01 | s01 | adshow | 5 | |||||||
| g01 | s02 | favor | 10 |
5、DWS聚合表：DWS_APL_ITR_AGU
注：此表也可以作爲用戶畫像標籤表來用（用戶交互行爲標籤明細表）
| gid | eventid | 次數 |
|---|---|---|
| g01 | favor | 12 |
| g01 | share | 10 |
| g02 | favor | 20 |
| g02 | adshow | 30 |
| g02 | share | 25 |
畫像中的應用舉例：
比如，畫像分析中，需要一份這樣的數據：
每個人在最近3個月中，哪10種行爲發生次數最多，及其次數
就可以從上述的“交互事件用戶聚合表”中得出：
將每個人的最近3個月的事件及其次數進行累加，然後對每個人取top10，即可！ |
6、ADS報表示例: 交互事件概況統計報表
需求建模：ADS_APL_ITR_OVW_CUBE
事件概況統計報表
| 日期 | 事件id | 次數 | 人數 | 省 | 市 | 區 | appver | 下載渠道 | osname | … |
|---|---|---|---|---|---|---|---|---|---|---|
| 2012-01-13 | favor | 32 | 2 | |||||||
| share | 35 | 5 |
建表語句：
CREATE TABLE ads_apl_itr_ovw_cube(
eventid string,
province string,
city string,
district string,
osname string,
osver string,
appver string,
release_ch string,
cnts int,
user_cnts int
)
partitioned by (dt string)
stored as parquet
;
《詳見項目代碼》
7、ADS報表示例: ADS_EVT_TOPN
求每一種事件中，發生次數最高的前100個用戶
| 日期 | 事件類型 | 用戶標識 | 發生次數 |
|---|---|---|---|
| adclick | g01 | 100 | |
| adclick | g05 | 90 |
《詳見項目代碼》
三、【路徑分析】訪問路徑分析
也可以稱作：“用戶行爲軌跡分析”
如下示意：
G01, S01, A -> D -> F -> A -> O
分析用戶在使用app/web過程中的訪問行爲路徑規律（更具體則爲：事件行爲）
1、需求分析
上圖中要統計的指標有：
某個特定步驟上，特定頁面跳轉到目標頁面的會話數，
某個特點步驟上，特定頁面的會話數
以及，該目標頁面上發生過的會話總數
從上，可以分析出，此報表中所要計算的數據指標如下：
訪問路徑分析的需求變化多端，當然，最常見的需求是“頁面路徑”的分析，即不考慮各類交互事件，只分析用戶在頁面之間如何跳轉！
2、DWD訪問路徑步驟記錄表模型
表設計
頁面訪問路徑記錄表
| gid | sessionid | 頁面id | 前置頁面id | 訪問步驟號 |
|---|---|---|---|---|
| g01 | s01 | A | NULL | 1 |
| g01 | s01 | B | A | 2 |
| g01 | s01 | C | B | 3 |
| g02 | s02 | F | NULL | 1 |
| g02 | s02 | B | F | 2 |
| g02 | s02 | C | B | 3 |
| g03 | s03 | F | NULL | 1 |
| g03 | s03 | C | F | 2 |
| g03 | s03 | A | C | 3 |
計算邏輯
源表：埋點日誌流量明細表 dwd_apl_tfc_dtl
核心邏輯：將每個人的頁面訪問記錄按時間戳排序，標記步驟號，並通過把上一行數據的pgid拉到下一行，作爲當前頁面的前頁面id
3、DWD訪問路徑步驟記錄表開發
源表：
流量明細表（或app埋點日誌全局明細表）：DWD_APL_TFC_DTL
計算過程：
假設有如下流量請求記錄：
-- 測試數據，對應的真實數據是 ： 流量明細表
g01,137001,s01,pgview,A
g01,137002,s01,pgview,C
g01,137003,s01,pgview,F
g01,137004,s01,pgview,E
g01,137005,s01,pgview,G
g01,137006,s02,pgview,A
g01,137007,s02,pgview,D
g01,137011,s02,pgview,F
g01,137012,s02,pgview,B
g01,137013,s02,pgview,C
g01,137014,s02,pgview,A
g02,137015,s03,pgview,U
g02,137016,s03,pgview,D
g02,137017,s03,pgview,F
g02,137018,s03,pgview,B
g02,137021,s03,pgview,A
g03,137022,s04,pgview,U
g03,137025,s04,pgview,X
g03,137026,s04,pgview,F
g03,137027,s04,pgview,B
g03,137028,s04,pgview,A
得到每個人的每次頁面請求的順序號：
按同一個人的同一次會話中請求時間的順序打上row number
得到該次請求的上一個頁面：
用lag over窗口函數將上一次請求的頁面，拉到當前行
g01,s01,pgview,A,1 ,\N
g01,s01,pgview,C,2 ,A
g01,s01,pgview,F,3 ,C
g01,s01,pgview,E,4 ,F
g01,s01,pgview,G,5 ,E
g01,s02,pgview,A,1 ,\N
g01,s02,pgview,D,2 ,A
g01,s02,pgview,F,3 ,D
g01,s02,pgview,B,4 ,F
g01,s02,pgview,C,5 ,B
g01,s02,pgview,A,6 ,C
實現代碼：
/*
事件分析主題ads層：用戶訪問路徑記錄表：dws_acc_route
結構：
用戶 會話 頁面 訪問順序號 前一頁面
@Author HUNTER
@Date 2019-07-26
@源表：ods_traffic_log
0: jdbc:hive2://localhost:10000> select imei,sessionid,event['url'],commit_time from ods_traffic_log t where eventtype='pg_view' limit 5;
+---------+---------------+------------------------+----------------+
| imei | sessionid | _c2 | commit_time |
+---------+---------------+------------------------+----------------+
| BHGPN7 | hs4NasTIrAAA | http://www.51doit.com/index.html | 1560599141549 |
| D9OGFD | OBYsMxtYFcVh | http://www.51doit.com/learn | 1560599141556 |
| V6WKTX | ayRyJcjG3e9S | http://www.51doit.com/job | 1560599141573 |
| DXJWCX | QCUNyRBAICuQ | http://www.51doit.com/hadoop | 1560599141585 |
| VLKQOP | KvpnX3uj72Ao | http://www.51doit.com/spark | 1560599141608 |
+---------+---------------+------------------------+----------------+
@目標：dws_acc_route
@計算邏輯：
順序號： 按時間排序標記row nunber
前一頁： 按時間排序，取lag over
*/
-- 建表：
drop table if exists dws_acc_route;
create table dws_acc_route(
uid string,
sessionid string,
url string,
sno int,
pre_url string
)
partitioned by (dt string)
stored as parquet
;
-- etl計算
insert into table dws_acc_route partition(dt='2019-06-16')
select
imei as uid,
sessionid,
event['url'] as url,
row_number() over(partition by imei,sessionid order by commit_time) as sno,
lag(event['url']) over(partition by imei,sessionid order by commit_time) as pre_url
from ods_traffic_log where dt='2019-06-16' and eventtype='pg_view'
;
4、ADS訪問路徑分析報表模型
頁面訪問路徑分析表
| 步驟號 | 頁面id | 前頁 | 路徑會話數 | 步驟頁面會話數 | 頁面會話數 |
|---|---|---|---|---|---|
| 3 | C | B | 2 | 100 | |
| 1 | A | null | 1 | ||
| 1 | F | null | 2 | ||
| 2 | B | A | 1 | ||
| 2 | B | F | 1 | ||
| 2 | C | F | 1 | ||
| 3 | A | C | 1 |
解釋：以第一行爲例：
該頁面總會話數：比如C，是所有訪問了C的會話數——100
該路徑會話數：第3步訪問的C，且前一頁是B，符合這種路徑的會話個數——2
5、ADS訪問路徑分析報表開發
計算邏輯：
第一步，算出 “步驟號，頁面id，前頁面”組合下的會話數
第二步，算出每一個頁面上的總會話數
第三步，將前2步的結果 join起來即可！
建表：ADS_APL_ACC_PATH
CREATE TABLE ADS_APL_ACC_PATH(
step int,
pgid string,
pre_pg string,
path_se_cnts int,
step_se_cnts int,
page_se_cnts int
)
stored as orc;
計算
select
step,
pgid,
pre_pg,
count(1) as path_se_cnts,
sum(count(1)) over(partition by step,pgid rows between unbounded preceding and unbounded following) as step_se_cnts,
sum(count(1)) over(partition by pgid rows between unbounded preceding and unbounded following) as page_se_cnts
from demo_path_dwd_dtl
group by step,pgid,pre_pg
;
四、【轉化分析】轉化漏斗統計
1、轉化相關核心概念
公司有很多很多的各種類型的業務
而每一項業務往往能分成若干個操作環節
用戶在業務的各個操作環節上進行操作，一步步走向業務目標（比如買單，比如註冊成功，比如充值完成，比如進入充值頁）
那麼，一個業務的操作環節鏈條，就叫做這個業務的轉化路徑！
而路徑中，每一個環節上的事件發生次數或人數，都會不同，一般是前面的環節上人數多，越往後越少，這樣就引出一個概念：轉化率，漏斗模型
漏斗模型： 是用來衡量一個業務轉化路徑效率的計算模型；它的主要要素有：業務轉化路徑的每一個步驟的定義！每一步上的人數、次數、金額等統計；
轉化率： 漏斗模型中，一個業務步驟相對於上一個業務步驟的人數變化率！
轉化率分爲相對轉化率和絕對轉化率；
相對轉化率： 一個步驟相對於上一個步驟的人數變化率
絕對轉化率：一個步驟相對於初始步驟的人數變化率
強大的分析平臺，應該是允許分析師自定義漏斗模型！
2、轉化漏斗分析表模型
建模和計算思路
| 漏斗名稱 | 步驟序號 | 完成人數 | 相對轉化率 | 整體轉化率 |
|---|---|---|---|---|
| 多易尋寶促銷 | 1 | 100 | ||
| 多易尋寶促銷 | 2 | 50 | 50% | 50% |
| 多易尋寶促銷 | 3 | 20 | 40% | 20% |
| 呼朋喚友拉新 | 1 | 1000 | ||
| 呼朋喚友拉新 | 2 | 800 | ||
| 呼朋喚友拉新 | 3 | 600 | ||
| 呼朋喚友拉新 | 4 | 200 | ||
| 呼朋喚友拉新 | 5 | 5 |
3、轉化漏斗案例1：多易尋寶-促銷活動
分析需求：
多易尋寶促銷活動的每一個環節的轉化率
“多易尋寶”活動，轉化路徑定義：
路徑步驟定義：
1.第一步 ： 多易尋寶活動廣告曝光事件（eventid=’adShowEvent’, ad_id=‘5’）
2.第二步 ： 多易尋寶活動廣告點擊事件（eventid=’adClickEvent’, ad_id=‘5’）
3.第三步 ： 活動參與（eventid=‘appClickEvent’, element_id=‘14’）
4.第四步 ： 尋寶訂單支付頁（eventid=‘appviewEvent’,pgid=‘455’）
5.第五步 ： 去支付點擊事件（eventid=‘appClickEvent’,element_id=‘26’）
代碼實現
《詳見項目代碼》
4、轉化漏斗案例2：呼朋喚友-拉新活動
“呼朋喚友”活動，轉化路徑定義：
1.用戶瀏覽“呼朋喚友”活動廣告（eventid=ad_show,ad_id=5）
2.用戶點擊“呼朋喚友”活動廣告（eventid=ad_click,act_id=5）
3.用戶點擊呼朋喚友二維碼生成按鈕（eventid=appClickEvent,element_id=hphy_ewm）
4.用戶點擊分享按鈕事件（eventid=appClickEvent,element_id=hphy_fx）
5.用戶打開活動落地頁（eventid=appviewEvent,pgid=988）
6.用戶填寫表單，點擊註冊（eventid=appClickEvent,element_id=hphy_zc）
代碼實現
《詳見項目代碼》
五、【廣告分析】站內廣告分析
站內廣告，指的是，在本公司網站的各處所投放的廣告，有些廣告是爲自己的產品做宣傳，有些廣告是爲第三方做宣傳；
以京東爲例，如下圖所示：
1、需求：概況分析
廣告概況分析報表： ADS_ADN_OVW
| 日期 | 廣告id | 曝光次數 | 曝光人數 | 曝光人數最大頁 | 點擊次數 | 點擊人數 | 點擊人數最大頁 |
|---|---|---|---|---|---|---|---|
源表：dwd_apl_adv_dtl 廣告事件明細表中做
2、DWS層廣告事件頁面聚合表
通過分析，發現，如果創建一個dws層的中間表，對後面的各種數據分析能提供有力支撐！
-- 建表
create table dws_apl_ad(
pgid string, -- 頁面id
adid string, -- 廣告id
eventid string, -- 事件類型
cnts int, -- 發生次數
use_cnts int -- 發生人數
)
partitioned by (dt string)
stored as parquet;
| 頁面id | 廣告id | 事件類型 | 發生次數 | 發生人數 |
|---|---|---|---|---|
| pg002 | 5 | adshow | 1000 | 600 |
| pg002 | 6 | adshow | 1000 | 500 |
| pg002 | 5 | adclick | 200 | 150 |
| pg008 | 5 | adshow | 800 | 700 |
| … |
-- 抽取
insert into table dws_apl_ad partition(dt='2019-10-28')
select
event['adId'] as adid,eventid,event['pgId'] as pgid,count(1) as cnts,
count(distinct uid) as use_cnts
from dwd_apl_ev_ad where dt='2019-10-28'
group by event['adId'],eventid,event['pgId']
;
《詳見項目代碼》
3、ADS層廣告概況報表
根據原型頁面的展示需求，梳理出如下表格模型：
廣告概況統計報表：ADS_ADN_OVW
| 日期 | 廣告id | 曝光次數 | 曝光人數 | 曝光人數最大頁 | 點擊次數 | 點擊人數 | 點擊人數最大頁 |
|---|---|---|---|---|---|---|---|
廣告概況統計報表：ADS_ADN_OVW
| 日期 | 廣告id | 行爲類型 | 次數 | 人數 | 最大頁 |
|---|---|---|---|---|---|
建表語句：
create table ads_apl_ad_ov(
ad_id string,
show_cnts int,
show_users int,
show_max_url string,
click_cnts int,
click_users int,
click_max_url string
)
partitioned by (dt string)
stored as parquet;
1)、梳理計算要素
從報表中，可以梳理出，在計算過程中所需要的要素如下：
日期
uid
頁面location
廣告id
事件類型
2)、計算邏輯
以頁面作爲分組條件，來計算，在這個頁面上：
頁面 某廣告 曝光的次數 曝光的人數
/a ad01 100 80
/b ad01 80 60
/b ad02 200 180
那麼，要統計某廣告的總次數，則按廣告分組，把所有頁的曝光次數累加！ 要得到某廣告曝光最多的頁面，則按廣告分組，求次數最大的頁即可
然後，將兩部分結果按照adid關聯起來即可
《詳見項目代碼》
六、【廣告分析】站外廣告分析
站外廣告，指的是本公司在第三方媒體上投放的廣告；
以淘寶在新浪所投放的廣告爲例，如下圖所示：
在第三方媒體投放廣告會耗費資金，當然需要統計這些廣告投放所產生的效果；
通常，一個公司在站外投放廣告，都是通過一些廣告聯盟(dsp)進行投放，廣告效果相關數據統計由廣告聯盟負責，並向廣告主提供實時或定期的報表；
而廣告主自己，也可以自行做一些站外廣告投放相關的數據分析，以便於跟廣告聯盟的數據報表進行比對；自行統計分析，需要用到UTM廣告跟蹤技術；
《UTM介紹見：3.1.4章節》
需要統計如下報表：廣告推廣流量分析表
推廣流量分析表：ADS_ADE_FLW
| 廣告平臺 | 廣告形式 | 廣告內容 | 營銷活動 | 來訪pv | 來訪會話數 | 來訪uv | 來訪新客 |
|---|---|---|---|---|---|---|---|
| 新浪 | banner | 10000 | |||||
| 新浪 | 側邊欄 | 8000 | |||||
| 新浪 | banner | 80000 | |||||
| 新浪 | 200000 |
該報表的統計，源表可以選擇 “流量事件明細表”，表中的日誌記錄中，如果某pv事件是來自於站外廣告的點擊，則事件日誌中的event字段（map類型字段）中會帶有多個utm參數值；
如果一個pageview事件的詳情中，帶有這些utm參數的值，則說明這個pageview是從站外投放的廣告引進來的；根據這些utm參數值（可以當成各種維度），即可統計出上述多維報表；
當然，在現實開發中，上述報表可以單獨開發實現，也可以在前面做pv，uv等報表統計時，把utm中的個參數作爲維度，一併統計出來！
《詳見項目代碼》
本項目教程筆記源自多易教育《Titan綜合數據倉庫與數據運營系統》，在CSDN學院有相關視頻教程購買鏈接，大數據企業級項目實戰–Titan大型數據運營系統
本項目課程是一門極具綜合性和完整性的大型大數據項目實戰課程，課程項目的業務背景源自各類互聯網公司對海量用戶瀏覽行爲數據和業務數據分析的需求及企業數據管理、數據運營需求。
學完本課程，你將很容易就拿到大數據數倉建設或用戶畫像建設等崗位的OFFER
本課程項目涵蓋數據採集與預處理、數據倉庫體系建設、用戶畫像系統建設、數據治理（元數據管理、數據質量管理）、任務調度系統、數據服務層建設、OLAP即席分析系統建設等大量模塊，力求原汁原味重現一個完備的企業級大型數據運營系統。
跟隨項目課程，歷經接近100+小時的時間，從需求分析開始，到數據埋點採集，到預處理程序代碼編寫，到數倉體系搭建…逐漸展開整個項目的宏大視圖，構建起整個項目的摩天大廈。