趙文芳，劉亞楠，余東昌

北京市氣象信息中心，北京　100089

1　引言

氣象與國民經(jīng)濟各行各業(yè)關(guān)系密切，氣象部門在千方百計提高預(yù)報預(yù)測準(zhǔn)確率的同時，一直致力于推動氣象與經(jīng)濟社會的融合，更好地發(fā)揮氣象在經(jīng)濟社會中的作用。為了順應(yīng)信息化時代發(fā)展趨勢，中國氣象局提出了“互聯(lián)網(wǎng)+氣象”行動計劃，促進氣象與經(jīng)濟社會融合發(fā)展 ?！盎ヂ?lián)網(wǎng)+氣象”行動計劃對氣象服務(wù)提出了明確要求，不再局限于單純地向社會提供氣象預(yù)報信息，而是為天氣高影響行業(yè)提供有針對性的專業(yè)氣象服務(wù)，對公眾提供精細化、個性化的氣象服務(wù)。目前，面向公眾和行業(yè)的氣象服務(wù)由于缺乏對用戶行為數(shù)據(jù)的分析，難以把握其活動特征，難以主動提供個性化氣象服務(wù)產(chǎn)品，存在專業(yè)化程度不高、針對性不強等問題。因此，如何為用戶推薦合適的氣象服務(wù)產(chǎn)品成為了需解決的重要問題。

推薦系統(tǒng)是幫助人們快速發(fā)現(xiàn)有用信息的重要工具，它不僅給用戶推薦符合個人興趣的內(nèi)容，還為用戶節(jié)省了在海量數(shù)據(jù)中查找信息的時間[1]。推薦系統(tǒng)中常用的推薦技術(shù)主要有基于內(nèi)容的推薦、協(xié)同過濾推薦及關(guān)聯(lián)規(guī)則推薦[2-7]等。其中，基于內(nèi)容的推薦算法適用于推薦新商品，但不適用于新用戶推薦；基于知識的推薦算法適用于用戶的行為數(shù)據(jù)較少，同時又有明確需求的場景；協(xié)同過濾算法依據(jù)用戶評分為用戶推薦商品，同時也存在冷啟動問題。

目前，現(xiàn)有的氣象服務(wù)模式主要以手機應(yīng)用程序、微信公眾號、微信小程序和網(wǎng)站為載體，向用戶提供氣象服務(wù)產(chǎn)品的瀏覽和查詢，沒有評分功能，無法獲取用戶評分?jǐn)?shù)據(jù)，只能大量記錄用戶行為的Web日志數(shù)據(jù)。本文提出了一個根據(jù)用戶瀏覽記錄向用戶推薦氣象服務(wù)產(chǎn)品的方法，具體貢獻如下。

●提出了一種對氣象產(chǎn)品進行挖掘的方法，利用FP-Growth算法進行關(guān)聯(lián)規(guī)則挖掘，然后對誤導(dǎo)性強關(guān)聯(lián)規(guī)則進行排查和過濾，建立暴雨、高溫、大風(fēng)、霧霾等高影響天氣下的氣象服務(wù)推薦模型。

●提出了一種基于頁面瀏覽總量的氣象產(chǎn)品相似度算法，實現(xiàn)用戶對每個產(chǎn)品瀏覽總量的線性變換處理，并映射到區(qū)間[1,5]，作為用戶對每個產(chǎn)品的評分，最后利用修正后的余弦相似度計算產(chǎn)品之間的相似度。

●基于Spark框架設(shè)計了兩種數(shù)據(jù)預(yù)處理并行算法，將原始數(shù)據(jù)抽象為彈性分布式數(shù)據(jù)集（resilient distributed datasets，RDD）模型，利用map 、groupByKey等函數(shù)進行數(shù)據(jù)的大量迭代計算、歸一化處理，快速實現(xiàn)數(shù)據(jù)清洗、轉(zhuǎn)換。

●提出了利用Impala實現(xiàn)原始數(shù)據(jù)冗余的處理方法。

●通 過在Cloudera大數(shù) 據(jù) 平臺的Spark框架下進行實驗，說明本方法的實用性和高效性。

2　相關(guān)工作

對于氣象服務(wù)產(chǎn)品的推薦，目前主要以手機移動軟件為載體實現(xiàn)兩個方面的研究應(yīng)用：基于用戶地理位置的氣象服務(wù)；根據(jù)用戶的訂閱計劃及時推送相應(yīng)氣象產(chǎn)品。 “氣象雷達—天氣預(yù)報、溫度和雨量圖”手機應(yīng)用軟件提供了便捷的地點搜索，為用戶提供最近距離氣象站的精準(zhǔn)天氣數(shù)據(jù)，并為用戶提供3種訂閱計劃 ?！爸袊鴼庀蟆笔謾C應(yīng)用軟件能為用戶提供最近距離的氣象站實況監(jiān)測信息和站點搜索功能 ?！爸腔蹥庀蟆笔謾C應(yīng)用軟件為用戶提供“一鍵式專業(yè)氣象信息訂制”功能，讓用戶一鍵輕松獲取所需信息 ?！安试铺鞖狻?“墨跡天氣” “北京氣象”等手機應(yīng)用軟件也提供了類似的功能。

