weka实战004：fp-growth关联规则算法

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的结构，很容易拆分到并行或者分布式计算。

原文：http://blog.csdn.net/lizhe_dashuju/article/details/45948671