咱們從爬取1000億個網頁中學到了什麼？

策劃編輯 | Natalie

編譯 | 無明

編輯 | Vincent

AI 前線導讀：現現在，爬取網頁看起來彷佛是一件很簡單的事。有不少開源框架或庫、可視化爬取工具和數據提取工具，利用這些工具能夠很容易地從網站上爬取數據。可是，當你想大規模爬取網站時，事情就變得棘手起來。其中包括應對不斷變化的網站格式、構建可伸縮的爬蟲基礎框架並保持吞吐量，與此同時還要挫敗網站反機器人的手段以及維護數據質量。在這篇文章中，流行 Python 爬蟲框架 Scrapy 開發者 Scrapinghub 分享了大規模爬取產品數據時將面臨的主要挑戰，以及他們爬取 1000 億個網頁後的經驗之談。

更多幹貨內容請關注微信公衆號「AI 前線」，（ID：ai-front）

Scrapinghub 成立於 2010 年，是一家領先的數據公司，當今最強大、最受歡迎的網絡爬取框架 Scrapy 就是由它開發的。目前，Scrapinghub 每月爲全球不少大型的電子商務公司爬取 80 億個網頁（其中有 30 億個是產品頁面）。

在進行大規模爬取時哪些東西是最重要的？

與標準的爬蟲應用程序不一樣，大規模爬取電子商務產品數據須要面臨一系列獨特的挑戰，這些挑戰讓爬取網頁變得更加困難。

這些挑戰能夠被歸結爲兩類：速度和數據質量。

由於時間一般是一個限制性的約束條件，因此在進行大規模爬取時要求爬蟲以很是快的速度進行爬取，同時又不影響數據質量。這種對速度的極限要求使得爬取大量產品數據變得極具挑戰性。

挑戰之一：凌亂的代碼和不斷變化的網頁格式

很顯然，凌亂的代碼和不斷變化的網頁格式是在大規模爬取數據時將面臨的最大挑戰。不必定是由於任務的複雜性，而是你要在這上面所花費的時間和資源。

若是你作過網店的爬蟲，就會知道，在網店的網頁中，凌亂的代碼氾濫成災。除了 HTML 格式問題或偶爾出現的字符編碼問題以外，還有其餘不少問題。多年來，咱們遇到了各類各樣的問題——濫用 HTTP 響應碼、糟糕的 JavaScripts 或濫用 Ajax：

• 網店在中止銷售某些產品時會刪除相應的產品頁面，但在網站升級後，404 錯誤處理程序卻返回了 200 響應碼。

• 錯誤地轉義了 JSON 數據，致使某些頁面上的 JavaScript 代碼沒法正常運行（例如’b0rk'd'），你不得不使用正則表達式來爬取數據。

• 濫用 Ajax，以致於你只能在渲染頁面（致使爬取變慢）或模擬 API 調用（致使更多的開發工做量）後才能抓取到你想要的信息。

這些凌亂的代碼不只是你開發爬蟲時的痛點，也會影響到那些可視化爬蟲工具或自動爬取工具。

在進行大規模爬取時，除了要應對這些凌亂的代碼，還要面臨網站不斷髮生變化所帶來的挑戰。根據常規經驗，目標網站通常每過 2-3 個月就會修改一次，你的爬蟲就會出問題（致使爬取覆蓋率或質量降低）。

這聽起來可能沒什麼大不了的，但在進行大規模爬取時，這些問題聚沙成塔，就會帶來大麻煩。Scrapinghub 的一個大型電子商務項目使用約 4,000 個爬蟲爬取約 1,000 個電子商務網站，這意味着他們天天會遇到 20-30 個爬蟲失敗。

不一樣區域和多語言網站的網頁佈局的變化、A/B 測試、產品套件和訂價的變化也給爬蟲帶來了更多難題。

沒有簡單的解決方案

對於這些問題，並無什麼萬能的靈丹妙藥。不少時候，在擴大規模時往項目中增長更多的資源。以上一個項目爲例，該項目的團隊由 18 名全職爬蟲工程師和 3 名專職 QA 工程師組成，以確保可以源源不斷地向客戶始提供數據。

可是，從經驗來看，你的團隊仍然要學會如何開發更強大的爬蟲，用它們來檢測和處理各類詭異的網頁格式。