針對關(guān)聯(lián)規(guī)則個性化推薦的研究主要包括：參考文獻[8]對關(guān)聯(lián)規(guī)則算法進行改進，并提出了一種基于劃分的關(guān)聯(lián)規(guī)則并行分層挖掘算法；參考文獻[9]提出了Hadoop 平臺下的并行Web日志挖掘算法；參考文獻[10]首先利用模糊聚類進行數(shù)據(jù)預(yù)處理，在此基礎(chǔ)上再進行頻繁項集的挖掘；參考文獻[11]提出了基于MapReduce的并行關(guān)聯(lián)規(guī)則增量更新算法；參考文獻[12]提出了一種基于關(guān)聯(lián)規(guī)則挖掘的跨網(wǎng)絡(luò)知識關(guān)聯(lián)及協(xié)同應(yīng)用；參考文獻[13]提出了一種結(jié)合關(guān)聯(lián)規(guī)則的協(xié)同過濾推薦算法；參考文獻[14]提出了基于業(yè)務(wù)路徑和頻度矩陣的關(guān)聯(lián)規(guī)則挖掘算法；參考文獻[15]采用多重約束進行時序關(guān)聯(lián)規(guī)則挖掘，分析得到了與實際情況高度吻合的氣候指數(shù)與陸地區(qū)域異常降水事件間的關(guān)系；參考文獻[16]采用了改進的FP-Growth算法挖掘出各種氣象因子之間可能存在的關(guān)聯(lián)，從而發(fā)現(xiàn)氣象特點，對近期天氣氣象做出預(yù)報。

以上研究表明，通過挖掘用戶行為提取興趣特征，在興趣特征基礎(chǔ)上再為用戶提供個性化推薦服務(wù)的方法廣泛用于電子商務(wù)中。但是，使用包含用戶軌跡的Web日志數(shù)據(jù)分析研究物品之間強關(guān)聯(lián)規(guī)則，再進行推薦的方法相對較少。此外，氣象服務(wù)推薦也局限于基于地理位置的精細化服務(wù)，缺少對氣象服務(wù)產(chǎn)品之間相關(guān)性的挖掘和用戶對不同產(chǎn)品的偏好研究，無法對用戶進行更精準(zhǔn)、個性化的推薦。因此，本文提出一種基于氣象服務(wù)產(chǎn)品關(guān)聯(lián)規(guī)則的推薦模型。

3　氣象服務(wù)產(chǎn)品推薦模型

FP-Growth算法是韓家煒等人在2000年提出的關(guān)聯(lián)分析算法，通過構(gòu)造一個樹結(jié)構(gòu)來壓縮數(shù)據(jù)記錄，使挖掘頻繁項集只需要掃描兩次數(shù)據(jù)記錄，而且該算法不需要生成候選集合，效率比經(jīng)典Apriori算法高。本文將氣象服務(wù)網(wǎng)站的Web日志作為基礎(chǔ)數(shù)據(jù)，結(jié)合FP-Growth算法和物品相似度算法建立氣象服務(wù)產(chǎn)品的推薦模型。

本節(jié)主要介紹模型概述和相關(guān)數(shù)據(jù)預(yù)處理算法。

3.1　模型概述

用戶每次訪問氣象服務(wù)網(wǎng)站時，會停留一段時間瀏覽一些頁面的服務(wù)產(chǎn)品，點擊頁面上的菜單按鈕，有時候還會下載相關(guān)的氣象數(shù)據(jù)和產(chǎn)品，這些被瀏覽的頁面、用戶點擊頁面、下載數(shù)據(jù)的行為形成用戶訪問記錄。用戶瀏覽軌跡表示用戶在這段時間內(nèi)瀏覽的氣象服務(wù)產(chǎn)品序列，該序列可以表示為：List=｛p1，p2，…，pn｝。用戶訪問記錄定義為：User_Res=〈U，server_time，List，time_spent，actions，actions_count〉，其中，U表示一個用戶，server_time表示用戶訪問網(wǎng)站時間，List表示瀏覽過的產(chǎn)品序列，time_spent表示用戶停留在網(wǎng)站的時間，actions表示用戶的行為，actions_count表示用戶行為次數(shù)。

氣象服務(wù)產(chǎn)品作為向用戶推薦的對象，其本身具有一些屬性。本文劃分為靜態(tài)屬性和動態(tài)屬性，靜態(tài)屬性來自于產(chǎn)品氣象本質(zhì)特征，動態(tài)屬性來自于對動態(tài)數(shù)據(jù)的統(tǒng)計分類的結(jié)果。靜態(tài)屬性包括產(chǎn)品更新頻率、產(chǎn)品所屬氣象數(shù)據(jù)類別（如觀測、數(shù)值模式產(chǎn)品，預(yù)報產(chǎn)品）、產(chǎn)品的用途（如實況、預(yù)報、統(tǒng)計）、產(chǎn)品來源等，本文以標(biāo)簽的形式描述這些屬性特征。氣象服務(wù)產(chǎn)品的靜態(tài)屬性定義為：P_sta＝〈PID，tag1，tag2，…，tagn〉。PID表示產(chǎn)品的唯一編號，tagi表示產(chǎn)品的第i個屬性標(biāo)簽，表示某個屬性特征。動態(tài)屬性主要指產(chǎn)品瀏覽次數(shù)和瀏覽時間，這些數(shù)據(jù)需要從Web日志數(shù)據(jù)統(tǒng)計得到。本文根據(jù)氣象服務(wù)產(chǎn)品的靜態(tài)屬性和動態(tài)屬性分別計算相似度。

FP-Growth 算法中的關(guān)鍵參數(shù)min_support及min_confidence通常都是人為設(shè)置的，生成的規(guī)則容易受到挖掘者主觀因素的影響，有必要對強關(guān)聯(lián)規(guī)則做進一步篩選和驗證，以提升規(guī)則的可靠性和準(zhǔn)確性。

