Spark+Hbase 億級流量分析實戰( 留存計算)

這篇已是本系列文章的第五篇了,上一篇大豬已經介紹 PV/UV 的實現方式以及程序的計算邏輯,本篇大豬繼續爲小夥伴介紹 留存 ,看在Spark+Hbase的架構中究竟是怎麼實現這種指標的。git

大豬 的習慣就是能上圖就儘可能不BB,好的圖是會說話的,大豬 也在努力實現中。github

詳細分析過程算法

  1. 大豬25經過某篇文章註冊了簡書賬號,26去浪去了。架構

  2. 27再次登陸簡書,小夥伴猜猜是哪天的幾日留存?函數

  3. 這麼簡單的問題,咱們的小夥伴確定能答得上來。性能

答案就是:25號的2日留存設計

啊?大豬 我怎麼答得不對呀3d

莫慌,你們看看當前的時間是28號,Spark+Hbase 計算的是03-27的數據,由於在27號這天只有大豬一我的訪問,因此數據只能+1,再看下張圖。cdn

  1. 21號有一頭大豬的粉絲大紅豬經過 PV/UV 文章註冊簡書賬號,咳咳...
  2. 25號還一頭大豬的粉絲大黃豬經過 小巧高性能的ETL 文章在簡書上註冊了
  3. 而後這兩頭大胖豬03-28號這天都來了
  4. 再算算是哪天幾日留存

大豬 此次我看懂,是21號的7日留存跟25號的3日留存 我就說小夥伴是聰明的,這仍是比較容易理解的。blog

接下來,咱們看看如何將留存轉成算法去實現,咱們會盡可能設計成SQL形式去實現。

大豬已經把留存表給設計好了,想必小夥伴跟大豬的設計也是同樣的,畢竟都是志同道合的小夥伴。

到這裏咱們就須要一張用戶表了,須要記錄用戶的註冊時間等信息,後面的不少指標也會使用到,Hbase的用戶創表語句以下:

Spark 計算註冊用戶並寫入用戶表的指標計算須要放在全部指標的前面 算法以下,有點黃黃的框框是批量寫入。

咱們接下來看Come具體的指標計算是如何計算的

因爲涉及到了用戶表,其實就是在UV去重的基礎上添加用戶註冊時間這個字段:

大豬 這就一一講這三個框的意思,第一個框在上一篇的 PV/UV 的指標已經講解過了,就是標記用戶的。

第二個框,跟第一個框邏輯差很少,就是批量去查用戶註冊時間的。

第三個框,就是把第一個框跟第二框的數據合併在一塊兒,把註冊時間合併進去,這樣每條數據都有註冊時間,下面就能夠用SQL來計算留存了。

眼尖的小夥伴一看就看到了留存的核心算法了吧,就是圈黃色框框的地方。

怎麼那麼多函數?又有SUM、IF、date_add,這樣的技巧小夥伴們要記住,由於在之後的指標計算當中會常用到,大豬 來解釋一下它們的含義:date_add函數就是日期+N天,IF就簡單啦,判斷恰好知足對應的留存日期就將數據SUM到對應的come留存。

爲何要這麼寫?由於這樣Spark就可使用一個job計算完全部留存指標,小夥伴們須要細細品嚐一下才有感受,若是不這麼寫,小夥伴們以爲怎麼寫?大豬 之前是一個留存寫一個SQL,是否是頗有問題?

下篇文章咱們繼續介紹其它有意思指標的算法。

本次源碼傳送門 => 留存計算源碼


相關文章
相關標籤/搜索