劉 哲，馬樂(lè)榮

(延安大學(xué) 數(shù)學(xué)與計(jì)算機(jī)科學(xué)學(xué)院，陜西 延安 716000)

隨著電子商務(wù)的快速發(fā)展，網(wǎng)上購(gòu)物已經(jīng)成為一種重要的購(gòu)物形式，大規(guī)模電商平臺(tái)每天都會(huì)產(chǎn)生海量的商品交易數(shù)據(jù)。大量研究人員選擇電商平臺(tái)的商品數(shù)據(jù)作為實(shí)驗(yàn)數(shù)據(jù)集[1-3]。針對(duì)這些數(shù)據(jù)的挖掘和分析，對(duì)于優(yōu)化平臺(tái)建設(shè)、增加產(chǎn)品銷(xiāo)量、改進(jìn)消費(fèi)者購(gòu)物體驗(yàn)等，都有著重要的研究?jī)r(jià)值。

電商平臺(tái)出于性能和安全的考慮，往往通過(guò)異步加載的方法對(duì)數(shù)據(jù)進(jìn)行展示。一些商品頁(yè)面在瀏覽器中查看時(shí)，可以顯示所有的商品數(shù)據(jù)，但通過(guò)爬蟲(chóng)將頁(yè)面下載到本地，卻無(wú)法獲取想要采集的數(shù)據(jù)或者只能獲取到部分?jǐn)?shù)據(jù)。例如，京東商城和天貓的商品詳情頁(yè)中，商品價(jià)格的顯示都是動(dòng)態(tài)加載的，通過(guò)查看頁(yè)面源代碼的方式，會(huì)發(fā)現(xiàn)顯示價(jià)格的html標(biāo)簽中沒(méi)有內(nèi)容。針對(duì)這些大規(guī)模電商平臺(tái)數(shù)據(jù)，常見(jiàn)的做法是對(duì)頁(yè)面中的http請(qǐng)求進(jìn)行抓包和分析，尋找數(shù)據(jù)源。這種做法通常是非常值得的，最終可以得到結(jié)構(gòu)化的、完整的數(shù)據(jù)和更快的抓取速度。然而，大規(guī)模電商平臺(tái)頁(yè)面內(nèi)容豐富、結(jié)構(gòu)復(fù)雜，一個(gè)商品頁(yè)面能產(chǎn)生上百個(gè)請(qǐng)求。而且，接口所需參數(shù)往往難以獲取并且不好分析。如果對(duì)參數(shù)進(jìn)行刪減，則得到的數(shù)據(jù)準(zhǔn)確性難以保證，并且容易被平臺(tái)的反爬機(jī)制發(fā)現(xiàn)，導(dǎo)致被屏蔽。隨著平臺(tái)的業(yè)務(wù)發(fā)展和技術(shù)迭代，接口參數(shù)也會(huì)發(fā)生變動(dòng)。

當(dāng)需要獲取不同平臺(tái)的商品數(shù)據(jù)時(shí)，必須重新抓包、分析，時(shí)間成本高，技術(shù)難度大。本文通過(guò)Splash模擬瀏覽器操作，結(jié)合Scrapy爬蟲(chóng)框架，設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)商品信息采集系統(tǒng)，可以快速實(shí)現(xiàn)對(duì)不同平臺(tái)商品信息的采集。

1 實(shí)驗(yàn)設(shè)計(jì)

大規(guī)模電商平臺(tái)擁有的商品數(shù)以萬(wàn)計(jì)，商品種類(lèi)繁多，為了方便消費(fèi)者快速定位感興趣的產(chǎn)品，通常都提供了“商品檢索”的功能。國(guó)內(nèi)一些常見(jiàn)的大規(guī)模電商平臺(tái)，例如京東商城、天貓、淘寶、當(dāng)當(dāng)網(wǎng)等，都提供了商品檢索的功能。這些平臺(tái)在商品詳情頁(yè)對(duì)商品進(jìn)行描述時(shí)，都包括以下幾個(gè)部分：商品基本信息、規(guī)格參數(shù)、用戶評(píng)論，以及一組用于商品展示的圖片等。因此，本實(shí)驗(yàn)主要針對(duì)商品詳情頁(yè)包含的四部分內(nèi)容進(jìn)行數(shù)據(jù)采集。