基于以上定義，本文提出的基于關(guān)聯(lián)規(guī)則的氣象產(chǎn)品推薦模型如圖1所示。模型從網(wǎng)站訪問日志中提取出用戶瀏覽記錄，篩選出每個用戶在有效時間內(nèi)訪問過的氣象服務(wù)產(chǎn)品序列，形成樣本數(shù)據(jù)集，開始訓(xùn)練模型，使用FP-Growth算法進行關(guān)聯(lián)規(guī)則挖掘，得到符合條件的關(guān)聯(lián)規(guī)則；計算氣象產(chǎn)品的相似度，根據(jù)相似度篩選關(guān)聯(lián)規(guī)則，構(gòu)建氣象服務(wù)產(chǎn)品推薦模型。

3.2　數(shù)據(jù)預(yù)處理方法

氣象服務(wù)網(wǎng)站一直使用谷歌公司的開源工具PIWIK進行網(wǎng)站流量和用戶行為監(jiān)控，相關(guān)Web日志信息存放在MySQL數(shù)據(jù)庫表中。本文使用了兩個表的數(shù)據(jù)：用戶訪問記錄表和頁面信息管理表。其中，用戶訪問記錄表用來記錄用戶每次訪問網(wǎng)站的相關(guān)頁面，包括用戶ID、頁面ID、用戶訪問時間、頁面停留時間、用戶行為（瀏覽或下載）；頁面信息表包括頁面ID與頁面URL對應(yīng)關(guān)系。具體表結(jié)構(gòu)見表1和表2，表1中的頁面ID字段和表2中的頁面ID字段相關(guān)聯(lián)。

與電子商務(wù)網(wǎng)站商品不同的是，氣象產(chǎn)品是與時間相關(guān)的，當(dāng)用戶請求同一個頁面URL并獲取不同時間氣象產(chǎn)品時，相關(guān)的Web日志會賦給這個頁面URL一個新頁面ID。例如，用戶在2017年1月1日20:00和2017年1月1日21:00對命名為aws.index.php的自動站實況頁面進行訪問，頁面URL為aws.index.php?time=2017-01-01 20:00:00和aws.index_php?time=2017-01-01 21:00:00，Web日志會賦予這兩個URL不同的頁面ID進行記錄，造成大量冗余頁面，在進行數(shù)據(jù)挖掘前，必須進行冗余頁面處理。

本文對冗余頁面的處理利用數(shù)據(jù)表的關(guān)聯(lián)實現(xiàn)。首先，創(chuàng)建頁面元數(shù)據(jù)信息表，其結(jié)構(gòu)見表2的id_re_name字段和表3。其次，對表3中的對應(yīng)值，同時使用這個對應(yīng)值對表3的id_name字段進行關(guān)聯(lián)匹配，得到表2的id_url在表1字段id_url進行更新。

本文中所有的挖掘算法處理都是基于經(jīng)過冗余處理的數(shù)據(jù)進行的。

表1　用戶行為記錄表結(jié)構(gòu)

表2　頁面信息表結(jié)構(gòu)

表3　頁面元數(shù)據(jù)信息表結(jié)構(gòu)

3.3　氣象服務(wù)產(chǎn)品相似度計算方法

3.3.1基于靜態(tài)屬性的相似度計算方法

當(dāng)新的氣象服務(wù)產(chǎn)品上線時，由于缺少Web訪問日志數(shù)據(jù)，無法開展關(guān)聯(lián)規(guī)則推薦。當(dāng)用戶瀏覽該產(chǎn)品時，可以把和它最相似的產(chǎn)品推薦給用戶。

兩個氣象服務(wù)產(chǎn)品可能會包含相同標(biāo)簽，例如更新頻次、所屬氣象數(shù)據(jù)類別，那么這些相同標(biāo)簽就是這兩個氣象服務(wù)產(chǎn)品的相似之處。兩個產(chǎn)品（pi和pj）中的相同標(biāo)簽占兩個產(chǎn)品所包含的所有標(biāo)簽的比值表示這兩個產(chǎn)品的相似程度，用StaSim(pi,pj)表示，計算方法如式（1）所示：

其中，Tags(pi)和Tags(pj)分別表示pi和pj包含的所有標(biāo)簽。對于pi和pj，它們包含的標(biāo)簽的交集中元素的個數(shù)與并集中元素的個數(shù)的比值表示pi與pj的相似程度。

3.3.2基于動態(tài)屬性的相似度計算方法

基于物品的協(xié)同過濾算法適用于物品數(shù)量變化小于用戶數(shù)量變化的場合，本文采用該算法，使用修正后的余弦相似度計算式計算氣象服務(wù)產(chǎn)品相似度。具體計算方法如式（2）所示：

其中，Sim(i，j)表示氣象服務(wù)產(chǎn)品i和j的相似度。Mu,i表示用戶u對產(chǎn)品i的評分，Mu,j表示用戶u對產(chǎn)品j的評分，表示用戶對產(chǎn)品i的平均評分，表示用戶對產(chǎn)品j的平均評分。

3.3.3用戶訪問頁面總次數(shù)的線性變化方法

對用戶訪問頁面總次數(shù)進行線性變化處理，使結(jié)果值映射到區(qū)間[1,5]，轉(zhuǎn)換函數(shù)如式（3）所示：

其中，F(xiàn)(x)表示映射后的值，x表示用戶訪問某頁面的總次數(shù)，max x表示某頁面訪問次數(shù)的最大值，min x表示該頁面訪問次數(shù)的最小值。

3.3.4氣象產(chǎn)品相似度的計算方法

