基於Spark的用戶行爲路徑分析的產品化實踐

前言：本文爲網上轉載內容，因爲跟公司作的項目類似，copy一份，細細品味。

--------------------------------------------華麗分割線------------------------------------

1.  什麼是用戶行爲路徑

用戶行爲路徑分析是互聯網行業特有的一類數據分析方法，它主要根據每位用戶在App或網站中的點擊行爲日誌，分析用戶在App或網站中各個模塊的流轉規律與特色，挖掘用戶的訪問或點擊模式，進而實現一些特定的業務用途，如App核心模塊的到達率提高、特定用戶羣體的主流路徑提取與瀏覽特徵刻畫，App產品設計的優化與改版等。

2. 路徑分析業務場景

用戶行爲路徑分析的一個重要終極目的即是優化與提高關鍵模塊的轉化率，使得用戶能夠便捷地依照產品設計指望的主流路徑直達核心模塊。具體在分析過程當中還存在着如下的應用場景：

i.用戶典型路徑識別與用戶特徵分析

用戶特徵分析中經常使用的都是一些如性別、地域等人口統計數據或訂單價、訂單數等運營數據，用戶訪問路徑數據爲咱們瞭解用戶特徵打開了另外一扇大門。例如對於一款圖片製做上傳分享的應用，咱們能夠經過用戶的App使用操做數據，來劃分出樂於製做上傳的創做型用戶，樂於點贊評論的互動型用戶，默默瀏覽看圖的潛水型用戶，以及從不上傳只會下載圖片的消費型用戶。

ii.產品設計的優化與改進

路徑分析對產品設計的優化與改進有着很大的幫助，能夠用於監測與優化指望用戶路徑中各模塊的轉化率，也能夠發現某些冷僻的功能點。

一款視頻創做分享型App應用中，從開始拍攝製做視頻到視頻的最終發佈過程當中，用戶每每會進行一系列的剪輯操做;經過路徑分析，咱們能夠清晰的看到哪些是用戶熟知並喜好的編輯工具，哪些操做過於冗長繁瑣，這樣能夠幫助咱們針對性地改進剪輯操做模塊，優化用戶體驗。

若是在路徑分析過程當中用戶的創做數量與用戶被點贊、評論以及分享的行爲密切相關，就能夠考慮加強這款App的社交性，加強用戶黏性與創做慾望。

iii.產品運營過程的監控

產品關鍵模塊的轉化率自己便是一項很重要的產品運營指標，經過路徑分析來監測與驗證相應的運營活動結果，能夠方便相關人員認識瞭解運營活動效果。

說到這裏不得不說起一下漏斗模型與路徑分析的關係

以上提到的路徑分析與咱們較爲熟知的漏斗模型有類似之處，廣義上說，漏斗模型能夠看做是路徑分析中的一種特殊狀況，是針對少數人爲特定模塊與事件節點的路徑分析。換句話說是一種高度的抽象邏輯。

漏斗模型一般是對用戶在網站或App中一系列關鍵節點的轉化率的描述，這些關鍵節點每每是咱們人爲指定的。例如咱們能夠看到某購物App應用的購買行爲的漏斗轉化狀況。

這款購物App平臺上，買家從瀏覽到支付成功經歷了4個關鍵節點，商品瀏覽、加入購物車、結算、付款成功，從步驟1到步驟4，經歷了其關鍵節點的人羣愈來愈少，節點的轉化率呈現出一個漏斗狀的情形，咱們能夠針對各個環節的轉化效率、運營效果及過程進行監控和管理，對於轉化率較低的環節進行鍼對性的深刻分析與改進。

路徑分析與漏斗模型存在不一樣之處，它一般是對每個用戶的每個行爲路徑進行跟蹤與記錄，在此基礎上分析挖掘用戶路徑行爲特色，涉及到每一步的來源與去向、每一步的轉化率。

能夠說，漏斗模型是事先的、人爲的、主動的設定了若干個關鍵事件節點路徑，而路徑分析是探索性的去挖掘總體的行爲路徑，找出用戶的主流路徑，甚至可能發現某些事先鮮爲人知的有趣的模式路徑。從技術手段上來看，漏斗模型簡單直觀計算並展現出相關的轉化率，路徑分析會涉及到一些更爲普遍的層面。

