基于頻繁項(xiàng)集挖掘算法的伴隨車(chē)應(yīng)用與實(shí)現(xiàn)

陳 瑤 桂 峰 盧 超 王 華

1(上海市計(jì)算技術(shù)研究所 上海 200040)2(同濟(jì)大學(xué)電子與信息工程學(xué)院 上海 201800)

基于頻繁項(xiàng)集挖掘算法的伴隨車(chē)應(yīng)用與實(shí)現(xiàn)

陳 瑤1桂 峰2盧 超1王 華1

1(上海市計(jì)算技術(shù)研究所 上海 200040)2(同濟(jì)大學(xué)電子與信息工程學(xué)院 上海 201800)

隨著大數(shù)據(jù)技術(shù)的發(fā)展和交通數(shù)據(jù)量迅速膨脹的挑戰(zhàn)，對(duì)海量交通數(shù)據(jù)進(jìn)行伴隨車(chē)挖掘已然成為研究熱點(diǎn)。提出一種基于Spark計(jì)算框架的頻繁項(xiàng)集挖掘算法應(yīng)用于伴隨車(chē)挖掘模塊當(dāng)中，對(duì)海量的卡口交通數(shù)據(jù)進(jìn)行Hadoop分布式文件存儲(chǔ)(HDFS)，并將伴隨車(chē)挖掘結(jié)果可視化地展示在集成系統(tǒng)當(dāng)中。以實(shí)際項(xiàng)目為依托，從而驗(yàn)證該伴隨車(chē)模塊的實(shí)現(xiàn)具有實(shí)際意義，并可為交通管理者提供科學(xué)的輔助決策。

HDFS Spark計(jì)算框架 頻繁項(xiàng)集挖掘 伴隨車(chē)

0 引 言

隨著交通系統(tǒng)中硬件設(shè)施的逐年更新和完善以及道路卡口識(shí)別系統(tǒng)的廣泛應(yīng)用，使得前端卡口設(shè)備采集的數(shù)據(jù)量越來(lái)越龐大。據(jù)統(tǒng)計(jì)，在北京、上海、廣州等這些交通繁忙的一線城市中，一些交通要道卡口位置的平均車(chē)流量為3 000輛/小時(shí)，一個(gè)交通卡口一天的數(shù)據(jù)采集量可達(dá)到6萬(wàn)條。以上海某區(qū)為例，該區(qū)有42個(gè)卡口位置，每天該區(qū)卡口過(guò)車(chē)數(shù)據(jù)采集量可達(dá)100萬(wàn)條。由此可見(jiàn)，卡口設(shè)備采集數(shù)據(jù)已經(jīng)進(jìn)入大數(shù)據(jù)時(shí)代。

由于車(chē)輛相關(guān)的刑事案件和治安案件的發(fā)現(xiàn)呈現(xiàn)逐年上升的趨勢(shì)，如何從多源動(dòng)態(tài)的海量交通數(shù)據(jù)中挖掘有價(jià)值的信息，為治安管理者提供決策支持的方案，已成為當(dāng)前交通領(lǐng)域研究的熱點(diǎn)和重點(diǎn)，其中對(duì)伴隨車(chē)挖掘已然成為一個(gè)重要的應(yīng)用方向。方艾芬等提出一種基于FP-Tree關(guān)聯(lián)規(guī)則的伴隨車(chē)挖掘算法，該方法在內(nèi)存中構(gòu)造FP-Tree，當(dāng)數(shù)據(jù)規(guī)模龐大時(shí)，會(huì)對(duì)內(nèi)存造成較大壓力[1]。曹波等提到基于Spark框架的FP-Growth算法進(jìn)行伴隨車(chē)挖掘，相較于方艾芬提出的方法，盡管緩解了內(nèi)存壓力，然而其產(chǎn)生頻繁子集的效率不高[2]。張笑達(dá)等提到一種矩陣剪枝的頻繁項(xiàng)集挖掘算法，該算法根據(jù)預(yù)判條件，有效地避免產(chǎn)生冗余候選頻繁項(xiàng)集[3]。然而對(duì)于數(shù)據(jù)集龐大的事務(wù)數(shù)據(jù)庫(kù)，無(wú)法進(jìn)行分布式算法的運(yùn)算，從而降低了算法的效率。

