这篇已经是本系列文章的第五篇了，
简书/小红书/CSDN还不快来感谢大猪，上一篇大猪已经介绍 PV/UV 的实现方式以及程序的计算逻辑，本篇大猪继续为小伙伴介绍 留存，看在Spark+Hbase 的架构中到底是怎么实现这种指标的。
大猪的习惯就是能上图就尽量不~~~，好的图是会说话的，大猪也在努力实现中。
详细分析过程
大猪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来计算留存了。
PS：纠正(dt.date 为 dt.regTime as date)
眼尖的小伙伴一看就看到了留存的核心算法了吧，就是圈黄色框框的地方。
怎么那么多函数？又有SUM、IF、date_add，这样的技巧小伙伴们要记住，因为在以后的指标计算当中会经常使用到。
大猪来解释一下它们的含义：date_add函数就是日期+N天，IF就简单啦，判断刚好满足对应的留存日期就将那条数据SUM到对应的come留存日期中。
留存率计算
select aid,sum(come1)/sum(register) from come_report where time = '2019-01-01' group by aid
为什么要这么写？因为这样Spark就可以使用一个job计算完所有留存指标，小伙伴们需要细细品尝一下才有感觉，如果不这么写，小伙伴们觉得怎么写？
反正 大猪 以前是一个留存写一个SQL，是不是很有问题？
下篇文章我们继续介绍其它有意思指标的算法。
本次源码传送门 => 留存计算源码
心明眼亮的你、从此刻开始。