這塊有一個對大部分產品問題初步斷定實踐，首先咱們會經過用戶行爲路徑大概的瞭解一下用戶是否依照產品設計指望的主流路徑直達核心模塊。 而後結合具體的業務場景創建漏斗細看轉化。最後經過用戶細查詳細的查看具體用戶的行爲。實際在具體實踐中反覆結合這三步，咱們能夠獲得許多有價值的信息。

3. 諸葛用戶行爲自動化報告實踐

Sunburst Partition可視化分析探索

經過解析布點得到的用戶行爲路徑數據，咱們能夠用最簡單與直接的方式將每一個用戶的事件路徑點擊流數據進行統計，並用數據可視化方法將其直觀地呈現出來。

D3.js是當前最流行的數據可視化庫之一，咱們能夠利用其中的Sunburst Partition來刻畫用戶羣體的事件路徑點擊情況。從該圖的圓心出發，層層向外推動，表明了用戶從開始使用產品到離開的整個行爲統計;Sunburst事件路徑圖能夠快速定位用戶的主流使用路徑。經過提取特定人羣或特定模塊之間的路徑數據，並使用Sunburst事件路徑圖進行分析，能夠定位到更深層次的問題。

4. 用戶行爲路徑算法

較經常使用的用戶行爲路徑算法有基於關聯分析的序列路徑挖掘方法和社會網絡分析

i.基於關聯分析的序列路徑挖掘方法

提到關聯規則分析，必然免不了數據挖掘中的經典案例「啤酒與尿布」。暫且不論「啤酒與尿布」是否是Teradata的一位經理胡編亂造吹噓出來的「神話故事」，這個案例在必定程度上讓人們理解與懂得了購物籃分析(關聯分析)的流程以及背後所帶來的業務價值。

將超市的每一個客戶一次購買的全部商品當作一個購物籃，運用關聯規則算法分析這些存儲在數據庫中的購買行爲數據，即購物籃分析，發現10%的顧客同事購買了尿布與啤酒，且在全部購買了尿布的顧客中，70%的人同時購買了啤酒。因而超市決定將啤酒與尿布擺放在一塊兒，結果明顯提高了銷售額。

咱們在此不妨將每一個用戶每次使用App時操做全部事件點當作「購物籃」中的「一系列商品」，與上面提到的購物籃不一樣的是，這裏的全部事件點擊行爲都是存在嚴格的先後事件順序的。

咱們能夠經過改進關聯規則中的Apriori或FP-Growth算法，使其能夠挖掘存在嚴格前後順序的頻繁用戶行爲路徑，不失爲一種重要的用戶路徑分析思路。咱們能夠仔細考量發掘出來的規則序列路徑所體現的產品業務邏輯，也能夠比較分析不一樣用戶羣體之間的規則序列路徑。

ii.社會網絡分析(或連接分析)

早期的搜索引擎主要基於檢索網頁內容與用戶查詢的類似性或者經過查找搜索引擎中被索引過的頁面爲用戶查找相關的網頁，隨着90年代中後期互聯網網頁數量 的爆炸式增加，早期的策略再也不有效，沒法對大量的類似網頁給出合理的排序搜索結果。

現今的搜索引擎巨頭如Google、百度都採用了基於連接分析的搜索引擎算法來做爲這個問題的解決方法之一。網頁與網頁之間經過超連接結合在一塊兒，如同微博上的社交網絡經過關注行爲鏈接起來，社交網絡中有影響力很大的知名權威大V們，互聯網上也存在着重要性或權威性很高的網頁。將權威性較高的網頁提供到搜索引擎結果的前面，使得搜索的效果更佳。

咱們將社交網絡中的人看做一個個節點，將互聯網中的網頁看做一個個節點，甚至能夠將咱們的App產品中的每個模塊事件看做一個個節點，節點與節點之間經過各自的方式鏈接組成了一個特定的網絡圖，如下將基於這些網絡結構的分析方法統稱爲社會網絡分析。

