中通科技是如何建模并高效处理车辆上的时序数据的

小 T 导读：车联网业务是中通科技配送全链路业务中非常重要的一环，在实际的项目需求中，需要实时查询车辆最新位置状态，达到车辆运营可视化管理。中智车联服务平台选择了用 TDengine 来高效处理从车辆上实时采集的时序数据。

业务背景

目前，中通科技拥有一支千人规模的研发团队，在数字信息科技研发方面以“互联网+物流”的理念，自研的软件系统和数字化工具已达百余个，赋能覆盖快递业务全场景，同时为快运、国际、云仓、优选、金融、商业等生态圈业务提供全方位的研发支持，建立起完善的互联网产品研发体系，全场景、全链路的数字化、互联化和智能化的业务地图愈发成熟。

2021 年年底，中通快递已完成了总部园区的实景三维模型，通过接入园区内的在线传感器，根据现有园区各功能区的区位布局，基于此三维模型开展园区内生产规划、调度运行和维护管理的全过程应用，从而实现园区内人、车、物在精准运行、资源优化和配置服务中的全过程精益化管理。

随着生产设备的小型化和智能化，快递企业也将更快地进入空间地理信息数据生产领域，有包裹流动的地方，就会有时空数据服务的需求。

这里先给大家介绍一下配送全链路业务，这是指包裹从商家仓出来一直到用户手上的这段派送履约链路，它包含 4 个主要的实操流程，分别是分拨实操、运输实操、站点实操和快递员实操。把 4 种实操管理放到三个系统里面，这三个系统分别是分拨管理、运输管理、末端站点实操管理。具体如下图所示。

其中车联网业务也是非常重要的一环，通过人、车、货、场全链条覆盖的车联网设备应用，实现物流运输全链路感知。在实际的项目需求中，我们需要实时查询车辆最新位置状态，达到车辆运营可视化管理，也就是我们的中智车联服务平台。

技术选型

在上述业务过程中，我们使用了 TDengine 来完成这个目标。

在选型时，我们对比了 Prometheus 和 TDengine 这两款很有代表性的时序数据库（Time Series Database）。相对而言，TDengine 的“一个设备采集点一张表”的底层设计，自带的降采样和窗口函数的优秀性能，都十分契合车辆网场景。其列式存储带来的压缩比也更好。所以我们选择了 TDengine。

技术架构

我们在每辆车上都安装了部标机（即卫星定位汽车行驶记录仪），来实时采集车辆的行驶速度、时间、里程以及与车辆行驶相关的其他状态信息。采集到的数据，通过我们的 IoT service 这层应用来处理。然后数据经由 MQ（消息队列）层由 JDBC-RESTful 的方式写入 TDengine 集群，以供上游平台使用，而部标机产生的其他类数据则通过别的途径供上游平台使用。

我们使用了三节点三副本的模式落地了 TDengine 集群。

建表很简单，我们选择了一类数据对应一张超级表，超级表下根据车牌号划分子表，表结构如下图所示。目前还是项目初期，所以只接入了 700 余辆车，后续会逐步增加接入车辆。也正因为这套环境接入设备不多，写入方面并无压力，远远达不到 TDengine 的写入极限。

具体应用

我们要通过数据的变化来实时得到车辆的很多信息，比如是否有停留、超速、缓行、离线等事件发生。有些功能可以通过 TDengine 的查询功能实现，有些不方便实现的暂时通过应用来完成。

下面我们通过几个例子来看看目前业务中使用比较频繁的查询：

1. 获取车辆的最新位置

SQL 语句如下。

select last_row(longitude,latitude),deviceId   from ioc_gps.vehicle_location groupby deviceId  where device_id = #{deviceId}  and ts >= #{startTime} and ts 

业务需要快速查询每辆车的最新坐标，这里用到了 TDengine 提供的 last_row 函数。除了查询单独某辆车，经常还会根据 groupId 或者一批 deviceId 去查询一批车辆的最新坐标。

系统界面如下图所示。

2. 车查轨迹信息查询：

select ts,device_id as deviceId,longitude,latitude,altitude,speed as speed,direction,alarm as warnBit,status as statusBit,mobile,mileage,speed2,rssi,satellites,signal_status as signalStatus,gmt_create as gmtCreate,create_ip as createIp,kind,oil,message_id as messageId,device_name as deviceName,plate,device_group_id as deviceGroupId,device_group_name as deviceGroupName,acc, device_code as deviceCode
      from ioc_gps.vehicle_location
      where device_id = #{deviceId}
        and ts >= #{startTime}        
        and ts 

通过指定时间范围和具体的车牌号，就可以立刻获得该车辆的轨迹数据并渲染出轨迹图像。如果知道子表名的话，还可以直接查询子表，这样会减少超级表中对于标签的检索。

系统界面如下图所示。

未来规划

通过项目初期的表现，可以知道 TDengine 能够轻松满足我们的业务需求。未来我们还有其他的使用规划，比如在我们的表字段中，有个 ACC 字段，1 表示点火，0 表示熄火，要求能够计算点火驾驶行程，由于 TDengine 当前还没有直接支持 GIS 计算，暂时不能通过坐标算出直线距离（当前所用的 TDengine 2.0 版本可能需要使用自定义的 UDF 实现），但是应该可以通过状态窗口+加权平均速度+开火时间算出车辆每次点火的驾驶路程，就想这样：

select time*speed from (select elapsed(ts,1s)as time,twa(speed) as speed,acc from t1 state_window(acc)) where acc =1 ;

而每次 ACC 开火熄火的起始点和结束点信息，可以通过 state_window 配合 first/last 函数来实现，比如：

select last(*),first(*) from t2 state_window(charge);

除此之外，我们也需要电子围栏计算，需要快速计算新轨迹点是否进入某电子围栏之中，或者需要快速计算（1s 内）位于某行政区划（省份/城市）边界内的所有车辆的数量。这类查询都需要等 TDengine 继续完善才能实现。

后续我们接入的车辆会达到几万辆，对于部标机产生的相关时序数据的使用也会越来越多。期待 TDengine 可以继续为车联网场景下的查询提供更为多样性的支持，产品越来越好。

往期推荐

☞ 中国云计算第一股关停 IoT云服务

☞ 2022年IoT平台趋势：私有化部署

☞ 5个值得分享的物联网创业失败教训

☞ 2021年4G通信模组企业排行

☞ 国内 4 大 IoT物联网平台选型对比

☞ 云厂商的 [IoT物联网平台] 不香了吗？