II_项目_电商用户行为分析/049_尚硅谷_电商用户行为分析_其它模块需求分析

接下来我们继续还是把这个剩下的需求给大家，还是说完好。第二个需求呢，是实时流量统计，那么在这里边首先我们就提出一个需求，可以统计流量的时候，我们可以统计什么呢？统计一段时间内比较热门的页面或者是站点。那这一部分信息，那大家会看到我们在买点日志里边，有可能没办法去看对吧？页面的话，或许我们用那个PV也可以做一个，呃，类似于这样的一个筛选，但是你如果要是说热门站点的统计，那可能就没有办法直接去从日志里边去筛了，那我们怎么办呢？这里边我们除了买点日志之外，还能拿到一份数据是。哎，服务器外部服务器的日志对不对，从他的那个日志里边我们就能看到，哎，不同的那个访问请求，访问了哪个页面，访问了哪个站点，所以我们可以从它里边去统计实时的热门访问的页面或者站点。

那这里面具体的需求是每分钟统计每分钟的IP访问量，然后呢，取出访问量最大的五个地址，每五秒更新一次，你看这个需求，这是不是又相当于是一个滑动窗口啊，所以我们现在要用的这个滑动窗口就是。长度是一分钟，滑动距离是五秒钟，对，其实就是按照不同的这个需求，我们去定义滑动窗口就可以，当然之后是不是还要再去做排序啊。排序，然后取这个top n top5输出就可以了，所以整体的实现跟前面给大家讲的这个实时的呃，热门商品其实是非常类似的啊，只不过当时我们算的时候，一开始取的是那个做分组，是不是按照商品ID去分组啊，那现在我们按什么去分组？ID大家想一想，是不是直接是页面ID是吧？啊对，当然这里边我们那个web服务器日志里边呢，没有页面ID这一说，诶那我们直接是不是就拿。

但是IP吗？那个里面的IP是是发送请求的IP对不对。哎，对，这个里边如果我们要统计的是不是要拿后边的那个页面的URL啊，对吧？哎，所以是这样的一个情况啊，就把这个URL当成我们之前的商品就好了，当然在这个服务器日志里边，它的时间是一个字符串，大家要记得把它转换成能用的那个时间戳，才能指定成英文time，对吧？要不然的话，这个flink是没有办法把它当成时间戳去分配的。呃，这个是热门页面，除了这样去统计热门页面，大家更熟悉的指标其实是PV和UV啊，大家其实我们知道所谓的PV是呃，Page view对吧？啊，其实就是说呃，实时的到底有多少人浏览了这样一个页面，那大家会看到这个PV，其实我们就可以从买点日志里边直接去取了，对吧？啊，所以这一部分我们就还是从u behavior那个买点日志里边以它作为数据源来进行处理啊，那实时要统计这个PV和UVUV的话是。

呃，Unique visitor，对吧，是相当于是这个独立访客数，独立访客数的话，是不是就相当于在PV的基础上得做一个驱虫啊，哎，那大家会想一想，这个我们这里面的要求是统计每个小时的访问量，然后还要对用户进行驱重，对吧，统计这个独立访客数，那怎么样去处理呢？这个PV其实很简单，每个小时访问量。这是不是就是一个。他说每个小时，那其实就是说是隔一个小时一个窗口，对吧？啊，就不应该再去滑动了，就是每个小时一个窗口就完了，这是不是就是一个滚动窗口啊，啊这个很简单，然后去做这个统计聚合就完事儿，那后面这个驱虫怎么做呢？

就简单的一个想法，我们是不是可以用这个啊，Set这样的一个数据结构去做驱重啊，你不管是放在内存里边，还是放在red类似的一些工具里边，都可以把它保存成set去做去宠，那另外还有一个问题就是假如你遇上了比较极端的数据规模特别大的那种场景呢？一个窗口一个小时里边上亿条数据，对吧，那这个时候怎么去做驱虫呢。你如果全存的话，有可能这些数据根本内存里边存不下，存不下呀，对吧？哎，所以这里边给大家说一个可以考虑用布隆过滤器去做一个去重，那它它的基本的一个思想就是大家可能知道，在这种情况下就得把它保存成一个位图对吧，一个bitmap，那所以布隆过滤器呢，基本上就是这样的一个思维。好，这个后续我们就在代码实现的过程当中再给大家展开就好了。