1.1 基本概念

在電商平臺(tái)進(jìn)行商品檢索時(shí)，首先需要在“商品搜索框”中輸入商品名稱(chēng)，點(diǎn)擊“搜索按鈕”后會(huì)返回搜索結(jié)果的第一頁(yè)，選定此時(shí)的頁(yè)面地址作為程序的啟動(dòng)URL(start_url)。同時(shí)，在電商平臺(tái)的商品檢索頁(yè)面下方，通常有一排用于顯示頁(yè)碼信息的分頁(yè)按鈕(例如京東，天貓，當(dāng)當(dāng)網(wǎng)等)，如下圖1所示為京東商城商品檢索頁(yè)中的分頁(yè)按鈕，圖中箭頭所示文本輸入框中的頁(yè)碼，稱(chēng)作頁(yè)號(hào)(page_num)(初始值設(shè)置為1，可根據(jù)需求適當(dāng)調(diào)整)。

圖1京東平臺(tái)商品檢索頁(yè)面中的分頁(yè)按鈕

1.2 系統(tǒng)算法設(shè)計(jì)

實(shí)驗(yàn)設(shè)計(jì)的基本步驟如下(圖2為對(duì)應(yīng)的程序流程圖)：

圖2 系統(tǒng)流程圖

(1)首先，訪問(wèn)start_url頁(yè)面。

(2)模擬瀏覽器操作，訪問(wèn)商品檢索結(jié)果中的第page_num頁(yè)：

a.在圖1所示的文本輸入框中填入page_num。

b.點(diǎn)擊‘確定’按鈕，訪問(wèn)檢索結(jié)果中的page_num頁(yè)。

c.根據(jù)實(shí)際情況，選擇性增加頁(yè)面滾動(dòng)的操作(適用于那些通過(guò)頁(yè)面滾動(dòng)的方式加載當(dāng)前檢索頁(yè)剩余商品的電商平臺(tái)，例如京東商城、蘇寧易購(gòu)等)。

(3)將檢索結(jié)果中的第page_num頁(yè)內(nèi)容下載至本地，解析出頁(yè)面中的商品詳情頁(yè)地址。

(4)遍歷商品詳情頁(yè)，依次采集商品的基本信息、圖片、評(píng)論數(shù)據(jù)。

(5)將采集到的商品信息存入數(shù)據(jù)庫(kù)。

(6)page_num+=1，重復(fù)步驟(1)～(5)，抓取剩余檢索頁(yè)中的商品信息。

(7)程序運(yùn)行結(jié)束。

說(shuō)明：通過(guò)這種方式，避免了對(duì)平臺(tái)的http請(qǐng)求進(jìn)行抓包和分析的繁瑣工作，當(dāng)需要采集其它平臺(tái)的商品數(shù)據(jù)，或者接口參數(shù)發(fā)生變動(dòng)時(shí)，只需更換start_url，便可快速開(kāi)始采集。

2 技術(shù)實(shí)現(xiàn)

本次實(shí)驗(yàn)使用Python 3.0作為編程語(yǔ)言，使用Splash模擬瀏覽器操作，并對(duì)商品頁(yè)面中的javascript代碼進(jìn)行預(yù)渲染，爬蟲(chóng)部分使用了Scrapy爬蟲(chóng)框架對(duì)數(shù)據(jù)進(jìn)行抓取和解析，數(shù)據(jù)的持久化儲(chǔ)存選擇了MongoDB[4，5]，系統(tǒng)總體框架如圖3所示。

2.1 主要組件介紹

