本项目旨在通过 Flink 解决生产中的实时需求处理. 本项目选择比较通用的电商模块, 通过对用户行为日志的分析, 实现以下需求的实时统计或分析:
- 实时热门商品统计
- 实时流量统计
- 市场营销商业指标统计分析
- 恶意登录监控
- 订单支付实时监控
这部分也可以参考 用户行为分析需求思维导图
每隔 5 分钟输出最近一小时内点击量最多的前 N 个商品.
读取服务器日志中的每一行log, 统计在一段时间内用户访问每一个url的次数, 然后排序输出显示.
每隔5秒, 输出最近10分钟内访问量最多的前N个URL. 可以看出, 这个需求与之前“实时热门商品统计”非常类似
衡量网站流量一个最简单的指标, 就是网站的页面浏览量 (Page View, PV) . 用户每次打开一个页面便记录1次PV, 多次打开同一页面则浏览量累计. 一般来说, PV与来访者的数量成正比, 但是PV并不直接决定页面的真实来访者数量, 如同一个来访者通过不断的刷新页面, 也可以制造出非常高的PV.
我们知道, 用户浏览页面时, 会从浏览器向网络服务器发出一个请求 (Request) , 网络服务器接到这个请求后, 会将该请求对应的一个网页 (Page) 发送给浏览器, 从而产生了一个PV. 所以我们的统计方法, 可以是从web服务器的日志中去提取对应的页面访问然后统计, 就向上一节中的做法一样; 也可以直接从埋点日志中提取用户发来的页面请求, 从而统计出总浏览量.
所以, 接下来我们用UserBehavior.csv作为数据源, 实现一个网站总浏览量的统计. 我们可以设置滚动时间窗口, 实时统计每小时内的网站PV.
PV 统计的是所有用户对页面的所有浏览行为, 也就是说, 同一用户的浏览行为会被重复统计. 而在实际应用中, 我们往往还会关注, 在一段时间内到底有多少不同的用户访问了网站.
另外一个统计流量的重要指标是网站的独立访客数 (Unique Visitor, UV) . UV指的是一段时间 (比如一小时) 内访问网站的总人数, 1天内同一访客的多次访问只记录为一个访客. 通过IP和cookie一般是判断UV值的两种方式. 当客户端第一次访问某个网站服务器的时候, 网站服务器会给这个客户端的电脑发出一个Cookie, 通常放在这个客户端电脑的C盘当中. 在这个Cookie中会分配一个独一无二的编号, 这其中会记录一些访问服务器的信息, 如访问时间, 访问了哪些页面等等. 当你下次再访问这个服务器的时候, 服务器就可以直接从你的电脑中找到上一次放进去的Cookie文件, 并且对其进行一些更新, 但那个独一无二的编号是不会变的.
当然, 对于UserBehavior数据源来说, 我们直接可以根据userId来区分不同的用户.
随着智能手机的普及, 在如今的电商网站中已经有越来越多的用户来自移动端, 相比起传统浏览器的登录方式, 手机APP成为了更多用户访问电商网站的首选. 对于电商企业来说, 一般会通过各种不同的渠道对自己的APP进行市场推广, 而这些渠道的统计数据 (比如, 不同网站上广告链接的点击量、APP下载量) 就成了市场营销的重要商业指标.
电商网站的市场营销商业指标中, 除了自身的APP推广, 还会考虑到页面上的广告投放 (包括自己经营的产品和其它网站的广告) . 所以广告相关的统计分析, 也是市场营销的重要指标.
对于广告的统计, 最简单也最重要的就是页面广告的点击量, 网站往往需要根据广告点击量来制定定价策略和调整推广方式, 而且也可以借此收集用户的偏好信息. 更加具体的应用是, 我们可以根据用户的地理位置进行划分, 从而总结出不同省份用户对不同广告的偏好, 这样更有助于广告的精准投放.
页面广告按照省份划分的点击量的统计.
点击量统计, 同一用户的重复点击是会叠加计算的. 在实际场景中, 同一用户确实可能反复点开同一个广告, 这也说明了用户对广告更大的兴趣; 但是如果用户在一段时间非常频繁地点击广告, 这显然不是一个正常行为, 有刷点击量的嫌疑. 所以我们可以对一段时间内 (比如一天内) 的用户点击行为进行约束, 如果对同一个广告点击超过一定限额 (比如100次) , 应该把该用户加入黑名单并报警, 此后其点击行为不应该再统计.
对于网站而言, 用户登录并不是频繁的业务操作. 如果一个用户短时间内频繁登录失败, 就有可能是出现了程序的恶意攻击, 比如密码暴力破解. 因此我们考虑, 应该对用户的登录失败动作进行统计, 具体来说, 如果同一用户 (可以是不同IP) 在2秒之内连续两次登录失败, 就认为存在恶意登录的风险, 输出相关的信息进行报警提示. 这是电商网站、也是几乎所有网站风控的基本一环.
电商网站中, 订单的支付作为直接与营销收入挂钩的一环, 在业务流程中非常重要. 对于订单而言, 为了正确控制业务流程, 也为了增加用户的支付意愿, 网站一般会设置一个支付失效时间, 超过一段时间不支付的订单就会被取消. 另外, 对于订单的支付, 我们还应保证用户支付的正确性, 这可以通过第三方支付平台的交易数据来做一个实时对账. 在接下来的内容中, 我们将实现这两个需求.
在电商平台中, 最终创造收入和利润的是用户下单购买的环节; 更具体一点, 是用户真正完成支付动作的时候. 用户下单的行为可以表明用户对商品的需求, 但在现实中, 并不是每次下单都会被用户立刻支付. 当拖延一段时间后, 用户支付的意愿会降低. 所以为了让用户更有紧迫感从而提高支付转化率, 同时也为了防范订单支付环节的安全风险, 电商网站往往会对订单状态进行监控, 设置一个失效时间 (比如15分钟) , 如果下单后一段时间仍未支付, 订单就会被取消.
对于订单支付事件, 用户支付完成其实并不算完, 我们还得确认平台账户上是否到账了. 而往往这会来自不同的日志信息, 所以我们要同时读入两条流的数据来做合并处理. 这里我们利用connect将两条流进行连接, 然后用自定义的CoProcessFunction进行处理.