綜上所述，本文旨在探討伴隨車(chē)功能的應(yīng)用與實(shí)現(xiàn)，將一種改進(jìn)的關(guān)聯(lián)規(guī)則算法——基于Spark的頻繁項(xiàng)集挖掘算法應(yīng)用于伴隨車(chē)的挖掘，并結(jié)合Hadoop大數(shù)據(jù)平臺(tái)對(duì)海量交通卡口數(shù)據(jù)采用分布式文件系統(tǒng)的方式存儲(chǔ)，最后將伴隨車(chē)挖掘結(jié)果以直觀、簡(jiǎn)潔的可視化方式呈現(xiàn)。本文針對(duì)數(shù)據(jù)、算法、視圖這幾個(gè)層次，分別從伴隨車(chē)分析、設(shè)計(jì)、實(shí)現(xiàn)、以及成果展示幾個(gè)部分，闡述了伴隨車(chē)功能的應(yīng)用實(shí)現(xiàn)，并最終以實(shí)際項(xiàng)目為依托，驗(yàn)證了該設(shè)計(jì)方法的可行性與實(shí)際意義。

1 伴隨車(chē)分析

伴隨車(chē)是一個(gè)交通術(shù)語(yǔ)，是指在規(guī)定的時(shí)間段內(nèi)，與追查車(chē)輛存在伴隨關(guān)系的車(chē)輛以一定概率存在時(shí)，且該概率大于設(shè)定的概率閾值，則該具有伴隨關(guān)系的車(chē)輛即為追查車(chē)輛的伴隨車(chē)[2]。由伴隨車(chē)的定義可知，要判斷兩輛車(chē)之間是否有伴隨關(guān)系，首先要根據(jù)卡口設(shè)備識(shí)別出來(lái)的車(chē)牌信息，規(guī)定在一定的時(shí)間范圍內(nèi)(既定義中的時(shí)間閾值)，經(jīng)過(guò)相同監(jiān)測(cè)地點(diǎn)的車(chē)輛集合，均視為存在伴隨關(guān)系。例如車(chē)輛A，規(guī)定的時(shí)間閾值為5分鐘，如果A經(jīng)過(guò)某一個(gè)方向的路口的時(shí)間是18:00，那么在17:55到18:05之間經(jīng)過(guò)相同方向、相同路口的車(chē)B視為一次伴隨關(guān)系。當(dāng)車(chē)輛A和車(chē)輛B存在伴隨關(guān)系次數(shù)的頻次達(dá)到一定高度時(shí)，可確定A和B是嫌疑伴隨車(chē)輛。

所以，伴隨車(chē)的查找實(shí)際上可以轉(zhuǎn)化為數(shù)據(jù)挖掘中頻繁項(xiàng)集挖掘的問(wèn)題[4]。從海量的原始過(guò)車(chē)數(shù)據(jù)中查找出頻繁出現(xiàn)的車(chē)輛集合，通過(guò)設(shè)定的最小支持?jǐn)?shù)(即是最少伴隨次數(shù))，從而篩查出嫌疑伴隨的車(chē)輛集合。

2 伴隨車(chē)應(yīng)用的設(shè)計(jì)