Splash是一種javascript渲染引擎，它的本質(zhì)是一個(gè)帶有HTTPAPI的輕量級(jí)Web瀏覽器。其支持以下功能：并行處理多個(gè)Web頁(yè)面；為用戶返回經(jīng)過(guò)渲染的頁(yè)面；可以方便的禁止圖片的加載，使頁(yè)面渲染速度得到極大的提升；在頁(yè)面上下文(pagecontext)中執(zhí)行用戶自定義的javascript腳本等。由于Splash是以html的形式返回了網(wǎng)頁(yè)的document樹(shù)結(jié)構(gòu)，我們可以方便的選擇自己熟悉的html解析器對(duì)頁(yè)面進(jìn)行解析。通過(guò)執(zhí)行用戶編寫(xiě)的自定義腳本，Splash的作用類(lèi)似于瀏覽器自動(dòng)化工具。

圖3 系統(tǒng)框架

Scrapy是一款基于Python實(shí)現(xiàn)的，已經(jīng)非常成熟的爬蟲(chóng)框架。它提供了很多方便實(shí)用的功能，讓數(shù)據(jù)爬取變得簡(jiǎn)單而高效。Scrapy自帶的選擇器(selector)，讓用戶可以通過(guò)xpath表達(dá)式或者css選擇器從html/xml結(jié)構(gòu)中選擇和提取數(shù)據(jù)，并對(duì)css選擇器進(jìn)行了擴(kuò)展。交互式的shell控制臺(tái)，在編寫(xiě)或者調(diào)試爬蟲(chóng)程序時(shí)非常有用。同時(shí)也提供了強(qiáng)大的可擴(kuò)展性支持，允許用戶使用自定義的中間件對(duì)框架進(jìn)行擴(kuò)展。

MongoDB是當(dāng)前很受歡迎的新一代數(shù)據(jù)庫(kù)，它由C++語(yǔ)言編寫(xiě)，是一個(gè)基于分布式文件存儲(chǔ)的開(kāi)源數(shù)據(jù)庫(kù)系統(tǒng)。相比于傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)，MongoDB對(duì)于大數(shù)據(jù)，高并發(fā)以及高可靠性有強(qiáng)大的支持。相比于其他的NoSQL數(shù)據(jù)庫(kù)，MongoDB的基于文檔的數(shù)據(jù)模型及其動(dòng)態(tài)建模的特性使得它更加自由靈活，適用于各種應(yīng)用場(chǎng)景。它支持幾乎所有的主流編程語(yǔ)言，例如Python，java，php等。

2.2 具體實(shí)現(xiàn)技術(shù)

搭建實(shí)驗(yàn)環(huán)境時(shí)，有幾項(xiàng)準(zhǔn)備工作要做：①由于Splash是運(yùn)行在Docker容器中的，所以需要先安裝Docker，安裝成功后，從DockerHub拉取Splash鏡像特別慢，容易拉取失敗，配置國(guó)內(nèi)的鏡像源后可以解決，可以參考文獻(xiàn)[6]。②采用Scrapy+Splash結(jié)構(gòu)時(shí)，還需要安裝Python包Scrapy-Splash，達(dá)到二者之間的無(wú)縫結(jié)合。安裝Scrapy-Splash時(shí)，要注意閱讀“配置”部分的內(nèi)容。③通過(guò)“pipinstallscrapy”命令安裝爬蟲(chóng)框架時(shí)，容易遇到因?yàn)槌瑫r(shí)拋出異常，無(wú)法下載成功的情況?？梢赃x擇一些比較穩(wěn)定、下載速度快的國(guó)內(nèi)鏡像來(lái)下載，安裝其他Python包時(shí)也可使用該方法進(jìn)行加速。表1中列出了一些常用的Python鏡像站。

表1 常用的國(guó)內(nèi)鏡像站