算法將用戶瀏覽產(chǎn)品的總次數(shù)經(jīng)過線性變換后將結(jié)果映射到區(qū)間[1,5]，利用修正后的余弦相似度計算式計算產(chǎn)品相似度。具體的算法描述如下，算法流程如圖2所示。

圖2　氣象產(chǎn)品相似度算法流程

算法：氣象產(chǎn)品相似度的預(yù)處理算法。輸入：去掉冗余后的用戶訪問記錄。輸出：氣象服務(wù)產(chǎn)品相似度矩陣。

步驟1從日志信息中獲取用戶與頁面瀏覽量數(shù)據(jù)。

步驟2對每個獨立IP用戶，迭代計算其瀏覽過的每個頁面總次數(shù)。將輸入數(shù)據(jù)map映射為JavaPairRDD的鍵值對，命名為Res_1。其中，鍵值對的key表示為“用戶ID_頁面ID”，value值自動累加，表示用戶ID訪問頁面ID所代表頁面的總次數(shù)，即<用戶ID_頁面ID，總次數(shù)>。例如<3312_78，56>表示ID為3312的用戶，對ID為78的頁面一共訪問了56次。

步驟3對用戶訪問每個頁面的總次數(shù)進行歸一化處理。在數(shù)據(jù)集Res_1中，找出key中包含相同頁面ID的所有鍵值對，對其中的value進行歸一化處理，將頁面訪問總次數(shù)按式（3）映射到區(qū)間[1,5]，生成新的數(shù)據(jù)集Res_2。

步驟4對Res_2數(shù)據(jù)集進行map映射計算，從key中提取出用戶ID，頁面ID和value的組合作為value，生成新的JavaPairRDD，得到數(shù)據(jù)集New_Res。

步驟5對New_Re s數(shù)據(jù)集進行g(shù)roupByKey聚合計算，將相同key的多個JavaPairRDD映射為JavaPairRDD>，得到數(shù)據(jù)集Count_Res。

步驟6將Iterable從數(shù)據(jù)集Count_Res提取出來，轉(zhuǎn)換成氣象服務(wù)產(chǎn)品評分矩陣。

步驟7對于n個產(chǎn)品，依次計算產(chǎn)品1與其他n-1個產(chǎn)品的相似度；再計算產(chǎn)品2與其他n-2個產(chǎn)品的相似度。對于其中任何兩個產(chǎn)品i和j而言：查找對i和j共同評價過的用戶集合Uij；分別計算用戶對產(chǎn)品i和產(chǎn)品j的平均評價值和；按照式（2）計算產(chǎn)品之間的相似度。

步驟8將計算得到的相似度結(jié)果存在數(shù)據(jù)庫表中，數(shù)據(jù)庫表結(jié)構(gòu)見表4。

表4　氣象服務(wù)產(chǎn)品相似度

圖3　氣象產(chǎn)品item提取算法流程

3.4　基于用戶訪問日志的關(guān)聯(lián)規(guī)則算法

該算法用于從用戶訪問日志生成最終關(guān)聯(lián)規(guī)則。首先對用戶訪問日志進行清洗，轉(zhuǎn)化為用戶訪問產(chǎn)品的序列數(shù)據(jù)集，然后調(diào)用FP-Growth算法產(chǎn)生關(guān)聯(lián)規(guī)則。該算法的關(guān)鍵在于用戶訪問日志的預(yù)處理階段，需要生成一個數(shù)據(jù)集，數(shù)據(jù)集中的每一個數(shù)據(jù)項包含了用戶每次訪問網(wǎng)站瀏覽過的產(chǎn)品ID序列。具體的算法描述如下，算法流程如圖3所示。

算法：基于用戶訪問日志的關(guān)聯(lián)規(guī)則算法。

輸入：去掉冗余后的用戶訪問記錄。輸出：氣象服務(wù)產(chǎn)品關(guān)鍵規(guī)則列表。

步驟1讀入訪問記錄，通過map映射為JavaPairRDD的鍵值對Res_1。其中，key表示用戶ID+訪問時間，訪問時間形式為YYYYMMDDHHMM，精確到分；value表示氣象產(chǎn)品ID。

步驟2對Res_1數(shù)據(jù)集進行g(shù)roup-ByKey聚合計算，將相同key的多個JavaPairRDD映射為JavaPairRDD>，得到數(shù)據(jù)集Res_2。

步驟3從數(shù)據(jù)集Res_2中提取出每一個鍵值對的格式為Iterable的value，然后逐天保存，作為數(shù)據(jù)挖掘的數(shù)據(jù)樣本集data_sam。

步驟4對數(shù)據(jù)樣本集data_sam調(diào)用FP-Growth算法，產(chǎn)生關(guān)聯(lián)規(guī)則列表。

3.5　強關(guān)聯(lián)規(guī)則的篩選方法

關(guān)聯(lián)規(guī)則挖掘算法需要預(yù)先設(shè)定最小支持度和最小可信度參數(shù)才能進行計算。而人為主觀設(shè)置這兩個參數(shù)容易導(dǎo)致規(guī)則過多或者或少，或者把不相關(guān)的規(guī)則推薦給用戶等問題。為了減少關(guān)聯(lián)規(guī)則挖掘的這些不利影響，讓規(guī)則總數(shù)量盡可能在一個適當(dāng)范圍，利用氣象服務(wù)產(chǎn)品之間相似度來篩選關(guān)聯(lián)規(guī)則。本文重點針對2個向量頻繁項集和3個向量頻繁項集中置信度大于90%的強關(guān)聯(lián)規(guī)則進行篩選。具體使用的方法描述如下。

