這篇已是本系列文章的第五篇了,上一篇大豬已經介紹 PV/UV 的實現方式以及程序的計算邏輯,本篇大豬繼續爲小夥伴介紹 留存 ,看在Spark+Hbase的架構中究竟是怎麼實現這種指標的。git
大豬 的習慣就是能上圖就儘可能不BB,好的圖是會說話的,大豬 也在努力實現中。github
詳細分析過程算法
大豬25經過某篇文章註冊了簡書賬號,26去浪去了。架構
27再次登陸簡書,小夥伴猜猜是哪天的幾日留存?函數
這麼簡單的問題,咱們的小夥伴確定能答得上來。性能
答案就是:25號的2日留存設計
啊?大豬 我怎麼答得不對呀3d
莫慌,你們看看當前的時間是28號,Spark+Hbase 計算的是03-27的數據,由於在27號這天只有大豬一我的訪問,因此數據只能+1,再看下張圖。cdn
大豬 此次我看懂,是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,是否是頗有問題?
下篇文章咱們繼續介紹其它有意思指標的算法。
本次源碼傳送門 => 留存計算源碼