伴隨車(chē)的挖掘模塊是基于Hadoop平臺(tái)實(shí)現(xiàn)的，因此將原始卡口交通數(shù)據(jù)的文本文件以Hadoop分布式文件系統(tǒng)HDFS的方式保存，做為底層的數(shù)據(jù)服務(wù)層支持分布式運(yùn)算?；趯?duì)引言中前人對(duì)頻繁項(xiàng)集算法的研究，并以實(shí)際課題項(xiàng)目的海量卡口數(shù)據(jù)為基礎(chǔ)，本方案中算法層采用基于Spark的矩陣剪枝頻繁項(xiàng)集挖掘算法。因?yàn)镾park計(jì)算框架的并行化機(jī)制，可以使算法結(jié)果緩存于集群的內(nèi)存當(dāng)中，有效地避免大量磁盤(pán)I/O操作。矩陣剪枝的頻繁子集挖掘可以減少冗余候選頻繁項(xiàng)集產(chǎn)生，緩解內(nèi)存壓力，提高算法效率[5]。最后通過(guò)異構(gòu)平臺(tái)的結(jié)果解析，反饋伴隨車(chē)挖掘結(jié)果。因此伴隨車(chē)應(yīng)用的設(shè)計(jì)方案如圖1所示。

圖1 伴隨車(chē)模塊設(shè)計(jì)

3 伴隨車(chē)應(yīng)用的實(shí)現(xiàn)

3.1 數(shù)據(jù)預(yù)處理

本文基于實(shí)際課題項(xiàng)目，以上海某區(qū)的卡口數(shù)據(jù)為基礎(chǔ)示范數(shù)據(jù)。該原始卡口交通數(shù)據(jù)存儲(chǔ)在Oracle數(shù)據(jù)庫(kù)當(dāng)中，包括過(guò)車(chē)信息表、卡口位置表、卡口設(shè)備信息表等27張表，其中最主要的過(guò)車(chē)信息表是一張動(dòng)態(tài)表，包括車(chē)牌信息、車(chē)輛顏色、過(guò)車(chē)時(shí)間、過(guò)車(chē)速度、卡口編號(hào)、卡口方向、等20多個(gè)字段。該表實(shí)時(shí)接受并存儲(chǔ)前端卡口設(shè)備采集的過(guò)車(chē)信息[6]。

1) 數(shù)據(jù)清洗

車(chē)牌識(shí)別技術(shù)是伴隨車(chē)挖掘的基礎(chǔ)，由于前端設(shè)備受天氣等各方面因素的影響，無(wú)法保證百分之百正確識(shí)別車(chē)牌，因此將對(duì)過(guò)車(chē)信息表中一些無(wú)用車(chē)輛信息從數(shù)據(jù)庫(kù)中清洗掉。在原始數(shù)據(jù)庫(kù)中，車(chē)牌號(hào)為“000000”以及“無(wú)車(chē)牌”的過(guò)車(chē)數(shù)據(jù)均視為無(wú)效數(shù)據(jù)，如圖2所示，方框內(nèi)的數(shù)據(jù)均是無(wú)效的過(guò)車(chē)數(shù)據(jù)。

圖2 過(guò)車(chē)信息表中的無(wú)效數(shù)據(jù)

2) 數(shù)據(jù)規(guī)約

伴隨車(chē)挖掘過(guò)程中，只需要過(guò)車(chē)信息表中車(chē)牌號(hào)碼、卡口編號(hào)和過(guò)車(chē)時(shí)間這三個(gè)字段，因此需將這三個(gè)字段從過(guò)車(chē)信息表中提取出來(lái)，以空格分隔，并將數(shù)據(jù)保存在文件中。

3) 數(shù)據(jù)轉(zhuǎn)換

基于Spark的伴隨車(chē)挖掘算法要求將原始的一條條過(guò)車(chē)數(shù)據(jù)轉(zhuǎn)換成原始事務(wù)數(shù)據(jù)庫(kù)中的事務(wù)。轉(zhuǎn)換規(guī)則是：對(duì)于任意某輛車(chē)，將與其經(jīng)過(guò)同一個(gè)卡口和相同方向的前后1 min內(nèi)的車(chē)輛集合做為一條事務(wù)。在Spark平臺(tái)下生成的原始事務(wù)數(shù)據(jù)庫(kù)流程如圖3所示。

圖3 基于Spark的事務(wù)數(shù)據(jù)庫(kù)生成流程