●對于2個向量頻繁項集，查看2個向量表示的氣象服務(wù)產(chǎn)品的相似度。如果其相似度小于支持度，則剔除，反之則保留。例如有規(guī)則“[13]=> [4]，置信度為 0.92”，而ID分別為13和4的氣象服務(wù)產(chǎn)品相似度為0.78，大于最小支持度0.2，標(biāo)記為有效規(guī)則進行保留。

●對于3個向量的頻繁項集，將向量間的相似度加權(quán)平均，再與最小支持度進行比較。對于規(guī)則“[A，B]=> [C]”，將向量A與向量C的相似度和向量B與向量C的相似度加權(quán)平均得出的結(jié)果與最小支持度相比，如果其相似度小于支持度，則剔除，反之則保留。

4　實驗與分析

4.1　實驗環(huán)境

本文選擇Apache Flume 1.5、Spark1.5、Java JDK(Java Development Kit) 1.7、Impala2.0、Cloudera 5.8.3作為系統(tǒng)的運行環(huán)境，采用另一種資源協(xié)調(diào)者(yet another resource negotiator，YARN)模式作為系統(tǒng)的運行方式。其中，Cloudera集群由7臺實體服務(wù)器構(gòu)成，每臺服務(wù)器的硬件配置見表5。

在Cloudera環(huán)境下，需要將YARN、Impala、Spark服務(wù)合理地部署在不同的節(jié)點上，以便充分利用集群資源給系統(tǒng)運行提供更好的性能保障。選擇運行Cloudera Manager服務(wù)的節(jié)點作為分布式文件系統(tǒng)的名字節(jié)點（namenode），并運行Spark Master、Impala Server和YARN資源管理服務(wù)。

4.2　實驗數(shù)據(jù)

本文使用的實驗數(shù)據(jù)來源于氣象服務(wù)網(wǎng)站2011—2016年的Web日志信息。經(jīng)過冗余處理后，可以獲得39146882條用戶瀏覽記錄，每條記錄包括用戶的訪問時間、用戶ID、IP地址、瀏覽氣象產(chǎn)品ID、瀏覽時間。其中，獨立IP地址1946條，包含氣象產(chǎn)品562個。篩選掉包含錯誤信息的記錄以及偽訪問用戶的記錄（有些用戶將客戶端瀏覽器設(shè)置為4 s以下頻率刷新網(wǎng)站，不能真實反映用戶瀏覽產(chǎn)品情況）后，提取出5148691條瀏覽記錄，在此基礎(chǔ)上進行本文的所有實驗。

4.3　算法實現(xiàn)

4.3.1冗余頁面的處理

本文使用Impala實現(xiàn)對冗余頁面的處理。根據(jù)文中提到的方法，將表1和表2數(shù)據(jù)導(dǎo)入Impala，并在Impala中建表3。然后在Impala中進行表的關(guān)聯(lián)操作。表2記錄數(shù)為5548191條，表1記錄數(shù)為39146882條，表3記錄數(shù)為563條。Impala是Cloudera平臺下的大規(guī)模并行處理（massive parallel processing，MPP）數(shù)據(jù)庫引擎，通過它進行表2和表3的關(guān)聯(lián)，耗時322 ms，表1和表2的關(guān)聯(lián)耗時9.13 s。

4.3.2基于修正的余弦相似度算法實現(xiàn)

基于修正的余弦相似度算法從5148691條瀏覽記中生成1946個用戶對562個產(chǎn)品的評分，最后得出562個產(chǎn)品相似度矩陣。算法基于Spark用Java語言開發(fā)實現(xiàn)，程序選擇Spark on YARN運行方式。在運行之前，先調(diào)整YARN服務(wù)的可用資源。在7個節(jié)點的集群中，每個節(jié)點有8個核以及32 GB的內(nèi)存。其中，1個節(jié)點運行YARN資源管理服務(wù)，6個節(jié)點運行YARN節(jié)點管理服務(wù)；考慮到每個節(jié)點上操作系統(tǒng)、Hadoop 的Daemon（守護）進程以及其他組件進程的運行也需要一定資源，在該測試中分配給YARN 75%的資源，即每個節(jié)點上YARN服務(wù)的可用資源為28 GB內(nèi)存和5個核。

對該算法運行效率進行測試，考察在數(shù)據(jù)量、任務(wù)提交方式及其他配置不變的情況下，改變num-executors、executorcores和executor-memory 3個運行參數(shù)引起的時效變化。一共進行9組試驗，詳細的參數(shù)配置見表6，num-executors、executor-cores和executor-memory在表中分別用參數(shù)1、參數(shù)2和參數(shù)3表示。

表5　Cloudera集群中各主機配置

表6　Spark Streaming作業(yè)運行參數(shù)配置

在試驗中，num-executors從2逐漸增大到24。由表6中每組試驗的耗時可知，算法耗時隨num-executors的增加呈下降趨勢。當(dāng)num-executors取值為2～4、4～8、8～16時，耗時并沒有明顯的變化。在將num-executors設(shè)置為20～24的4組試驗中，啟用spark.default.parallelism參數(shù)，程序運行效率得到提升。當(dāng)numexecutors為24、executor-cores為3、executor-memory為2 GB、spark.default.parallelism為900時，整體性能達到最優(yōu)。spark.default.parallelism參數(shù)用于設(shè)置每個階段的默認任務(wù)數(shù)量。前5組試驗沒有啟用這個參數(shù)，而Spark默認設(shè)置任務(wù)數(shù)為幾十個，導(dǎo)致60%～70%的Executor進程沒有任務(wù)執(zhí)行，因此盡管Executor參數(shù)在增大，但程序的耗時基本沒有變化。由此可見，如果這個參數(shù)不設(shè)置或者設(shè)置不當(dāng)，會直接影響Spark作業(yè)性能。另外，Spark作業(yè)性能與運行參數(shù)、平臺分配給YARN的可用資源、spark.default.parallelism等諸多因素有關(guān)，在其他參數(shù)不變的情況下，性能與num-executors參數(shù)也不是簡單的線性關(guān)系。因此，在實際運行中，需要統(tǒng)籌考慮這些參數(shù)的影響，選擇一個最優(yōu)的參數(shù)組合。

