原文链接

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

初始方案

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

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

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

存在问题

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

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

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

新的方案，刻不容缓！

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

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

于是，我们将原来的方案替换成：

经过测试，百万车辆50%的在线率的时候，读写的性能都没有出现明显的变化，而且表格存储是一款全托管的服务，也大大减轻了我们运维上的代价。

表格存储的数据生命周期功能可谓是数据管理的神器，我们将不同数据存储时长要求的数据存储在一张大表中，设置好过期时间，过期的数据会自动被删除掉，不仅仅很方便的控制了成本，更降低了人工操作的风险。

对于报表分析，我们将原来在SQLServer上的SQL分析语句迁移到了MaxCompute（就是阿里云以前的ODPS）https://www.aliyun.com/product/odps上，在MaxCompute上关联好TableStore上的外表，定期执行，既方便，又省钱。这一样以来无需维护数据分析程序，并且按量付费的模式可以最大限度节省成本。

粗略算了下，使用表格存储的成本，一辆车不停的跑一年，存储与读写分析的成本也只有1块5，比买瓶饮料还便宜，比最初使用的方案中单车年成本低了一个数量级。

写在最后

选择上云是我们一个非常大的挑战，一度担心云上的稳定性会导致我们业务的失灵，然而事实证明我们的选择是正确的，云确确实实带来了很多便利，节省了很多成本，让我们可以更聚焦在业务逻辑上，技术架构也能快速迭代，为我们保持一定的行业竞争力提供了有力保障。

原文链接

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