apriori算法的计算量太大,如果数据集略大一些,会比较慢,非常容易内存溢出。
我们可以算一下复杂度:假设样本数有N个,样本属性为M个,每个样本属性平均有K个nominal值。
1. 计算一项频繁集的时间复杂度是O(N*M*K)。
2. 假设具有最小支持度的频繁项是q个,根据它们则依次生成一项频繁集,二项频繁集,....,r项频繁集合,它们的元素数量分别是:c(q, 1), c(q,2), ...,c(q, r)。那么频繁集的数量是极大的,单机肯定不能支持,比如说,假设q=10000--其实很小,电商/零售商的数据比这大太多了--此时生成的二项频繁集合的元素数量是5千万,三项频繁集超过1000亿... 打住吧,不要再往下算了...
3. 如果transaction有100万个,这也不算多,但计算二项频繁集的关联规则就要扫描数据库100万*5千万。
所以快速算法是必须,否则搞不下去。
fp-growth就是一种快速算法,设计非常巧妙,它的流程是这样的:
1. 计算最小支持度频繁项,并按照支持度从大到小排列,形如{'f':100, 'c':84, 'd':75, 'a':43, 'q':19, ...}
2. 把transaction的所有记录,都按照最小支持度频繁项进行排列,如果没有某个频繁项,就空下来,于是,transaction就是如下的形式:
{'f', 'd', 'q', ....} //前面是频繁项,后面是非频繁项
{'c', 'd', 'a', ...}
...
3. 然后,建立一个fp-tree,树结构:
3.1 树的根节点是null
3.2 把transaction的记录向树结构做插入:
3.2.1 第一次插入{'f', 'd', 'q', ....},此时null的子节点没有'f',那就建立一个名为'f'的节点,将它的次数计为1,然后将这个transaction的id存储在节点。
3.2.2 第二次插入{'c', 'd', 'a', ...},此时null的子节点没有'c',那就建立一个名为'f'的节点,将它的次数计为1,然后将这个transaction的id存储在节点。
3.2.3 以此类推,继续插入其他所有记录,如果遇到节点已经存在,把节点次数+1,再把transaction加入到节点。
3.2.4 当所有的transaction被加入到fp-tree之后,fp-tree的第一层子节点有若干个,就把所有transaction的第一个元素进行了分类。
3.2.5 再按照这个方式,再对所有transaction的第二个元素进行分类,也就是在fp-tree的根节点的子节点进行上述3.2.1~3.2.3的操作。
3.2.6 知道将所有transaction分到不在有符合最小支持度的元素为止。这样fp-tree就建成了。
3.3 计算关联规则,这就是很简单啦,凡是需要计算的频繁项集合,都在fp-tree上按照支持度列出来了,从根节点挨个往下薅就行了,而且,再也不需要遍历所有的transaction了,计算量大大减少。
3.4 fp-tree的结构,很容易拆分到并行或者分布式计算。
4. 实际上,在原作paper,构造fp-tree的方式和本文的方式略有差别,它是深度优先的,比如说,对第一个transaction是一次性建立'f'-->'d'-->'q'三个节点,然后计数,其他以此类推。本文的方式为了方便理解。