003_尚硅谷大数据技术_用户行为数据分析Flink项目_项目介绍（三）_项目模块设计

现在已经知道电商用户行为分析，我们把这个数据提取出来之后能够做什么事了，那现在我们当前的这个项目到底是主要用来分析哪些？呃，就是做哪些需求呢？实现哪些功能呢？诶这里面大家就要考虑了，我们当前哪些分析的这个手段是需要实时性非常高，哪些是可能数据量非常大，我们需要去做离线处理的呢？那首先其实大家想到就是我我们前面讲的那个批处理跟流处理啊，那是不是如果数据非常非常海量的话，那我们就只能用离线处理对吧？那如果只要不是那个非常海量的数据，那是不是流失处理的话，至少它的那个时效性会比离线处理要好很多啊，诶所以假如是同样的需求，我做离线分析你可以去做，呃，就是写一个CQ，直接把它在在这个数仓里边，对吧，把它提取出来，统计出这个结果，那我如果要是能用flink这样的流式架构做实时分析的话，那不是更好吗？得到结果都一样，它的效果就是变快了，哎，所以自然我们能想到，只要是对这个实时性要求，就是只要是能做转换的啊，我们都可以用这个流失处理架构去做一个时效性的提升，那这里边大家就要分析一下，到底哪些是很有必要，哪些是可能没那么有必要的呢？

诶，那首先我们就看一下统计分析各种统计指标，要生成报表的时候，大家想一下这个我们对于实时性的要求高不高。哎，当然有同学说这个要求可能没那么高，对吧，好像这个我稍微晚一点啊，比方说我做一个离线处理，但是大家想我们传统做离线处理的时候，是不是有可能会比方说我统计一个月的数据，对吧，我统计三个月一个季度的数据，那是不是可能这个跑就是我们之前说的要要要跑几个小时甚至一天啊。那你说这个时间是不是还是差别有点大呀？啊，另外就还涉及到一些有一些的这个我们统计的这个数据，它是不是有可能要做实时展示啊，比方说像我们之前那个温度，实时的那个温度值，当前那个比方说最大的对吧，当前来讲这个实时的最大的温度值，它是不是需要实时显示，实时更新啊啊所以在这种场景下，其实我们对于这一个统计分析也是要有一个时效性的保证的。

或者至少比方说你统计的，你不是那种要求它实时更新啊，随时变化，那我要求的是我显示一个小时统计一次当前的这个，比方说当前我们这个商商品的这个销售销售额，对吧，或者说我统计一下当前的这个PVUV，那大家想一个小时统计一次的话，那你如果说数据量特别大，你先攒齐了再去统计。出结果的时候是不是有可能就会滞后比较长的时间啊，有可能隔了半个小时才才统计出上一个上一个窗口的结果，对吧，那这个时效性是不是看起来就非常的差。而如果说我们用流式处理，用flink的话，是不是可以相当于窗口结束时间，马上就可以把那个结果输出，因为大家知道我是增量聚合的嘛，来一个的时候同时就把这个结果都已经聚合在一起了，到点的时候直接输出就完事了，对吧？哎，这就是你的这个统计分析结果啊，我要统计八点到九点的数据，你是直接。

我我来一个处理一个，等到九点的时候马上就得到结果，还是说到九点的时候我才把所有的数据都攒齐，然后开始遍历，开始去计算，对吧，然后可能要算个几分钟甚至几十分钟啊，所以这就是这个差别，那大家想我能快是不是更好啊，那所以当然这个统计分析，我们用这个流梳理是没有问题的啊，而且有些场景是确实也需要用流处理。呃，然后另外这个风险控制，其实这个大家想这个是这个是不是对时效性要求非常高啊，马上出现这个异常，马上要检测到对吧，所以这个是没有问题的啊，肯定这个就用，呃这个这个用用批处理其实是不合适的，就必须得用流处理，之前我们都是用业务系统去搞的嘛，啊，所以现在我们是把那业务系统的功能承接过来了，而中间这一部分偏好统计呢，就做这个用户画像和推荐列表呢。

