大数据十大经典算法之Aprior算法

最新推荐文章于 2024-08-28 22:29:36 发布

Angelahhj

最新推荐文章于 2024-08-28 22:29:36 发布

阅读量4.1k

点赞数 2

CC 4.0 BY-SA版权

分类专栏：大数据文章标签：数据挖掘算法数据分析 Aprior

本文链接：https://blog.youkuaiyun.com/Angelahhj/article/details/40510119

大数据专栏收录该内容

6 篇文章

订阅专栏

本文采用Apriori算法对Mushroom数据集进行关联规则挖掘，通过数据预处理、算法执行过程和结果分析，揭示了在不同支持度下关联规则的变化规律，同时分析了Apriori算法的特点与效率，强调了参数选择的重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

数据集描述

本文采用mushroom 数据集，该数据集由Jeff Schlimmer在1987年贡献，通常用于分类算法中。mushroom数据集包含8124个数据项。

数据如下：

数据预处理过程

在数据分析过程中，获得进行统计分析和建模的对象（即数据）的过程也是必不可少的重要环节。数据的预处理包括数据整理、数据合并及分拆、数据清洗、数据变换等内容。

本文采用的数据预处理方法是把字符转换成数字，这样方便数据信息的扫描。

挖掘算法描述

由Agrawal等人提出的Apriori是经典的关联规则和频繁项集挖掘算法，围绕着它的改进和实现有大量的文献。该算法是挖掘产生布尔关联规则频繁项目集的经典算法，从其产生到现在对关联规则挖掘方面的研究有着很大的影响。

算法执行过程：

宽度优先搜索整个项集空间，从k=0开始，迭代产生长度为k+1的候选项集的集合C_k+1。候选项集是其所有子集都是频繁项集的项集。C₁由I₀中所有的项构成，在第k层产生所有长度为k+1的项集。这由两步完成：第一步，F_k自连接。将F_k中具有相同(k-1)-前缀的项集连接成长度为k的候选项集。第二步是剪枝，如果项集的所有长度为k的子集都在F_k中，该项集才能作为候选项集被加入C_k+1中。为了计算所有长度为k的候选项集的支持度，在数据库水平表示方式下，需要扫描数据库一遍。在每次扫描中，对数据库中的每条交易记录，为其中所包含的所有候选k-项集的支持度计数加1。所有频繁的k-项集被加入F_k中。此过程直至C_k+1等于空集时结束。详细过程如下图所示：

挖掘结果分析

算法运行后的首界面如下图所示：

在支持度为0.2时的两项关联结果：

在最小支持度为0.2时的n-1项关联结果：

在支持度为0.2时的n项关联结果：

运行结果分析：

该算法的运行环境如下，软件环境：Win7 ， Microsoft Visual Studio 2008，硬件环境：PC机，1.8GHZ主频，2G内存。改变参数得到下表：

最小支持度	执行时间	最小支持度个数	关联的最多项数
0.15	11.590	1218	12
0.2	7.254	1624	12
0.3	3.635	2437	11
0.4	1.404	3249	10
0.5	0.734	4062	9

通过上表我们可以看出，随着支持度的增加，执行时间越来越少，最小支持度的个数增加，有关联关系的项数减少。因为Aprior算法是反复地扫描数据库、计算候选集的支持度，再生成新的长度加1的候选集，Apriori算法是冗长乏味的，尤其是当存在长模式的时候。每一次剪枝操作都会对数据库进行扫描，每一次product操作需要对队列中的k-集合两两进行join操作，其复杂度为C(sizeof(L(k)),2)。对于较大的数据集，如果时间要求很高，那么我们就不能把支持度设置的很小，这样带来的代价是可能有关联关系的长模式就被过滤掉了。所以在使用该算法时，要根据我们的需求，恰当的设置参数，才能得到我们理想的实验结果。

Aprior算法特点的分析

Apriori算法性质分析：

为了提高频繁项目的挖掘效率，Apriori算法利用了两个重要的性质，用于压缩搜索的空间。

【1】若X为频繁项目集，则X的所有子集都是频繁项目集。

【2】若X为非频繁项目集，则X的所有超集均为非频繁项目集。

Apriori算法的效率分析：

（1）Apriori性质能显著减少候选集的数目。事务数据库TDB总共有4个项目，因此可能的2-项集有 =6个。利用Apriori性质，我们可能只需要检查4个候选2-项集的支持度。Apriori算法在2项集这个层次上剪枝率达33.3%。随着候选集的长度逐渐增大，可能的组合数目也急剧增大，因此Apriori算法的剪枝效率也越来越高。

（2）尽管Apriori能对大量候选集剪枝，但是在大型的事务数据库中，仍然可能有大量的候选集需要处理，并且这种操作相当耗时。例如，如果事务数据库包含10⁶个项目，并且只有1%（即10⁴）的项目是频繁的，Apriori需要产生超过10⁷个候选2-项集，扫描数据库计算它们的支持度，生成L₂以产生候选3-项集。

（3）反复地扫描数据库、计算候选集的支持度，再生成新的长度加1的候选集，Apriori算法是冗长乏味的，尤其是当存在长模式的时候。Apriori是一种产生候选集，然后检测其支持度的算法。

Apriori算法存在的缺点，我们应该对Apriori算法进行多方面的改进，找出一个高效、可靠的挖掘频繁项集的算法。这些算法目前的增量更新算法、并行算法等，大多是以 Apriori 为核心，或是其变体，或是其扩展。我觉得我们应该根据不同实验环境的需求，恰当的使用相关的算法。