這篇已經是本系列文章的第五篇了，上一篇大豬已經介紹 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，是不是很有問題？
下篇文章我們繼續介紹其它有意思指標的演算法。
本次原始碼傳送門 => 留存計算原始碼
