随着big data大資料概念逐漸升溫，如何搭建一個能夠采集海量資料的架構體系擺在大家眼前。如何能夠做到所見即所得的無阻攔式采集、如何快速把不規則頁面結構化并存儲、如何滿足越來越多的資料采集還要在有限時間内采集。這篇文章結合我們自身項目經驗談一下。
<a target="_blank"></a>
我們來看一下作為人是怎麼擷取網頁資料的呢？
1、打開浏覽器，輸入網址url通路頁面内容。
2、複制頁面内容的标題、作者、内容。
3、存儲到文本檔案或者excel。
從技術角度來說整個過程主要為 網絡通路、扣取結構化資料、存儲。我們看一下用java程式如何來實作這一過程。
通過這個例子，我們看到通過httpclient擷取資料，通過字元串操作扣取标題内容，然後通過system.out輸出内容。大家是不是感覺做一個爬蟲也還是蠻簡單呢。這是一個基本的入門例子，我們再詳細介紹怎麼一步一步建構一個分布式的适用于海量資料采集的爬蟲架構。
整個架構應該包含以下部分：資源管理、反監控管理、抓取管理、監控管理。
看一下整個架構的架構圖：
社會化海量資料抓取元件圖
資源管理指網站分類體系、網站、網站通路url等基本資源的管理維護；
反監控管理指被通路網站（特别是社會化媒體）會禁止爬蟲通路，怎麼讓他們不能監控到我們的通路時爬蟲軟體，這就是反監控機制了；
一個好的采集架構，不管我們的目标資料在哪兒，隻要使用者能夠看到都應該能采集到。所見即所得的無阻攔式采集，無論是否需要登入的資料都能夠順利采集。
現在大部分社交網站都需要登入，為了應對登入的網站要有模拟使用者登入的爬蟲系統，才能正常擷取資料。不過社會化網站都希望自己形成一個閉環，不願意把資料放到站外，這種系統也不會像新聞等内容那麼開放的讓人擷取。這些社會化網站大部分會采取一些限制防止機器人爬蟲系統爬取資料，一般一個賬号爬取不了多久就會被檢測出來被禁止通路了。
那是不是我們就不能爬取這些網站的資料呢？肯定不是這樣的，隻要社會化網站不關閉網頁通路，正常人能夠通路的資料，我們也能通路。說到底就是模拟人的正常行為操作，專業一點叫“反監控”。
那一般網站會有什麼限制呢？
一定時間内單ip通路次數。沒有哪個人會在一段持續時間内過快通路，除非是随意的點着玩，持續時間也不會太長。可以采用大量不規則代理ip來模拟。
一定時間内單賬号通路次數。這個同上，正常人不會這麼操作。可以采用大量行為正常的賬号，行為正常就是普通人怎麼在社交網站上操作，如果一個人一天24小時都在通路一個資料接口那就有可能是機器人了。
如果能把賬号和ip的通路政策控制好了，基本可以解決這個問題了。當然對方網站也會有運維會調整政策，說到底這是一個戰争，躲在電腦螢幕後的敵我雙方，爬蟲必須要能感覺到對方的反監控政策進行了調整，通知管理者及時處理。未來比較理想應該是通過機器學習算法自動完成政策調整，保證抓取不間斷。
抓取管理指通過url，結合資源、反監控抓取資料并存儲；我們現在大部分爬蟲系統，很多都需要自己設定正規表達式，或者使用htmlparser、jsoup等軟體來寫死解決結構化抓取的問題。
不過大家在做爬蟲也會發現，如果爬取一個網站就去開發一個類，在規模小的時候還可以接受，如果需要抓取的網站成千上萬，那我們不是要開發成百上千的類。
為此我們開發了一個通用的抓取類，可以通過參數驅動内部邏輯排程。比如我們在參數裡指定抓取新浪微網誌，抓取機器就會排程新浪微網誌網頁扣取規則抓取節點資料，調用存儲規則存儲資料，不管什麼類型最後都調用同一個類來處理。對于我們使用者隻需要設定抓取規則，相應的後續處理就交給抓取平台了。
整個抓取使用了 xpath、正規表達式、消息中間件、多線程排程架構（參考）。
正規表達式補充xpath抓取不到的資料，還可以過濾一些特殊字元。
消息中間件，起到抓取任務中間轉發的目的，避免抓取和各個需求方耦合。比如各個業務系統都可能抓取資料，隻需要向消息中間件發送一個抓取指令，抓取平台抓完了會傳回一條消息給消息中間件，業務系統在從消息中間件收到消息回報，整個抓取完成。
不管怎麼模拟總還是會有異常的，這就需要有個異常處理子產品，有些網站通路一段時間需要輸入驗證碼，如果不處理後續永遠傳回不了正确資料。我們需要有機制能夠處理像驗證碼這類異常，簡單就是有驗證碼了人為去輸入，進階一些可以破解驗證碼識别算法實作自動輸入驗證碼的目的。
所見即所得我們是不是真的做到？規則配置也是個重複的大任務？重複網頁如何不抓取？
1、有些網站利用js生成網頁内容，直接檢視源代碼是一堆js。
可以使用mozilla、webkit等可以解析浏覽器的工具包解析js、ajax，不過速度會有點慢。
2、網頁裡有一些css隐藏的文字。
使用工具包把css隐藏文字去掉。
3、圖檔flash資訊。
如果是圖檔中文字識别，這個比較好處理，能夠使用ocr識别文字就行，如果是flash目前隻能存儲整個url。
4、一個url有多個網頁結構。
如果隻有一套抓取規則肯定不行的，需要多個規則配合抓取。
5、html不完整，不完整就不能按照正常模式去扣取。
這個時候用xpath肯定解析不了，我們可以先用htmlcleaner清洗網頁後再解析。
6、 如果網站多起來，規則配置這個工作量也會非常大。
如何幫助系統快速生成規則呢？首先可以配置規則可以通過可視化配置，比如使用者在看到的網頁想對它抓取資料，隻需要拉開插件點選需要的地方，規則就自動生成好了。另在量比較大的時候可視化還是不夠的，可以先将類型相同的網站歸類，再通過抓取的一些内容聚類，可以統計學、可視化抓取把内容扣取出幾個版本給使用者去糾正，最後确認的規則就是新網站的規則。這些算法後續再講。
這塊再補充一下（多謝zicjin建議）：
背景：如果我們需要抓取的網站很多，那如果靠可視化配置需要耗費大量的人力，這是個成本。并且這個交給不懂html的業務去配置準确性值得考量，是以最後還是需要技術做很多事情。那我們能否通過技術手段可以幫助生成規則減少人力成本，或者幫助不懂技術的業務準确的把資料扣取下來并大量複制。
方案：先對網站分類，比如分為新聞、論壇、視訊等，這一類網站的網頁結構是類似的。在業務打開需要扣取的還沒有錄入我們規則庫的網頁時，他先設定這個頁面的分類（當然這個也可以機器預先判斷，他們來選擇，這一步必須要人判斷下），有了分類後，我們會通過“統計學、可視化判斷”識别這一分類的字段規則，但是這個是機器識别的規則，可能不準确，機器識别完後，還需要人在判斷一下。判斷完成後，最後形成規則才是新網站的規則
7、對付重複的網頁。
如果重複抓取會浪費資源，如果不抓需要一個海量的去重判斷緩存。判斷抓不抓，抓了後存不存，并且這個緩存需要快速讀寫。常見的做法有bloomfilter、相似度聚合、分類海明距離判斷。
監控管理指不管什麼系統都可能出問題，如果對方伺服器當機、網頁改版、更換位址等我們需要第一時間知道，這時監控系統就起到出現了問題及時發現并通知聯系人。
目前這樣的架構搭建起來基本可以解決大量的抓取需求了。通過界面可以管理資源、反監控規則、網頁扣取規則、消息中間件狀态、資料監控圖表，并且可以通過背景調整資源配置設定并能動态更新保證抓取不斷電。
不過如果一個任務的處理特别大，可能需要抓取24個小時或者幾天。比如我們要抓取一條微網誌的轉發，這個轉發是30w，那如果每頁線性去抓取耗時肯定是非常慢了，如果能把這30w拆分很多小任務，那我們的并行計算能力就會提高很多。不得不提的就是把大型的抓取任務hadoop化，廢話不說直接上圖：
今天先寫到這裡，後續再介紹下 日均千萬大型采集項目實戰。
原文釋出時間為：2013-09-03
本文來自雲栖社群合作夥伴“linux中國”