小 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 <= #{endTime}业务须要疾速查问每辆车的最新坐标，这里用到了 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 <= #{endTime}通过指定工夫范畴和具体的车牌号，就能够立即取得该车辆的轨迹数据并渲染出轨迹图像。如果晓得子表名的话，还能够间接查问子表，这样会缩小超级表中对于标签的检索。
零碎界面如下图所示。
将来布局
通过我的项目初期的体现，能够晓得 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 能够持续为车联网场景下的查问提供更为多样性的反对，产品越来越好。
想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。