呃，然后下下面一大模块是所谓的市场营销分析，首先我们一个具体的指标是APP市场推广的一个统计，那大家知道现在越来越多的包括电商啊，这就还涉及到其他的一些行业，其实呃，我们的这个电脑上面的网页浏览啊，浏览器的浏览，其实都已经渐渐的不不不算做一个主要的呃入口流量入口了，对吧，那更多的浏量其实是来源于这个APP，那所以大家会想到在这里边，那其实这个市场部的任务啊，它就是要大量的去推广，对不对啊，得让更多的人能够下载APP，能够登录APP，能够用起来，这样可能才能把这个市场做大，那现在我们要统计的指标就是什么呢？要统计APP市场推广的这个数据指标，一般情况可能就是说下载量对吧？啊，或者说这个点击量，访问量啊，也是类似于这样的一些东西，所以这里边我们可能就直接以这个下载量相关的一些东西，或者安装量这样的一些东西去做这个指标来进行统计，呃，那当然了，这里边可能还会有新的一些需求，就是说我可能要的是一个这个时间段的一个总数，对吧？啊，就是这个时间段到底一共有多少，呃，那个下载量或者说这个访问量，那另外一个是。

因为大家知道这个APP推广的过程当中，它其实是有不同渠道的，对不对，诶你到底是从哪儿点进来去去下载了一下呢？哎，你是从这个呃，直接从a apptore去去下的，还是说呃，从其他的一些页面分享来的，对吧，还是从其他的一些广告点击进来的，这些其实是不同的流量入口推广渠道，所以。便于我们这个做接下来的市场营销策略调整的话，是不是要根据不同的推广渠道分别去统计啊，啊，那大家看这个需求好处理吗。

其实也很好处理，那你既然是要统计不同的推广渠道，是不是本身那个日志数据里边，你应该能够判断出来用户是从从哪儿跳转点过来的呀，对吧，只要你把这个数据已经埋在，就是放在写写入日志里边去了，那我们这里肯定就是按照那个渠道做一个KY是不是就可以了，然后各自统统统计各自的就可以了啊，所以这就是我们比较简单的一个一个想法啊，当然一开始我们是需要去过滤这个用户行为的，那比方说我们那个买点日志里边用户行为是多种多样，什么样的行为都有，或者说假如说我们已经做过提取，是都是针对我们那个，就是呃，APP下载，或者说跟APP相关的，对吧？呃，安装相关的那一个地方埋的点统计出来的，那大家会想到有一些行为可能是下载安装这样的，这可能能代表这是正面的一个反馈。那有一。

也有可能是用户卸载了一个APP，对不对啊，装了之后又卸载了，这种也写到日志里了，那这个是不是我们得滤掉啊啊，这是大家能够想到的一些基本的应用啊，当然最后我们可以还是用process方式。做一个处理，可以自定义得到的一个输输出的数据类型，对不对？你想要什么样的数据都可以包装成另外的数据格式，这是这个APP市场推广。市场营销这一部分呢，还有一部分是页面广告啊，那为什么放到这儿呢？因为它其实跟这一方面，它本身也是一个推广的渠道，另外一方面呢，作为这个电商平台而言，上面的页面广告其实也是跟自己的这个营销收入相关的，对吧？啊，这个你是要按照它的这个页面的热门程度，它的点击量去考虑给上面的广告进行定价的。

