編者按：互聯(lián)網(wǎng)上有浩瀚的數(shù)據(jù)資源，要想抓取這些數(shù)據(jù)就離不開爬蟲。鑒于網(wǎng)上免費開源的爬蟲框架多如牛毛，很多人認為爬蟲定是非常簡單的事情。但是如果你要定期上規(guī)模地準確抓取各種大型網(wǎng)站的數(shù)據(jù)卻是一項艱巨的挑戰(zhàn)，其中包括網(wǎng)站的格式經(jīng)常會變、架構(gòu)必須能靈活伸縮應對規(guī)模變化同時要保持性能，與此同時還要挫敗網(wǎng)站反機器人的手段以及維護數(shù)據(jù)質(zhì)量。流行的Python爬蟲框架Scrapy開發(fā)者Scrapinghub分享了他們抓取一千億個網(wǎng)頁后的經(jīng)驗之談。

現(xiàn)在爬蟲技術(shù)似乎是很容易的事情，但這種看法是很有迷惑性的。開源的庫/框架、可視化的爬蟲工具以及數(shù)據(jù)析取工具有很多，從網(wǎng)站抓取數(shù)據(jù)似乎易如反掌。然而，當你成規(guī)模地在網(wǎng)站上抓東西時，事情很快就會變得非常棘手。

自2010年以來抓取超過1000億個產(chǎn)品頁面，我們將會通過系列文章來分享從中學到的經(jīng)驗教訓，讓你深入了解從電子商務商店中規(guī)模析取數(shù)據(jù)時所面臨的挑戰(zhàn)，并且跟你分享應對這些挑戰(zhàn)的某些最佳實踐。

本文是該系列文章的第一篇，在這里我們將提供規(guī)模抓取產(chǎn)品數(shù)據(jù)所面臨主要挑戰(zhàn)的概覽，以及Scrapinghub從抓取1000億產(chǎn)品頁面中學到的經(jīng)驗教訓。

成立于2010年的Scrapinghub是領(lǐng)先的數(shù)據(jù)析取公司之一，也是當今最健壯和流行的web爬蟲框架Scrapy的作者。目前Scrapinghub每月抓取許多全球最大型電子商務公司的頁面數(shù)超過80億（其中30億是產(chǎn)品頁面）。

對于那些對規(guī)模爬取網(wǎng)頁技術(shù)感興趣但對要不要建立專門的web爬取團隊或者外包給專門的web爬取公司的人來說，最好看看這個免費指南，企業(yè)web爬蟲：規(guī)模化web爬取技術(shù)指南

規(guī)模爬取技術(shù)為什么重要？

跟標準的web爬取應用不一樣的是，規(guī)模爬取電子商務產(chǎn)品數(shù)據(jù)有一項獨特挑戰(zhàn)使得web抓取要困難許多。

本質(zhì)上這些挑戰(zhàn)可歸結(jié)為兩件事情：速度和數(shù)據(jù)質(zhì)量。

由于時間通常是限制因素，規(guī)模抓取要求你的爬蟲要以很高的速度抓取網(wǎng)頁但又不能拖累數(shù)據(jù)質(zhì)量。對速度的這張要求使得爬取大規(guī)模產(chǎn)品數(shù)據(jù)變得極具挑戰(zhàn)性。

挑戰(zhàn)1：草率而且總是在變的網(wǎng)站格式

這一點很明顯但也許不是最性感的挑戰(zhàn)，但是草率而一直在變的網(wǎng)站格式是目前為止你在規(guī)模析取數(shù)據(jù)時將會面臨的最大挑戰(zhàn)。這未必是因為任務的復雜性，而是由于你要投入的時間和資源。

如果你花過時間開發(fā)過電子商務商店的爬蟲的話，你就會知道電子商務網(wǎng)站代碼之草率是一種流行病。這可不僅僅是HTML完構(gòu)性或者偶爾的字符編碼問題。這些年來我們遇到過形形色色的問題——HTTP響應代碼的誤用，損壞的JavaScript代碼，或者Ajax的誤用：

• 停掉產(chǎn)品時移除頁面的商店在網(wǎng)站升級后突然間會在404錯誤處理程序返回200響應碼。
• 不恰當?shù)腏SON轉(zhuǎn)義破壞了部分頁面的JavaScript代碼（比如‘b0rk’d’），導致你需要用正則表達式來抓取那部分數(shù)據(jù)。
• 濫用Ajax調(diào)用的商店以至于你只能靠渲染該頁面（這會導致爬取慢很多）或者模仿API調(diào)用（導致要付出更多的開發(fā)努力）來獲得數(shù)據(jù)。