首先通過(guò)調(diào)用textFile()函數(shù)讀取HDFS上的原始過(guò)車(chē)數(shù)據(jù)，得到一個(gè)彈性分布式數(shù)據(jù)RDD(Resilient Distributed Datasets)，該RDD中的每個(gè)元素是由車(chē)牌號(hào)碼、卡口編號(hào)和過(guò)車(chē)時(shí)間組成的三元組(id,n,t)；其次通過(guò)調(diào)用map()函數(shù)，將上述三元組轉(zhuǎn)換成一個(gè)key-value鍵值對(duì)，其中key對(duì)應(yīng)三元組中的卡口編號(hào)n，value值是由車(chē)牌號(hào)碼和過(guò)車(chē)時(shí)間組成的二元組(id,t)，從而獲得一個(gè)包含鍵值對(duì)的RDD；然后通過(guò)groupByKey()函數(shù)的調(diào)用，將上一步中得到的鍵值對(duì)RDD按照key值(即卡口編號(hào))進(jìn)行分組，得到另一個(gè)包含鍵值對(duì)的RDD，該鍵值對(duì)中的key值即為卡口編號(hào)，value值為該卡口編號(hào)方向的所有車(chē)牌號(hào)碼n及其過(guò)車(chē)時(shí)間t所組成的二元組；最后調(diào)用mapPratitions()函數(shù)，按照轉(zhuǎn)換規(guī)則，最終得到一個(gè)事務(wù)RDD，該事務(wù)RDD中的每個(gè)元素即為一個(gè)伴隨關(guān)系的車(chē)輛集合。至此便完成了原始過(guò)車(chē)數(shù)據(jù)到事務(wù)數(shù)據(jù)的轉(zhuǎn)換。

3.2 算法應(yīng)用

伴隨車(chē)的挖掘算法采用基于Spark的矩陣剪枝頻繁項(xiàng)集挖掘算法，該算法依據(jù)傳統(tǒng)關(guān)聯(lián)規(guī)則Apriori算法進(jìn)行改進(jìn)[7]。為降低內(nèi)存占用，本方案使用BitSet數(shù)據(jù)結(jié)構(gòu)表示事務(wù)數(shù)據(jù)庫(kù)中每個(gè)項(xiàng)目的支持?jǐn)?shù)，同時(shí)結(jié)合矩陣剪枝的挖掘特點(diǎn)，在產(chǎn)生候選頻繁k-項(xiàng)集矩陣M時(shí)(k>1)，采用HashMap數(shù)據(jù)結(jié)構(gòu)代替矩陣M右上角的元素。算法的挖掘過(guò)程分為兩步：

(1) 計(jì)算頻繁1-項(xiàng)集和2-項(xiàng)集矩陣。如圖4所示為伴隨車(chē)挖掘算法的步驟一。

a.首先讀取HDFS中的原始事務(wù)數(shù)據(jù)庫(kù)，該原始事務(wù)數(shù)據(jù)庫(kù)就是3.1節(jié)中由原始數(shù)據(jù)轉(zhuǎn)換得到。通過(guò)調(diào)用cache()函數(shù)將事務(wù)數(shù)據(jù)庫(kù)緩存在Spark集群內(nèi)存。

b.調(diào)用flatmap()函數(shù)，可以得到一個(gè)存儲(chǔ)項(xiàng)目的RDD，這個(gè)RDD邏輯上包含事務(wù)數(shù)據(jù)庫(kù)的全部事務(wù)。

c.通過(guò)調(diào)用reduceByKey()函數(shù)可以計(jì)算每個(gè)項(xiàng)目在原始事務(wù)數(shù)據(jù)庫(kù)中的支持?jǐn)?shù)，得到一個(gè)存儲(chǔ)的RDD，其中value值為項(xiàng)目在事務(wù)數(shù)據(jù)庫(kù)中實(shí)際的支持?jǐn)?shù)，得到了鍵值對(duì)的RDD。