那这里面我们的需求是什么呢？是不是就应该实时的去统计当前这段时间内广告页面广告的点击量啊，如果点的越多，是不是这个页面上广告应该越值钱啊，这个东西其实是我们可以去实时做统计计算的啊，这里边还做了另外一个需求，如果说我们就是统计每个小时的点击量，五秒刷新一次，大家觉得是不是这个就好没意思啊，对吧？这其实就是一个划窗嘛，你开了之后直接去统计就完了，哎，这里面多了一个。按照不同的省份进行划分，诶为什么会有这样的一个一个需求呢。因为大家会想到，其实对，其实我们的这个当然就是大家访问网站的时候，你根本天南海北哪里的人都有，但是其实不是每个省份，特别是电商这个商品啊，各种商品五花八门，不同地区，不同区域的人，他对这一个商品的需求是不是就不一样啊。啊，那你想你这个这个在在冬天的时候，大家可能会想到这个羽绒服啊，这个棉大衣啊什么的，这这些这个厚衣服的需求量就会更高，对不对啊，但是假如现在人家这些用户他在这个地方在在海南岛对吧？啊你你说你你一定想给人家这个这个推推这个，呃，对这个什么羽绒服什么什么棉袄棉裤，这显然就没有对症下药嘛，啊所以说包括这个。

这个广告它其实投放也是，就是现在越来越多的，它是大家看那个广告是定制化投放的，对不对？对，精准投放，它是要分析你用户的一些个人的信息和和给你做画像之后给你进行投放的啊有同学肯定有经验，就是说我们打开同一个页面，或者说就是我不同的时间段去，去不同的时候打开一个页面，那个给你推出来的广告是不一样的，对吧？啊，所以它其实是在随时变化的，呃，那大家会想到一个基本的想法，就是我可以根据省份先先做一个划分，对不对？呃，你你这个点击量，这个页面有可能它在这个省它就非常受欢迎，点击量多啊，那有可能它在另外一个省就根本没什么点击量，所以大家可以在这里做一个这样的一个区分，呃，另外这里边还有一点就是说，既然我们是按照这个每小时的广告点击量来算钱的，那大家又会想到那是不是这就。

是你有政策，别人有应对的对策，对不对？呃，那那你想这个你既然是按照这个点击量统计算钱，那我如果想让我这个页面的这个，我这个商品页面的这个广告更值钱一些，我是不是就使劲儿的点啊，对吧，使劲的点给你把这个量刷上去，那到时候我这个广告当然就就比较值钱了嘛，所以这种情况其实是类似于刷单的一种操作了啊，它是频繁的这个点击行为。

那我们是不是应该对这样的行为做一个过滤啊好，那大家想到这个东西怎么去做过滤呢？哦，这里边其实大家会想到是不是就是数据来了之后，相当于我们是不是又得存一个列表啊呃，也类似于这样的一个操作，对不对把或者是我至少不存一个列列表是不是至少要存一个，你当前到底点这个广告点了多少次对吧？同一个用户点一个广告点了多少次，是不是要保存一下这个状态啊，所以把这个保存下来。如果达到一定上限，那是不是就应该给它过滤掉了，对吧，你就不应该再点了，你再点我就不给基数了，另外如果达到一定这个程度，是不是我应该有一个黑名单机制啊，对吧，我应该今天比方说我就把这个用户就是添加到黑名单里边，输出一个报警信息，那后续你可能就看着这个黑名单有一些操作了，是给他这个用户啊，限制他的权限，还是说给他一个短信提示，还是怎么怎么样，对吧？这就是我们后续的一些操作了，那当然这个黑名单是不是可以以一个测输出流的形式。

输出到一个另外的一个地方去做处理啊，那正常，那我们主流里边是干什么呢？主流是不是这里边过滤完了之后，还要接下来继续开窗去做统计啊，对吧？所以大家就想到这是我们的一个流程，这个呃，进行黑名单过滤的这个流程，其实是在开窗统计之前的一步啊，这就是我们整个处理的过程啊。好，接下来再说一下这个恶意登录，恶意登录呃，恶意登录的话，这个需求就比较简单了，因为大家知道如果一个用户同一个用户在短时间之内频繁登录失败，那是有可能遭到了恶意攻击，所以我们的需求就是说，假如一个用户在两秒钟之内啊，当然这个这个需求给的比较比较简单啊，就是大家可以把这个指标调高对不对啊，连续两次登录失败的话，我就立刻就报警。