關(guān)于Scrapy的框架結(jié)構(gòu)，內(nèi)部各組件間數(shù)據(jù)的處理和流向，官方文檔中有詳細(xì)的介紹，也可以參考文獻(xiàn)[7，8]，本文不再贅述。這里主要介紹如何通過(guò)上述各種工具，快速實(shí)現(xiàn)對(duì)不同平臺(tái)商品信息的采集。下圖3給出了完整的系統(tǒng)框架，從圖中可以看出，商品信息的采集可以分為兩大類(lèi)：一種是需要通過(guò)Splash對(duì)頁(yè)面中的內(nèi)容進(jìn)行動(dòng)態(tài)渲染(模擬瀏覽器操作的本質(zhì)也是動(dòng)態(tài)執(zhí)行自定義js腳本)，例如，商品檢索頁(yè)面，商品詳情頁(yè)面。采集時(shí)，需要將默認(rèn)的Scrapy Request對(duì)象，經(jīng)過(guò)包Scrapy-Splash轉(zhuǎn)換為Splash可以接受的Splash Request對(duì)象，再由Splash訪問(wèn)對(duì)應(yīng)的頁(yè)面，返回經(jīng)過(guò)渲染后的內(nèi)容。另一種不需要經(jīng)過(guò)Splash預(yù)渲染，可以直接通過(guò)訪問(wèn)獲取到數(shù)據(jù)，例如，商品的展示圖片和商品評(píng)論。當(dāng)Splash返回商品詳情頁(yè)的內(nèi)容后，通過(guò)解析可以獲取到商品圖片的地址，Scrapy中有自帶的ImagesPipeline模塊，可以自動(dòng)將圖片下載到本地文件系統(tǒng)中。不過(guò)為了便于持久化儲(chǔ)存，我們直接將下載到的圖片內(nèi)容(二進(jìn)制格式)記錄在對(duì)應(yīng)的商品Item中，當(dāng)商品評(píng)論下載完成時(shí)，再將Item儲(chǔ)存在數(shù)據(jù)庫(kù)中。由于我們?cè)谏唐吩斍轫?yè)瀏覽評(píng)論時(shí)，評(píng)論頁(yè)的跳轉(zhuǎn)產(chǎn)生的http請(qǐng)求較少，數(shù)據(jù)源容易確定，實(shí)驗(yàn)中直接通過(guò)評(píng)論接口抓取商品的評(píng)論信息。

需要指出的是，在程序的運(yùn)行過(guò)程中，檢索結(jié)果頁(yè)、商品詳情頁(yè)、商品圖片及商品評(píng)論的下載是同時(shí)進(jìn)行的，Scrapy會(huì)自動(dòng)維護(hù)請(qǐng)求和響應(yīng)隊(duì)列，我們也可以為Request對(duì)象設(shè)置優(yōu)先級(jí)(priority)來(lái)指定請(qǐng)求的執(zhí)行順序。

3 主要問(wèn)題及解決方案

本部分內(nèi)容選取了實(shí)驗(yàn)過(guò)程中遇到的一些難點(diǎn)問(wèn)題，并給出了詳細(xì)的解決方案，總結(jié)如下。

問(wèn)題1：程序運(yùn)行一段時(shí)間后，頻繁出現(xiàn)Splash服務(wù)停止運(yùn)行的情況。

Splash運(yùn)行時(shí)使用的不是一塊固定的內(nèi)存(use an unbound in-memory cache)，隨著時(shí)間的推移，會(huì)消耗掉所有的內(nèi)存資源。解決方法是，當(dāng)使用過(guò)多內(nèi)存時(shí)重新啟動(dòng)該進(jìn)程?？赏ㄟ^(guò)Splash中的—maxrss選項(xiàng)來(lái)指定該閾值。同時(shí)，為了防止異常錯(cuò)誤導(dǎo)致的Splash服務(wù)停止運(yùn)行，可以在Docker啟動(dòng)命令中增加—restart選項(xiàng)。啟動(dòng)一個(gè)需要長(zhǎng)時(shí)間運(yùn)行的Splash服務(wù)命令如下，當(dāng)內(nèi)存占用超過(guò)1000MB或者服務(wù)停止運(yùn)行時(shí)，會(huì)重新啟動(dòng)Splash服務(wù)：

“dockerrun-d-p8050：8050-restart=always scrapinghub/splash-maxrss1000”

問(wèn)題2：當(dāng)某個(gè)商品的評(píng)論數(shù)據(jù)采集完成后，需要存入數(shù)據(jù)庫(kù)，如何判斷這個(gè)時(shí)間點(diǎn)。

