這篇已經是本系列文章的第五篇了，上一篇大豬已經介紹 PV/UV 的實現方式以及程序的計算邏輯，本篇大豬繼續爲小夥伴介紹 留存 ，看在Spark+Hbase的架構中到底是怎麼實現這種指標的。
大豬 的習慣就是能上圖就儘量不BB，好的圖是會說話的，大豬 也在努力實現中。
詳細分析過程
-
大豬25通過某篇文章註冊了簡書帳號，26去浪去了。
-
27再次登錄簡書，小夥伴猜猜是哪天的幾日留存？
-
這麼簡單的問題，我們的小夥伴肯定能答得上來。
答案就是：25號的2日留存
啊？大豬 我怎麼答得不對呀
莫慌，大家看看當前的時間是28號，Spark+Hbase 計算的是03-27的數據，因爲在27號這天只有大豬一個人訪問，所以數據只能+1，再看下張圖。
- 21號有一頭大豬的粉絲大紅豬通過 PV/UV 文章註冊簡書帳號，咳咳…
- 25號還一頭大豬的粉絲大黃豬通過 小巧高性能的ETL 文章在簡書上註冊了
- 然後這兩頭大胖豬03-28號這天都來了
- 再算算是哪天幾日留存
大豬 這次我看懂，是21號的7日留存跟25號的3日留存
我就說小夥伴是聰明的，這還是比較容易理解的。
接下來，我們看看如何將留存轉成算法去實現，我們會盡量設計成SQL形式去實現。
大豬已經把留存表給設計好了，想必小夥伴跟大豬的設計也是一樣的，畢竟都是志同道合的小夥伴。
到這裏我們就需要一張用戶表了，需要記錄用戶的註冊時間等信息，後面的很多指標也會使用到，Hbase的用戶創表語句如下：
Spark 計算註冊用戶並寫入用戶表的指標計算需要放在所有指標的前面
算法如下，有點黃黃的框框是批量寫入。
我們接下來看Come具體的指標計算是如何計算的
由於涉及到了用戶表，其實就是在UV去重的基礎上添加用戶註冊時間這個字段：
大豬 這就一一講這三個框的意思，第一個框在上一篇的 PV/UV 的指標已經講解過了，就是標記用戶的。
第二個框，跟第一個框邏輯差不多，就是批量去查用戶註冊時間的。
第三個框，就是把第一個框跟第二框的數據合併在一起，把註冊時間合並進去，這樣每條數據都有註冊時間，下面就可以用SQL來計算留存了。
眼尖的小夥伴一看就看到了留存的核心算法了吧，就是圈黃色框框的地方。
怎麼那麼多函數？又有SUM、IF、date_add，這樣的技巧小夥伴們要記住，因爲在以後的指標計算當中會經常使用到，大豬 來解釋一下它們的含義：date_add函數就是日期+N天，IF就簡單啦，判斷剛好滿足對應的留存日期就將數據SUM到對應的come留存。
爲什麼要這麼寫？因爲這樣Spark就可以使用一個job計算完所有留存指標，小夥伴們需要細細品嚐一下才有感覺，如果不這麼寫，小夥伴們覺得怎麼寫？大豬 以前是一個留存寫一個SQL，是不是很有問題？
下篇文章我們繼續介紹其它有意思指標的算法。
本次源碼傳送門 => 留存計算源碼
