新功能!Lindorm Ganos 轨迹出入点统计

简介: 阿里云云原生超融合多模数据库Lindorm广泛支持宽表、时序、对象、文本、队列、空间等多种数据模型,Lindorm Ganos作为Lindorm的时空引擎,将达摩院空天数据库引擎的时空数据库技术与Lindorm深度融合,为Lindorm提供了一站式解决海量轨迹场景的存储和各类查询问题的能力。本文介绍Lindorm Ganos在轨迹出入点统计应用场景下的解决方案和能力优势。

阿里云云原生超融合多模数据库Lindorm广泛支持宽表、时序、对象、文本、队列、空间等多种数据模型,Lindorm Ganos作为Lindorm的时空引擎,将达摩院空天数据库引擎的时空数据库技术与Lindorm深度融合,为Lindorm提供了一站式解决海量轨迹场景的存储和各类查询问题的能力。Lindorm Ganos的典型应用场景之一是车联网轨迹处理,NoSQL“小钢炮”,Lindorm时空引擎Ganos轨迹处理实测 一文介绍了Lindorm Ganos在海量轨迹实时写入、在线轨迹检索、实时围栏报警场景下的能力优势。


业务场景

在某客户的轨迹系统中,需要统计出轨迹点出入某个区域的信息,包括:驶入时间、驶出时间、停留时长、轨迹数量等。比如:

  • 统计一辆出租车何时进入了小区,何时驶出小区,过去24小时一共进出了几次等
  • 统计一辆卡车何时进入服务区,休息了多久,何时离开,过去24小时内一共有多少量卡车停留休息
  • 统计一个道路卡口(如红绿灯口),过去24小时内一共有多少量车驶入驶出,每辆车在卡口的停留时间等

有了这些统计信息后,业务层可以依据这些统计这些信息优化业务系统,比如:

  • 某个道路卡口中,每个车辆的停留时间过长,可能是该卡口的服务流程存在问题,需要业务层面考虑优化手段。
  • 车队的车辆监控服务中,发现某辆车并未在规定的时间内进入某个小区,也未在指定的服务时间内驶出小区,因而可以辅助判别某个车辆是否按时履约服务。


业务系统每天会收集到大量不同汽车实时上报的车辆信息,将车辆的实时位置、实时属性等信息写入数据库。车辆上传的轨迹点记录可能分布在较大的空间区域内,跨越较长的采集时间范围,数据量可以达到上亿条。统计信息有可能需要实时获取,查询的要求一般是几十秒以内。

对于上述大体量轨迹数据的实时进出统计需求,在不利用时空引擎的情况下,需要通过全表扫描+业务层内存聚合计算实现,这样做的主要劣势在于:

  1. 数据扫描量过大。只能使用时间列索引,需要对全空间范围的数据进行扫描
  2. 内存消耗过大。如果数据本来没有按时间排好序,轨迹点需要全部加载到内存进行排序才能重构出轨迹;
  3. 计算量过大。重构后需要对全空间范围的轨迹点逐个判断是否在给定的精确空间范围内
  4. 业务系统实现复杂。数据库只能提供聚合能力,轨迹的重构、进出判断都需要在业务层进行


ST_TrajectoryProfile算子

Lindorm Ganos 通过内置ST_TrajectoryProfile来高效的实现出入信息的统计。利用其原生实现的时空索引技术,可有效过滤掉大多数不在查询范围内的数据,减少扫描量、内存使用量,降低计算代价,从而可以有效解决上述的三个问题。具体的解决方法包括:

  1. 利用空间索引+过滤下推,减少扫描量,减少存储层与查询节点间的数据传输。降低数据库IO,减轻查询节点的内存、计算压力;
  2. 聚合加速:分组聚合计算并行进行,并将部分聚合逻辑下推到数据所在节点,减少查询节点内存和计算压力,提高聚合效率;
  3. 进出点计算封装:在聚合算子内部完成进出点的判断和轨迹段进出信息提取,减少业务层操作,使用方便

使用限制:由于在聚合操作前,1、2两步已经过滤掉了不在查询区域范围内的轨迹点,在进行出入点判断时,也就无法知道在查询范围以外的数据信息,因此对轨迹出入的判断有以下几个局限性:

1)划分轨迹段的条件依赖于时间阈值的设定,仅在轨迹点均匀采集点的情况下完全没有误差。对于中断采样情况,需要对返回结果进行额外的业务判断

2)对于出点,只能给出离开区域范围前的最后一个点,需要根据返回数据另外查询离开区域范围后的第一个点


使用示例

上述方案由Lindorm Ganos时空引擎的ST_TrajectoryProfile函数实现,函数具体说明详见ST_TrajectoryProfile


测试表结构

