这篇已经是本系列文章的第五篇了，上一篇大猪已经介绍 PV/UV 的实现方式以及程序的计算逻辑，本篇大猪继续为小伙伴介绍 留存 ，看在Spark+Hbase的架构中到底是怎么实现这种指标的。

大猪 的习惯就是能上图就尽量不BB，好的图是会说话的，大猪 也在努力实现中。

详细分析过程

1. 大猪25通过某篇文章注册了简书帐号，26去浪去了。

2. 27再次登录简书，小伙伴猜猜是哪天的几日留存？

3. 这么简单的问题，我们的小伙伴肯定能答得上来。

答案就是：25号的2日留存

啊？大猪 我怎么答得不对呀

莫慌，大家看看当前的时间是28号，Spark+Hbase 计算的是03-27的数据，因为在27号这天只有大猪一个人访问，所以数据只能+1，再看下张图。

1. 21号有一头大猪的粉丝大红猪通过 PV/UV 文章注册简书帐号，咳咳...
2. 25号还一头大猪的粉丝大黄猪通过 小巧高性能的ETL 文章在简书上注册了
3. 然后这两头大胖猪03-28号这天都来了
4. 再算算是哪天几日留存

大猪 这次我看懂，是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，是不是很有问题？

下篇文章我们继续介绍其它有意思指标的算法。

本次源码传送门 => 留存计算源码