基于物联网平台的车辆时序数据存储实践-阿里云开发者社区

近些年来，物联网技术得到了飞速发展，应用到了诸多行业里。智慧城市、智能家居、车联网、新能源等领域中都享受着物联网技术带来的红利。物联网技术在应用到日益复杂的场景的同时，也面临着越来越多的难题。不同于传统互联网，物联网数据的产生源由“人”转向了“物”。在传统互联网中，一条数据的产生可能是一次购物下单操作、一条朋友圈发布等，数据的结构、产生时间等都是动态的。而在物联网中，数据是由设备（终端）生成的，设备有着固定的型号与上报周期，特定的设备型号采集的数据维度也是固定的，由此可以看出物联网数据的结构、产生频率、时间都是可预料的。这类数据我们可以称之为时序数据。在物联网的应用领域中，会产生多种类型的时序数据，比如车速、集群水位、电表数等等，如下图举例。

时序数据场景解读

我们以车联网场景为例，来分析车联网场景中会产生哪些时序数据，以及具体的业务场景需求。

车辆时序数据特点

首先我们需要了解车联网场景中会产生哪些数据时序数据。

车身数据。智能车辆会通过各类传感器定时采集车身状态信息，比如行驶速度、发动机转速、轮胎压力值、里程数等，这类数据是以一个固定的频率上报的。
事件数据。另外一种是车辆事件数据，比如门锁上防、撤防、车辆碰撞、异常移动等，这类数据是由某个事件触发产生的。

不同的车辆设备上报数据的过程是独立的，每次上报数据都会带有时间戳，一台车辆在一段时间内上报的数据可以看作是一条时间线，一条时间线中包含了多条带有时间戳属性的数据。所以时间线的条数取决于设备个数，时序数据的规模取决于设备个数与上报周期。如下图展示了一条时间线：

、

从上述内容中我们可以总结出时序数据的如下几个特点：

数据规模大。假设一万台车辆每 10 秒上报一条 1KB 大小的数据，一年就会产生 30TB 的时序数据。
度量维度多且固定。车身传感器上报的是车内温度、发动机转速等行驶状态数据，而门锁传感器上报的则是门锁上防、门锁撤防等事件类数据。
数据随时间增长顺序生成。车辆都是随着时间推移间隔上报数据，每一条数据带有一个时间戳。

车联网场景需求

车联网场景中需要基于各种型号的传感器采集车身状态、事件信息等数据，通过对数据的处理和分析来实现业务需求。那么首先就需要构建能够支持大规模车辆接入的 MQTT 集群，用于满足时序数据的正常上报过程。数据采集完毕后，需要将时序数据持久化存储用于满足后续的查询分析的业务需求，为了降低存储成本，运营商通常只会选择的保留近一段时间内的数据，比如三个月或者一年，更早的数据访问频率非常低，常见的处理方式是冷归档或者删除。时序数据从 MQTT 集群转发到存储的过程中，TPS 会达到十万甚至百万级别，并且基本不会出现 Update 操作。数据写入到存储后，业务方可以查询或分析时序数据来满足需求，大致可以分为单时间线查询和多时间线查询两类。单时间线查询的数据量通常较小，对于延迟较为敏感，例如查询某台车辆一段时间内的行驶轨迹、计算某台车辆一段时间内的平均速度。多时间线查询命中的数据规模大，例如分析某种型号所有车辆的平均里程、分析某个城市所有车辆的平均排放值等。下面我们对车联网的场景需求做一个总结：

车辆设备接入	车身数据、事件数据持久化存储	数据写入	数据查询与分析
大规模车辆设备稳定连接	存储 TB、PB 规模时序数据数据生命周期管理	高 TPS 低延迟写入基本都是 Put 操作，极少有 Update 操作	单时间线范围查询、分析多时间线聚合分析

时序数据对存储的需求

从上述对车联网场景需求的分析中可以总结出对存储侧的几个关键需求：

低成本存储

由于时序数据的规模太大，所以要求存储侧能够支持较低的存储单价。常见的时序存储产品降低用户存储成本的策略是冷热分层存储、压缩存储、数据保留策略（RP），其中冷热分层存储的做法是将旧数据迁移到低成本的存储介质中，以降低整体的数据存储单价；压缩存储是提供更高的数据压缩比，降低存储空间大小，从而达到降低存储成本的目的。RP 策略是能够支持用户设置数据保留的时长，定时清理掉旧数据，降低存储空间。

高并发低延迟写入

时序数据的写入并发取决于设备数和上报周期，在车联网业务中可轻易达到十万甚至百万 TPS，这就要求存储侧最好是可以弹性伸缩的集群架构。而如果是单机存储，当业务规模增大时，就必须对机器资源进行扩容，这将进一步带来额外的运维成本。并且时序数据对写入延迟非常敏感，比如在车辆轨迹实时大屏场景中，如果写入延迟太高，将导致车辆实际位置与大屏显示位置存在误差，这显然是难以接受的。

大规模数据分析

车联网业务中需要对单条时间线或多时间线进行复杂的查询和分析，例如上文提到的轨迹查询、排放值分析等等。参与聚合分析的数据量可能达到上百万行，这就要求存储系统对分析性能进行优化，例如支持易于分析的数据格式等。在查询方式上，存储侧需要兼容 SQL 语法，降低用户的使用门槛。

下面列出了常见的几款存储产品在时序数据存储需求上的对比：

	存储成本	扩展性	查询方式	分析性能
InfluxDB	低	低	InfluxQL	高
RDS	高	低	SQL	中
Tablestore	低	高	API/SQL	高

通过对存储产品的对比可以看出，在存储成本、可扩展性、易用性和分析性能上，Tablestore 具有更好的优势。下面我们将基于阿里云物联网平台 + 表格存储 Tablestore 架构来实现车联网时序数据存储的业务需求。