d.對(duì)上一步中的RDD執(zhí)行filter()函數(shù)，該函數(shù)通過(guò)value值與最小支持?jǐn)?shù)s對(duì)比，找出符合要求的鍵值對(duì)，并按照value值升序排列獲得一個(gè)有序的RDD。

e.提取上一步RDD中的key值即為頻繁1-項(xiàng)集，通過(guò)調(diào)用cache()函數(shù)，將其保存在集群內(nèi)存中，同時(shí)將計(jì)算所得頻繁1-項(xiàng)集對(duì)應(yīng)的Bitset數(shù)據(jù)廣播到集群的節(jié)點(diǎn)上。

f.根據(jù)上一步中廣播的Bitset數(shù)據(jù)，計(jì)算2-項(xiàng)集矩陣M，如前文中討論的，此處的矩陣M采用HashMap數(shù)據(jù)結(jié)構(gòu)形式存儲(chǔ)其上三角的數(shù)據(jù)。該HashMap鍵值對(duì)是一個(gè)嵌套的HashMap結(jié)構(gòu)，其中的key值為頻繁1-項(xiàng)集，value值仍是一個(gè)HashMap數(shù)據(jù)，內(nèi)部這個(gè)HashMap的鍵值對(duì)中，key為可能組合成為頻繁2-項(xiàng)集的候選頻繁1-項(xiàng)集，value為這個(gè)候選頻繁2-項(xiàng)集的支持度計(jì)數(shù)[8]。最后將該嵌套HashMap數(shù)據(jù)結(jié)構(gòu)的Bitset廣播到集群節(jié)點(diǎn)，以支持后續(xù)計(jì)算使用。

圖4 伴隨車(chē)挖掘算法步驟(一)

(2) 由頻繁k-項(xiàng)集集合迭代計(jì)算出頻繁(k+1)-項(xiàng)集集合(k≥1)，直到算法停止。如圖5為伴隨車(chē)挖掘算法的步驟二。

a.首先判斷頻繁k-項(xiàng)集集合Lk中的個(gè)數(shù)是否大于等于k+1，此為計(jì)算頻繁(k+1)-項(xiàng)集的前提條件。若判斷成立，則算法繼續(xù)執(zhí)行，否則算法過(guò)程終止，算法結(jié)束。

b.根據(jù)(1)中廣播出去的數(shù)據(jù)結(jié)構(gòu)，此時(shí)在Spark集群內(nèi)存節(jié)點(diǎn)中存在頻繁k-項(xiàng)集的HashMap和相應(yīng)的Bitset的只讀數(shù)據(jù)變量，對(duì)頻繁k-項(xiàng)集的RDD調(diào)用map()函數(shù)，計(jì)算得到候選頻繁(k+1)-項(xiàng)集和其相應(yīng)的Bitset數(shù)據(jù)，并返回一個(gè)鍵值對(duì)RDD，其中key為頻繁(k+1)-項(xiàng)集候選集，value是其對(duì)應(yīng)的Bitset。

c.對(duì)上一步中產(chǎn)生的候選(k+1)-項(xiàng)集RDD調(diào)用filter函數(shù)和map函數(shù)，篩選出支持?jǐn)?shù)不小于最小支持?jǐn)?shù)s的頻繁項(xiàng)，這里通過(guò)計(jì)算Bitset中“1”的個(gè)數(shù)大于等于s即可，最終得到邏輯上存儲(chǔ)頻繁(k+1)-項(xiàng)集的RDD。

圖5 伴隨車(chē)挖掘算法步驟(二)

4 成果展示

4.1 運(yùn)行環(huán)境

伴隨車(chē)的挖掘所需要的Spark集群環(huán)境由3臺(tái)高配置的PC機(jī)組成。部署模式為Standalone，即ClusterManager為Standalone模式。部署過(guò)程中我們將Master節(jié)點(diǎn)的PC機(jī)同時(shí)賦予其Worker節(jié)點(diǎn)角色，可以使得集群中增加一個(gè)Worker工作節(jié)點(diǎn)。每套機(jī)器的配置如表1所示。

