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

編者按：互聯網上有浩瀚的數據資源，要想抓取這些數據就離不開爬蟲。鑑於網上免費開源的爬蟲框架多如牛毛，不少人認爲爬蟲定是很是簡單的事情。可是若是你要按期上規模地準確抓取各類大型網站的數據倒是一項艱鉅的挑戰，其中包括網站的格式常常會變、架構必須能靈活伸縮應對規模變化同時要保持性能，與此同時還要挫敗網站反機器人的手段以及維護數據質量。流行的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團隊任何與預期數據類型不一致的數據項，而後再進行人工檢查、提醒已驗證或者標記爲錯誤。
• 產品差別化錯誤——從同一網站的多個版本（不一樣語言、地區）爬取相同產品數據時，有可能變量或者像產品重量或者尺寸這樣本該是固定值的數據項也會不同。這多是網站反機器人對策向你的一到多個爬蟲提供篡改信息的結果。再次地，你須要算法來識別和標記相似這樣的狀況。
• 基於數量的不一致性——另外一個關鍵的監控腳本是檢測返回記錄的任何異常變化。這可能預示網站已經作出改變或者你的爬蟲被提供了篡改的信息。
• 網站變化——目標網站發生的結構性改變是爬蟲失效的主要緣由。咱們的專用監控系統會監控到這一點。該工具會對目標網站進行頻繁的檢查，確保自從上次抓取以後沒有發生任何變化。若是改變被發現，它也會發出通知。

總結

正如你所看到那樣，規模抓取產品數據會面臨一系列的獨特挑戰。但願這篇文章可以讓你更加意識到相關挑戰，而且就如何解決這些問題得到啓發。

原文連接：https://baijiahao.baidu.com/s?id=1606482126832777393&wfr=spider&for=pc

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

好文章拿來讀一讀。編輯：不良將。