大家会想一下，就是用户画像，我现在如果用户实时的来了一个点击行为，难道这个用户的画像就变了吗？没有那么快，对吧，那就是当前我的每一次行为，这可能我要收集非常大量非常多的历史数据来了之后，我可能才能把这个用户的画像勾勒出来，才能看到一个大概的一个场景，对吧？哎，所以大家会发现这种场景其实对于时效性的要求是不高的。啊，当然有些同学可能会想到那推荐列表呢，推荐列表这个对时效性要求高啊，但大家想这个实时推荐的话，是不是我其实也是基于之前我给出的这个用户画像，或者接下来我是，呃，就是比方说用户刚点了一个什么，我就推他相相关的那个东西，对吧，这种其实在电商这个行为分析里边，其实是相对来讲可能也也有应用啊，但是可能应用的话不如在这个短视频里边那个呃更多，大家知道短视频里边的话，就是你刚看了一个之后马上划过来，是不是就都是类似的东西啊对吧，他就直接用这个你当前的这个行为给你推荐相关的东西出来就完事了啊，这个里边有时候是对这个时效性比较高的啊，但是如果说你要是基于当前的用户画像去做关联规则推荐的话，那是不是前提还是有海量数据，你先得分析出来这个用户到底喜欢什么呀啊，所以这是这个偏好统计这一部分啊，然后另外就是说这里边还还会涉及到这个特征。

工程和机器学习算法这一部分的话，那大家想这个就这是另外一个很大的课题了，对吧？我们这里边可能需要更多的这个基础知识，这个我们就不再统一展开了，所以接下来我们的项目里边主要给大家要做的事情就是统计分析和风险风险控制两大类，对吧？啊，所以接下来我们的这个模块设计就是分成了这样两大类，然后具体来讲的话，实时统计分析这一部分有这么几个模块啊，就是我们做这个实时的热门商品统计，做一个热门统计啊，大家知道热门统计是不是就是top n啊，类似于top n的一个需求，然后另外还有就是实时页页面流量，热门的页面流量统计，那这个其实类似于也是一个hot top n的统计，对吧？啊，那另外还有就是访问流量，PVUV的统计，还有就是APP市场推广，另外还有这个广告点击量的统计，其实主要就是这些啊，那这只是举例啊，大家想这里面连连那个订单统计都都没列出来对吧？呃。

这个主要是因为我们的测试数据里边，呃，缺失这个订单的这些信息啊，所以说我们就不给大家就是重复的去讲这个实现了，其实大家想你既然能统计点击量，是不是来了订单数据的话也是一样统计啊，不就是一个count吗？对吧？或者你如果想统计那个销售额的话，不就是1SUM吗？啊，所以这个实现是非常类似的。另外呢，我们要给大家讲一讲这个业务流程和风险控制，讲风控类指标，这一类指标大家看到有什么呢？比方说有这个黑名单过滤，这黑名单指的是什么？就是类似于如果出现那种疯狂的点击一个广告的时候，类似于一个刷单行为，对吧？检测到这种异常行为的时候，我把它做一个黑名单过滤，另外还有就是恶意登录，短时间内大量登录失败，我要做一个检测，还有呢，就是前面我们提到的订单，如果支付失效的话，隔一段时间失效了，我要做一个监控，做一个报警，对吧？呃，最后还有一个需求是支付实时对账，这指的就是说我们正常支付的话，大家知道其实现在都是基于第三方支付平台了啊，那如果说第三方支付平台那边给我们一个确认信息，我就认为已经这个交易完成对吧，那大家想到在有一些场景下，可能我还要去做一个对账校对，就是我还得查自己的那个平台账号到底到了没有，对不对。

