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

先前花了一些篇幅在介紹網路爬蟲的使用方式，都是比較偏重技術面的討論，但是爬蟲本身在理解原理後並不難實作，下一個階段就是如何規劃一個完整的爬蟲專案，這反而是比較需要討論以及有挑戰性的部分．過去的爬網專案都以中小型（監測的網站約50個以下，頻率頂一個小時一次）居多，以這樣的規模來討論在規劃上可能要注意哪些事情．
以下將從幾個角度來討論規劃的方向（這些角度之間的考量也會受到彼此的影響）：

1. 爬蟲目的與應用
2. 爬蟲設計策略（包括反爬蟲，結果監測，平行化）
3. 資料流策略（包括資料庫規劃與例行維運）

• 爬蟲目的與應用：目的與應用導向的專案才能有效的收斂各個策略考量，所以在進行專案之前，應該要先花最多時間討論此次爬網的目的．一般來說，爬蟲的目的不外乎是：
• 監控特定網站資訊
• 廣泛搜集特定主題資訊
• 製作搜尋引擎

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

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

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

以上是自己一些過往經驗的心得整理，很多考慮的地方可能未盡周詳，也請各位前輩不吝指教討論．

系列文章請參考：

• 基本介紹篇：

[Python][教學] 網路爬蟲（crawler）實務（上）--網頁元件解析
[Python][教學] 網路爬蟲（crawler）實務（下）--爬蟲策略以及設定

• 資料庫設定篇：

[Python][教學] Scrapy(Web Crawler) to PostgreSQL（一）簡介 ＆ 網路爬蟲基本設定
[Python][教學] Scrapy(Web Crawler) to PostgreSQL（二）postgreSQL資料庫連接設定

• 應用篇：

[Python][教學] 現學現賣之網路爬蟲(Crawler)--以抓本BLOG為例
[R] PTT推文文化的社群網絡分析（Social Network Analysis），帶你一窺社群網絡中的互動情況