当初要研究关联规则挖掘算法，就是为了解决 商城购物车页 采用协同过滤效果一般的问题，既然对 FPGrowth算法原理已经掌握得很好了，学它当然是为了用它，那么应该如何构造数据？得到频繁模式后又如何应用到推荐系统中？在掌握了算法的使用之后，作为 IT 工作者，忍不住要一探究竟：FPGrowth 到底是如何实现的？
这些问题，将会在本篇得到答案。
本篇代码的软件环境：Spark 2.4.0。
一句话需求
提高商城购物车页的推荐指标。
需求一句话，开发把班加！
数据源
假设我们拥有这样一张数据表：
| user | item | action_type | session_id | timestamp | day |
|---|---|---|---|---|---|
| 用户 ID | 物品 ID | 行为类型 | 会话 ID | 行为时间戳 | 分区日期 |
表字段说明：
- 用户 ID：用户 ID
- 物品 ID：物品 ID
- 行为类型：这里需要注意一下，我们要优化的是购物车页的指标，需要找到关联的物品而不是相似的物品，所以我们只采用用户的加车、收藏和购买数据
- 会话 ID：商城 App 的每条数据都有
session_id这么一个字段，用户从打开 App 开始直到关闭 APP 止，session_id是唯一的。再次打开 App 时会重新生成一个session_id - 行为时间戳：顾名思义
- 分区日期：当天的日期
关联规则挖掘需要 Transaction，所以我们就需要定义什么才算是 1 个 Transaction。
Transaction：3 天内用户的所有加车、收藏和购买行为作为 1 个
Transaction。
当然读者可能会有疑问：为什么不以一个 session_id 内用户的行为作为 1 个 Transaction，而要使用 3 天的时间呢？
这是因为商城（可以泛化到一般的电商）的用户行为特别的稀疏，更别提 加车、收藏和购买 这种又更稀疏的用户行为了，如果单单以 1 次 session_id 或者 1 天 的用户行为作为 Transaction 的话，那么有很大的可能会导致大部分的 Transaction 中含有的物品个数为 1 个，而这对于关联规则挖掘算法来说基本等同于无用数据。当然，读者们可以根据自己的数据来设定到底是用 1 周还是 3 天 还是 1 天的数据。
下面这张图展示了 Transaction 的生成过程，为了演示清楚，只用一个用户——小明：
Transaction
网友评论