社會網絡分析中存在一些較爲常見的分析方法能夠運用到咱們的路徑分析中來，如節點的中心性分析，節點的影響力建模，社區發現等。經過中心性分析，咱們能夠去探索哪些模塊事件處於中心地位，或者做爲樞紐鏈接了兩大類模塊事件，或者成爲大多數模塊事件的最終到達目的地。經過社區發現，咱們能夠去探索這個社會網絡中是否存在一些「小圈子」，即用戶老是喜歡去操做的一小部分行爲路徑，而該部分路徑又與其餘大部分模塊相對獨立。

5. 用戶行爲路徑產品化實踐

下面是一個大體的用戶行爲路徑產品需求導圖

咱們大致目標要完成基於人數和次數的用戶行爲路徑，能夠支持從任意事件起下查後續行爲或者上查來源行爲，而且要支持任意30天時間行爲路徑的查看。最重要的一點是強調用戶體驗須要較實時處理得到結果。根據上述這些需求，咱們給出基於Spark的用戶行爲路徑實踐。

6. 基於Spark的用戶行爲路徑

Spark是一個基於內存計算的開源集羣計算系統，目的是更快速的進行數據分析

下面是一個Spark的套件圖

伯克利將Spark的整個生態系統稱爲伯克利數據分析棧(BDAS)。其核心框架是Spark，同時BDAS涵蓋支持結構化數據SQL查詢與分析的查詢引擎Spark SQL，提供機器學習功能的系統MLbase及底層的分佈式機器學習庫MLlib、並行圖計算框架GraphX，流計算框架Spark Streaming。這些子項目在Spark上層提供了更高層、更豐富的計算範式。

下面簡單介紹一下Spark的 Yarn-Cluster任務提交流程

1. Spark Yarn Client向YARN中提交應用程序，包括ApplicationMaster程序、啓動ApplicationMaster的命令、須要在Executor中運行的程序等;

2. ResourceManager收到請求後，在集羣中選擇一個NodeManager，爲該應用程序分配第一個Container，要求它在這個Container中啓動應用程序的ApplicationMaster，其中ApplicationMaster進行SparkContext等的初始化;

3. ApplicationMaster向ResourceManager註冊，這樣用戶能夠直接經過ResourceManage查看應用程序的運行狀態，而後它將採用輪詢的方式經過RPC協議爲各個任務申請資源，並監控它們的運行狀態直到運行結束;

4. 一旦ApplicationMaster申請到資源(也就是Container)後，便與對應的NodeManager，要求它在得到的Container中啓動啓動CoarseGrainedExecutorBackend，CoarseGrainedExecutorBackend啓動後會向ApplicationMaster中的SparkContext註冊並申請Task。這一點和Standalone模式同樣，只不過SparkContext在Spark Application中初始化時，使用CoarseGrainedSchedulerBackend配合YarnClusterScheduler進行任務的調度，其中YarnClusterScheduler只是對TaskSchedulerImpl的一個簡單包裝，增長了對Executor的等待邏輯等;

5. ApplicationMaster中的SparkContext分配Task給CoarseGrainedExecutorBackend執行，CoarseGrainedExecutorBackend運行Task並向ApplicationMaster彙報運行的狀態和進度，以讓ApplicationMaster隨時掌握各個任務的運行狀態，從而能夠在任務失敗時從新啓動任務;

6. 應用程序運行完成後，ApplicationMaster向ResourceManager申請註銷並關閉本身。

下面給出咱們總體行爲路徑的數據流向以及請求過程

數據收集：

互聯網行業對數據的獲取有着得天獨厚的優點，路徑分析所依賴的數據主要就是服務器中的日誌數據。用戶在使用App過程當中的每一步均可以被記錄下來，這時候須要關注的即是優秀的布點策略，它應當與咱們所關心的業務息息相關。事實上，在每一個App裏，不是全部事件都有着一樣的價值，基於對核心事件的深度分析需求，推薦你們使用層級化的自定義事件布點方式，每個事件由三個層次組成的：事件(Event)、屬性(Key)和屬性值(Value)。

數據清洗：

在ETL階段咱們會把收集到的Android/IOS/JS SDK數據進行統一的處理，從上述的JSON格式裏面取出預約義好的字段(咱們須要的一些信息)寫入本地文件中。

數據獲取：