就先有一个报警信息，这个账，这个账户有可能有问题，对吧？啊，那当然了，大家会看到这个我们是判断同一个用户还是同一个IP呢。我们当然是得用用户ID对不对，那大家想到有一些这个黑客，或者说他的攻击程序其实做的是很，呃，就是比较高级的，他是不是可以去挂代理，不停的变换IP啊，呃，其实是有这种攻击手段的啊，所以我们当然是要用这个用户的ID去做检测。那这个过程大家想怎么去实现呢？一个简单的想法是，呃，大家会想到是不是这可以用那个状态编程来处理啊，呃，状态编程跟思想你是两秒钟之内连续两次登陆失败，大家能联系起什么来，是不是就能啊联系red是吧，我们之前其实啊，当然red里边是有这种就是失效时间类似这样的一些东西的，对吧？但是这里边这里边我们是要连续检测它两两次登录失败，这个跟那个失效时间还不太一样，对吧？对，当时我们状态编程是不是讲过一个对在几秒钟之内温度连续升高的那个例子啊，哎，那大家想这个是不是有一点类似，诶，所以我们可以用类似的一个思维啊，就比方说我们是不是可以检测到登录失败的话，就把它存到一个列表里边。

然后是不是设一个定时线，然后在这个过程当中，哎，来一次失败我就存一个，来一次失败就存一个，等到两秒钟之后触发，然后看这个列表里边到底失败了几次对不对，那一旦要是中间登录成功了，按我们的规则是不是就把这个清空就好了啊，所以这是就是大家能够想到一种比较简单的实现，那其实这个过程大家会想到状态编程其实还是挺烦的，有没有更容易更简单的实现方式呢？

啊，其实是有的，就是在这个呃，CP里边啊，就就是在这个flink里边，它给我们提供了一个库叫CP，就是复杂事件处理，它其实可以实现事件流上的一个类似于模式匹配这样的一个状态，就是它可以检测出来，诶登录失败了，然后又登录失败了，对吧，连续登录失败，他直接可以配置这样的一个模式，这个就是到时候我们给大家用不同的方法把这个需求做一个实现。呃，然后最后一个拈是订单相关，那这里面又分了两部分，一个是对订单的支付做一个实时监控，做一个呃超时的失效处理，那大家会想到就是用户下单之后呢，你说这个订单难道就是一直挂在那儿，一直有效吗？他是随时去支付都可以吗？啊，其实不应该对吧？呃，大家如果有这个经验的话，会发现一般的网站，或者说一般的这个，呃，我们不管是网就是电商还是其他的一些业务背景的啊，涉及到支付的时候，下订单的时候，是不是往往都有一个失效时间啊，对吧？啊请你赶快支付订单在多长时间内有效啊，之后就就就会失效了，就会取消，那大家想想这是为什么呢？

那首先这个是不是本身你如果要是大量下单又不支付的话，相当于是不是有一些系统风险啊，对吧，这个有可能是有人在搞破坏对吧，搞一些莫名其妙的事情，而且大家会发现，如果说你在有一些场景里边下了单之后一直。单单想，如果说你这个单已经下了的话，库存里边是不是这个商品就应该减掉啊，你这个商品还能再卖吗？啊，已已经有人下订单，已经把它订个订订购了，对吧，那是不是这个就已经要从这个商品架上要下架啊，对吧，正常来讲是应该这样的一个操作，比方说大家想一想，你在这个12306上订票，那是不是你这里边。

