關聯規則：評定規則的標准
支持度：規則前項LHS和規則后項RHS所包括的商品都同時出現的概率，LHS和RHS商品的交易次數/總交易次數。
置信度：在所有的購買了左邊商品的交易中，同時又購買了右邊商品的交易機率，包含規則兩邊商品的交易次數/包括規則左邊商品的交易次數。
提升度（有這個規則和沒有這個規則是否概率會提升，規則是否有價值）：無任何約束的情況下買后項的交易次數/置信度。提升度必須大於1才有意義。
一、Aprioir（利用以前的頻繁集產生候選集，從長度為1到2到3...）
利用性質的關鍵：一個itemsets要想頻繁，它所有子集必須頻繁，反過來如果有子集不頻繁，它的超集也就不可能頻繁。所有就可以先找短的，長度為1的都不頻繁，包含這個的長的item就不可能頻繁，如果長度為1的頻繁，就可以繼續通過這個找潛在的候選集。
多遍數據庫掃描是昂貴的，挖掘長模式需要很多遍掃描，並產生大量候選。Aprioir具有的性質：頻繁項集的所有非空子集也必須是頻繁的。向下閉包性，利用已滿足支持度的頻繁，進行組合，生成候選集，只有這些候選集才有可能
首先找頻繁一項集（滿足最小支持度要求的項集），在頻繁一項集的基礎上尋找頻繁二項集，再依次尋找頻繁三、四等等，直到沒有滿足最小支持度的項集。
(1)怎樣尋找候選集呢？selfjoining+pruning
假設L3={abc, abd, acd, ace, bcd} 將頻繁集的字母排序
Selfjoining: 共享前綴的abc,abd合並成abcd; ace,acd合並成acde
Pruning: acde可以去掉，因為其中的ade不在頻繁項集中
這樣L4={abcd}
(2)找到候選集以后怎么去給候選集數數？support counting 候選集--->頻繁集
跑到數據庫里找，哪些是真正的頻繁集，哪些不是？這里需要建立hash tree
如何計算呢？如果把所有頻繁項集的非空子集放到一個list中，再通過掃描數據集來統計，每個規則出現的次數，損耗的資源會較大，效率太低（比如頻繁項包含10個項，那么就需要掃描完整數據庫10次）
更快的方法計數呢，是hash-tree按照一定的規則，將頻繁項存儲到子節點，然后對每個tranction通過搜索樹來計數。復雜度o(log(n))，每個transction都要在這個樹結構里面周游。（根據hash function將這些數很有效的分離開，比如hashfunction是1,4,7往左子樹走，2,5,8往中間樹走，3,6,9往右邊走，然后<1,3,6>這個itemset就是左子樹，右子樹，把左右的candidate按照這個規則塞到一棵樹里面，這時候要想去查找每個itemset在一個transaction中是否出現，只需要大約走Log(n)，如果找到然后給他的次數+1）
電腦讀取過程 CPU-MEMORY-DISK
改進方式有三個角度：
1. 減少掃描數據庫的次數（Partition算法、FP-growth算法）
2. 減少候選集（Aprior已經減少了一部分candidates，但還有沒有更快的方法）
3. 怎樣數這個candiates出現次數數的更快
再根據頻繁項集產生關聯規則。頻繁項集的非空子集（這個數量會很大可能，怎樣減少ccandidates也是個巨大的問題）計算置信度，在一定置信度的情況下保留下來相應有用的規則。
Aprioir算法本來orange2.7算法可以實現，不知道為什么orange3給取消了這個算法
偽代碼
怎樣實現並行？
（1）share memory
整個大機器就是一個大內存的情況，無非兩種思路，一種是data parallize一種是task parallize。先說data paralize,肯定是橫着划分（由於item數據都不等長，不可能豎着划分），每個process里面有一部分數據，現在是一個大的global memory，所有不需要做任何的數據傳輸，每個process只要看它們自己的數據（有index），這就是data partition，不存在數據通信，如果我給了它一個hashtree（在global memory里面，把所有的變量聲明為全局變量，main function的外面，這樣就必然是全局的樹），那些candidates，process1就把所有的item都放到樹里面找一遍，該加1加1，幾個process同時做這一個事情，當兩個process對同一個節點加1的時候，我們需要用一個加鎖機制loce，一個先加一個后加保證他們不沖突，當三個process做完的時候，就是所有的數據被掃描了一遍，沒有任何的重復工作。這就實現了p/n倍的時間了。
知道這些正真的頻繁的之后，我們就需要建比這個長度再加1的candidates，這步也可以讓多個process並行generate，每個process負責一部分，即上面L3里面的一部分，然后同時去join，完了之后做pruning。這樣就有了新的candidates，就要built新的tree了，刪除原來的tree。每個process掌握一批candidates，同時建樹，按照同樣的規則在global memory里面建樹，當兩個process跑到同一個節點時，就用加鎖防止沖突，每個葉節點有個lock，誰拿到這個lock就可以對它分裂，沒拿到的就先等着。這個算法就是CCPD common count partition data。
（task paralize也可以，可以讓每個task負責一些candidates，相當於每個process負責一部分工作，負責一部分candidates的counting，對整個數據庫掃描，等每個process都完成了后，再合起來，就找到了所有candidates的counting了，相比於data paralize就差一點了。）
（2）clusters集群的情況
share nothing的體系結構。每個process都有自己的內存，而不存在共享內存。
data parallize。這種算法叫count distribution。就得通過明確的信息傳輸，使得每個process上得到n/p個records，數據並行，每個process上有完整的hash tree（這點還是不怎么理想，hash tree有些很大，如果每個節點就是一個pc機的話，有點超過它的能力），掃描在自己那部分數據上，給所有candidates統計一個數，candidates在這部分數據上出來的頻率怎么樣，當所有的process完成了工作以后，只需要做一次全局的comunication，要把那些counts和candidates通過MPI傳來傳去，加和sum那些counts，所有的candidates在全體的數據中頻率就求出來。process0擁有這個數以后，就很容易知道誰是正真的頻繁集，Lk就出來了。緊接着，產生Lk+1的候選集，通常Lk也不會太大，所以這步不用並行計算，直接就由process0產生。再由process0把candidatesLk+1廣播出去，使得每個process上又都擁有完整的hash tree，長度為K+1的candiates。下一個循環又開始了，周而復始。
（task parallize。每個process負責一部分candidates，每個process有全體的數據，找到自己負責的candidates是不是真正頻繁項，然后通過MPI conmunition產生K+1，再進行通信，再找candidates。還是不如data paralize）
二、FP-Growth
FP-growth算法不同於Apriori算法生成候選項集再檢查是否頻繁的“產生-測試” 方法，而是使用一種稱為頻繁模式樹（FP-Tree，PF代表頻繁模式，Frequent Pattern）菜單緊湊數據結構組織數據，並直接從該結構中提取頻繁項集，不需要產生候選集。每個事務被映射到FP-tree的一條路徑上，不同的事務會有相同的路徑，因此重疊的越多，壓縮效果越好。
FP-growth算法分為兩個過程，一是根據原始數據構造FP-Tree，（保存原來數據庫中元素的關系，又將數據進行了壓縮，使得能夠在內存中存放）
1.首先掃描一遍數據集，找出頻繁項的列表L，並且按照支持度排序，根據此排序調整原數據中事務的排序。
Budget
{f, a, c, d, j, l, m, p}
{f, a, c, h, j}
……….
比如f:4 c:4 a:3 b:3 p:3 l:2 h:2 j:2 假設support=3頻率低於3的都淘汰，所以只留下f, c, a, b, p.
Budget就變成
{f, a, c, p}
{f, a, c}
2.然后掃描上面的頻繁budget，開始構造FP-tree，根節點為空，處理每個事物時按照L中的順序將事物中出現的頻繁項添加到中的一個分支。每次出現的字母，計數+1，從這顆樹中，我們就能找到頻繁子集，而不用去掃描完整數據庫了。（其實是一邊按照上面1排序一邊建樹的）
3.構造完成FP-Tree后，選定葉節點（就是滿足最小支持度的那些字母，頻繁1項），收集所有包含葉節點的前綴路徑（條件模式基），從支持度最小的I5開始，比如下圖中I5前綴路徑有I2 I1和I2 I1 I3，根據I5的支持度，修正其前綴路徑的支持度<I2,I1:1>,<I2,I1,I3:1>，得到兩個條件模式基，接着再用這些條件模式基去建樹。把每一個產生的條件模式基再看成一個database，再為新的database建fp-tree，刪除不滿足支持度的元素。對於不滿足單一路徑的樹，略微負雜，需要遞歸的調用fp_tree。又要重新對樹中的每一個節點建立條件模式基。
還有其他算法，比如Eclat
http://www.docin.com/p-1457838635.html
http://www.docin.com/p-1473280690.html
https://wenku.baidu.com/view/3a5cd6a17f1922791688e8c5.html