+-------------------+--------------+-------------------------------------+---------+----------------+------------+
|   TABLE_SCHEMA    |   TABLE_NAME |             COLUMN_NAME             |  TYPE   | IS_PRIMARY_KEY | SORT_ORDER |
+-------------------+--------------+-------------------------------------+---------+----------------+------------+
|      default      |     test     | device_code                         | VARCHAR | true           | ASC        |
|      default      |     test     | collect_time                        | BIGINT  | true           | ASC        |
|      default      |     test     | create_time                         | BIGINT  | true           | ASC        |
|      default      |     test     | latitude                            | DOUBLE  | false          | none       |
|      default      |     test     | longitude                           | DOUBLE  | false          | none       |
|      default      |     test     | altitude                            | DOUBLE  | false          | none       |
|      default      |     test     | gps_type                            | INT     | false          | none       |
|      default      |     test     | gps_valid                           | INT     | false          | none       |
|      default      |     test     | gps_status                          | INT     | false          | none       |
|      default      |     test     | ...                                 | ...     | ...            | ...        |
+-------------------+--------------+-------------------------------------+---------+----------------+------------+

表的联合主键为device_code(车辆id)、collect_time(gps位置采集时间)、create_time(记录创建时间),另外还有其它74个非主键属性字段,包括对应collect_time的latitude(纬度)、longitude(经度)等。每辆车的gps按照10s的时间间隔连续采集轨迹点数据。


创建索引

为test表创建z-order二级索引,冗余longitude、latitude两列,避免主表回查

CREATE INDEX zorder_idx ON test (z-order(longitude, latitude)) INLCUDE(longitude, latitude);


进出点查询

要获取test表中的每个设备在指定时间段(2022-08-12 11:12:39 - 2022-08-17 09:39:19)内进出指定区域(以经纬度120.20495, 30.187485810为圆心,半径1000米内的区域)的情况,查询语句如下:

SELECT device_code, ST_TrajectoryProfile(longitude, latitude, collect_time, 10000) FROM test WHERE ST_DwithinSphere(ST_GeomFromText('POINT (120.20495 30.187485810)'), longitude, latitude, 1000.0) and collect_time >= 1660273959000 and collect_time <= 1660700359000 group by device_code;

ST_TrajectoryProfile函数返回各个轨迹段的概要信息(进出点和进出时间)。由于gps采样间隔为10s,ST_TrajectoryProfile的时间阈值参数为10000(ms)。


返回结果

+-------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| device_code |                                                 ST_TRAJECTORYPROFILE(longitude, latitude)                                                 |
+-------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| 13184922496 | {"0":"{\"endY\":30.1830,\"endX\":120.2000,\"startY\":30.1820,\"startTime\":1660273959000,\"startX\":120.1989,\"endTime\":1660283962000}"} |
+-------------+-------------------------------------------------------------------------------------------------------------------------------------------+

该示例的返回结果表示在查询时间和区域内,只有一辆车进出了区域一次,进入时间为1660273959000 (2022-08-12 11:12:39),进入点为 (120.1989, 30.1820),离开前最后一次记录的时间为1660283962000 (2022-08-12 13:59:22),离开前最后一个记录点为 (120.2000, 30.1830)

注:该示例collect_time存储格式为LONG类型,可支持的时间字段类型还有TIMESTAMP、TIME


性能表现

测试环境

Lindorm Ganos测试集群:Lindorm 2.4.1版本,三节点16核32GB,1040G性能型云存储


测试数据

测试表结构与示例表结构相同,每条记录为车辆行驶过程中采集上传的一个轨迹点,表大小为3146MB,包含25辆车近3个月在经度范围[115.6253, 122.2817]、纬度范围[24.553466, 33.1788] 内的27045751个行驶轨迹点记录。


查询性能

  • 查询的空间范围为半径1000m的圆形区域或面积在1平方千米左右的不规则区域,查询的时间范围均在一天左右。
  • 返回时间主要取决于索引过滤后聚合计算的数据量和空间范围过滤条件的复杂程度。测试耗时均在20s以内,部分查询情况如下


查询条件

聚合计算数据量(查询范围内记录数)

查询耗时

空间范围:(120.20495 30.187485810) 周边1000m,时间范围:2022-10-20 18:12:48 - 2022-10-21 18:12:48

3572683

17s

空间范围:矩形[(120.20322 30.18733),(120.21495 30.188485)],时间范围:2022-10-20 07:06:08 - 2022-10-21 15:26:08

23026

1s

空间范围:外包框为[(120.20122 30.186485),(120.21595 30.189483)] 的不规则多边形,时间范围:2022-10-01 08:27:16 - 2022-10-02 13:18:41

3008

6s


总结

针对轨迹出入点实时计算这一需求,Lindorm Ganos 结合其原生时空索引技术开发了ST_TrajectoryProfie聚合函数,快速返回给用户在给定时间、空间范围内轨迹进出的时间和位置,能够实现百万级计算量10s级返回,较传统不利用时空引擎的方法有一个量级以上的提升,可以满足实时应用场景的需求。



