OBD车联网的数据

　　在《OBD车联网产品的简要分析》一文中，对OBD车联网的功能、技术、商业模式、发展趋势做了简单介绍。本文将从大数据的角度描述车联网数据的商业处理、技术处理。

一、商业模式中的数据

OBD车联网按照“卖××”来分商业模式，有三种东西可卖：设备、服务、数据。

卖设备，是把OBD设备卖给车联网的运营商，设备厂家有或者没有自己的运营网络。OBD设备，必须包含的模块是OBD模块；其次，通讯模块多是蓝牙的或GSM的；定位模块，可以选择GSM基站定位、或者GPS；还有些厂家的设备包含G-Sensor。

卖服务，一般是由车联网运营商为车主提供的各种用车管车服务，比如车队管理；也有OBD车联网服务是其它客户服务的增值服务的情况，比如4S集团使用OBD设备来加强与客户的联接。服务通常按年收费，服务费可能包含或者不包含设备价格。目前，面向个人车主的服务模式不给力。

卖数据，这种方式非常互联网化，指通过对车联网数据的分析，从而提供某种个性化的服务，这种服务不限于汽车使用，更侧重汽车活动（关于汽车使用、汽车活动的区分，参考《互联网化后的车机与手机》）。目前盛行的是卖保险，从之前基于里程的PAYD，到考虑驾驶安全的的PHYD，发展到现在综合各种因素的UBI。将来随着制造和零售夹带服务性质、随着服务业的O2O模式的普及、随着移动互联网的发展并突破盈利点，汽车驾驶数据将大有可为，可为车主提供丰富的服务。

“卖××”的模式，不仅仅限于车联网的OBD设备，对前装的车机同样试用。以UBI为例：PAYD可以没有任何设备（到汽车上抄里程数即可）；目前的UBI则以便于安装和拆卸的OBD口为主；如果将来UBI模式普及，UBI设备则可能在汽车出厂时就已携带，厂家可能更多地选择车机来完成这一任务。

二、数据的商业处理

以UBI为例来说明，车联网数据在商业方面的处理方式。

可以预期：首先，保险公司将以差异化的价廉的保费吸引客户；其次，传统的保险服务（比如便捷的异地出险）将增加竞争力；最后，优质的车联网服务将提供关键的竞争力。以目前的态势看，保险公司注重第一点，或看不到、或忽略、或不重视最后一点。

如果以这三点来看车联网数据的商业化处理，那么，为了发挥数据的最大价值，数据应该具备一定的、可控的开放性，这样，才能形成良好的生态链及其多样性，最快地积累和发展客户，并且提供优质的关键竞争力之一的车联网服务。具体的开放性应体现在三点：设备、车联网服务、保险服务。

设备是开放性的。对于UBI运营平台来说，设备是哪个厂家的并不重要，重要的是这些设备采集的数据能够进入运营平台。这些数据可以是异构的，即结构是不一样的，但应该是同义的，即具备同样的含义和价值。至于设备的可靠性和稳定性，应由运营平台及其车主在使用中按照竞争法则来选择。

车联网服务是开放性的。目前的车联网服务，服务商是要控制设备的，而OBD这样的设备，更多是服务商自己做的（因为需要卖设备来赚钱）。那么，对这些服务商，UBI也可以采取数据合作的方案，保险公司的客户车主可以选择车联网服务商。另外，将来基于这些车联网数据的其它衍生服务，可能更多的是移动互联网服务商，对以，应以OpenAPI的方式提供相关的数据。

保险服务是开放性的。对于车联网服务商来讲，可以把数据给不同的保险公司，或者同时为几家保险公司提供设备、系统或者服务，那么，他们就有可能让自己的客户来选择保险公司。UBI运营平台可以对此开放相关保险方面的数据，而保险公司要控制的是现金流等金融操作。

当然，开放是相对的，必须是在可控的、安全的前提条件下。要做到数据的开放与可控，需要运营管理与技术处理的良好结合。对于运营管理，本人不做描述。

三、数据处理的技术