最好是隻開發一個能夠處理不一樣頁面佈局的爬蟲，而不是爲不一樣的頁面佈局開發多個爬蟲，爬蟲的可配置下越高越好。

雖然這樣會讓你的爬蟲變複雜（咱們的一些爬蟲代碼長達數千行），但也更容易維護。

大多數公司天天都須要爬取產品數據，由於工程團隊要修復爬蟲問題而不得不等上幾天，這可不是個好主意。在出現這種狀況時，Scrapinghub 使用基於機器學習的數據提取工具。這種基於 ML 的提取工具可自動識別目標網站上的目標字段（產品名稱、價格、貨幣類型、圖像、SKU 等）並返回所需的結果。

挑戰之二：可伸縮架構

第二個挑戰是構建一個可伸縮的爬蟲基礎架構，能夠隨着請求數量的增長而伸縮，而不會影響到性能。

在大規模爬取產品數據時，一個只能串行化爬取數據的簡單網絡爬蟲是不夠的。一般，串行化的爬蟲在一個循環中一個接一個地發出請求，每一個請求須要 2-3 秒才能完成。

若是你的爬蟲天天發出的請求少於 40,000 個（每 2 秒請求一次至關於天天 43,200 個請求），那麼使用這種方法就足夠了。可是，在此以後，你須要轉換到一種爬蟲架構，這樣才能天天爬取數百萬個網頁，而不會下降性能。

爬取速度是大規模爬取產品數據的關鍵。你要確保可以在給定的時間內（一般爲一天）找到並爬取全部必需的產品頁面。爲此，你須要執行如下操做：

實現產品發現和產品抓取的分離

要大規模爬取產品數據，須要將產品發現爬蟲與產品抓取爬蟲分開。

用於產品發現的爬蟲主要負責導航到目標產品類別（或「貨架」），併爲產品提取爬蟲保存該類別下的產品 URL。在產品發現爬蟲將產品 URL 添加到隊列後，產品抓取爬蟲會從該產品頁面爬取目標數據。

Scrapinghub 爲此開發了 Frontera（https://github.com/scrapinghub/frontera），並將其開源，雖然 Frontera 最初被設計與 Scrapy 一塊兒使用，但也能夠與其餘爬蟲框架或獨立項目一塊兒使用。在這篇文章（https://blog.scrapinghub.com/2015/04/22/frontera-the-brain-behind-the-crawls/）中，咱們分享瞭如何使用 Frontera 大規模爬取 HackerNews。

爲產品爬取分配更多資源

每一個產品類別可能包含 10 到 100 個產品，而且爬取產品數據比爬取產品 URL 更耗費資源，所以產品發現爬蟲一般比產品抓取爬蟲運行得更快。因此，你須要爲每一個發現爬蟲配備多個抓取爬蟲。根據經驗，大約每 100,000 個網頁須要配備一個單獨的抓取爬蟲。

挑戰之三：保持吞吐量

大規模爬取能夠比做一級方程式賽車，你的終極目標是從車上卸掉每一克沒必要要的重量，並以速度的名義榨取發動機最後那一點馬力。大規模網頁爬取也是如此。

在爬取大量數據時，你始終在尋找最小化請求週期時間的方法，並最大限度地提升爬蟲性能，全部這些都是爲了能爲每一個請求減小几毫秒的時間。

你的團隊須要深刻了解正在使用的爬蟲框架、代理和硬件，才能調整它們以得到最佳性能。除此以外，還須要關注：

爬取效率

在進行大規模爬取時，應該儘量只爬取必要的數據。額外的請求或數據抓取都會下降爬取網站的速度。在設計爬蟲時，請記住如下幾點：

• 只在逼不得已的狀況下才使用 headless 瀏覽器（如 Splash 或 Puppeteer）來解析 JavaScript，由於使用 headless 瀏覽器解析 JavaScript 至關耗費資源，會嚴重影響爬取的速度。

• 若是能夠從產品頁面（如產品名稱、價格、評級等）獲取所需數據而無需請求每一個產品頁面，那麼就不要請求產品頁面。

• 除非真的須要，不然不要請求或抓取圖像。

挑戰之四：反機器人措施

若是你正在大規模爬取電子商務網站，確定會碰到使用反機器人措施的網站。

