昨天有一個網友說，他最近面試了幾家公司，有一個問題被問到了好幾次，每次都回答的不是太好。
面試官：比如有10萬個網站需要採集，你有什麼方法快速的獲取到數據？
想回答好這個問題，其實需要你有足夠的知識面，有足夠的技術儲備。
最近，我們也在招聘，每週都會面試十幾個人，感覺合適的也就一兩個，大多數和這位網友的情況差不多，都缺乏整體思維，那怕那些有三四年工作經驗的老司機。他們解決具體問題的能力很強，卻很少能由點及面，站在一個新的高度，全面思考問題。
10萬個網站的採集覆蓋度，已經比大多數的專業輿情監控公司的數據採集範圍都廣了。要達到面試官說的採集需求，就需要我們從網站的收集，直到數據存儲的各個方面進行綜合考慮，給出一個合適的方案，以達到節省成本，提高工作效率的目的。
下面我們就從網站的收集，直到數據存儲的各方面，做個簡單的介紹。
一、10萬個網站從哪裏來？
一般來說，採集的網站，都是根據公司業務的發展，逐漸積累起來的。
我們現在假設，這是一個初創公司的需求。公司剛剛成立，這麼多網站，基本上可以說是冷啓動。那麼我們如何收集到這10萬個網站呢？可以有以下幾種方式：
1) 歷史業務的積累
不管是冷啓動，還是什麼，既然有采集需求，一定是有項目或產品有這方面的需求，其相關的人員前期一定調研過一些數據來源，收集了一些比較重要的網站。這些都可以作爲我們收集網站和採集的原始種子。
2) 關聯網站
在一些網站的底部，一般都有相關網站的鏈接。尤其是政府類型的網站，通常會有下級相關部門的官網。
3) 網站導航
有些網站可能爲了某種目的(比如引流等)，收集一些網站，並對其進行歸類進行展示，以方便人們查找。這些網站可以快速的爲我們提供第一批種子網站。然後，我們再通過網站關聯等其他方式獲取更多的網站。
4) 搜索引擎
也可以準備一些與公司業務相關的關鍵詞，去百度、搜狗等搜索引擎中搜索，通過對搜索結果進行處理，提取相應的網站，作爲我們的種子網站。
5) 第三方平臺
比如一些第三方的SaaS平臺，都會有7~15天的免費試用。所以，我們就可以利用這段時間，把與我們業務相關的數據採集下來，然後提取出其中的網站，作爲我們初始採集種子。
雖然，這種方式是最有效，最快的網站收集方式。但是在試用期內，獲取10萬個網站的可能也極小，所以尚需要結合上述的關聯網站等其他方式，以便快速獲取所需網站。
通過以上五種方式，相信我們可以很快的收集到，我們需要的10萬個網站。但是，這麼多網站，我們該如何管理？如何知道其正常與否呢？
二、10萬個網站如何管理？
當我們收集到10萬個網站以後，首先面對的就是如何管理、如何配置採集規則、如何監控網站正常與否等。
1) 如何管理
10萬個網站，如果沒有專門的系統來管理，那將是一場災難。
同時，可能由於業務的需要，比如智能推薦等，需要我們對網站進行一些預處理(比如打標籤)。此時，一個網站管理系統將是必須的。
2) 如何配置採集規則
前期我們收集的10萬個網站只是首頁，如果只把首頁作爲採集任務，那麼就只能採集到首頁很少的信息，漏採率很大。
如果要根據首頁URL進行全站採集，則對服務器資源消耗又比較大，成本過高。所以，我們需要配置我們關心的欄目，並對其進行採集。
但是，10萬個網站，如何快速、高效的配置欄目呢？目前，我們以自動解析HTML源碼的方式，進行欄目的半自動化配置。
當然，我們也試驗過機器學習的方式來處理，不過效果還不是太理想。
由於需要採集的網站量達到10萬級別，所以一定不要使用xpath等精確定位的方式進行採集。否則，等你把這10萬網站配置好，黃花菜都涼了。
同時，數據採集一定要使用通用爬蟲，使用正則表達式的方式來匹配列表數據。在採集正文時，通過使用算法來解析時間、正文等屬性；
3) 如何監控
由於有10萬網站，這些網站中每天都會有網站改版，或者欄目改版，或新增/下架欄目等。所以，需要根據採集的數據情況，簡單的分析一下網站的情況。
比如，一個網站幾天都沒有新數據，一定是出現了問題。要麼網站改版，導致信息正則失效常，要麼就是網站本身出現問題。
爲了提高採集效率，可以使用一個單獨的服務，每隔一段時間，檢測一次網站和欄目的情況。一是檢測網站、欄目是否能正常訪問；二要檢測配置的欄目信息正則表達式是否正常。以便運維人員對其進行維護。
三、任務緩存
10萬個網站，配置完欄目以後，採集的入口URL應該會達到百萬級別。採集器如何高效的獲取這些入口URL進行採集呢？
如果把這些URL放到數據庫中，不管是MySQL，還是Oracle，採集器獲取採集任務這一操作，都會浪費很多時間，大大降低採集效率。
如何解決這個問題呢？內存數據庫便是首選，如Redis、 Mongo DB 等。一般採集用Redis來做緩存。所以，可以在配置欄目的同時，把欄目信息同步到Redis中，作爲採集任務緩存隊列。
四、網站如何採集？
就像是你想達到年薪百萬，最大概率是要去華爲、阿里、騰訊這種一線大廠，而且還需要到一定的級別纔行。這條路註定不易。
同樣，如果需要採集百萬級別的列表URL，常規的方法也一定是無法實現。
必須使用分佈式+多進程+多線程的方式。同時，還需要結合內存數據庫Redis等做緩存，以實現高效獲取任務，以及對採集信息進行排重；
同時，信息的解析，如發佈時間、正文等，也必須使用算法來處理。比如現在比較火的GNE，
有些屬性，可以在列表採集時獲取的，就儘量不要放到和正文一起進行解析。比如：標題。一般情況下，從列表中獲取到的，標題的準確度，要遠大於算法從信息html源碼中解析的。
同時，如果有一些特殊網站、或者一些特殊需求，我們再採用定製開發的方式進行處理即可。
五、統一數據存儲接口
爲了保持採集的及時性，10萬個網站的採集，可能需要十幾二十臺服務器。同時，每臺服務器上又部署N個採集器，再加上一些定製開發的腳本，整體採集器的數量將會達到上百個。
如果每個採集器/定製腳本，都自行開發一套自己的數據保存接口，則開發、調試就會浪費不少時間。而且後續的運維，也將是一件非糟心的事情。尤其是業務有所變化，需要調整時。所以，統一數據存儲接口還是很有必要的。
由於數據存儲接口統一，當我們需要相對數據做一些特殊處理時，比如：清洗、矯正等，就不用再去修改每個採集存儲部分，只需要修改一下接口，重新部署即可。
快速、方便、快捷。
六、數據及採集監控
10萬個網站的採集覆蓋度，每天的數據量絕對在200萬以上。由於數據解析的算法無論多精確，總是不能達到100%（能達到90%就非常不錯了）。所以，數據解析一定會存在異常情況。比如：發佈時間大於當前時間、正文中包含相關新聞信息等等。
但是，由於我們統一了數據存儲接口，此時就可以在接口處，進行統一的數據質量校驗。以便根據異常情況，來優化採集器及定製腳本。
同時，還可以統計每個網站或欄目的數據採集情況。以便能夠及時地判斷，當前採集的網站/欄目信源是否正常，以便保證始終有10萬個有效的採集網站。
七、數據存儲
由於每天採集的數據量較大，普通的數據庫(如：mysql、Oracle等)已經無法勝任。即使像Mongo DB這樣的NoSql數據庫，也已經不再適用。此時，ES、Solr等分佈式索引是目前最好的選擇。
至於是否上Hadoop、HBase等大數據平臺，那就看具體情況了。在預算不多的情況下，可以先搭建分佈式索引集羣，大數據平臺可以後續考慮。
爲了保證查詢的響應速度，分佈式索引中儘量不要保存正文的信息。像標題、發佈時間、URL等可以保存，這樣在顯示列表數據時可以減少二次查詢。
在沒有上大數據平臺期間，可以把正文以固定的數據標準，保存到txt等文件系統中。後續上大數據平臺後，再轉存到HBASE中即可。
八、自動化運維
由於服務器、採集器，以及定製腳本較多，單純的靠人工進行部署、啓動、更新、運行情況監控等，已經顯得非常的繁瑣，且容易出現人爲失誤。
所以，必須有一套自動化運維繫統，能夠實現對採集器/腳本進行部署、啓動、關閉、運行等，以便能夠在出現變動時快速的響應。
“比如有10萬個網站需要採集，你有什麼方法快速的獲取到數據？”，如果你能回答出這些，拿到一個不錯的offer應該沒什麼懸念。
最後，願正在找工作的各位朋友，都能收穫滿意的offer，找到一個不錯的平臺。
本文分享自微信公衆號 - 十點數據（crawler-small-gun）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。