資料從業者必讀：抓取了一千億個網頁後我才明白，爬蟲一點都不簡單

大規模抓取資料會面臨很多挑戰

2

編者按：網際網路上有浩瀚的資料資源，要想抓取這些資料就離不開爬蟲。鑑於網上免費開源的爬蟲框架多如牛毛，很多人認為爬蟲定是非常簡單的事情。但是如果你要定期上規模地準確抓取各種大型網站的資料卻是一項艱鉅的挑戰，其中包括網站的格式經常會變、架構必須能靈活伸縮應對規模變化同時要保持效能，與此同時還要挫敗網站反機器人的手段以及維護資料質量。流行的Python爬蟲框架Scrapy開發者Scrapinghub分享了他們抓取一千億個網頁後的經驗之談。

現在爬蟲技術似乎是很容易的事情，但這種看法是很有迷惑性的。開源的庫/框架、視覺化的爬蟲工具以及資料析取工具有很多，從網站抓取資料似乎易如反掌。然而，當你成規模地在網站上抓東西時，事情很快就會變得非常棘手。

自2010年以來抓取超過1000億個產品頁面，我們將會通過系列文章來分享從中學到的經驗教訓，讓你深入瞭解從電子商務商店中規模析取資料時所面臨的挑戰，並且跟你分享應對這些挑戰的某些最佳實踐。

本文是該系列文章的第一篇，在這裡我們將提供規模抓取產品資料所面臨主要挑戰的概覽，以及Scrapinghub從抓取1000億產品頁面中學到的經驗教訓。

成立於2010年的Scrapinghub是領先的資料析取公司之一，也是當今最健壯和流行的web爬蟲框架Scrapy的作者。目前Scrapinghub每月抓取許多全球最大型電子商務公司的頁面數超過80億（其中30億是產品頁面）。

對於那些對規模爬取網頁技術感興趣但對要不要建立專門的web爬取團隊或者外包給專門的web爬取公司的人來說，最好看看這個免費指南，企業web爬蟲：規模化web爬取技術指南

跟標準的web爬取應用不一樣的是，規模爬取電子商務產品資料有一項獨特挑戰使得web抓取要困難許多。

本質上這些挑戰可歸結為兩件事情：速度和資料質量。

由於時間通常是限制因素，規模抓取要求你的爬蟲要以很高的速度抓取網頁但又不能拖累資料質量。對速度的這張要求使得爬取大規模產品資料變得極具挑戰性。

 挑戰#1——草率而且總是在變的網站格式 

這一點很明顯但也許不是最性感的挑戰，但是草率而一直在變的網站格式是目前為止你在規模析取資料時將會面臨的最大挑戰。這未必是因為任務的複雜性，而是由於你要投入的時間和資源。

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

    停掉產品時移除頁面的商店在網站升級後突然間會在404錯誤處理程式返回200響應碼。

    不恰當的JSON轉義破壞了部分頁面的JavaScript程式碼（比如‘b0rk’d’），導致你需要用正規表示式來抓取那部分資料。

    濫用Ajax呼叫的商店以至於你只能靠渲染該頁面（這會導致爬取慢很多）或者模仿API呼叫（導致要付出更多的開發努力）來獲得資料。

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

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

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

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

不幸的是，不存在銀彈可以徹底解決這些問題。很多時候這只是隨著規模而擴大投入更多資源到你的專案上才能解決的事情。再拿上一個例子來說吧，那個專案有18名全職的爬蟲工程師以及3名專職的QA工程師來確保客戶總能得到可靠的資料流。

不過，你的團隊有經驗以後就會學會如何開發出更加健壯的爬蟲，從而檢測並處置目標網站格式中的異常。

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

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

由於大多數公司日常都需要析取產品資料，等待幾天讓你的工程團隊修復任何壞掉的爬蟲不是可選項。當出現這些情況時，Scrapinghub會利用自己開發的基於機器學習的資料析取工具來作為後備，直到爬蟲修復好。這個基於ML的析取工具會自動識別目標網站的目標欄位（產品名稱、價格、貨幣單位、影象、SKU等）並且返回想要的結果。

我們會在未來幾周之內釋出這項工具以及相關的指導文章，告訴大家如何將機器學習用到你的資料析取過程當中。

 挑戰 2：可伸縮的架構 

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

在規模析取產品資料時，一個序列爬取的簡單web爬蟲是不堪此任的。通常一個序列的web爬蟲會迴圈發出請求，每一項請求都要2到3秒鐘完成。

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

這個話題得用一篇文章才能說得清楚，未來幾周我們將釋出一篇專門的文章來討論如何設計和開發高吞吐量的爬取架構。然而，本節的剩餘部分我們將討論一些高階原則和最佳實踐。

正如我們討論過那樣，在規模爬取產品資料時速度是關鍵。你需要確保在時間閾值範圍內（通常是1天）可以找到並且爬取所有要求的產品頁面。為此你需要做以下一些事情：

為了規模爬取產品資料你需要將你的產品發現爬蟲與產品析取爬蟲分開。

產品發現爬蟲的目標應該是讓它瀏覽目前產品目錄（或者“貨架”）然後儲存該目錄下的產品URL供產品析取爬蟲使用。

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

