关于车联网数据分析（一）

近日来，一直研究公司（营销中心）如何从车联网数据获取价值。我们是新能源汽车公司，按国家规定，必须收集和上传车辆的实时信息，这一过程是集团发包T-Box厂家和第三方TSP公司完成的。数据必然保存在我们公司的数据库上，数据库是Cassandra；最底层的数据是每辆车每隔10秒一个报文。现在我的目标是利用已有的数据以便得到有营销价值的报表；从汽车研发上来讲，这些数据的价值更大，但是他们不是我的工作对象。公司在利用车联网数据上，目前效率很低，使用的是前述第三方公司的BS架构的“报表”平台，数据非常接近底层，几乎不可使用。

这一课题的第一个障碍是我很难获取数据权限；这很容易理解，我并不属于IT部门，必然在非技术领域，有巨大的障碍。好在公司现在没有人在利用车联网数据，从这个角度，矿山一直被闲置着，IT的首席领导不介意我涉入工作。

接下来就是技术上的事情了。数据提取--转换......直到分析场景的报表，框架被我设计好了。有两个途径获得原始数据：1、Cassandra数据库；2、前述第三方公司搭建的BS架构平台。第1个渠道需要VPN，目前公司IT并不热心，暂时无法获取，第2个渠道本质就是互联网数据自动获取——爬虫。基于现实原因，只能研究第2个渠道。

我先用requests进行测试，首先需要tensorflow进行深度学习，破解登录时的验证码，这很简单。我测试了一辆单日行程88km的车辆，发现响应时间超过10秒，我对数据ETL的过程耗时是0.03秒。“请求-响应”其实有很大的浪费，因为很多数据我根本不需要，但是无法在请求参数中过滤，它是一次发送全部数据。就是如果按照这个进度，2万辆车的数据要请求，即使平均22km，也要处理14个小时。这是行不通的。

接下来我用scrapy改写代码，进行并发下载，希望飞速提升效率。Scrapy这个爬虫框架很好，但是并不友好。你需要习惯它的思维模式，熟悉它的各种接口，遵循它的代码规范。

但是最后的结果似乎并没有大幅改善，虽然可以并发32、64、128...个请求，但是服务器在处理数据量大的请求时，好像没有并发，或者说并发很有限。它平均1.3秒一个页面（最多1个页面900条json数据，有的页面数据为空）。那么如果都是88km的，估计5~6秒一台车的数据，仅仅比我用requests提高1倍而已。我现在猜测服务端不支持并发，比如同步请求时，是5秒钟处理、5秒钟网络IO；并发请求时，依然是5秒钟处理1个，剩下是网络IO，这样仅仅是不同响应的网络IO并发节省了时间。

————————

事情并不像这样，当我把每页的records数量，即pageSize调整到最大时（360*24），同时将vins清单单独爬取时（之前是在上页vins返回之后再爬下一页，一页有500个vin），事情出现了改观，平均0.82秒/台，并且是全天数据。

因为一定会先有500个vin，所以把vins清单单独爬取影响并不大。所以应该是pageSize，估计是服务器在最大时反而处理环节最少。