呃，买票的时候还没支付一下单，是不是他就应该锁定这个票别人不能买了，要不然大家想一想，你在这个春运的时候抢票的时候，你你下了单了，还没支付的时候，别人直接把这个票票给抢走了，你想想你这个有多多多憋屈对吧？啊，所以显然这个过程是他应该把这个库存要锁定的啊，所以从这个角度讲，业务流程讲，显然是得有一个失效时间，另外一个其实呢，它其实也是设置失效时间是有好处的。它可以提高用户的支付意愿啊，这个也很好理解，假如说我下了订单之后随时支付都行，没有失效时间，那是不是大家都无所谓了，对吧，那我就来不来随便就给你下个单，先占了再说啊，到时候我我想买的时候，对吧，心情好的时候我再去买，那这种下单这就没意义了，这跟购物车一样了，对不对啊，所以而且它又是一个很重的操作，你要锁定库存，所以显然是显然是不恰当，那所以这里边我们应该去设置一个订单失效时间，我们的需求就是用户下单15分钟之后，如果没有支付的话，那输出一个监控的信息提示，对吧？呃，当前这个应该失效了，我们应该把它置为失效状态。

大家想一想，这个在其实我们更常见的做法就是我们可能是用数据库去做的，对不对？呃，有同学刚才也提到了这个red red里边其实是不是可以直接做这个事情啊，对吧？啊，那当然了，就是说如果我们遇到这个数据量特别特别大的场景，那有可能啊，会出现这个数据库也会性能受到影响，对吧，有可能搞不定的这种场景，那我们是不是就可以用flink这样的实时的处理，呃，这个大数据处理引擎来解决这样一个问题啊，那我们的思路是怎么做呢？同样也可以用cep，也可以用状态编程啊，就是这个逻辑是不是就是我要判断在这个时间段内，哎，你是不是有这个下订单的一个一个日志来了，一个事件来了，但是后边没有支付，对吧，如果出现这种情况，到了15分钟的时候，我就得输出一个监控的一个报警信息啊，这就是我们。

实现的一个思路。好，然后最后一部分呢，还有一个拈是订单支付的实时对账，诶这个又是在做什么事情呢？呃，这个可以跟大家说一个就是就是具体的一个场景啊，大家可能会想到我们一般情况做这个支付，我们可能都会调用这个第三方支付平台，对吧？呃，这个支付宝或者说微信去支付，那这个时候用户那边他调用这个支付成功之后，正常来讲是不是应该第三方平台会给我们有一个返回啊，我们收到返回就认为他已经支付成功了，我们这边可能就做这些操作了，但是有时候大家会会会想到啊，当然一方面就是说是不是有可能我收到了这个支付的这个结果，但是有可能那个账还没到啊，啊有可能出现这种情况对不对？

那还有另外一种情况是可能网络的问题。他那边第三方平台已经支付成功了，但是它那个返回我们没收到，对吧，这两种情况是不是都有可能有问题啊。所以这相当于就有一个这个对账的需求出现了，那这个对账怎么做呢？大家想一想。我们的数据应该是来从哪里来的，这个数据其实就是要至少有两个源来自于两条数据流了，为什么呢？因为一条应该是订单支付的时候，我们拿到的第三方平台返回的那个信息，对不对啊，这个我们可以在业务系统里边代码里边是不是也是埋一个点，收到的时候是不是就把它写到日志里边哦，那我们可以从这个本身业务系统的埋点日志里边获取，那另外那个我们的本身那个账户到账的那个信息。

那怎么办呢？那是不是得单独起一个应用，或者说跑一个程序去查询我们本身的那个账户里边的一些数据啊，啊，所以说本身的这一个到账信息，或者说交易的这个具体的处理信息，这个可能我们是需要用另外一个任务去跑的，所以那个任务又会产生它对应的一些log，或者说我们查询的一些实时查询的一些结果，我们可以把它作为另外一个数据源输入，所以现在我们要做的事情其实是什么？是要处理两条流了，两条流那那怎么处理呢？是不是就应该要做一个合并啊，哎，我们可以用一个connect把它两条流连接起来，然后接下来怎么办呢？啊，那样处理是不是就是你要不就是抠map扣flat map，要不我们直接放大招，是不是可以用一个抠process function去处理啊啊这个讲到process function的时候，给大家讲过有各种不同的process function处理两条流连接起来之后，这个状态是不是就是Co process function啊，所以用这种方式就可以做一个处理了啊，这就是我们整个这个项目想要实现的一些需求和基本的一些思路啊，所以给大家把这个框架先梳理清楚，大家先有一个整体的概念。