OBD車聯網如何在大資料上作文章？

【編者按】本文轉載自車雲網，作者八路軍。

本文將從大資料的角度描述車聯網資料的商業模型及挖掘之道。 OBD車聯網按照「賣××」來分商業模式，有三種東西可賣：設備、服務、資料。

賣設備：把OBD設備賣給車聯網的運營商。 OBD設備必須包含OBD模組；通訊模組多是藍牙的或GSM；定位模組可以選擇GSM基站定位、或者GPS；還有些廠家的設備包含G-Sensor。

賣服務：一般是由車聯網運營商為車主提供各種用車管車服務，比如車隊管理；也包括增值服務，比如4S集團使用 OBD設備來加強與客戶的聯接。 服務通常按年收費，服務費可能包含或者不包含設備價格。 目前，面向個人車主的服務模式不給力。

賣資料：這種方式非常互聯網化，指通過對車聯網資料的分析，從而提供某種個人化的服務，這種服務不限於汽車使用，更側重汽車活動。 目前盛行的是賣保險，從之前基於里程的PAYD，到考慮駕駛安全的的PHYD，發展到現在綜合各種因素的UBI。

「賣××」的模式，不僅僅限於車聯網的OBD設備，對前裝的車機同樣試用。 目前的UBI主要通過便於安裝和拆卸的OBD介面；將來則可能在汽車出廠時就已攜帶。

可控、開放是王道

以UBI為例，為了發揮資料的最大價值，資料應該具備一定的、可控的開放性，才能形成良好的生態鏈及其多樣性。 具體而言，資料開放性體現在三點：設備、車聯網服務、保險服務。

設備。 對於UBI運營平臺來說，設備是哪個廠家的並不重要，重要的是這些設備採集的資料能夠進入運營平臺。 這些資料可以是異構的，即結構是不一樣的，但應該是同義的，即具備同樣的含義和價值。

車聯網服務。 目前的車聯網服務商是要控制設備的，而OBD設備更多是由服務商自己做（因為需要賣設備來賺錢）。 對這些服務商，UBI也可以採取資料合作的形式，讓車主自主選擇。 另外，將來基於這些資料的其它衍生服務，應以OpenAPI的方式提供基礎資料。

保險服務。 對於車聯網服務商來講，可以同時為幾家保險公司提供設備、系統或者服務，那麼，他們就有可能讓自己的客戶來選擇保險公司。 UBI運營平臺可以對此開放相關保險資料，而保險公司要控制的是現金流等金融操作。

當然，開放是相對的，必須是在可控的、安全的前提條件下。 要做到資料的開放與可控，需要運營管理與技術處理的良好結合。

大資料採礦之道

以賣資料中的賣保險為例，整個資料的處理流程，如下圖所示：

如果是其它的賣資料方案，則駕駛行為模型、保費風險模型、汽車保險管理系統、保單理賠資料四個部分可能做相應的調整，比如，駕駛行為模型變為LBS的位置模型。

在上面的流程圖中，斜體部分標注了不同的環節對資料計算的要求。 在對車輛做監控管理的時候，要求即時性高；當計算駕駛行為模型時，可以採取批次處理的方式，若有一些及時性的要求，則可以結合事件驅動的計算模式；當做保險的風險模型時，則屬於BI的範疇，保費風險模型也是屬於近年出現的新需求。

針對這樣的系統，過去的方案一般是：關係資料庫＋大記憶體＋匯流排或消息系統，根據需要可能會包含工作流和規則引擎。 若使用JAVA開源技術，那麼這種方案裡，通常是把資料庫操作元件、記憶體元件、匯流排元件等作為一個整體框架的組成部分，程式整體打包後運行在Server下；根據不同的需要，可能要解決分表、Fail over、熱部署等問題。

大資料技術普及的現在，對這樣的系統可選方案為：關係資料庫＋NoSQL＋流式計算＋分散式批量計算+BI。 這些方案目前都有較為成熟的技術，並且都較好地解決了透明化通信、熱部署、Fail over等程式設計及系統管理性問題。 （注：上面的系統構成中沒有給出人的操作端、車的操作端等終端部分。 而在這個方面，整個體系也有變化，過去以車機和PC為主，當前則多了手機。 手機的加入，改變的不僅僅是多了一種顯示介面、多了很多操作方式，而是多了很多需求。 ）

關係資料庫用在車聯網運營管理部分，這個部分的業務和技術都已經比較成熟，指保存車及車主資料（包括維修保養）。

NoSQL用於管理從汽車上採集到的資料，以及後面流程的資料，但是，不同的部分應選用不同的、適應各自特性的NoSQL方案：

車輛行駛資料，更適合以日誌檔的方式存儲。 車輛上報的資料通常是基於位元組編碼的比如ASN.1，需要計算時再解碼。

監控管理結果，更適合採用一種記憶體資料庫方案，可能需要支援快速讀寫歷史資料、以及定時或定量將資料寫入（固態）硬碟。

駕駛行為模型，則需要考慮解決變更計算參數後重新計算、增減模型因數後增刪相關資料、因數的值的類型多樣化（甚至是複合類型）、等問題。

保費風險模型，或者採用與目前保險公司方案相容的，或者採用適合新型BI的（新型BI在後面會有介紹）。

流式計算用於滿足即時性要求高的汽車監管。 不同的流式計算系統側重解決不同的問題。 比如Storm解決了即時的分散式運算問題，包括計算流可以分佈在一個或多個機器上、動態增減伺服器及Fail over自管理、通信機制透明化、熱部署計算流等；Esper解決了事件之間的規則及關係問題。 如果監控需求導致資料多且複雜，那麼一個記憶體資料庫是有必要的。

分散式批量計算，目前最流行的方案就是Hadoop。 當前Hadoop的熱點之一就是改造Hadoop以滿足一定的及時性要求，而不單單是批量處理；之所以說是及時性，因為它還達不到即時性的程度。

BI（商業智慧）。 在當前的大資料環境下，傳統的基於關係資料庫的方式呈現出幾個不足：1、傳統方案側重社會化（分析出整體模型，拿個體特徵與其對比），難以滿足個體在某時某地的「複雜性/混沌的/發散的」的需求；2、傳統方案在資料量非常大時， 可能是抽樣的，難以做到全量分析；3、更多互聯網公司的資料和企業化系統的資料，其存儲已經使用NoSQL方案，傳統方案難以匹配。 能解決以上三個問題的BI框架還未成熟。

不管在資料處理的哪個環節，使用那種處理技術，對於資料的品質識別、優劣控制都是必須的。 在車聯網中，從車機或OBD設備開始，由於車型的多樣性、設備工作環境的複雜性，資料就不可能達到統一的品質標準，如何處理不同的可用率的資料，如何對待由這些資料產生的價值精准性，是必須考慮的重點問題。

(責任編輯：蒙遺善)