4.3.3FP-Growth 算法的關(guān)聯(lián)規(guī)則挖掘?qū)崿F(xiàn)

編寫Java程序，從5148691條瀏覽記錄中經(jīng)過預(yù)處理生成2500000個樣本數(shù)據(jù)，通過調(diào)用Spark機器學(xué)習(xí)庫（machine learning library，MLlib）生成FPGrowth 算法，最終生成氣象服務(wù)產(chǎn)品的關(guān)聯(lián)規(guī)則列表。程序選擇Spark on YARN運行方式，按照表6中耗時最少的參數(shù)組合提交作業(yè)到集群上。

設(shè)定最小支持度為20，取出1000、10000、50000、100000、500000、1000000、1500000、2000000、2500000條數(shù)據(jù)，進行算法效率對比實驗，結(jié)果如圖4所示。

圖4　不同記錄數(shù)的算法效率對比

由圖4可知，在給定最小支持度的條件下，F(xiàn)P-Growth算法挖掘所需的時間隨記錄數(shù)增加呈上升趨勢，但是并非線性增加。記錄數(shù)為1000時，耗時25 s左右，而記錄增加到2500000，擴大2500倍時，算法耗時僅增加一倍多。這說明當(dāng)數(shù)據(jù)量呈指數(shù)級別增加時，算法耗時并沒有隨之大幅增加，充分體現(xiàn)了分布式并行計算框架的優(yōu)勢。

圖5　最小支持度與關(guān)聯(lián)規(guī)則總數(shù)量對比

另外給定2500000 條數(shù)據(jù)，在最小支持度為10、20、30、40、50、60的條件下進行實驗，進行規(guī)則總條數(shù)與最小支持度的對比實驗，結(jié)果如圖5所示。圖5可知，隨著最小支持度的增加，規(guī)則挖掘的總數(shù)量在不斷減少，當(dāng)最小支持度達到70時，幾乎沒有挖掘出符合條件的強關(guān)聯(lián)規(guī)則。這種變化說明，最小支持度對挖掘出的關(guān)聯(lián)規(guī)則數(shù)量有很大影響，在實際應(yīng)用上要小心設(shè)置最小支持度。設(shè)置過小，容易造成關(guān)聯(lián)規(guī)則過多，給篩選和排查帶來困難；設(shè)置過大，容易過濾掉很多關(guān)聯(lián)規(guī)則，對結(jié)果造成影響。由

4.4　實驗結(jié)果分析

一共進行5組實驗，第一組選擇所有樣本；第二組選擇2012—2016年累計降水超過50 mm的時間來收集樣本，作為暴雨天氣條件下的樣本集；第三組選擇2012—2016年超過35℃高溫的時間來收集樣本，作為高溫天氣條件下的樣本集；第四組選擇2012—2016年陣風(fēng)超過6級的時間來收集樣本，作為大風(fēng)天氣條件下的樣本集；第五組選擇2012—2016年有霧霾的時間來收集樣本，作為霧霾天氣條件下的樣本集；最小支持度為20%，最小置信度為80%。

第一組實驗得到819條規(guī)則，1個向量頻繁項集106個，2個向量頻繁項集412個，3個向量頻繁項集187個，4個向量頻繁項集220個。第二組實驗得到237條規(guī)則，第三組實驗得到137條規(guī)則，第四組實驗得到50條規(guī)則，第五組實驗得到96條規(guī)則。表7給出了每組實驗置信度最高的5條規(guī)則。

對挖掘結(jié)果進行分析可知：第一組大多數(shù)規(guī)則反映出瀏覽了自動站實況和預(yù)警的用戶，會瀏覽逐小時天氣預(yù)報；第二組大多數(shù)規(guī)則反映出瀏覽了雷達回波、自動站累計降水量的用戶，會關(guān)注逐10 min累計降水量預(yù)報、全球定位系統(tǒng)（global positioning system，GPS）水汽分布、微波輻射計等；第三組大多數(shù)規(guī)則反映出瀏覽了溫度預(yù)報、自動站溫度實況的用戶會查看模式預(yù)報結(jié)果和探空圖；第四組大多數(shù)規(guī)則反映出風(fēng)和探空圖存在較強關(guān)系；第五組大多數(shù)規(guī)則反映出能見度、相對濕度、風(fēng)、大氣成分存在較強關(guān)系。

4.5　實驗結(jié)果預(yù)測

4.5.1命中率預(yù)測

強降水天氣和霧霾天氣容易給公眾的出行和工作帶來很多影響，本文選擇這兩種天氣下的樣本數(shù)據(jù)，用規(guī)則預(yù)測用戶行為，計算規(guī)則的命中率作為客觀指標(biāo)。把每次天氣過程當(dāng)成一個樣本集，對規(guī)則[A]=>B，計算[A]=>B出現(xiàn)次數(shù)與[A]=>[X]出現(xiàn)次數(shù)的比值。用pop(A，B)表示，計算方法如式（4）所示：

