老司机带你用MaxCompute和表格存储玩转车联网数据

2017/06/02 14:36
阅读数 55

阅读全文

“自动驾驶汽车”在近两年频频出现于各大科技新闻头条,自2012年谷歌获得美国首个自动驾驶汽车许可证以来,国外各大知名汽车厂商如奔驰、沃尔沃、大众、通用、丰田、日产、特斯拉等也纷纷宣布自己的自动驾驶汽车验证开发计划。自动驾驶依托于人工智能技术的发展,而对于一个人工智能平台来说,重要的不光是算法和平台,更重要的是数据!今天我们暂且不聊自动驾驶,我们先聊聊最基础的车联网数据的存储与处理。

 

  初始方案

 

出于对两客一危监管的需要,车联网很早就开始起步,彼时大家的车联网方案都长这个样子:

 

1f8760e401bab1a6a76105eed086097ce17704fc

 

将车辆上传的数据进行编码解析,存储到对应的数据库中。由于车辆种类的不同,所上传的传感器数据也会有所区别。为了避免修改表结构对服务造成的影响,采用的是将传感器数据进行分类,分别存储到不同的数据库的方法,也就是图中的数据库层分为了轨迹库、温度库、油量库等。这样的好处是新增一批新类型的传感器时,不需要数据停库维护,不会影响在线应用,但是对数据采集解析程序需要升级更新,大大增加了维护的代价。

 

另外一方面,随着近几年私家车的爆发式增长,车联网也迎来了更多的机遇和挑战。百万在网车辆,几十万的在线车辆都让车联网系统时时刻刻在经受着挑战。

 

 

  存在问题

 

首先就是并发问题。SQLServer的单机并发是有限制的,我们只能在已经分库分表的基础上再对数据进行按时间或者车辆类型的二次分库分表,这大大增加了前后端系统开发和维护的复杂性。同时,为了应对早晚高峰高的不像话的在线率,我们又对像轨迹、油量等通用的基础数据做了数据库的主备读写分离,避免数据采集高峰影响其他的在线业务,这个时候,这个架构已经非常非常复杂了。

 

不仅仅是在线业务,由于多层次的分库分表,我们的报表分析程序中跨表跨库的Join查询让经验丰富的DBA也头疼痛不已。

 

而为了保持在这个行业的竞争力,降低成本是非常有效的一个法宝。我们采用的最直接的手段就是在夜深人静的时候小心翼翼的删除掉过期的数据。

 

  新的方案,刻不容缓!

 

 

我们开始寻找基于云计算的分布式数据解决方案,直到我们看到了下面的一张图。

 

f191ee80d1fa0c7b8f83e255b53a76e239e8a073

 

表格存储(OTS)是阿里云最近推出的一款自研分布式 NoSQL 数据库,其schema free的特性很适合属性列变化较为频繁的数据存储。车载设备更新和迭代的速度也在不断加快,车联网的业务模式也在不断在变化,表格存储这种弱结构的数据模式与当前车联网数据的需求非常契合。所有车辆的数据均可以存储在一张大表里,新的车载设备上线也不需要修改表结构了。

 

于是,我们将原来的方案替换成:

阅读全文

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部