假設(shè)商品有n頁(yè)評(píng)論，通過(guò)循環(huán)的方式順序發(fā)出m1，m2，……，mn個(gè)異步請(qǐng)求。Scrapy框架中雖然可以通過(guò)request.meta屬性為每個(gè)請(qǐng)求標(biāo)上序號(hào)，并傳遞給對(duì)應(yīng)的response進(jìn)行訪問(wèn)，但由于無(wú)法控制服務(wù)器的響應(yīng)時(shí)間和網(wǎng)絡(luò)傳輸?shù)臅r(shí)間，這n個(gè)請(qǐng)求返回本地的順序是不確定的，通過(guò)判斷請(qǐng)求序號(hào)是否為n(最后一頁(yè))來(lái)確定商品評(píng)論采集完成的方法是錯(cuò)誤的。Scrapy本身也沒(méi)有給出這種情況下的解決方案。我們的解決方案是，為request.meta屬性(字典結(jié)構(gòu))設(shè)置一個(gè)鍵，對(duì)應(yīng)的值初始化為空列表，每成功抓取一頁(yè)評(píng)論，向這個(gè)列表中增加一個(gè)計(jì)數(shù)元素(可以是數(shù)字0)。

該方法利用了Python語(yǔ)言中列表類(lèi)型數(shù)據(jù)的特性，將用于計(jì)數(shù)的列表保存在本地，雖然請(qǐng)求是異步的，但是每個(gè)請(qǐng)求都指向了同一個(gè)列表(meta字段中實(shí)際保存的只是列表的內(nèi)存地址)。當(dāng)響應(yīng)返回本地時(shí)，每個(gè)響應(yīng)都可以通過(guò)判斷該列表的長(zhǎng)度和評(píng)論接口返回的“maxPage”(評(píng)論頁(yè)總數(shù))是否相等，來(lái)確定商品的所有評(píng)論信息是否采集完成。

商品詳情頁(yè)中圖片的采集也采用類(lèi)似的方法。當(dāng)圖片采集完成后，開(kāi)始采集評(píng)論數(shù)據(jù)，評(píng)論數(shù)據(jù)采集完成后，存入數(shù)據(jù)庫(kù)。

問(wèn)題3：setting.py中的自定義配置項(xiàng)問(wèn)題。

表2 setting.py中的自定義配置項(xiàng)

Scrapy框架的setting模塊允許用戶自定義項(xiàng)目中的所有組件行為，為項(xiàng)目增添或者修改任何配置的工作，都是在setting.py文件中進(jìn)行的。Scrapy提供了大量的內(nèi)建配置項(xiàng)，表2中列出了一些可以?xún)?yōu)化項(xiàng)目運(yùn)行的配置項(xiàng)。其中，DOWNLOAD_DELAY用于限制從同一網(wǎng)站連續(xù)下載頁(yè)面時(shí)，每次發(fā)送請(qǐng)求前程序應(yīng)等待的時(shí)間，這樣做的目的是為了限制爬取速度，避免對(duì)服務(wù)器造成太大的沖擊，同時(shí)降低被爬蟲(chóng)檢測(cè)程序發(fā)現(xiàn)的風(fēng)險(xiǎn)，該值的設(shè)置參考了文獻(xiàn)[9]。LOG_FILE用于長(zhǎng)時(shí)間數(shù)據(jù)采集時(shí)，將運(yùn)行日志保存為本地文件。RETRY_TIMES用于設(shè)置頁(yè)面下載失敗時(shí)，嘗試重新下載的最大次數(shù)，默認(rèn)值是2次，可根據(jù)情況適當(dāng)修改。RETRY_HTTP_CODES表示請(qǐng)求下載失敗時(shí)，根據(jù)http狀態(tài)碼，決定是否重新發(fā)起請(qǐng)求，這里在原來(lái)的配置項(xiàng)中增加狀態(tài)碼400，因?yàn)樵诖笠?guī)模的數(shù)據(jù)采集過(guò)程中，會(huì)遇到少量的狀態(tài)碼為400的情況。