其中，Sum(A，B)表示[A]=>B規(guī)則出現(xiàn)次數(shù)，Sum([A]=>[X])表示所有以[A]為條件的規(guī)則總數(shù)。

用表7中第二組關(guān)聯(lián)規(guī)則對北京2017年1—6月的5個強降水過程進行預(yù)測。另外用表7中第五組關(guān)聯(lián)規(guī)則對北京2016年10—12月霧霾天氣過程進行預(yù)測。結(jié)果如圖6和圖7所示。

表7　1～5組實驗最高置信度關(guān)聯(lián)規(guī)則

由圖6可以看出，2個向量頻繁項的規(guī)則命中率高于3個向量頻繁項，而且變化不明顯，大致分布在區(qū)間[60%，95%]；而3個向量頻繁項的命中率隨不同降水過程波動相對大一些，規(guī)則3、規(guī)則4和規(guī)則5在降水量過程4中的命中率明顯偏低。

由圖7可以看出，規(guī)則的命中率分布在區(qū)間[20%，65%]；規(guī)則1的命中率趨勢平坦，分布在區(qū)間[50%，60%]；規(guī)則4和規(guī)則5的命中率較低，分布在區(qū)間[20%，40%]。造成這種現(xiàn)象的原因與霧霾樣本數(shù)偏少有關(guān)，僅有182個樣本數(shù)據(jù)可用；此外，也與霧霾天氣特點有關(guān)，例如持續(xù)時間長、天氣系統(tǒng)穩(wěn)定等導(dǎo)致氣象服務(wù)產(chǎn)品本身隨時間變化較小，用戶總體訪問量也小，從而能收集的日志數(shù)據(jù)偏少。

4.5.2不相關(guān)規(guī)則的過濾

以第一組實驗生成的819條規(guī)則為例進行排查。選出置信度超過85%的2個向量頻繁項集規(guī)則，查看2個向量的相似度，如果相似度小于最小支持度，則判斷這條規(guī)則有明確不相關(guān)性，標(biāo)記為不可用規(guī)則。一共檢查了412個規(guī)則，結(jié)合相似度過濾了76條規(guī)則。對置信度超過85%的3個向量頻繁項集規(guī)則進行處理，一共檢查了187個規(guī)則，過濾掉49個規(guī)則。

5　結(jié)束語

本文將關(guān)聯(lián)規(guī)則和物品協(xié)同過濾方法結(jié)合起來運用于氣象服務(wù)產(chǎn)品的推薦方法中，綜合使用大數(shù)據(jù)平臺多種技術(shù)實現(xiàn)了算法的并行運行，通過對算法效率的改進和推薦規(guī)則的有效排查，使規(guī)則挖掘所需的時間以及推薦的準(zhǔn)確率都有所改善，初步證明了利用這種方法進行氣象服務(wù)產(chǎn)品的推薦是可行的。在以后的工作中，可進一步細化用戶興趣的行為因素，建立用戶人物畫像群，對挖掘得到的推薦結(jié)果按強關(guān)系和弱關(guān)系用戶進行篩選，進一步提升推薦的準(zhǔn)確性。

圖6　關(guān)聯(lián)規(guī)則在5個降水過程中的命中率分布

圖7　關(guān)聯(lián)規(guī)則在5個霧霾過程中的命中率分布

參考文獻：

[1]紀(jì)淑娟, 王理, 梁永全, 等. 基于神經(jīng)網(wǎng)絡(luò)的用戶視頻評分自動獲取方法[J]. 計算機科學(xué),2015, 42(11): 96-100.JI S J, WANG L, LIANG Y Q, et al. Neuralnetwork-based method for automatic acquisition of user’s video rating[J].Computer Science, 2015, 42(11): 96-100.

[2]王濤, 覃錫忠, 賈振紅, 等. 基于相似度和信任度的關(guān)聯(lián)規(guī)則微博好友推薦[J]. 計算機應(yīng)用, 2016, 36(8): 2262-2267.WANG T, QIN X Z, JIA Z H, et al.Association rules recommendation of microblog friend based on similarity and trust[J]. Journal of Computer Applications,2016, 36(8): 2262-2267.

[3]L I U J G, Z H O U T, WA N G B H.Personalized recommender systems: a survey of the state-of-the-art[J]. Progress in Natural Science, 2009, 19(1): 1-15.

[4]LIN W, ALVAREZ S A, RUIZ C. Efficient adaptive-support association rule mining for recommendation systems[J]. Data Mining and Knowledge Discovery, 2002,6(1): 83-105.

[5]李杰, 徐勇, 王云峰, 等. 面向個性化推薦的強關(guān)聯(lián)規(guī)則挖掘[J]. 系統(tǒng)工程理論與實踐,2009, 29(8): 144-152.LI J, XU Y, WANG Y F, et al. Strongest association rules mining for personalized recommendation[J]. System Engineering-Theory &Practice, 2009, 29(8): 144-152.

[6]易芝, 汪琳琳, 王練. 基于關(guān)聯(lián)規(guī)則相關(guān)性分析的Web 個性化推薦研究[J]. 重慶郵電大學(xué)學(xué)報(自然科學(xué)版), 2007, 19(2): 234-237.YI Z, WANG L L, WANG L. Research on Web personalized recommendation based on correlation analysis of association rule[J]. Journal of Chongqing University of Posts and Communications (Natural Science), 2007, 19(2): 234-237.