像這樣草率的代碼會導致編寫爬蟲非常痛苦，但也會使得可視化爬取工具或者自動析取不再可行。

在規(guī)模爬取的時候，你不僅要瀏覽成百上千個有著草率代碼的網(wǎng)站，還將被迫應對不斷演變的網(wǎng)站。一條好的經(jīng)驗法則是要預計你的目標網(wǎng)站每隔2到3個月就會發(fā)生讓你的爬蟲工作不了的變化。

這也許看起來不像是多大的事，但是當你規(guī)模抓取時，那些事件就會累積。比方說，Scrapinghub有一個規(guī)模比較大的電子商務項目大概有4000個爬蟲抽取約1000個電子商務網(wǎng)站，意味著每天可能會經(jīng)歷20到30次爬蟲失敗。

而且網(wǎng)站在不同地區(qū)、語言的變化，A/B測試以及包裝/定價的派生也會制造出各種問題導致爬蟲失敗。

沒有容易的解決方案

不幸的是，不存在銀彈可以徹底解決這些問題。很多時候這只是隨著規(guī)模而擴大投入更多資源到你的項目上才能解決的事情。再拿上一個例子來說吧，那個項目有18名全職的爬蟲工程師以及3名專職的QA工程師來確?？蛻艨偰艿玫娇煽康臄?shù)據(jù)流。

不過，你的團隊有經(jīng)驗以后就會學會如何開發(fā)出更加健壯的爬蟲，從而檢測并處置目標網(wǎng)站格式中的異常。

如何處理目標網(wǎng)站有各種布局可能的情況呢？用多個爬蟲也許不是最好的做法，我們的最佳實踐是只用一個產(chǎn)品爬蟲來處理不同頁面布局個各種可能規(guī)則和模式。你的爬蟲可配置性越強越好。

盡管這些實踐會讓你的爬蟲更加復雜（我們有些爬蟲有好幾千行），但它會確保你的爬蟲更容易維護。

由于大多數(shù)公司日常都需要析取產(chǎn)品數(shù)據(jù)，等待幾天讓你的工程團隊修復任何壞掉的爬蟲不是可選項。當出現(xiàn)這些情況時，Scrapinghub會利用自己開發(fā)的基于機器學習的數(shù)據(jù)析取工具來作為后備，直到爬蟲修復好。這個基于ML的析取工具會自動識別目標網(wǎng)站的目標字段（產(chǎn)品名稱、價格、貨幣單位、圖像、SKU等）并且返回想要的結(jié)果。

我們會在未來幾周之內(nèi)發(fā)布這項工具以及相關(guān)的指導文章，告訴大家如何將機器學習用到你的數(shù)據(jù)析取過程當中。

挑戰(zhàn) 2：可伸縮的架構(gòu)

你將面臨的第二個挑戰(zhàn)是建設一個可隨每日請求數(shù)增長而擴充且性能不會下降的爬蟲基礎設施。

在規(guī)模析取產(chǎn)品數(shù)據(jù)時，一個串行爬取的簡單web爬蟲是不堪此任的。通常一個串行的web爬蟲會循環(huán)發(fā)出請求，每一項請求都要2到3秒鐘完成。

如果你的爬蟲每天發(fā)出的請求數(shù)不到40000的話這種做法是沒有問題的。然而，超過這個點你就得過渡到一種讓你每天可以完成數(shù)百萬請求而不會性能下降的爬蟲架構(gòu)。

這個話題得用一篇文章才能說得清楚，未來幾周我們將發(fā)布一篇專門的文章來討論如何設計和開發(fā)高吞吐量的爬取架構(gòu)。然而，本節(jié)的剩余部分我們將討論一些高級原則和最佳實踐。

正如我們討論過那樣，在規(guī)模爬取產(chǎn)品數(shù)據(jù)時速度是關(guān)鍵。你需要確保在時間閾值范圍內(nèi)（通常是1天）可以找到并且爬取所有要求的產(chǎn)品頁面。為此你需要做以下一些事情：

將產(chǎn)品發(fā)現(xiàn)與產(chǎn)品析取分開

為了規(guī)模爬取產(chǎn)品數(shù)據(jù)你需要將你的產(chǎn)品發(fā)現(xiàn)爬蟲與產(chǎn)品析取爬蟲分開。

產(chǎn)品發(fā)現(xiàn)爬蟲的目標應該是讓它瀏覽目前產(chǎn)品目錄（或者“貨架”）然后存儲該目錄下的產(chǎn)品URL供產(chǎn)品析取爬蟲使用。

