近日來，一直研究公司（營銷中心）如何從車聯網數據獲取價值。我們是新能源汽車公司，按國家規定，必須收集和上傳車輛的實時信息，這一過程是集團發包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，估計是服務器在最大時反而處理環節最少。