問(wèn)題4：采集商品評(píng)論時(shí)，評(píng)論接口參數(shù)的值獲取困難。

實(shí)驗(yàn)中還遇到一個(gè)難點(diǎn)，當(dāng)采集京東商城商品評(píng)論時(shí)，評(píng)論接口參數(shù)callback的值無(wú)法確定，它的值都具有“fetchJSON_comment98vv5289”的形式，不同商品的評(píng)論接口中，該字符串末尾的幾位數(shù)字是隨機(jī)的。雖然去掉callback參數(shù)時(shí)也可以采集到評(píng)論數(shù)據(jù)，但采集一段時(shí)間后，接口返回“套接字錯(cuò)誤”的提示，無(wú)法繼續(xù)獲取到評(píng)論數(shù)據(jù)。通過(guò)多次分析發(fā)現(xiàn)，在商品頁(yè)面中存在一個(gè)js變量comment Version，該變量的值和參數(shù)callback中最后幾位數(shù)字是一致的，通過(guò)編寫(xiě)正則表達(dá)式和字符串拼接，就能得到完整的評(píng)論接口。

問(wèn)題5：程序結(jié)構(gòu)和邏輯的優(yōu)化問(wèn)題。

在對(duì)頁(yè)面內(nèi)容進(jìn)行解析，得到原始數(shù)據(jù)后，往往還需要進(jìn)一步的加工處理，例如，去除字符串兩端的空白，檢查采集到的url字符串是否缺少“https：”協(xié)議頭等。隨著采集字段的增加，這樣的特殊處理越來(lái)越多，使主程序邏輯混亂，代碼結(jié)構(gòu)臃腫。大多數(shù)項(xiàng)目在數(shù)據(jù)采集的過(guò)程中，對(duì)這個(gè)問(wèn)題都沒(méi)有引起足夠的重視[10-12]，當(dāng)遇到大規(guī)模的數(shù)據(jù)采集時(shí)，往往擴(kuò)展困難，容易造成維護(hù)噩夢(mèng)。

解決方案就是將原始數(shù)據(jù)的處理過(guò)程從主程序中分離出去，通過(guò)使用Scrapy中的ItemLoader模塊可以實(shí)現(xiàn)這個(gè)功能。由于采集到的數(shù)據(jù)是以Item的形式進(jìn)行傳遞的，ItemLoader為Item中的每個(gè)字段提供一個(gè)輸入處理器和一個(gè)輸出處理器，用戶可以在輸入、輸出處理器中，擴(kuò)展或者覆蓋不同字段的解析規(guī)則。通過(guò)這樣的方式，實(shí)現(xiàn)了對(duì)程序中原始數(shù)據(jù)的解析和處理兩個(gè)過(guò)程的解耦，讓程序結(jié)構(gòu)和邏輯更加清晰，系統(tǒng)更易維護(hù)。

4 實(shí)驗(yàn)結(jié)果與分析

本次實(shí)驗(yàn)選取了“京東商城”和“當(dāng)當(dāng)網(wǎng)”2個(gè)平臺(tái)作為數(shù)據(jù)采集的對(duì)象，以“手機(jī)”作為檢索關(guān)鍵詞，分別對(duì)所設(shè)計(jì)的系統(tǒng)進(jìn)行驗(yàn)證。針對(duì)京東商城，采集前10頁(yè)的手機(jī)商品數(shù)據(jù)，在商品詳情頁(yè)中采集商品介紹、規(guī)格包裝、圖片和全部的評(píng)論數(shù)據(jù)。對(duì)于當(dāng)當(dāng)網(wǎng)，采集前5頁(yè)的手機(jī)商品數(shù)據(jù)，在商品詳情頁(yè)中，僅采集商品介紹和規(guī)格參數(shù)、圖片等基本信息。