這個可以靠Scrapinghub 開發(fā)的開源工具Frontera之類的爬蟲前端輔助完成。盡管Frontera原先的目的是配合Scrapy使用的，但它其實完全是不可知論者，可用于任何爬蟲框架或者獨立項目。在這篇文章中，我們分享了如何利用Frontera來規(guī)模抓取HackerNews的東西。

分配更多資源給產(chǎn)品析取

由于每一個產(chǎn)品目錄“貨架”可包含10到100種產(chǎn)品，而且析取產(chǎn)品數(shù)據(jù)需要的資源要比析取產(chǎn)品URL更多，發(fā)現(xiàn)爬蟲通常運行要比產(chǎn)品析取爬蟲更快。這種情況下，你需要有多個析取爬蟲來對應每一個發(fā)現(xiàn)爬蟲。一條好的經(jīng)驗法則是每10萬個頁面分配一個析取爬蟲。

挑戰(zhàn) 3：維護吞吐量性能

一級方程式的目標是將車上一切不必要的載荷都剔除掉，并且以速度之名將引擎最后一絲馬力都榨干，從這個意義上來說規(guī)模抓取可以跟一級方程式相比較。規(guī)模web抓取也是一樣的道理。

在析取大量數(shù)據(jù)時，在現(xiàn)有硬件資源條件下，你總是會想方設法要尋找請求周期最小化爬蟲性能最大化的手段。這一切都是希望你能給每個請求節(jié)省下來那么幾微秒的時間。

為此你的團隊需要對web爬取框架、代理管理以及所使用的硬件具備深刻理解，這樣才能對它們進行調(diào)整以優(yōu)化性能。你還需要關(guān)注：

爬取效能

規(guī)模爬取時你應該始終把焦點放在以盡量少的請求析取所需數(shù)據(jù)上。任何額外請求或者數(shù)據(jù)析取都會放緩你爬取網(wǎng)站的節(jié)奏。在設計你的爬蟲時請記住這些提示：

• 作為最后一招，僅使用無界面瀏覽器，比如Splash或者Puppeteer來渲染JavaScript。用無界面瀏覽器渲染JavaScript同時爬取是非常耗資源的，會嚴重影響爬取的速度。
• 如果你可以從貨架頁面（比如產(chǎn)品名稱、價格、評分等）獲得所需的數(shù)據(jù)而不需要向獨立的產(chǎn)品頁面提出請求的話，那就不要向產(chǎn)品頁面發(fā)出請求。
• 不要請求或者析取圖像，除非迫不得已。

挑戰(zhàn) 4：反機器人的對策

如果你批量抓取電子商務網(wǎng)站的話一定會遇到采用反機器人對策的網(wǎng)站。

規(guī)模小一點的網(wǎng)站其反機器人對策就是些基本手段（屏蔽發(fā)送請求過量的IP）。然而，較大的電子商務網(wǎng)站，比如Amazon等，會采用復雜的反機器人對策，比如Distil Networks、Incapsula或者Akamai等來使得析取數(shù)據(jù)困難許多。

代理

了解到這一點之后，任何項目想要規(guī)模抓取才數(shù)據(jù)，首要的基本需求就是得用代理。規(guī)模抓取數(shù)據(jù)時你需要可觀的代理清單，而且需要實現(xiàn)必要的IP輪轉(zhuǎn)、請求限制、會話管理以及黑名單邏輯來預防代理被屏蔽。

或者除非你有或者愿意用一支規(guī)?？捎^的團隊管理你的代理，否則的話你應該把抓取流程中的這一部分外包出去。提供各種水平服務的代理服務有很多。

然而，我們的建議是找一家能夠提供單個代理配置端點并且將所有的代理管理復雜性隱藏起來的代理提供商。在沒有重新發(fā)明輪子、開發(fā)和維護自己的內(nèi)部代理管理基礎設施的情況下規(guī)模抓取就已經(jīng)很耗資源了。

大多數(shù)大型電子商務公司都采用這種做法。一些全球最大型的電子商務網(wǎng)站采用Scrapinghub 開發(fā)的智能下載器Crawlera，這個東西的代理管理完全是外包的。當你的爬蟲每天要發(fā)出2000萬條請求時，把注意力放在分析數(shù)據(jù)而不是管理代理上會有意義得多。

代理以外

不幸的是，光靠使用代理服務并不足以確保你能規(guī)避大型電子商務網(wǎng)站的反機器人對策。越來越多的網(wǎng)站正在利用復雜的反機器人對策來監(jiān)控你的爬蟲行為，檢測其是否真人訪客。

這些范機器人對策不僅使得爬取電子商務網(wǎng)站越來越困難，而且克服這些手段如果做得不對的話也會嚴重拖累爬蟲性能。

