FPGrowth 算法使用详解

当初要研究关联规则挖掘算法，就是为了解决 商城购物车页 采用协同过滤效果一般的问题，既然对 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