表1 Spark集群的PC機(jī)配置

伴隨車(chē)的挖掘算法需要Hadoop組件中的HDFS提供數(shù)據(jù)存儲(chǔ)，因此還需搭建Hadoop集群，算法挖掘集群的軟件配置如表2所示。

表2 集群軟件配置

伴隨車(chē)數(shù)據(jù)文件存放在本地電腦根目錄下的文件夾“AccompanyCar”中，該文件夾中一共有82個(gè)數(shù)據(jù)文本，對(duì)應(yīng)某區(qū)的82個(gè)交通卡口數(shù)據(jù)采集設(shè)備。在客戶端通過(guò)Hadoop命令“hadoop fs -mkdir /accompanycar_input”在HDFS文件系統(tǒng)下建立一個(gè)伴隨車(chē)輸入文件夾，然后利用“hadoop fs-copyFromLocal/AccompanyCar/* /accompanycar_input”將本地伴隨車(chē)輸入數(shù)據(jù)上傳到HDFS文件系統(tǒng)中[9]。

4.2 運(yùn)行效果

伴隨車(chē)挖掘的結(jié)果集是保存在本地的一個(gè)文件當(dāng)中，其挖掘結(jié)果如圖6所示。

圖6 伴隨車(chē)挖掘結(jié)果

該伴隨車(chē)結(jié)果集中的每條數(shù)據(jù)格式如下：

車(chē)牌號(hào)car1：([與car1形成伴隨關(guān)系的車(chē)輛集合]+伴隨次數(shù))

即以車(chē)牌“京GS3006”為例，伴隨車(chē)的結(jié)果為([滬FU6527，滬B52710，…滬DK5578，京GS3006]，7)時(shí)，則表示車(chē)牌為滬FU6527和滬DK5578等車(chē)輛集與“京GS3006”的車(chē)輛有7次伴隨關(guān)系，故被檢索為具有伴隨嫌疑的車(chē)輛。

在對(duì)伴隨車(chē)結(jié)果進(jìn)行可視化時(shí)，我們采用B/S結(jié)構(gòu)，使用Java語(yǔ)言在Eclipse平臺(tái)進(jìn)行開(kāi)發(fā)，對(duì)伴隨車(chē)挖掘結(jié)果文件進(jìn)行解析，解析的關(guān)鍵代碼如下：

BufferedReader br=null;

try{

br = new BufferedReader(new InputStreamReader(new

FileInputStream(request.getSession().getServletContext().

getRealPath(″″)+″/upload/car.txt″), ″UTF-8″));

while(br.ready()){

line=br.readLine();

_carName=_line.substring(0,_line.indexOf(″([″));

followcar=_line.substring(_line.indexOf(″([″)).split

(″),([″);

for(i=0;i

followcars=followcar[i].replace(″([″, ″″).split(″],″);

_c+=″″+

followcars[0]+″″+followcars[1].replace(″)″,

″″)+″″;

}

}

br.close();

}finally{

if(br!=null){

br.close();

br=null;

}

}

解析后的結(jié)果以表格的形式顯示在伴隨車(chē)的系統(tǒng)模塊當(dāng)中，伴隨車(chē)功能實(shí)現(xiàn)的效果如圖7所示。

圖7 伴隨車(chē)功能展示

5 結(jié) 語(yǔ)

本文中提出的伴隨車(chē)功能的實(shí)現(xiàn)，以海量的卡口交通數(shù)據(jù)為基礎(chǔ)，對(duì)海量數(shù)據(jù)采用HDFS的方式進(jìn)行分布式存儲(chǔ)，并采用基于Spark計(jì)算框架的頻繁項(xiàng)集挖掘算法，高效地從海量數(shù)據(jù)中進(jìn)行伴隨車(chē)功能的挖掘。最終以直觀友好的界面展示在系統(tǒng)的伴隨車(chē)模塊當(dāng)中，為交通運(yùn)輸?shù)墓芾碚咛峁┹o助決策的功能。由于伴隨車(chē)的挖掘結(jié)果與伴隨車(chē)功能實(shí)現(xiàn)實(shí)行異構(gòu)平臺(tái)的交互，因此文中的方案具有良好的可擴(kuò)展性。下一步將對(duì)伴隨結(jié)果的可視化工作做進(jìn)一步研究，或采用processing等可視化工具進(jìn)行結(jié)果展示，以豐富大數(shù)據(jù)挖掘的成果呈現(xiàn)。

[1] 方艾芬,李先通,蔄世明,等.基于關(guān)聯(lián)規(guī)則挖掘的伴隨車(chē)輛發(fā)現(xiàn)算法[J].計(jì)算機(jī)應(yīng)用與軟件,2012,29(2):94-96,144.

[2] 曹波,韓燕波,王桂玲.基于車(chē)牌識(shí)別大數(shù)據(jù)的伴隨車(chē)輛組發(fā)現(xiàn)方法[J].計(jì)算機(jī)應(yīng)用,2015,35(11):3203-3207.

[3] 張笑達(dá),徐立臻.一種改進(jìn)的基于矩陣的頻繁項(xiàng)集挖掘算法[J].計(jì)算機(jī)技術(shù)與發(fā)展,2010,20(4):93-96.

[4] 陳慧萍,王建東,王煜.一種高效的最大頻繁項(xiàng)集挖掘算法DFMFI-Miner[J].計(jì)算機(jī)仿真,2006,23(7):79-83.

[5] 吳湘華,張祖平.Apriori算法中頻繁項(xiàng)集求法的改進(jìn)[J].科技創(chuàng)新與應(yīng)用,2013(15):58.

[6] 蔡昌理.郫縣公安局機(jī)動(dòng)車(chē)緝查布控系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D].成都:電子科技大學(xué),2014.

[7] 張忠平,李巖,楊靜.基于矩陣的頻繁項(xiàng)集挖掘算法[J].計(jì)算機(jī)工程,2009,35(1):84-86.

[8] 鄭志嫻.基于云計(jì)算的Apriori算法設(shè)計(jì)[J].莆田學(xué)院學(xué)報(bào),2014,21(5):61-64.

[9] 劉亞光.實(shí)時(shí)同步云存儲(chǔ)客戶端的設(shè)計(jì)與實(shí)現(xiàn)[D].大連:大連理工大學(xué),2014.

APPLICATION AND REALIZATION OF ESCORT VEHICLE BASED ON FIM ALGORITHM

Chen Yao1Gui Feng2Lu Chao1Wang Hua1

1(ShanghaiInstituteofComputingTechnology,Shanghai200040,China)2(SchoolofElectronicsandInformationEngineering,TongjiUniversity,Shanghai201800,China)

With the development of big data technology and the challenge of the rapid expansion of traffic data, escort vehicle data mining to the massive traffic data has become a hot research area. In this paper, a frequent itemset mining (FIM) algorithm based on Spark computing framework is proposed, which is applied to the escort vehicle mining module, using HDFS to store the massive traffic bayonet data and visualization display the result of escort vehicle mining in the integrated system. Based on the actual project, this paper proves that the verification of the escort vehicle mining module has practical significance, and can provide scientific auxiliary decision for the traffic management.

HDFS Spark computing framework FIM Escort vehicle

2016-03-31。上海市科學(xué)技術(shù)委員會(huì)應(yīng)用技術(shù)開(kāi)發(fā)專(zhuān)項(xiàng)(2014-104)。陳瑤，碩士，主研領(lǐng)域：應(yīng)用軟件開(kāi)發(fā)。桂峰，碩士。盧超，工程師。王華，教授級(jí)高工。

TP3

A

10.3969/j.issn.1000-386x.2017.04.011