這些機器人對策有很大一部分使用到了JavaScript來確定請求是否來自于爬蟲還是人（Javascript引擎檢查、字體枚舉、WebGL與Canvas等）。

不過正如前面所述，規(guī)模爬取時你希望限制可編寫腳本的無界面瀏覽器（Splash 或者Puppeteer等）的使用，因為渲染頁面的任何JavaScript都非常耗資源并且放慢爬取網(wǎng)站的速度。

這意味著為了確保你能取得必要的吞吐量讓爬蟲提交每天的產(chǎn)品數(shù)據(jù)，你往往需要痛苦地對目標網(wǎng)站采用的反機器人對策進行逆向工程，并且在不使用無界面瀏覽器的情況下設計你的爬蟲抵消那些對策。

挑戰(zhàn) 5：數(shù)據(jù)質(zhì)量

從數(shù)據(jù)科學家的角度來說，任何網(wǎng)站爬取項目最重要的考慮是析取數(shù)據(jù)的質(zhì)量。規(guī)模爬取只會令這一關(guān)注變得更加重要。

當每天都要析取數(shù)百萬數(shù)據(jù)點時，想靠人工來驗證數(shù)據(jù)是否干凈和完整是不可能的。變臟或者不完整的數(shù)據(jù)很容易就會流入到你的數(shù)據(jù)流里面，進而破壞了數(shù)據(jù)分析的效果。

尤其是在抓取同一個的不同版本（不同的語言、地區(qū)等）或者不同商店上的產(chǎn)品時更是如此。

在爬蟲開發(fā)的設計階段，需要進行仔細的QA流程，爬蟲代碼要經(jīng)過同行評審和測試以確保用最可靠的方式析取到想要的數(shù)據(jù)。確保最高數(shù)據(jù)質(zhì)量的最好的辦法是部署一套自動化QA監(jiān)控系統(tǒng)。

作為任何數(shù)據(jù)析取項目的一部分，你需要計劃和開發(fā)一套監(jiān)控系統(tǒng)，這套系統(tǒng)將提醒你任何不一致的數(shù)據(jù)以及發(fā)生的爬蟲錯誤。Scrapinghub開發(fā)了一個機器學習算法來檢測：

• 數(shù)據(jù)驗證錯誤——每一個數(shù)據(jù)項都有定義好的遵循一致模式的數(shù)據(jù)類型和值。我們的數(shù)據(jù)驗證算法會提醒項目的QA團隊任何與預期數(shù)據(jù)類型不一致的數(shù)據(jù)項，然后再進行人工檢查、提醒已驗證或者標記為錯誤。
• 產(chǎn)品差異化錯誤——從同一網(wǎng)站的多個版本（不同語言、地區(qū)）爬取相同產(chǎn)品數(shù)據(jù)時，有可能變量或者像產(chǎn)品重量或者尺寸這樣本該是固定值的數(shù)據(jù)項也會不一樣。這可能是網(wǎng)站反機器人對策向你的一到多個爬蟲提供篡改信息的結(jié)果。再次地，你需要算法來識別和標記類似這樣的情況。
• 基于數(shù)量的不一致性——另一個關(guān)鍵的監(jiān)控腳本是檢測返回記錄的任何異常變化。這可能預示網(wǎng)站已經(jīng)做出改變或者你的爬蟲被提供了篡改的信息。
• 網(wǎng)站變化——目標網(wǎng)站發(fā)生的結(jié)構(gòu)性改變是爬蟲失效的主要原因。我們的專用監(jiān)控系統(tǒng)會監(jiān)控到這一點。該工具會對目標網(wǎng)站進行頻繁的檢查，確保自從上次抓取之后沒有發(fā)生任何變化。如果改變被發(fā)現(xiàn)，它也會發(fā)出通知。

我們會在稍后的文章中專門討論自動質(zhì)量保證的細節(jié)。

總結(jié)

正如你所看到那樣，規(guī)模抓取產(chǎn)品數(shù)據(jù)會面臨一系列的獨特挑戰(zhàn)。希望這篇文章能夠讓你更加意識到相關(guān)挑戰(zhàn)，并且就如何解決這些問題獲得啟發(fā)。

然而，這只是本系列文章的第一部分，所以如果你感興趣的話可以注冊我們的電子郵件列表，一旦下一篇文章發(fā)表了我們會第一時間通知你。

原文鏈接：https://blog.scrapinghub.com/web-scraping-at-scale-lessons-learned-scraping-100-billion-products-pages

譯者：boxi，由36氪編譯組出品。編輯：郝鵬程。

譯文地址：http://36kr.com/p/5143517.html

本文由 @郝鵬程 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自 Pexels，基于 CC0 協(xié)議