將寫好的本地文件經過定時加載程序加載到Inforbright裏面，獲得一系列的基礎表。而後從這些基礎表裏經過跑批程序跑出方便查詢和使用的一些彙總表。

爲了減小Spark實時內存計算壓力咱們將用戶行爲路徑核心算法過程分爲離線部分和線上請求部分。以下：

中間結果計算：

回溯以前第五節說到產品需求，要完成這些須要(人數，次數，後續行爲，來源行爲，30天時間內任意查詢)，咱們須要從數據庫裏獲取事件ID，會話ID，事件觸發時間，設備ID，用戶ID這些信息。如圖所示：

下面重點來了，首先咱們會將上述信息作一些處理。

原則就是將一個會話ID下面的同一個用戶ID的全部事件按照事件發生的順序進行排序。這塊爲了進一步減小以後Spark內存使用咱們會將全部超長ID進行一次map。 例以下圖中最後一列的1表示的就是map事後的會話ID。第三列表示的是用戶ID第五列和第六列表示的是這個會話ID內事件對發生的順序。第一列和第二列表示的是具體的事件對。

具體解讀一下圖中的信息:

用戶ID爲16351的用戶在其map事後ID爲1的會話中的事件

正序順序 8532810 -> 7232351 -> 7232351 -> 8532810 -> 8532810 -> 7232351 -> 8532810 -> 8532810 -> 565 -> 8532810 -> 6907797 -> 565

逆序順序 565 -> 6907797 -> 8532810 -> 565 -> 8532810 -> 8532810 -> 7232351 -> 8532810 -> 8532810 -> 7232351 -> 7232351 -> 8532810

你會發現按照上述的過程，咱們將獲取到的原始數據進行離線轉化後，新的數據就會自然的支持咱們的產品需求：人數，次數，後續行爲，來源行爲。對於30天內任意時間查詢，咱們也作了特殊的處理。咱們會將天天的數據存放在一個文件裏面，這樣就會有30個用天數命名的文件，這樣天天的離線計算只須要進行增量的部分。這種作法會大大節省咱們離線部分計算的開銷。

數據計算：

因爲在離線部分準備的充分，故在Spark實時計算階段咱們只須要將數據Load到內存後經過一系列的Spark RDD算子查出咱們須要的結果便可。固然按照離線計算後數據格式的特色結合咱們的具體產品需求，在Spark處理過程當中也是有很多小技巧可循，例如查詢某個條件的用戶行爲路徑能夠只使用filter算子就能夠獲得結果，今天就很少贅述了。

數據請求：

前端的請求會經過Redis的訂閱和發佈機制告訴Spark提交相應的任務到集羣。

下面是諸葛用戶行爲路徑的demo數據

文章部分參考諸葛io吳揚的《新技能get | 如何作用戶行爲路徑分析》.

Q&A

Q1：上面可視化分析的圖好難看懂。能仔細解釋一下嗎?

李亮：這個圖實際上是轉自我司CS團隊的經驗，是來對大部分產品問題初步斷定的一個實踐。具體的操做是結合用戶行爲路徑，漏斗，用戶細查這三個功能的結合，看出問題端倪。

Q2：您說到用戶行爲路徑算法有兩類算法： 關聯分析 和 社會網絡分析 從您的講座來看，貌似使用的關聯分析的算法，而後由於大數據量的問題，使用了不少方法減小內存數據量。 是的嗎? 您能大致說一下這類算法在功能上的優缺點嗎?

李亮：其實個人用的方法不算是關聯規則，關聯規則在用戶行爲路徑的實踐更多的是挖掘存在嚴格前後順序的頻繁用戶行爲路徑，而我將整個過程分紅離線部分和線上部分徹底是來知足我司產品苛刻要求下的一些想法。不過經過這樣的分離確實能起到減小後面Spark的內存使用量。

Q3：中間結果計算，關於數據的時序組裝可否再細緻說一下?

李亮：在同一個會話中，全部事件都是按照事件排序組關聯，因此一組會話值，從前到後是正序時序，從後到前是逆序時序。

李亮，諸葛io創新產品部 架構師。前Intel 移動事業部算法成員，在Intel期間，得到4項專利受權。5年機器學習和數據挖掘經驗。現關注點爲大規模機器學習算法，流式機器學習算法，場景化數據分析。