物联网平台 + Tablestore 架构介绍

架构图

架构介绍

物联网平台。阿里云物联网平台提供了可靠的设备连接通信能力，支持设备数据采集上云，规则引擎流转等功能。本文架构中物联网平台负责车辆设备的接入，通过不同的规则引擎配置将车身数据、事件数据分别转发到下游 Tablestore 时序表中存储。
表格存储 Tablestore。表格存储 Tablestore 是阿里云自研的一款存储产品，适用于物联网设备监控、机器监控数据、车联网等场景。支持数据冷热存储、数据压缩存储、数据生命周期管理等众多能力，相比传统存储成本可降低 90%。本架构中表格存储 Tablestore 作为车身、事件数据的存储库，并且在 Tablestore 上使用 SQL 语法查询、分析数据。

案例背景

某厂商负责全市的出租车运营，为更方便的管理和运营车辆，厂商定时采集车辆的行驶状态数据。现在需要将车辆上报的时序数据接入到云端进行存储，为降低业务成本，厂商选择保留近三个月的数据。车辆每次上报的数据格式如下：

//车身数据样例
car_data ={"vin_id": 车架号
"city": 所在城市
"model": 型号
"time": 上报时间
"gps": 位置坐标
"speed": 行驶速度
"mileage": 里程
"emission": 排放值
}

业务上需要基于上述的时序数据来实现如下几个需求：

查询某台车辆一段时间内的位置信息，用于轨迹展示。
计算某台车辆一段时间内的平均行驶速度。
计算某个型号的车辆的平均里程数。
计算某个城市的车辆一段时间内的平均排放值。

实现步骤

本文将采用物联网平台 + Tablestore 架构来实现上述案例，首先需要开通物联网平台服务和表格存储 Tablestore 服务。Tablestore 在多地域以实例（数据库）提供 Serverless 服务，开箱即用按量计费，无需任何运维操作。上述案例将以下面几个步骤来进行：时序数据存储初始化、车辆数据上报、配置规则引擎、时序数据查询分析。

1. 时序存储表初始化

时序表数据模型介绍

首先创建 Tablestore 实例，并且创建两张时序表，分别存储车身数据（car_data_table）和事件数据（event_data_table）。Tablestore 时序表定义了固定的时间线 Schema ，分别是度量名称，数据源，标签。在车辆时序数据写入时，需要设计哪些字段与时间线中的属性对应，如下图展示了车身数据的一条记录存储结构：

创建时序表

创建 Tablestore 时序表支持设置数据生命周期 TTL，服务端将自动删除过期的数据。例如下图创建了用于存储车身数据的时序表，并且仅保存三个月内的数据。

2. IoT平台数据转发到存储

物联网平台中的规则引擎功能提供了将 Topic 中的数据转发到 Tablestore 时序表中存储的能力。如下图规则引擎中包括了数据源、数据目的和解析器脚本。

数据源中需要指定哪些 Topic 中的数据将参与解析处理和转发。
解析器脚本为用户自定义的 JS 代码或 SQL 语句，负责对数据进行规则处理。
数据目的为 Tablestore 时序表所处的空间配置，比如服务地址、实例名、表名等。

下图展示了车身数据的 Topic 经过解析器脚本处理后，写入 Tablestore 时序表的过程：

配置完规则引擎并启动后，设备上报的数据将经过解析器处理后写入到对应的 Tablestore 时序表中。下面将使用物联网平台提供的设备模拟器模拟上报一条车身数据，验证数据链路的正确性。

3. 模拟设备上报数据

物联网平台提供了设备模拟器、设备端 SDK 等多种方式实现设备上报数据到平台的过程，下面我们使用设备模拟器模拟上报一条车身数据，如下图所示：

设备数据上报到平台后，将被规则引擎转发到 Tablestore 时序表中存储。下图展示了 Tablestore 控制台中存储的车身时序数据：

4. 时序数据查询与分析

在 Tablestore 时序存储引擎中，自动对时间线的列构建了索引。客户端可以使用 SQL 语法直接查询分析时序表中的数据。下面展示了上述案例中的几个业务需求实现：

查询某台车辆一段时间内的位置坐标

select gps from `car_series_table::muti_model` where _m_name ='car_series_data'and _data_source ='vin_id_1488'and _time >1655189452942704and _time <1655189872942704;

分析某台车辆一段时间内的平均速度

select avg(speed)from `car_series_table::muti_model` where _m_name ='car_series_data'and _data_source ='vin_id_1488'and _time >1655189452942704and _time <1655189872942704;

计算某个型号车辆的平均里程数

select avg(mileage)from `car_series_table::muti_model` where tag_value_at(_tags,"model")='model_0'；

计算某个城市的车辆一段时间内的平均排放值

4. 
select avg(emission)from `car_series_table::muti_model` where tag_value_at(_tags,"city")='cn-hangzhou'and _time >1655189452942704and _time <1655189872942704;

总结

本文阐述了在车联网时序数据场景的一些业务需求，包括了大规模设备稳定连接、数据低成本存储、单/多时间线分析等，这对于网关和存储系统都有着较高的要求。文章中采用了物联网平台 + Tablestore 架构实现了完整的车联网时序数据，基于 Tablestore 时序模型实现了海量车身数据、事件数据低成本存储，并使用 Tablestore SQL 实现了对单台、多台车辆的查询与分析。

如果对本文章的架构感兴趣或有意向了解更多物联网中的数据存储场景解决方案，欢迎关注“物联网存储 IoTstore”微信公众号。同时可加入钉钉群（44327024） - “物联网存储 IoTstore 开发者交流群”，群内提供免费的在线专家服务，或扫描下方二维码加入。