由於每一個產品目錄“貨架”可包含10到100種產品，而且析取產品資料需要的資源要比析取產品URL更多，發現爬蟲通常執行要比產品析取爬蟲更快。這種情況下，你需要有多個析取爬蟲來對應每一個發現爬蟲。一條好的經驗法則是每10萬個頁面分配一個析取爬蟲。

 挑戰 3：維護吞吐量效能 

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

在析取大量資料時，在現有硬體資源條件下，你總是會想方設法要尋找請求週期最小化爬蟲效能最大化的手段。這一切都是希望你能給每個請求節省下來那麼幾微秒的時間。

為此你的團隊需要對web爬取框架、代理管理以及所使用的硬體具備深刻理解，這樣才能對它們進行調整以優化效能。你還需要關注：

規模爬取時你應該始終把焦點放在以儘量少的請求析取所需資料上。任何額外請求或者資料析取都會放緩你爬取網站的節奏。在設計你的爬蟲時請記住這些提示：

    作為最後一招，僅使用無介面瀏覽器，比如Splash或者Puppeteer來渲染JavaScript。用無介面瀏覽器渲染JavaScript同時爬取是非常耗資源的，會嚴重影響爬取的速度。

    如果你可以從貨架頁面（比如產品名稱、價格、評分等）獲得所需的資料而不需要向獨立的產品頁面提出請求的話，那就不要向產品頁面發出請求。

    不要請求或者析取影象，除非迫不得已。

 挑戰 4：反機器人的對策 

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

規模小一點的網站其反機器人對策就是些基本手段（遮蔽傳送請求過量的IP）。然而，較大的電子商務網站，比如Amazon等，會採用複雜的反機器人對策，比如Distil Networks、Incapsula或者Akamai等來使得析取資料困難許多。

瞭解到這一點之後，任何專案想要規模抓取才資料，首要的基本需求就是得用代理。規模抓取資料時你需要可觀的代理清單，而且需要實現必要的IP輪轉、請求限制、會話管理以及黑名單邏輯來預防代理被遮蔽。

或者除非你有或者願意用一支規模可觀的團隊管理你的代理，否則的話你應該把抓取流程中的這一部分外包出去。提供各種水平服務的代理服務有很多。

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

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

不幸的是，光靠使用代理服務並不足以確保你能規避大型電子商務網站的反機器人對策。越來越多的網站正在利用複雜的反機器人對策來監控你的爬蟲行為，檢測其是否真人訪客。

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

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

不過正如前面所述，規模爬取時你希望限制可編寫指令碼的無介面瀏覽器（Splash 或者Puppeteer等）的使用，因為渲染頁面的任何JavaScript都非常耗資源並且放慢爬取網站的速度。

這意味著為了確保你能取得必要的吞吐量讓爬蟲提交每天的產品資料，你往往需要痛苦地對目標網站採用的反機器人對策進行逆向工程，並且在不使用無介面瀏覽器的情況下設計你的爬蟲抵消那些對策。

 挑戰 5：資料質量 

從資料科學家的角度來說，任何網站爬取專案最重要的考慮是析取資料的質量。規模爬取只會令這一關注變得更加重要。

當每天都要析取數百萬資料點時，想靠人工來驗證資料是否乾淨和完整是不可能的。變髒或者不完整的資料很容易就會流入到你的資料流裡面，進而破壞了資料分析的效果。

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

在爬蟲開發的設計階段，需要進行仔細的QA流程，爬蟲程式碼要經過同行評審和測試以確保用最可靠的方式析取到想要的資料。確保最高資料質量的最好的辦法是部署一套自動化QA監控系統。

作為任何資料析取專案的一部分，你需要計劃和開發一套監控系統，這套系統將提醒你任何不一致的資料以及發生的爬蟲錯誤。Scrapinghub開發了一個機器學習演算法來檢測：

資料驗證錯誤——每一個資料項都有定義好的遵循一致模式的資料型別和值。我們的資料驗證演算法會提醒專案的QA團隊任何與預期資料型別不一致的資料項，然後再進行人工檢查、提醒已驗證或者標記為錯誤。

產品差異化錯誤——從同一網站的多個版本（不同語言、地區）爬取相同產品資料時，有可能變數或者像產品重量或者尺寸這樣本該是固定值的資料項也會不一樣。這可能是網站反機器人對策向你的一到多個爬蟲提供篡改資訊的結果。再次地，你需要演算法來識別和標記類似這樣的情況。

基於數量的不一致性——另一個關鍵的監控指令碼是檢測返回記錄的任何異常變化。這可能預示網站已經做出改變或者你的爬蟲被提供了篡改的資訊。

網站變化——目標網站發生的結構性改變是爬蟲失效的主要原因。我們的專用監控系統會監控到這一點。該工具會對目標網站進行頻繁的檢查，確保自從上次抓取之後沒有發生任何變化。如果改變被發現，它也會發出通知。

我們會在稍後的文章中專門討論自動質量保證的細節。

正如你所看到那樣，規模抓取產品資料會面臨一系列的獨特挑戰。希望這篇文章能夠讓你更加意識到相關挑戰，並且就如何解決這些問題獲得啟發。

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

∑編輯 | Gemini

來源 | 技能get

演算法數學之美微信公眾號歡迎賜稿

稿件涉及數學、物理、演算法、計算機、程式設計等相關領域，經採用我們將奉上稿酬。

投稿郵箱：math_alg@163.com