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

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

业务背景

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

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

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

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

TDengine Database

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

技术选型

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

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

技术架构

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

TDengine Database

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

TDengine Database

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

TDengine Database

具体应用

我们要通过数据的变化来实时得到车辆的很多信息,比如是否有停留、超速、缓行、离线等事件发生。有些功能可以通过 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 <= #{endTime}

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

系统界面如下图所示。

TDengine Database

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 <= #{endTime}

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

系统界面如下图所示。

TDengine Database

未来规划

通过项目初期的表现,可以知道 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 可以继续为车联网场景下的查询提供更为多样性的支持,产品越来越好。