[7]鮑玉斌, 王大玲, 于戈. 關(guān)聯(lián)規(guī)則和聚類分析在個性化推薦中的應(yīng)用[J]. 東北大學(xué)學(xué)報(自然科學(xué)版),2003, 24(12): 1149-1188.BAO Y B, WANG D L, YU G. Application of association rules and clustering analysis to personalized recommendation[J]. Journal of Northeastern University (Natural Science ), 2003, 24(12): 1149-1188.

[8]張忠林, 田苗鳳, 劉宗成. 大數(shù)據(jù)環(huán)境下關(guān)聯(lián)規(guī)則并行分層挖掘算法研究[J]. 計算機科學(xué),2016, 43(1): 286-289.ZHANG Z L, TIAN M F, LIU Z C. Parallel hierarchical association rule mining in big data environment[J]. Computer Science,2016, 43(1): 286-289.

[9]周詩慧, 殷建. Hadoop 平臺下的并行Web 日志挖掘算法[J]. 計算機工程, 2013, 39(6): 43-46.ZHOU S H, YIN J. Parallel web log mining algorithm in Hadoop platform[J]. Computer Engineering, 2013, 39(6): 43-46.

[10]劉帥, 楊英杰, 常德顯, 等. 改進的模糊關(guān)聯(lián)規(guī)則及其挖掘算法[J]. 計算機工程與設(shè)計,2015, 36(4): 942-947.LIU S, YANG Y J, CHANG D X, et al.Improved fuzzy association rule and its mining algorithm[J]. Computer Engineer and Design, 2015, 36(4): 942-947.

[11]程廣, 王曉峰. 基于MapReduce的并行關(guān)聯(lián)規(guī)則增量更新算法[J]. 計算機工程, 2016,42(2): 21-26.CHENG G, WANG X F. Incremental updating algorithm of parallel association rule based on MapReduce[J]. Computer Engineer, 2016, 42(2): 21-26.

[12]黃曉雯, 嚴(yán)明, ?；w, 等. 基于關(guān)聯(lián)規(guī)則挖掘的跨網(wǎng)絡(luò)知識關(guān)聯(lián)及協(xié)同應(yīng)用[J]. 計算機科學(xué), 2016, 43(7): 51-57.HUANG X W, YAN M, SANG J T, et al.Association rules mining based crossnetwork knowledge association and collaborative application[J]. Computer Science, 2016, 43(7): 51-57.

[13]陳平華, 陳傳瑜, 洪英. 一種結(jié)合關(guān)聯(lián)規(guī)則的協(xié)同過濾推薦算法[J]. 小型微型計算機系統(tǒng),2016,37(2): 287-293.CHEN P H, CHEN C Y, HONG Y.Incorporating association rules for collaborative filtering recommendation algorithm[J]. Journal of Chinese Computer Systems, 2016, 37(2): 287-293.

[14]胡波, 黃寧, 仵偉強. 基于業(yè)務(wù)路徑和頻度矩陣的關(guān)聯(lián)規(guī)則挖掘算法[J]. 計算機科學(xué),2016, 43(12): 146-154.HU B, HUANG N, WU W Q. Algorithm for mining association rules based on application paths and frequency matrix[J].Computer Science, 2016, 43(12): 146-154.

[15]石巖, 鄧敏, 劉啟亮, 等. 海陸氣候事件關(guān)聯(lián)規(guī)則挖掘方法[J]. 地理信息科學(xué), 2014,16(2): 182-191.SHI Y, DENG M, LIU Q L, et al. Discovering sequential association rules between single ocean climate index and land abnormal climate events[J]. Journal of Geo-information Science, 2014, 16(2): 182-191.

[16]劉娟, 宋安軍. 改進FP-growth 算法在氣象預(yù)報中的應(yīng)用[J]. 計算機系統(tǒng)應(yīng)用, 2016,25(10): 199-205.LIU J, SONG A J. Application of an improve FP-growth algorithm in meteorological forecast[J]. Application of Computer System, 2016, 25(10): 199-205.

[17]BINZENH?FER A, TUTSCHKU K,GRABEN B A D, et al. A P2P-based framework for distributed network management[M]. Berlin: Springer Berlin Heidelberg, 2005.

[18]CHEVUL S, BINZENHFER A, SCHMID M, et al. A self-organizing concept for distributed end-to-end quality monitoring[R]. Germany: University of Wurzburg Institute, 2006.

[19]董長青, 任女爾, 張慶余, 等. 基于HBase+ElasticSearch的海量交通數(shù)據(jù)實時存取方案設(shè)計[J]. 大數(shù)據(jù), 2017(1): 80-89.DONG C Q, REN N E, ZHANG Q Y, et al.Design scheme of massive traffic data real-time access based on HBase and Elastic Search[J]. Big Data Research,2017(1): 80-89.

[20]李大中, 劉劍, 鄧景文. 大數(shù)據(jù)能力開放平臺創(chuàng)新和發(fā)展[J]. 大數(shù)據(jù), 2017(1): 72-80.LI D Z, LIU J, DENG J W. Innovation and development of big data ability open platform[J].Big Data Research, 2017(1): 72-80.

[21]石勇, 孟凡. 信用評分基本理論及其應(yīng)用[J].大數(shù)據(jù), 2017(1): 19-27.SHI Y, MENG F. Credit scoring: basic theory and applications[J]. Big Data Research, 2017(1): 19-27.

[22]劉巖, 王華, 秦葉陽, 等. 智慧城市多源異構(gòu)大數(shù)據(jù)處理框架[J]. 大數(shù)據(jù), 2017(1): 51-60.LIU Y, WANG H, QIN Y Y, et al.Multisource heterogeneous big data processing architecture in smart city[J].Big Data Research, 2017(1): 51-60.