OBD车联网如何在大数据上作文章?

NoSQL用于管理从汽车上采集到的数据,以及后面流程的数据,但是,不同的部分应选用不同的、适应各自特性的NoSQL方案:

车辆行驶数据,更适合以日志文件的方式存储。车辆上报的数据通常是基于字节编码的比如ASN.1,需要计算时再解码。

监控管理结果,更适合采用一种内存数据库方案,可能需要支持快速读写历史数据、以及定时或定量将数据写入(固态)硬盘。

驾驶行为模型,则需要考虑解决变更计算参数后重新计算、增减模型因子后增删相关数据、因子的值的类型多样化(甚至是复合类型)、等问题。

保费风险模型,或者采用与目前保险公司方案兼容的,或者采用适合新型BI的(新型BI在后面会有介绍)。

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

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

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

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