2015年4月12日 星期日

[心得] 網路爬蟲專案規劃策略

先前花了一些篇幅在介紹網路爬蟲的使用方式,都是比較偏重技術面的討論,但是爬蟲本身在理解原理後並不難實作,下一個階段就是如何規劃一個完整的爬蟲專案,這反而是比較需要討論以及有挑戰性的部分.過去的爬網專案都以中小型(監測的網站約50個以下,頻率頂一個小時一次)居多,以這樣的規模來討論在規劃上可能要注意哪些事情.
以下將從幾個角度來討論規劃的方向(這些角度之間的考量也會受到彼此的影響):
  1. 爬蟲目的與應用
  2. 爬蟲設計策略(包括反爬蟲,結果監測,平行化)
  3. 資料流策略(包括資料庫規劃與例行維運)
  • 爬蟲目的與應用:目的與應用導向的專案才能有效的收斂各個策略考量,所以在進行專案之前,應該要先花最多時間討論此次爬網的目的.一般來說,爬蟲的目的不外乎是:
    • 監控特定網站資訊
    • 廣泛搜集特定主題資訊
    • 製作搜尋引擎

  • 根據不同的目的,需要進一步考量:
    • 要爬的網站是特定網站特定版位;還是根據特定的條件廣泛地爬取(不限定網站)
    • 爬蟲走尋需要多久頻率更新一次,每5分鐘?一小時?每天?
    • 爬回來的資料儲存哪些資訊?可能只需要儲存少部分欄位,或是全部網頁結果存取.

  • 根據專案的目的與考量,來規劃第一支爬蟲,通常第一支爬蟲不會遇到太大的問題(爬蟲本身的技術細節也不是本篇文章在意的事情),問題通常會發生在當你開始真正運行後:
    • 如果是個高頻次的爬蟲(或是大量針對某網站資訊爬取的爬蟲),可能馬上就會發現你的爬蟲沒辦法運行的如你想像中有效,可能突然進來一堆404的網頁,收到奇怪的警告訊息,甚至原本可以爬的網站突然不能爬了,這表示你的爬蟲可能被對方系統抓到,把你的蟲導到其他錯誤資料的伺服器,甚至是ban掉了(一些網路商城網站都會運用爬蟲來爬取競爭對手的資料,同時也要避免自己被爬,但是同時也會適度的開放一些爬蟲來抓自己的資料回去).一些很基本的反爬技術像是隨機讀取時間,使用跳板伺服器,都可以多少增加自己存活的機率(但是永遠沒有保證有效的反爬策略).
    • 如果是個需要例行運行的爬蟲,就要嚴肅考慮到網站改版的情況了.我們通常使用網站節點來解析網頁資料,但是不管怎樣設計,節點就是個脆弱的指標,只要改個class name,就會造成parsing失敗.我們不能只靠祈禱對方網站不改版,只能靠自己設計檢核機制來確保欄位的正確性,以及在資料錯誤時能及早知道及早補救.
    • 如果你手上監測不同網站的爬蟲超過100個,那可能就需要仔細規劃你的網路和硬體了.這100個爬蟲如果需要同時出去搜集資料,那必須將爬蟲平行化讓他們能夠同時間運作.當你打算讓100個爬蟲平行化,就要考量到這100個爬蟲會不會卡在你的對外網路上.所以不單是執行緒的平行化,也要考慮網路本身是不是也需要平行化處理(最快的方法就是多用幾台爬網的伺服器).不過我還沒做過需要那麼即時的爬網專案,而且爬網吃的網路流量相對要小.

  • 當爬蟲順利的將資料帶回來,就要考量後續的資料存放問題.資料通常不太可能只要老實地躺在硬碟裡就好,根據之後的應用,需要轉換成不同的方式存放.比較常見的做法就是導到NOSQL資料庫(因為網路資料多半是非結構化資料),但是近期一些關聯式資料也開始支援Json的格式(像postgreSQL甚至Teradata),考量到資料單一位置存放的方便性,也可以將資料存在既有的資料庫系統中.
    • 如果你想把檔案存在Hadoop,就要考量到Hadoop架構不太適合存放多個小檔案,可能要先將爬蟲資料累積到一定量後再存進去.
    • 維運上另外要考量當系統如果當掉該怎麼辦?你的專案能夠承受多長的當機時間?很多網路資料是時間過了就不一樣了(例如社群網站資料),少那幾個小時的資料對使用上有沒有差異.如果能接受的當機時間短,就要規劃另外的備援機制,當主要的爬蟲伺服器掛點的時候,可以馬上啟動備援方案.



沒有留言:

張貼留言