你好,游客 登录 注册 搜索
背景:
阅读新闻

车联网如何利用大数据

[日期:2013-06-21] 来源:车云网  作者: [字体: ]

 

  本文将从大数据的角度描述车联网数据的商业模型及挖掘之道。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设备开始,由于车型的多样性、设备工作环境的复杂性,数据就不可能达到统一的质量标准,如何处理不同的可用率的数据,如何对待由这些数据产生的价值精准性,是必须考虑的重点问题。

 





收藏 推荐 打印 | 录入: | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款