在采集京東商城的商品數(shù)據(jù)時(shí)，我們將外層循環(huán)的迭代次數(shù)設(shè)置為1，程序運(yùn)行時(shí)，只對(duì)一個(gè)檢索頁(yè)面中的商品信息進(jìn)行采集。通過(guò)將page_num的值依次設(shè)置為1、2、3、…、10，分次采集了前10頁(yè)的商品信息。采集當(dāng)當(dāng)網(wǎng)時(shí)，外層循環(huán)的迭代次數(shù)設(shè)置為5，page_num初始值設(shè)置為1，程序運(yùn)行時(shí)，直接采集前5頁(yè)商品基本信息。圖4給出對(duì)京東平臺(tái)進(jìn)行分頁(yè)采集時(shí)，每頁(yè)數(shù)據(jù)的耗時(shí)曲線，檢索頁(yè)商品的評(píng)論總數(shù)曲線，及采集產(chǎn)生的請(qǐng)求數(shù)曲線。圖中的x軸代表采集時(shí)的檢索頁(yè)頁(yè)碼，兩個(gè)y軸代表商品評(píng)論總數(shù)(或者產(chǎn)生的請(qǐng)求個(gè)數(shù))和總耗時(shí)。最后，在圖中標(biāo)注出了對(duì)當(dāng)當(dāng)網(wǎng)一次性采集5頁(yè)商品基本信息時(shí)的總耗時(shí)。

仔細(xì)觀察圖中的耗時(shí)曲線，并且對(duì)比當(dāng)當(dāng)網(wǎng)不采集商品評(píng)論情況下的總耗時(shí)可以發(fā)現(xiàn)，數(shù)據(jù)采集的耗時(shí)主要受到商品評(píng)論數(shù)量的影響。圖中耗時(shí)曲線上有兩個(gè)異常點(diǎn)，第5頁(yè)和第10頁(yè)的耗時(shí)均高于前一個(gè)點(diǎn)，但評(píng)論數(shù)量卻均低于前一個(gè)點(diǎn)。通過(guò)分析日志發(fā)現(xiàn)，采集這兩頁(yè)數(shù)據(jù)時(shí)，程序中產(chǎn)生的retry_request更多，即由于各種原因?qū)е履硞€(gè)請(qǐng)求下載失敗時(shí)，重新發(fā)起的采集請(qǐng)求。對(duì)比請(qǐng)求曲線中，這兩個(gè)點(diǎn)的值均高于前一個(gè)點(diǎn)，也可以印證這一分析。

圖4 商品信息采集結(jié)果展示

圖4客觀反映出了本文提出的數(shù)據(jù)采集方法的運(yùn)行效率，在實(shí)踐中，用戶可以根據(jù)需要，采集商品的若干頁(yè)評(píng)論，提升采集效率。同時(shí)，由于實(shí)驗(yàn)條件的限制，程序運(yùn)行時(shí)的爬蟲(chóng)系統(tǒng)，數(shù)據(jù)庫(kù)服務(wù)，支撐Splash及Docker服務(wù)的虛擬機(jī)等均運(yùn)行在同一臺(tái)筆記本電腦上，一定程度上也影響了數(shù)據(jù)采集的效率，這也是以后的一個(gè)改進(jìn)方向。數(shù)據(jù)采集的成功，直接說(shuō)明了本文提出的大規(guī)模電商平臺(tái)商品信息采集方法的可行性，該方法可以實(shí)現(xiàn)對(duì)不同平臺(tái)商品數(shù)據(jù)的快速采集，為廣大的研究人員節(jié)省開(kāi)發(fā)時(shí)間。

5 結(jié)論

本文以大規(guī)模電商平臺(tái)商品交易數(shù)據(jù)為采集對(duì)象，提出了一種快速采集不同平臺(tái)商品數(shù)據(jù)的有效方法，并以京東商城、當(dāng)當(dāng)網(wǎng)為例進(jìn)行數(shù)據(jù)采集。通過(guò)實(shí)驗(yàn)證明，該方法能有效降低數(shù)據(jù)采集的難度，也可以用于單個(gè)平臺(tái)的數(shù)據(jù)采集。在后期的工作中，我們將采集不同平臺(tái)的商品數(shù)據(jù)，在此基礎(chǔ)上構(gòu)建電商知識(shí)圖譜。