最近一段时间主要重心在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)，需要进一步的清洗。