相关文章
|
2月前
|
存储 Cloud Native 搜索推荐
Lindorm Ganos
Lindorm Ganos 是阿里云推出的一款云原生超融合多模数据库,它集成了流引擎、宽表引擎、对象引擎、搜索引擎等多种功能,可用于解决海量数据的存储和查询问题。其中,Ganos 时空引擎是 Lindorm 的一个重要组件,主要负责处理时空数据。
49 3
|
2月前
|
存储 SQL 达摩院
Lindorm Ganos轨迹点
Lindorm Ganos 是阿里云推出的一款云原生超融合多模数据库,它集成了达摩院空天数据库引擎 Ganos
42 1
|
2月前
|
消息中间件 存储 Kafka
Lindorm Ganos轨迹点快速聚合能力简介
本文介绍了Ganos时空数据库在Lindorm流引擎上的全新能力与最佳实践,帮助客户解决车辆网场景中轨迹点实时聚合生成轨迹线的能力。Lindorm Ganos实现了Lindorm宽表、流、计算等引擎在时空领域的打通,支持原生时空类型与多种时空算子,支持多种不同的时空索引,不仅可用于传统的周边查询,还面向了历史轨迹的查询分析、实时地理围栏查询、点面查询等更加复杂的业务需求。
|
存储 消息中间件 SQL
基于Lindorm Ganos的车辆实时行为分析
本文介绍了Ganos时空数据库在Lindorm流引擎上的全新能力与最佳实践,帮助客户解决车辆网场景中实时时空数据分析的需求。Lindorm Ganos实现了Lindorm宽表、流、计算等引擎在时空领域的打通,支持原生时空类型与多种时空算子,支持多种不同的时空索引,不仅可用于传统的周边查询,还面向了历史轨迹的查询分析、地理围栏查询、点面查询等更加复杂的业务需求。
|
存储 SQL NoSQL
NoSQL“小钢炮”,Lindorm时空引擎Ganos轨迹处理实测
Lindorm作为一款阿里云推出的云原生超融合多模数据库,包含了流引擎、宽表引擎、对象引擎、搜索引擎等。最新发布的Lindorm已经深度融合了达摩院空天数据库引擎Ganos(Lindorm Ganos),可以一站式的解决海量轨迹场景的存储和各类查询需求,本文通过对Lindorm Ganos在常用的时空场景进行测试,用过程和实际的数据展示Lindorm Ganos的具备的能力和特性。
NoSQL“小钢炮”,Lindorm时空引擎Ganos轨迹处理实测
|
SQL 分布式计算 并行计算
用 Lindorm Ganos 一条 SQL 计算轨迹距离
Lindorm 多模数据库提供宽表、时序、搜索、文本、空间等多种数据模型,面向互联网、IoT、车联网等场景,是阿里巴巴核心业务提供关键支撑的数据库之一。Lindorm Ganos 将 Ganos 对时空数据的处理能力深度融合到 Lindorm 中,提供原生的时空数据类型和时空算子,内置时空主键索引和时空二级索引,将时空算子下推并优化了查询计划,可以很好地满足车联网业务对轨迹、位置、范围等数据处理的需求。针对轨迹距离计算场景,Lindorm Ganos 内置 ST_Length_Rows 函数来高效实现轨迹距离计算。
用 Lindorm Ganos 一条 SQL 计算轨迹距离
|
存储 SQL NoSQL
轨迹数据处理“小钢炮”,Lindorm时空引擎Ganos实测
本文在Lindorm Ganos中对常用的时空场景进行测试,用过程和实际数据展示Lindorm Ganos具备的能力和特性
轨迹数据处理“小钢炮”,Lindorm时空引擎Ganos实测
|
多模数据库 物联网 数据处理
明日14点开播!多模数据库Lindorm的车联网轨迹数据处理技术与应用解析
《数据库风向标》是一档聚焦数据库新趋势与新技术的视频栏目,节目每期会请到几位资深技术大咖,与大家共话数据库热点话题。
明日14点开播!多模数据库Lindorm的车联网轨迹数据处理技术与应用解析
|
25天前
|
存储 SQL 多模数据库
多模数据库Lindorm再升级:对接Dataphin,打通数据治理“最后一公里”
Lindorm通过与Dataphin的深度整合,进一步解决了数据集成和数据治理的问题,为企业提供更加高效和更具性价比的方案。
多模数据库Lindorm再升级:对接Dataphin,打通数据治理“最后一公里”
|
1月前
|
数据采集 安全 API
DataphinV4.1大升级: 支持Lindorm开启高性价比数据治理,迎来“公共云半托管”云上自助新模式
Dataphin 是阿里巴巴旗下的一个智能数据建设与治理平台,旨在帮助企业构建高效、可靠、安全的数据资产。在V4.1版本升级中,Dataphin 引入了Lindorm等多项新功能,并开启公共云半托管模式,优化代码搜索,为用户提供更加高效、灵活、安全的数据管理和运营环境,提升用户体验,促进企业数据资产的建设和价值挖掘。
1328 3
DataphinV4.1大升级: 支持Lindorm开启高性价比数据治理,迎来“公共云半托管”云上自助新模式