最近一段時間主要重心在Amazon電商數據分析上，這是一個偏數據分析和可視化的項目。具體來說就是先獲取Amazon的商品數據，數據清洗和持久化存儲后作為我們自己的數據源。分析模塊和可視化模塊基於數據進行一系列的操作。
顯然，整個項目中最基本，也是最重要的就是前期數據的獲取，本篇文章就是針對數據獲取和清洗過程進行一個簡單的介紹和總結。
整個項目我們采用了Python作為開發語言，其中可視化模塊基於Django搭建，當然在數據獲取，即爬蟲模塊，我們也是采用了Python作為我們的開發語言。
對於爬蟲模塊，因為需求是確定的，並且爬取站點也是固定的——Amazon.com，因此在爬蟲模塊主要需要考慮的是調度問題、頁面解析問題以及流程自動化的問題。
首先說明一下爬蟲的整體架構，一開始我們是采用單機器爬取，啟動方式也很簡單——命令行啟動，但這樣帶來的問題是顯著的，不穩定，需要手動啟動任務。之后我們將爬蟲部署成服務，對於進入的任務，可能是用戶提交的，也可能是我們內部提交的，通過一個提交系統加入到服務隊列中，之后爬蟲服務檢測並啟動爬取任務。這樣一定程度上解決了不穩定的問題，但隨着數據增長，帶寬等因素凸顯出來，因此，我們又加入一些機器，構建一個小型的爬蟲集群來分布式爬取。但這不算是真正意義上的分布式，並沒有節點
具體實現方面我們采用Python的一個開源爬蟲框架——Scrapy，該框架提供了基本的調度、頁面爬取等功能。我們需要做的是基於該框架設定DOM解析方案和后續數據的處理存儲方案，同時基於該框架搭建一個小型的偽分布式爬取系統。
下面來介紹一下我們在爬蟲設計過程需要考慮的幾個問題。
首先頁面解析問題，因為JS異步加載的原因，爬蟲實際得到的頁面DOM元素和我們在瀏覽器中打開頁面得到的DOM元素有點區別，這就不能完全依靠瀏覽器來定位具體的DOM元素。其次，在訪問達到一定次數，特別是並發訪問請求達到一定次數后，Amazon會對請求進行封殺，返回Robot Check頁面甚至是500 Server Error。針對這種情況，一種解決方案是減少並發請求的數目，根據我們實際測試發現，每秒鍾發送的請求如果超過50條會被Amazon返回500 Server Error(可能現在Amazon會不斷更新策略)，因此我們設置了並發請求數為32，即一秒鍾一台機器發送32個請求。對於可能會有Robot Check的情況，這個我們還在探索階段，因為此類頁面出現較少且集中出現在商品信息頁面，而該頁面由於信息比較固定可以較長時間不更新。目前是加入Proxy作為下載中間件(DownloadMiddleware)。另外考慮到可能因為國內訪問過於頻繁的話也會導致此類問題的出現，我們目前正在將爬蟲遷移到Amazon EC2上，一來比較穩定，另外訪問也會比在國內機器上快點。
其次是調度問題。在單機器單任務的爬蟲中不存在這樣的問題。但是在多機器多任務中這是一個比較重要的問題，多個任務提交后怎么進行調度，如果有優先級的話是按照優先級來，否則是默認放在任務隊列里依次進行。在我們的爬蟲系統中，多台機器組成的爬蟲系統是由一個調度控制，當一個爬取任務提交后，調度將任務拆分並分發到不同的爬蟲機器上，在單個的爬蟲機器上，會有一個爬取隊列，隊列中是分發到該機器上的所有爬取子任務，在目前是默認從隊列中依次獲取任務，一台機器上能同時啟動六個爬取任務進行並行爬取。
最后是流程的自動化問題。在我們的系統中，需要實現任務提交后，在網站上直接看到處理后的數據以可視化圖表展現。這就需要將整個流程實現自動化，提交任務后開始爬取數據，爬取任務完成后對數據進行處理和歸並，生成一些統計信息，最終得到規范化的數據並在前端可視化展示。這一系列過程主要分為兩個階段，爬取和處理，爬取階段任務提交分發后爬蟲會啟動爬取任務，在爬取完成后，利用Scrapy的接口實現了對爬取任務狀態的修改，例如對於一個任務T，啟動時在數據庫中加入狀態，{‘name’: T, ‘jobid’: ‘Task_id’, ‘status’: ‘running’}，在爬取完成后，修改狀態為 finished，同時，會有定時腳本輪詢看數據庫中各任務是否完成。如果完成的話，啟動數據處理的流程。數據處理完成后歸並數據到正式的項目數據庫中，完成數據的前端可視化展現。由於本項目部署在Linux服務器上，因此就直接采用了linux下的cronjob來實現了腳本的輪詢和執行。簡單來說，寫入幾個crontab后，啟動cronjob，這幾個腳本串接了上述說的每個流程，使其成為完整的一套流程。
上述說的是數據爬取過程中的幾個主要問題，也是比較重要的問題，說實話，即便是現在的系統，仍然沒有完美解決這幾個問題，解析依然會遇到Amazon的封殺，自動化的魯棒性太弱等等。這可能是下一階段需要考慮的問題，同時，數據爬取存儲后依然有不少臟數據(Dirty Data)，需要進一步的清洗。