啊，这笔钱如果到了的话，这才是一个完整的交易啊，所以我们到时候给大家讲一讲这个实时对账的过程，这就是整体的一个拈设计啊，具体来说的话，那就是这张图了，五个具体的拈块，然后指标的话可能分成了啊，应该有这样的九个指标啊，就是具体来讲这么分啊啊呃，那这个关于这个模块的划分呢，大概就是这样，接下来我们重点是要给大家分析第一个拈，就是热门商品这一部分，然后在这之前呢，要给大家说一下当前我们的这个数据源是什么样的数据源，这里边是有一个CSV文件，叫做user behavior csv，它里边的字段大家看啊，大家看这个明显这是做过ETL的，对不对，它已经不是我们熟悉的那种日志数据了，它本身已经变成了逗号分割的一个CSV文件嘛，我们想要的字段是不是就已经提取出来了啊，然后这分别是哪些这个字段呢？这里边主要就是哦，这里边给大家。

看一眼啊，主要就是user ID，然后item ID，然后是一个类别ID对吧，品类ID，然后后面还有当前的这个行为，也就是说用户对于哪个类型的哪个商品做了一个什么事，然后这个行为呢，这里比较少，这个数据还是比较少啊啊尽管这个u behavior这个数据已经是某个电商平台的一个真实数据提取出来我们拿到的啊，但是这个数据量呢，还是比较少，有一些特定行为就拿不到，只能拿到什么呢？PVPV大家知道就是一个浏览行为对吧，点击浏览行为，然后BY的话就是一个下单购买行为，还有就是cut cut是对呃，就是收藏对吧，是呃，购物车对吧，收藏到购物车的这个行为，还有这个废物的话，就类似于like对吧，喜欢的这样一个行为，只有这么几种，然后最后还有一个就是时间戳了啊，这是已经提取之后的啊，所以大家想我是不是应该包装成这样的一个。

一个po类型啊，对吧，一个一个Java并类似于Java并的一个类型，后面我的数据流里边是不是直接用这个做操作就可以了啊，这个其实还是比较简单的一个想法啊。

然后另外呢，我们会想到更加真实的场景，其实我们拿到的不应该是ETL之后的数据，应该是什么呢？是不是就是log呀，就是日志对吧？呃，然后一般我们应该是有那个业业务系统里面应该有买点日志，把把这个数据是不是都收集起来啊，那假如说没有买点日志怎么办呢？我们还可以直接去看web服务器的日志，因为大家知道web服务器里边是不是都会就用户那边做一个操作，做一个行为，都会向web服务器提交一个请求啊。HTV请求对吧，所以我们把这个收集起来的话，有时候也是可以表达一些事情的，比方说这里边收集起来这个日志长什么样呢？诶大家看这就是一个IP对吧？然后中间两个杠，这其实是user ID和username啊，有时候我们用户是匿名的，那那就收集不到，后边还有时间，呃，然后加0000，这个是这个是时区，这个我们就不管了，对吧，后面就是get，这是当前发起的请求，最后还有。

当前的URL对吧，所以有时候如果我收集不到用户的那个买点日志的话，行为的那个买点日志的话，我用这个当前的服务器日志是不是也是可以啊，就是web服务器日志啊，也是可以收集起来的，那这个数据我们包装起来就是我可以把它叫做阿帕奇log event对吧，关心的就是IP user ID。大家想我不关心username对吧，我直接把它滤掉啊，IP user ID，然后even time，呃，这里边也可以就叫time STEM对吧？大家想我最后要用的那个东西是不是应该把这个时间转成一个长整型的时间戳啊，啊，这样的话后面才好用嘛，啊所以后续还有这个method和URL，这就是我们现在能够用到的一些数据，当然有一些模块里边大家看到，比方说后面我们还有那个登录，这里面没有登用户登录信息对吧？那所以比方说我们要检测那个连续登录失败的那个异常报警的话，那可能我们就去用一些自定义的测试数据源对吧？呃，就是大家用一些测试数据源把它这个功能实现就可以了，这就是关于我们当前这个项目模块的划分和数据源的一个一个准备。