大多數小型網站使用基本的反機器人措施（好比禁掉頻繁訪問的 IP 地址）。而像亞馬遜這樣大型的電子商務網站會使用像 Distil Networks、Incapsula 或 Akamai 這些複雜的反機器人措施，這讓爬取數據變得更加困難。

代理

所以，在進行大規模產品數據爬取時，首先須要考慮使用代理。你須要大量的代理，而且須要實現 IP 輪換、請求限制、會話管理和黑名單邏輯，防止代理被禁。

除非你已經或者願意養一個龐大的團隊來管理代理，不然應該將這部分爬取過程外包出去。如今有大量的代理服務，他們提供了不一樣級別的服務。

咱們的建議是與代理提供商合做，代理提供商能夠爲代理配置提供單個端點，並隱藏管理代理的複雜性。大規模爬取很是耗費資源，因此不該該本身重複發明輪子，好比開發和維護本身的內部代理管理基礎設施。

代理以外

不過，僅僅使用代理服務還不足以確保你能夠在大型的電子商務網站上規避反機器人措施，愈來愈多的網站正在使用複雜的反機器人措施來監控你的爬蟲。

這些反機器人措施不只會讓爬取電子商務網站變得更加困難，若是處理很差，會嚴重影響爬取工具的性能。

在這些反機器人措施中，有很大一部分使用 JavaScript 來判別請求是來自爬蟲仍是人類（JavaScript 引擎檢查、字體枚舉、WebGL 和 Canvas 等）。

不過以前已經提到，在進行大規模爬取時，要儘可能限制使用 headless 瀏覽器（如 Splash 或 Puppeteer）來解析 JavaScript，由於它們很是耗費資源，而且會下降爬取網頁的速度。

所以，爲了確保爬蟲的吞吐量，以便天天提供必要的產品數據，你一般須要精心對網站的反機器人措施進行反向工程，在不使用 headless 瀏覽器的狀況下讓你的爬蟲搞定一切。

挑戰之五：數據質量

從數據科學家的角度來看，爬蟲項目最重要的考慮因素是所提取數據的質量，而大規模爬取只會讓對數據質量的關注變得更加劇要。

天天提取數百萬個數據點，就沒法手動驗證全部數據是否乾淨且無缺無損。髒數據或不完整的數據很容易進入到你的數據源並破壞你的數據分析工做。

在爬取同一網站（不一樣語言，地區等）或不一樣網站相同產品的多個版本時，尤爲須要考慮數據質量問題。

在爬蟲的設計階段，須要進行嚴格的 QA 過程，爬蟲的代碼須要通過嚴格的評審和測試，確保能夠以最可靠的方式提取所需的數據。確保高質量數據的最佳方法是開發自動化 QA 監控系統。

做爲數據爬取項目的一部分，須要規劃和開發一個監控系統，在發現數據不一致或發生錯誤時能夠發出告警。在 Scrapinghub，咱們開發了機器學習算法，用於檢測：

• 數據驗證錯誤——每一個數據項都有定義好的數據類型，它們的值都遵循一致的模式。咱們的數據驗證算法能夠標記出與數據類型的預期不一致的數據項，QA 團隊將手動檢查這些數據，併發出告警或將其標記爲錯誤。

• 產品差別錯誤——從同一網站的多個版本（不一樣語言、地區等）爬取相同的產品數據時，一些變量（如產品重量或尺寸）可能會有不一樣的值。這多是網站的反機器人措施爲爬蟲提供的僞造信息。一樣，你須要有適當的算法來識別和標記此類數據。

• 數據量不一致性——另外一個關鍵的監控動做是檢測異常的返回數據量。若是出現異常，多是由於網站已經發生了變動，或者網站向你的爬取工具提供了僞造信息。

• 網站變動——目標網站發生的結構性變動是致使爬取工具崩潰的主要緣由。咱們的專用監控系統對此進行監控，它會頻繁地檢查目標網站，確保自上次爬取以來沒有發生任何變動。若是發生變動，它會發送通知。

總 結

本文介紹了在進行大規模爬取產品數據時須要面對的一系列獨特的挑戰。對於那些有興趣瞭解大規模網站爬取的人，能夠進一步參閱 Enterprise Web Scraping: A Guide to Scraping the Web at Scale（https://info.scrapinghub.com/enterprise-web-scraping-scraping-at-scale）。

英文原文：

https://blog.scrapinghub.com/web-scraping-at-scale-lessons-learned-scraping-100-billion-products-pages