以卖数据中的卖保险为例，其整个数据的处理流程，如下图所示：

如果是其它的卖数据方案，则驾驶行为模型、保费风险模型、汽车保险管理系统、保单理赔数据四个部分可能做相应的调整，比如，驾驶行为模型变为LBS的位置模型。

在上面的流图中，斜线部分标注了不同的对数据计算的要求。在对车辆做监控管理的时候，要求实时性高；当计算驾驶行为模型时，可以采取批处理的方式，若有一些及时性的要求，则可以结合事件驱动的计算模式；当做保险的风险模型时，则属于BI的范畴。其中保费风险模型，属于近年出现的新需求。

针对这样的系统，过去的方案一般是：关系数据库＋大内存＋总线或消息系统，根据需要可能会包含工作流和规则引擎。若使用Java开源技术，那么这种方案里，通常是把数据库操作组件、内存组件、总线组件等，作为一个整体框架的组成部分，程序整体打包后运行在Server下；根据不同的需要，可能要解决分表、Failover、热部署等问题。

在大数据技术普及的现在，对这样的系统，可选方案为：关系数据库＋NoSQL＋流式计算＋分布式批量计算+BI。这些方案目前都有较为成熟的技术，并且都较好地解决了透明化通信、热部署、Failover等编程及系统管理性问题。

注：上面的系统构成中没有给出人的操作端、车的操作端等终端部分。而在这个方面，整个体系也有变化，过去以车机和PC为主，当前则多了手机。手机的加入，改变的不仅仅是多了一种显示界面、多了很多操作方式，而是多了很多需求。

关系数据库用在车联网运营管理部分，这个部分的业务和技术都已经比较成熟，保存“车及车主数据（包括维修保养）”。

NoSQL用于管理从汽车上采集到的数据，以及后面流程的数据：驾驶行为模型、监控管理结果、保费风险模型；但是，不同的部分，应选用不同的、适应各自特性的NoSQL方案。车辆行驶数据，更适合以日志文件的方式存储，车辆上报的数据通常是基于字节编码的比如ASN.1，需要计算时再解码。监控管理结果，更适合采用一种内存数据库方案，可能需要支持快速读写历史数据、以及定时或定量将数据写入（固态）硬盘。驾驶行为模型，则需要考虑解决：变更计算参数后重新计算、增减模型因子后增删相关数据、因子的值的类型多样化（甚至是复合类型）、等问题。保费风险模型，或者采用与目前保险公司方案兼容的，或者采用适合新型BI的（新型BI在后面会有介绍）。

流式计算用于满足实时性要求高的汽车监管。不同的流式计算系统侧重解决不同的问题。比如Storm解决了实时的分布式计算问题，包括计算流可以分布在一个或多个机器上、动态增减服务器及Failover自管理、通信机制透明化、热部署计算流等；Esper解决了事件之间的规则及关系问题。如果监控需求导致数据多且复杂，那么一个内存数据库是有必要的。

分布式批量计算，目前最流行的方案就是Hadoop。当前Hadoop的热点之一就是改造Hadoop以满足一定的及时性要求，而不单单是批量处理；之所以说是及时性，因为它还达不到实时性的程度。

BI，在当前的大数据环境下，传统的基于关系数据库的方式呈现出几个不足：1、传统方案侧重社会化（分析出整体模型，拿个体特征与其对比），难以满足个体在某时某地的“复杂性/混沌的/发散的”的需求；2、传统方案在数据量非常大时，可能是抽样的，难以做到全量分析；3、更多互联网公司的数据和企业化系统的数据，其存储已经使用NoSQL方案，传统方案难以匹配。能解决以上三个问题的BI框架还未成熟。

不管在数据处理的哪个环节，使用那种处理技术，对于数据的质量识别、优劣控制都是必须的。在车联网中，从车机或OBD设备开始，由于车型的多样性、设备工作环境的复杂性，数据就不可能达到统一的质量标准，如何处理不同的可用率的数据，如何对待由这些数据产生的价值精准性，是商业模式和数据技术都必须考虑的重点问题。