[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

CN113806466A - 路径时间查询方法、装置、电子设备和可读存储介质 - Google Patents

路径时间查询方法、装置、电子设备和可读存储介质 Download PDF

Info

Publication number
CN113806466A
CN113806466A CN202011597002.5A CN202011597002A CN113806466A CN 113806466 A CN113806466 A CN 113806466A CN 202011597002 A CN202011597002 A CN 202011597002A CN 113806466 A CN113806466 A CN 113806466A
Authority
CN
China
Prior art keywords
path
sub
track
query
paths
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202011597002.5A
Other languages
English (en)
Inventor
李瑞远
俞自生
王如斌
鲍捷
郑宇�
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Jingdong City Beijing Digital Technology Co Ltd
Original Assignee
Jingdong City Beijing Digital Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jingdong City Beijing Digital Technology Co Ltd filed Critical Jingdong City Beijing Digital Technology Co Ltd
Priority to CN202011597002.5A priority Critical patent/CN113806466A/zh
Publication of CN113806466A publication Critical patent/CN113806466A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/31—Indexing; Data structures therefor; Storage structures
    • G06F16/316—Indexing structures
    • G06F16/319—Inverted lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/31—Indexing; Data structures therefor; Storage structures
    • G06F16/316—Indexing structures
    • G06F16/322—Trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/38—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G06F16/387—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using geographical or spatial information, e.g. location

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Library & Information Science (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开提供了一种路径时间查询方法、装置、电子设备和可读存储介质，涉及计算机技术领域。其中，路径时间查询方法包括：将待查询路径分解成多个子路径；根据子路径和设定的查询时间范围，从第一预设长度的后缀树索引中检索获得轨迹标识集合；根据子路径和轨迹标识集合，重建轨迹标识集合中的每条轨迹在查询时间范围内的行动路径；根据全部轨迹标识集合的行动路径生成查询时间范围内的轨迹集合。通过本公开的技术方案，降低了轨迹数据的维护难度，降低了索引和查询的耗时，减少了磁盘读写和验证计算的开销。

Description

路径时间查询方法、装置、电子设备和可读存储介质
技术领域
本公开涉及计算机技术领域，尤其涉及一种路径时间查询方法、装置、电子设备和可读存储介质。
背景技术
路径时间查询(Path Temporal Query)旨在查询出在给定时间范围内经过给定路径(一个相连的路段序列)的轨迹集合。如图1所示，给定一条虚线所示的路径e1→e2→e3和一段时间范围为10:00至11:00，路径时间查询返回满足条件的轨迹集合。
目前路径时间查询的算法主要如下：首先构建一个经过每个路段的轨迹倒排索引，进而由倒排索引确定给定每个路段的轨迹标识，最后将这些不同的轨迹标识进行集合相交(JOIN)操作，以得到满足条件的轨迹集合。
但是，现有的路径时间查询至少存在严重的效率问题，主要分为三个方面：
(1)倒排索引占用的存储空间大：倒排索引消耗存储空间大，尤其当轨迹的数据量非常庞大的时候，在内存中通常难以维持。
(2)扫描轨迹时无有效过滤：没有设计有效的过滤条件，导致扫描了大量的无效轨迹信息，而轨迹数据都是存储在数据库中，这就容易造成性能瓶颈。
(3)集合相交操作耗时大：当轨迹标识非常多时，执行JOIN操作也会非常耗时。
需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
发明内容
本公开的目的在于提供一种路径时间查询方法、装置、电子设备和可读存储介质，至少在一定程度上克服由于相关技术中路径时间范围查询的效率低的问题。
本公开的其他特性和优点将通过后续的详细描述变得显然，或部分地通过本公开的实践而习得。
根据本公开的一个方面，提供一种路径时间查询方法，包括：将待查询路径分解成多个子路径；根据子路径和设定的查询时间范围，从第一预设长度的后缀树索引中检索获得轨迹标识集合；根据子路径和轨迹标识集合，重建轨迹标识集合中的每条轨迹在查询时间范围内的行动路径；根据全部轨迹标识集合的行动路径生成查询时间范围内的轨迹集合。
在本公开的一个实施例中，路径时间查询方法还包括：确定预设的查询时间最大值和存储空间；根据查询时间最大值和存储空间，确定第一预设长度；根据第一预设长度构建基于外存的后缀树索引。
在本公开的一个实施例中，根据第一预设长度构建基于外存的后缀树索引包括：确定第一预设长度，通过第一预设长度的滑动窗对后缀树索引的轨迹进行切割，以获得第一预设长度的子轨迹；将子轨迹和经过子轨迹的起始时间确定为节点的内容，以生成后缀树索引中的节点；对节点中的预设时间段的轨迹记录的数量进行计数，并将计数结果记录至节点。
在本公开的一个实施例中，根据第一预设长度构建基于外存的后缀树索引还包括：按照时空属性对子轨迹进行分类，并按照预设周期对后缀树索引中的节点进行更新。
在本公开的一个实施例中，根据第一预设长度构建基于外存的后缀树索引还包括：将轨迹的后缀记录写入非关系型数据库的表格存储中。
在本公开的一个实施例中，在将待查询路径分解成多个子路径前，还包括：通过spark架构构建分布式后缀树索引，包括：从外部读入或者经由轨迹预处理得到查询时间范围内的匹配的子轨迹；调用平面图形化操作生成子轨迹的后缀记录；将后缀记录存储至外设存储设备中。
在本公开的一个实施例中，通过spark架构构建分布式后缀树索引还包括：调用存为Hadoop数据操作，将子轨迹的后缀记录存入到Hbase数据库中，以获得后缀树索引的后缀记录。
在本公开的一个实施例中，通过spark架构构建分布式后缀树索引还包括：利用聚合操作，对子轨迹和经过子轨迹的小时计数的组合进行计数；调用存为文本文件操作，将子轨迹的小时计数的结果存入到hdhoop分布系统中；将文本文件格式的小时计数的结果加载至内存，以获得后缀树索引。
在本公开的一个实施例中，将待查询路径分解成多个子路径包括：将待查询路径分解为第二预设长度的子路径，第二预设长度小于或等于第一预设长度，且子路径的并集为待查询路径的数据集。
在本公开的一个实施例中，将待查询路径分解为第二预设长度的子路径包括：生成第二预设长度的滑动窗；通过第二预设长度的滑动窗对待查询路径进行分解，以使子路径的数量最少。
在本公开的一个实施例中，将待查询路径分解为第二预设长度的子路径还包括：确定分解后的子路径的小时计数；根据小时计数创建第一动态转移方程；通过对第一动态转移方程进行求解，返回分解子路径的位置，以最小化子路径的小时计数的总数。
在本公开的一个实施例中，第一动态转移方程包括：
Figure BDA0002866669360000031
f1(i)表示对子路径进行分解的最小轨迹总数，ei表示第i个子路径，ej表示第j个子路径，c(ei:ej)表示由子路径ei至子路径ej对应的轨迹小时计数，H表示第二预设长度。
在本公开的一个实施例中，将待查询路径分解为第二预设长度的子路径包括：确定分解后的子路径的小时计数；根据小时计数创建第二动态转移方程；通过对第二动态转移方程进行求解，返回分解子路径的位置，以最小化每条子路径的最大的小时计数。
在本公开的一个实施例中，第二动态转移方程包括：
Figure BDA0002866669360000032
f2(i)表示对子路径进行分解的最少最大轨迹数目，ei表示第i个子路径，ej表示第j个子路径，c(ei:ej)表示由子路径ei至子路径ej对应的轨迹小时计数，H表示第二预设长度。
在本公开的一个实施例中，轨迹标识集合包括待查询路径的标识、子路径的序列和经过子路径的起始时间。
根据本公开的另一个方面，提供一种路径时间查询装置，包括：分解模块，用于将待查询路径分解成多个子路径；检索模块，用于根据子路径和设定的查询时间范围，从后缀树索引中检索获得轨迹标识集合；重建模块，用于根据子路径和轨迹标识集合，重建轨迹标识集合中的每条轨迹在查询时间范围内的行动路径；生成模块，用于根据全部轨迹标识集合的行动路径生成查询时间范围内的轨迹集合。
根据本公开的再一个方面，提供一种电子设备，包括：处理器；以及存储器，用于存储处理器的可执行指令；其中，处理器配置为经由执行可执行指令来执行上述任意一项的路径时间查询方法。
根据本公开的又一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意一项的路径时间查询方法。
本公开的实施例所提供的路径时间查询方案，通过将待查询路径分解成多个子路径，根据子路径和设定的查询时间范围，从后缀树索引中检索获得轨迹标识集合，能够克服倒排索引效率低的技术问题，能够高效地支持海量轨迹数据的路径时间查询，有效减少了查询所用时间，提高了查询效率。
其中，通过改进传统的后缀树索引的关键技术如下：
(1)设置了一个后缀索引树的最大高度，当树的高度达到设定的最大高度时，自动截断轨迹数据。
(2)在后缀树的每个节点记录有一个统计值，该统计值能够反映轨迹数据在时间上的分布情况，为后续查询处理提供优化信息。
(3)将每个后缀树索引的详细轨迹记录在外存中，以存储管理海量的历史轨迹数据，通过高效索引机制和分布式处理技术，能够实现高效的路径时间查询。
(4)基于改进的后缀树索引，本公开还提出了多种分解查询路径的方法，然后从外存中提取轨迹数据，组装成最终的查询结果。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1示出本公开实施例中一种路径时间查询方案的示意图；
图2示出本公开实施例中一种路径时间查询方法的后缀树索引的示意图；
图3示出本公开实施例中另一种路径时间查询方法的后缀树索引的示意图；
图4示出本公开实施例中一种路径时间查询方法的流程图；
图5示出本公开实施例中另一种路径时间查询方法的流程图；
图6示出本公开实施例中又一种路径时间查询方法的流程图；
图7示出本公开实施例中又一种路径时间查询方法的流程图；
图8示出本公开实施例中又一种路径时间查询方法的流程图；
图9示出本公开实施例中又一种路径时间查询方法的流程图；
图10示出本公开实施例中又一种路径时间查询方法的流程图；
图11示出本公开实施例中又一种路径时间查询方法的流程图；
图12示出本公开实施例中又一种路径时间查询方法的流程图；
图13示出本公开实施例中又一种路径时间查询方法的流程图；
图14示出本公开实施例中又一种路径时间查询方法的流程图；
图15示出本公开实施例中又一种路径时间查询方法的流程图；
图16示出本公开实施例中又一种路径时间查询方法的流程图；
图17示出本公开实施例中一种路径时间查询方案的流程图；
图18示出本公开实施例中另一种路径时间查询方案的流程图；
图19示出本公开实施例中又一种路径时间查询方案的流程图；
图20示出本公开实施例中又一种路径时间查询方案的流程图；
图21示出本公开实施例中一种路径时间查询方案的测试结果的示意图；
图22示出本公开实施例中一种路径时间查询方案的测试结果的示意图；
图23示出本公开实施例中一种路径时间查询方案的测试结果的示意图；
图24示出本公开实施例中一种路径时间查询方案的测试结果的示意图；
图25示出本公开实施例中一种路径时间查询方案的测试结果的示意图；
图26示出本公开实施例中一种路径时间查询装置的示意图；
图27示出本公开实施例中一种电子设备的示意图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。
此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
本公开提供的方案，通过将待查询路径分解成多个子路径，根据子路径和设定的查询时间范围，从后缀树索引中检索获得轨迹标识集合，能够克服倒排索引效率低的技术问题，能够高效地支持海量轨迹数据的路径时间查询，有效减少了查询所用时间，提高了查询效率。
如图1所示，在本公开的路径时间查询方案中，涉及到以下几个关键概念：
(1)GPS点(GPSPoint)：GPS点p＝(lat；lng；t)包含一个纬度lat，一个经度lng，以及一个时间戳t。表示移动物体在t时刻，位于地理坐标位置(lat；lng)。
(2)轨迹(Trajectory)：一条轨迹tr＝＜p1→p2→…→pn＞是将同一个移动对象产生的GPS点按时间先后顺序排序所组成的序列，即：
Figure BDA0002866669360000061
pi.t＜pi+1.t。
(3)路径(Path)：路径P＝＜e1→e2→…→en＞是一组连续路段的集合，其中路段的顺序即为对象移动的顺序。通常使用一个自然数代表路段标识。
如图1所示，基于路径时间范围查询，将路径102分解为子路径e1、子路径e2和子路径e3，从海量轨迹数据集确定匹配轨迹，并将匹配轨迹聚合形成轨迹数据集104，每条数据记录均用于描述经过的子路径和起始时间。
(4)匹配后的轨迹(MapMatchTrajectory)：轨迹经过地图匹配算法后可映射至路段的路段，形成匹配后的轨迹tr＝＜(e1，t1)→(e2，t2)→…→(en，tn)＞。其中，ei指的是路网上第i条子路径的标识，ti指的是移动对象进入该子路径的时间。下文中，如无特殊说明，所说的轨迹均为匹配后的轨迹。
(5)路径时间范围查询(PathTemporalRangeQuery)：给定一条路径P，一个时间范围[ts，te]以及一个匹配轨迹集合T，路径时间范围查询找到T中所有匹配轨迹tri，其存在某条子轨迹tr′i＝＜(e1，t1)→(e2，t2)→…→(ek，tk)＞恰好在给定时间段内经过路径P，即：t1≥ts，tk≤te。
本公开实施例提供的方案涉及后缀树、路径分解和分布式架构等技术，具体通过如下实施例进行说明。
上述路径时间查询方案可以通过多个终端和服务器集群的交互实现。
终端可以是手机、游戏主机、平板电脑、电子书阅读器、智能眼镜、MP4(MovingPicture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、智能家居设备、AR(Augmented Reality，增强现实)设备、VR(Virtual Reality，虚拟现实)设备等移动终端，或者，终端也可以是个人计算机(Personal Computer，PC)，比如膝上型便携计算机和台式计算机等等。
其中，终端中可以安装有用于提供路径时间查询的应用程序。
终端与服务器集群之间通过通信网络相连。可选的，通信网络是有线网络或无线网络。
服务器集群是一台服务器，或者由若干台服务器组成，或者是一个虚拟化平台，或者是一个云计算服务中心。服务器集群用于为提供路径时间查询的应用程序提供后台服务。可选地，服务器集群承担主要计算工作，终端承担次要计算工作；或者，服务器集群承担次要计算工作，终端承担主要计算工作；或者，终端和服务器集群之间采用分布式计算架构进行协同计算。
在一些可选的实施例中，后缀树索引最开始是用来索引字符串，能够提高字符串后缀搜索的性能。在轨迹数据管理中，匹配后的轨迹可以看作是一个字符串，每个路段的标识等价于字符串的一个字符，路径查询(不考虑时间过滤条件)可以映射成字符串的后缀搜索问题，即：利用路段标识序列进行搜索可以看作是利用字符序列进行搜索。
如图2所示，轨迹tr1依次经过了四条子路径：e1、e2、e3和e4。因此这条轨迹自根节点Root起，生成了四个后缀，即：＜e1→e2→e3→e4＞、＜e2→e3→e4＞、＜e3→e4＞和＜e4＞。这四个后缀随后插入到后缀树索引中的对应位置。每个节点记录着经过对应路径的轨迹标识以及经过的起止时间。
譬如，tr1经过子路径e1、子路径e2、子路径e3和子路径e4这四条子路径的记录为tr1：(e1，10:31)→(e2，10:32)→(e3，10:35)→(e4，10:38)。Tr2经过子路径e1、子路径e2和子路径e4这三条子路径的记录为tr2：(e1，10:35)→(e2，10:37)→(e4，10:38)→(e4，10:38)。
基于上述记录，利用后缀树索引的查询处理包括：当需要查询经过给定路径的轨迹时，只需遍历后缀树索引中对应的节点，获得对应的记录即可。例如，给定查询路径P＝＜e1＞，从根节点开始，依次遍历节点的子路径e1，匹配的所有轨迹记录将会被返回，即“tr1，10:31→10:31”和“tr2，10:35→10:35”。又如，给定查询路径P＝＜e1→e2＞，从根节点Root开始，依次遍历节点的子路径e1和的子路径e2，匹配的所有轨迹记录将会被返回，即“tr1，10:31→10:32”和“tr2，10:35→10:37”。
然而，如图2所示后缀树索引需要占用非常多的内存空间来存储轨迹的后缀，因为即使对一条轨迹进行查询，将会产生非常多的后缀。当轨迹数据集非常大时，后缀树索引也会非常大。更进一步，上述后缀树索引也没有对查询时间进行优化，查询特定时间段的轨迹将会访问很多无效的数据，造成许多不必要的I/O(Input/Output，即输入/输出)开销。因此，现有的系统仅仅利用后缀树索引来处理最近一段时间或者更新最频繁的轨迹，无法支持历史轨迹数据集上的路径查询，也不支持时间范围的过滤。
在一些可选的实施例中，服务器集群用于存储路径时间的查询结果和后缀结果，譬如，经过子路径的车牌号、待查询路径的标识、子路径的序列、经过子路径的起始时间和单位时间内经过子路径的轨迹的计数值等，但不限于此。
如图3所示，为了高效支持大规模轨迹数据上的路径时间范围查询，本公开在图2所示的后缀树索引上进行了改进，改进后的后缀树索引包括两个重要部分：(1)后缀树，包含一个树结构以及一系列的统计信息。其中，后缀树可分布式存储，譬如Hbase(HBase是一种Hadoop数据库，经常被描述为一种稀疏的，分布式的，持久化的，多维有序映射，它基于行键、列键和时间戳建立索引，是一个可以随机访问的存储和检索数据的平台)，当执行查询时加载到内存中；(2)后缀记录，真正存储了轨迹的记录信息。
相较于图2所示的后缀树索引，图3所示的基于外存的后缀树索引有三个特点：
(1)最大高度：为控制后缀树占用空间的大小，本公开为其设定一个最大高度H。换言之，后缀树仅包含长度不超过H的子轨迹信息，由于长度为H的路径数目有限，因此不论轨迹数目有多大，均可确保后缀树结构能完全加载至内存中。
如图3所示，设置后缀树索引的最大高度H为3，选择一个合适的最大高度H对系统来说是一个权衡，若H很小，因为产生了更小的路径后缀则更有利于索引构建，但同时查询效率会降低，因为需更多的集合交集操作以及更多的磁盘I/O开销。
(2)小时计数：在每个后缀树节点中维护一个字典。将一天按小时分为24段，字典中存储了对应小时内经过该后缀树节点(每个节点代表了从根节点到该节点的一系列路段)的轨迹平均数目。
以图3为例，给出了节点的子路径e1和子路径e2的实施例，小时计数为后续的查询处理模块提供了一些信息，能够指定更有效的查询计划，进而减少数据访问节省查询时间。
(3)表格存储：后缀索引树的真实轨迹数据存储在NoSQL(泛指非关系型的数据库)中，实际上，本公开采用了HBase，因为其具有很强的扩展性和较高的查询效率。每个后缀树节点都能够唯一地对应一个路段标识序列，因此可将其拼接作为轨迹记录在HBase中键的前缀pre。另外，本公开为了区分不同的路段组合，如：e1(1)→e2(23)和e1(12)→e2(3)，需在其间添加一个分隔符(如1_23和12_3)，否则无法恢复pre＝123的实际路段组合。
进一步地，如图3所示，对于存储在HBase中的轨迹记录，其键值包括三方面信息：1)对应后缀树中的节点表示的前缀pre；2)精确到毫秒级别的时间戳ts；3)车牌号plate标识。这表示车辆plate标识在时间点ts时开始进入路径pre，并依次顺序经过了此路径pre。
在一些可选的实施例中，NoSQL存储的键是按字典序排序的，为了保证结果的正确性，基本想法是要求不同记录的pre所占用的字节数相同，即设置统一的前缀字节长度lenpre，当长度不足lenpre时，则填充空白字符。但这种方法可能会造成存储空间的浪费，一种极端的情况为：当pre＝1只有一个字符时，冗余的字节数为lenpre-1。
进一步地，本公开为了解决存储空间浪费问题，在前缀pre和时间戳ts之间使用一个特殊分隔符，例如@，该分隔符不是pre、ts和plate标识中任何可能的字符，即可保证查询结果的正确性。
例如，若需要找到在2020年5月31日23时至2020年6月1日1时经过路段标识为1和20的路径的轨迹，若不采用填充方法且pre与ts间的分隔符与pre内的分隔符一致(均为_)，则产生的扫描键范围为[1_20_2020053123，1_20_2020060101]。
又如，若有一条记录的键为1_20_20200532_202004290032bjA001，在扫描过程中也会将这条不满足条件的数据取出，其原因为刚好出现“借位”的情况，因此，引入特殊分隔符则可避免这种情况。
另外，本公开的实施例中，键的末尾加上车牌号很重要，因为不同的车辆可能在同一时刻进入同一个路段当中，加上车牌号能够避免键值冲突。
其中，对于NoSQL中每条记录的值，应当包括三部分信息：1)车牌号plate标识；2)该车辆进入对应路径的时间ts；3)该车辆离开对应路径的时间te。而实际情况中，在每条记录的键中存储了车牌号和进入时间，因此只需在值中存储离开时间即可，可以高效地查询出给定时间内经过给定路径的车辆。
可选地，不同的终端中安装的应用程序的客户端是相同的，或两个终端上安装的应用程序的客户端是不同控制系统平台的同一类型应用程序的客户端。基于终端平台的不同，该应用程序的客户端的具体形态也可以不同，比如，该应用程序客户端可以是手机客户端、PC客户端或者全球广域网客户端等。
本领域技术人员可以知晓，上述终端的数量可以更多或更少。比如上述终端可以仅为一个，或者上述终端为几十个或几百个，或者更多数量。本公开实施例对终端的数量和设备类型不加以限定。
可选的，该系统还可以包括管理设备，该管理设备与服务器集群之间通过通信网络相连。可选的，通信网络是有线网络或无线网络。
可选的，上述的无线网络或有线网络使用标准通信技术和/或协议。网络通常为因特网、但也可以是任何网络，包括但不限于局域网(Local Area Network，LAN)、城域网(Metropolitan Area Network，MAN)、广域网(W标识e Area Network，WAN)、移动、有线或者无线网络、专用网络或者虚拟专用网络的任何组合)。在一些实施例中，使用包括超文本标记语言(Hyper Text Mark-up Language，HTML)、可扩展标记语言(ExtensibleMarkupLanguage，XML)等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层(Secure Socket Layer，SSL)、传输层安全(Transport Layer Security，TLS)、虚拟专用网络(Virtual Private Network，VPN)、网际协议安全(InternetProtocolSecurity，IPsec)等常规加密技术来加密所有或者一些链路。在另一些实施例中，还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。
下面，将结合附图及实施例对本示例实施方式中的路径时间查询方法的各个步骤进行更详细的说明。
图4示出本公开实施例中一种路径时间查询方法流程图。本公开实施例提供的方法可以由任意具备计算处理能力的电子设备执行，例如如图1中的终端120和/或服务器集群140。在后续的举例说明中，以终端120为执行主体进行示例说明。
如图4所示，服务器集群140执行路径时间查询方法，包括以下步骤：
步骤S402，将待查询路径分解成多个子路径。
步骤S404，根据子路径和设定的查询时间范围，从第一预设长度的后缀树索引中检索获得轨迹标识集合。
步骤S406，根据子路径和轨迹标识集合，重建轨迹标识集合中的每条轨迹在查询时间范围内的行动路径。
步骤S408，根据全部轨迹标识集合的行动路径生成查询时间范围内的轨迹集合。
在上述实时例中，路径时间查询的过程共包含三个部分：1)路径分解，将查询路径P分解成多个子路径；2)后缀记录检索，根据分解的子路径以及查询时间范围，从后缀记录中找出候选的轨迹ID集合；3)轨迹重建，根据子路径和查询出的候选轨迹ID集合，可以重建出每条轨迹在给定时间范围内的行动路径。最后，得到满足条件的轨迹集合。通过将待查询路径分解成多个子路径，根据子路径和设定的查询时间范围，从后缀树索引中检索获得轨迹标识集合，能够克服倒排索引效率低的技术问题，能够高效地支持海量轨迹数据的路径时间查询，有效减少了查询所用时间，提高了查询效率。
基于图4所示的步骤，如图5所示，路径时间查询方法还包括：
步骤S502，确定预设的查询时间最大值和存储空间。
步骤S504，根据查询时间最大值和存储空间，确定第一预设长度。
步骤S506，根据第一预设长度构建基于外存的后缀树索引。
在一些可选的实施例中，后缀树索引的创建包括以下步骤：
(1)后缀生成：匹配后的轨迹中产生所有长度不超过H的后缀。本质上来说，分别利用大小从1到H的滑动窗口，以步长1滑动，对轨迹进行切割。
例如，如果本公开设H＝2，给定匹配轨迹tr＝＜(e1，t1)→(e2，t2)→(e3，t3)＞，首先用大小为1的滑动窗口进行切割，得到3个子轨迹：＜(e1，t1)＞、＜(e2，t2)＞和＜(e3，t3)＞，然后用大小为2的滑动窗口进行切割，得到2个子轨迹：＜(e1，t1)，(e2，t2)＞和＜(e2，t2)，(e3，t3)＞。
(2)索引更新：对上一步获得的子轨迹按照路径和时间进行分组，然后更新后缀树中每个节点在每个小时的统计值。例如，对在上午十点到十一点经过路径＜e1→e2→e3＞的轨迹进行分组，然后更新索引中对应节点的小时计数。
(3)记录插入：将轨迹记录插入到NoSQL的表格存储中，在相邻时间段内经过相同路径的轨迹会存储在一起，这样就能高效地查询出满足条件的那些轨迹信息。
基于图4和图5所示的步骤，如图6所示，根据第一预设长度构建基于外存的后缀树索引包括：
步骤S6062，确定第一预设长度，通过第一预设长度的滑动窗对后缀树索引的轨迹进行切割，以获得第一预设长度的子轨迹。
步骤S6064，将子轨迹和经过子轨迹的起始时间确定为节点的内容，以生成后缀树索引中的节点。
步骤S6066，对节点中的预设时间段的轨迹记录的数量进行计数，并将计数结果记录至节点。
在上述实施例中，将查询路径P分解成多条子路径，每条子路径的长度不超过H，对应后缀索引树上的一个节点。分解后的子路径用于从后缀索引记录中检索候选轨迹信息。将一条路径分解成多个长度不大于H的子路径有多种方式，选择一种合适的分解方式对提高查询处理效率非常重要。为了有效地利用NoSQL表中的后缀记录，需要满足以下两个要求：
要求1：
Figure BDA0002866669360000121
即每个分解后的子路径长度应等于H，因为这样能够从NoSQL存储中返回最少的候选轨迹记录，从而减少I/O开销，提升效率。
要求2：
Figure BDA0002866669360000122
即所有子路径的路段集合的并集应等于查询路径P。否则，若只覆盖了部分路段，将会返回那些没有真正经过查询路径的轨迹记录。例如：假如P＝＜e1→e2→e3＞，子路径中只覆盖了＜e1→e2＞，那么返回的轨迹中可能只经过了＜e1→e2→e4＞，这并不满足条件。
每条子路径在不同的查询时间范围内可能包含不同的轨迹数目，例如：在市中心区域或者早高峰时期轨迹多，在郊区或者深夜轨迹少。在查询处理过程中，不同的路径分解方法返回的轨迹记录是不同的，这对查询响应时间影响很大。本公开通过小时计数刻画了每条子路径的轨迹数目的近似分布，因此可以通过这些信息选择一种较好的路径分解方式。
基于图4和图6所示的步骤，如图7所示，根据第一预设长度构建基于外存的后缀树索引还包括：
步骤S702，按照时空属性对子轨迹进行分类，并按照预设周期对后缀树索引中的节点进行更新。
基于图4、图5和图6所示的步骤，如图8所示，根据第一预设长度构建基于外存的后缀树索引还包括：
步骤S802，将轨迹的后缀记录写入非关系型数据库的表格存储中。
基于图4所示的步骤，如图9所示，在将待查询路径分解成多个子路径前，还包括：
通过spark架构构建分布式后缀树索引，包括：
步骤S902，从外部读入或者经由轨迹预处理得到查询时间范围内的匹配的子轨迹。
步骤S904，调用平面图形化操作生成子轨迹的后缀记录。
步骤S906，将后缀记录存储至外设存储设备中。
在一些可选的实施例中，为了克服后缀树构建的I/O瓶颈，本公开提出了一个基于分布式索引框架Spark的索引构建方案，本公开选择Spark的原因包括：
(1)Spark提供了高可用、高效率和高扩展的分布式计算能力，具有强大的大数据处理能力。
(2)通过Spark，后缀产生的操作能够在多个不同的节点进行，加快了执行效率。
(3)利用Spark的多个计算节点，可以克服系统写大量数据到NoSQL中的I/O瓶颈。
基于图4和图9所示的步骤，如图10所示，通过spark架构构建分布式后缀树索引还包括：
步骤S1002，调用存为Hadoop数据操作，将子轨迹的后缀记录存入到Hbase数据库中，以获得后缀树索引的后缀记录。
基于图4和图9所示的步骤，如图11所示，通过spark架构构建分布式后缀树索引还包括：
步骤S1102，利用聚合操作，对子轨迹和经过子轨迹的小时计数的组合进行计数。
步骤S1104，调用存为文本文件操作，将子轨迹的小时计数的结果存入到hdhoop分布系统中。
步骤S1106，将文本文件格式的小时计数的结果加载至内存，以获得后缀树索引。
基于图4所示的步骤，如图12所示，将待查询路径分解成多个子路径包括：
步骤S1202，将待查询路径分解为第二预设长度的子路径，第二预设长度小于或等于第一预设长度，且子路径的并集为待查询路径的数据集。
基于图4所示的步骤，如图13所示，将待查询路径分解为第二预设长度的子路径包括：
步骤S1302，生成第二预设长度的滑动窗。
步骤S1304，通过第二预设长度的滑动窗对待查询路径进行分解，以使子路径的数量最少。
在上述实施例中，通过最少子路径数目(Minimum Sub-path Number，MSN)进行路径分解，该方法使用一个长度为H滑动窗口，然后以步长H对查询路径进行分解。其主要想法是让分解后的子路径数目最小，因为每个子路径会触发一次NoSQL查询，因此本质上也是使NoSQL查询次数最少。
例如，假设后缀树索引的最大高度H为3，查询路径为P＝＜e1→e2→e3→e4→e5→e6→e7→e8＞，MSN方法将查询路径P分解成三条子路径：P1＝＜e1→e2→e3＞、P2＝＜e4→e5→e6＞和P3＝＜e7→e8→e9＞。
基于图4所示的步骤，如图14所示，将待查询路径分解为第二预设长度的子路径还包括：
步骤S1402，确定分解后的子路径的小时计数。
步骤S1404，根据小时计数创建第一动态转移方程。
步骤S1406，通过对第一动态转移方程进行求解，返回分解子路径的位置，以最小化子路径的小时计数的总数。
在上述实施例中，最少轨迹总数(Minimum Total Count，MTC)。该方法的目标是最小化分解后的路径所对应的小时计数总数。本质上来说，这种方法希望减少从NoSQL中获取轨迹记录的数目。本公开构建了一个动态规划算法来找到MTC方法的最佳分解方案，其动态转移方程如下所示：
Figure BDA0002866669360000151
其中，f(i)表示对路径＜e1→e2→…→ei＞进行MTC路径分解的最小轨迹总数。c(ei：ej)表示路径＜ei→…→ej＞对应的轨迹小时计数。当查询路径的长度大于H时，其最后一个后缀＜ei-H+1→…→ei＞)肯定会作为分解子路径，这样才能满足要求1和要求2。本公开使用一个长度为|P|的数组u来记录每一步中最优的分解方案，数值u[i]表示最近一次划分的位置。动态规划算法从数组u的最后往前对查询路径进行扫描，最后返回分解的结果。其时间复杂度为O(n)，其中n表示查询路径的长度。
结合表1、表2和表3，给出了一个查询路径分解的例子，其中P＝＜e1→…→e8＞，H＝3。
表1
后缀 e<sub>1</sub>e<sub>2</sub>e<sub>3</sub> e<sub>2</sub>e<sub>3</sub>e<sub>4</sub> e<sub>3</sub>e<sub>4</sub>e<sub>5</sub> e<sub>4</sub>e<sub>5</sub>e<sub>6</sub> e<sub>5</sub>e<sub>6</sub>e<sub>7</sub> e<sub>6</sub>e<sub>7</sub>e<sub>8</sub>
计数 60 20 50 85 1 70
表2
Figure BDA0002866669360000152
表3
Figure BDA0002866669360000161
表1显示了对应查询时间范围内每组后缀的小时计数，表2显示了分解过程，其中列i表示的是步骤数目，f(i)计算了每一步候选轨迹记录的总数，u记录了每一步最优的分解位置。
从u最后往前看，发现u[8]＝7，表明路径＜e5→e6→e7＞在最后的解中。
u[7]＝4，表明路径＜e2→e3→e4＞在最后的解中。
进一步，u[4]＝3，表明路径＜e1→e2→e3＞在最后的解中。
u[3]＝0，终止探查。
最终，查询路径被分解成四个子路径：p1＝＜e1→e2→e3＞、p2＝＜e2→e3→e4＞、p3＝＜e5→e6→e7＞和p4＝＜e6→e7→e8＞，其总共的小时计数为151。
在本公开的一个实施例中，第一动态转移方程包括：
Figure BDA0002866669360000162
f1(i)表示对子路径进行分解的最小轨迹总数，ei表示第i个子路径，ej表示第j个子路径，c(ei：ej)表示由子路径ei至子路径ej对应的轨迹小时计数，H表示第二预设长度。
其中，f1(i)表示对路径＜e1→…→ei＞按MMC策略分解的最少最大轨迹数目。同样，利用一个数组u来记录每一步分解策略。算法的时间复杂度也与查询路径的长度呈线性关系。
基于图4所示的步骤，如图15所示，将待查询路径分解为第二预设长度的子路径包括：
步骤S1502，确定分解后的子路径的小时计数。
步骤S1504，根据小时计数创建第二动态转移方程。
步骤S1506，通过对第二动态转移方程进行求解，返回分解子路径的位置，以最小化每条子路径的最大的小时计数。
在上述实施例中，通过最少最大轨迹数目(Minimize Max Count，MMC)进行路径分解，该方法最小化每条子路径的最大小时计数。其基本思想是尽量减少最坏情况下的子路径所对应的轨迹记录，从而减少总体时间开销。这种方法在分布式环境中特别有用，因为在分布式环境中，最终的查询处理时间取决于最后完成的子任务。本公开采用类似的动态规划算法来找到MMC条件下最佳的路径分解方案。
表1和表3给出了一个MMC条件下的路径分解例子，其中路径P被分解成了三条子路径p1＝＜e1→e2→e3＞、p2＝＜e3→e4→e5＞和p3＝＜e6→e7→e8＞。
综上，与MTC方法相比，MMC方法返回的记录总数更多，即180和151，但是每个子路段的记录数的差值更小，即|50-70|和|70-1|。
在本公开的一个实施例中，第二动态转移方程包括：
Figure BDA0002866669360000171
f2(i)表示对子路径进行分解的最少最大轨迹数目，ei表示第i个子路径，ej表示第j个子路径，c(ei：ej)表示由子路径ei至子路径ej对应的轨迹小时计数，H表示第二预设长度。
在本公开的一个实施例中，轨迹标识集合包括待查询路径的标识、子路径的序列和经过子路径的起始时间。
如图16所示，基于Spark的分布式后缀树索引构建的过程，首先从外部读入或者经由轨迹预处理得到匹配轨迹RDD[MMTrajectory]，然后调用flatMap(扁平视图化)操作生成轨迹的后缀RDD[Suffix]。使用flatMap的原因是，每条匹配轨迹会分解得到多个后缀。尽管每条匹配轨迹会产生非常多的后缀，执行时间复杂度高，但是本公开充分利用了多台机器的内存和CPU资源，因此效率很快。
基于此，会产生两个数据流，第一个数据流是利用操作saveAsHadoopDataset(存为Hadoop数据集)将RDD[Suffix]存入到HBase中，得到后缀树索引的后缀记录，这个过程是分布式进行的，充分利用了多台机器的I/O带宽，因此效率很高；第二个数据流是利用reduceByKey(聚合)操作，对后缀树按照后缀树的路径和小时数的组合进行计数，这里尽管触发了Spark的shuffle操作(即存在不同机器之间进行数据交换)，但这是不可避免的，利用reduceByKey而不是groupByKey(群键)的原因是reduceByKey操作只会传输计数而不是后缀本身，传输的数据量非常少，因此效率也是非常快的。最后，本公开调用saveAsTextFile(存为文本文件)操作将路径小时计数存入到HDFS中，得到上层后缀树结构，为后续查询优化提供有用的信息。
在Spark分布式架构中，数据通常不跨分区分布，以便在特定操作的必要位置。在计算过程中，单个任务将在单个分区上运行，因此，要组织单个reduceByKey的reduce任务执行的所有数据，Spark需要执行全部操作。它必须从所有分区读取以查找所有键的所有值，然后将各个值组合在一起以计算每个键的最终结果，这称为shuffle。
需要注意的是，上述附图仅是根据本公开示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。
所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。
图17至图20，示出了路径时间查询方案的一个实施例。
如图17所示，根据给定的路径时间范围查询为：e1→e2→e3→e4，[10:20,10:25]，路径分解为e1e2e3，[10:20,10:25]，e2e3e4，[10:20,10:25]。
如图18所示，构建后缀树索引，并获得后缀记录检索，即轨迹记录。
如图19所示，根据轨迹记录进行轨迹重建，并获得后缀记录检索。
如图20所示，根据轨迹重建结果，生成查询结果为tr1[10:21,10:24]，e1→e2→e3→e4。
图17至图20，示出了路径时间查询方案的测试过程的一个实施例。
测试环境配置：1)T-Drive，这是一个公开数据集，包含北京10000多辆出租车的GPS点信息，时间跨度从2008年2月2日到2008年2月8日共7天；2)使用Spark预处理轨迹，HBase作为底层NoSQL存储。3)所有的实验均在一个具有5个节点的集群中执行，每个节点安装有Centos7.4操作系统，具有8核CPU、32GB内存和1T普通机械磁盘。
为了验证提出的基于后缀树索引的路径时间范围查询的性能，我们比较了两种对比方法：1)基于外存的倒排索引方法II，即当H＝1时后缀树索引方法就退化成倒排索引。2)基于时空的过滤方法ST(Space and Time)，即先求得查询路径的最小外包矩形(MinimumBounding Rectangle，MBR)，然后以此MBR对轨迹执行时空范围查询(即查询在给定空间和时间的轨迹)，最后验证查询出的每一条轨迹是否完全经过给定的路径。实验使用的T-Drive数据集，原始大小约767MB，在做完路径匹配后，匹配轨迹大小达到了5GB，这进一步说明了采用外存构建索引的必要性。
(1)索引性能比较：随着数据集的增大，不同方法的索引所占磁盘空间和索引时间的变化情况。这里没有比较ST方法的索引性能，因为ST方法没有构建额外的索引。对于H＞1的后缀树索引，只考虑其长度为H的后缀，随着数据集的增大，所有方法的索引大小和索引时间都呈线性增长，这也说明如果要支持超大规模轨迹数据的路径时间范围查询，在内存中构建索引不是一个好的方法，需要将索引记录存储到外存中。
如图21所示，基于外存的倒排索引方法II的索引比后缀索引占用的空间小些，而且随着H的增加，索引空间越大，因为索引的键所占空间随着H的增大而增大。
如图22所示，索引时间并不一直随着H的增大而增大，一方面是因为分布式环境中索引时间受诸多外部环境(例如网络抖动等)影响，另一方面，H越小时，相同长度的轨迹产生的大小等于H的后缀越多，造成插入外存的数据条目更多。
查询性能比较。我们还比较了不同方法的查询响应时间随着查询参数和数据集的变化情况，注意其纵轴为log尺度的。这里默认的数据集大小为所有的T-Drive的数据，默认的后缀树高度H＝3，默认的查询路径长度为15，默认的查询时间窗口大小为3小时。
经过测试可以得出以下结论：
1)基于后缀树索引方法和倒排索引方法比ST方法快很多，因为在ST方法中，根据查询路径的MBR查询出了很多无效的完整轨迹记录信息，导致磁盘I/O非常多。更进一步，验证每条轨迹是否完全经过给定路径也非常耗时。
相反，基于后缀树索引和倒排索引的方法只是读出了少量的必要的轨迹记录信息，同时通过集合相交的操作来验证是否完全经过给定路径，比从头开始验证轨迹是否经过给定路径效率更快。
2)基于后缀树索引的方法比基于倒排索引方法的查询性能高，原因有两点，第一，基于后缀树的方法根据分解后的子路径查询的轨迹信息比单个路段查询出的轨迹信息少，减少了磁盘的读写。更少的轨迹信息也能够加速集合相交的操作。第二，基于后缀树的方法分解的子路径数目更少，查询NoSQL的次数少，返回的集合数也更少，这也加快了集合相交的效率。
3)在分布式环境下，MMC比MSN和MTC方法更优。
因为MMC最小化了每个子查询最大开销，在分布式并行计算的环境下，整体的查询效率取决于最慢的那个子查询。
4)如图23所示，在固定查询路径长度的前提下，所有方法的查询响应时间随着查询时间窗口的增加而逐渐增加。因为时间窗口越长，返回的轨迹更多，增加了磁盘读写和验证计算开销。
5)如图24所示，在固定查询窗口的情况下，所有方法的查询响应时间随着查询路径的长度增加而增加，这容易理解，随着查询路径的长度增加，对于后缀树索引方法和倒排索引方法而言，子查询就更多了，需要进行集合相交操作也更多。
对于ST方法而言，查询路径越长，查询MBR通常也越大，查询出的轨迹也越多。
6)如图25所示，在给定查询参数的情况下，所有方法的查询响应时间随着数据集的增大而增大。因为数据集越大，满足条件的数据就越多，增大了计算开销和磁盘开销。
7)对于后缀树索引方法而言，H值越大，查询效率更高(见图25所示)。
因为H值越大，查询路径分解的子路径很可能越少，子查询越少，而且每个子查询返回的轨迹也越少。
不过，H值也不宜过大，因为H值越大，构建后缀树索引时产生的轨迹后缀越多，存储空间也就越大，即使我们只存储长度为H的后缀，当查询路径长度小于H时，就会退化成倒排索引的方法，查询性能会收到影响。
因此，H的取值应该根据具体的业务场景、空间索引大小预算而定。
下面参照图26来描述根据本公开的这种实施方式的路径时间查询装置2600。图26所示的路径时间查询装置2600仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
路径时间查询装置2600以硬件模块的形式表现。路径时间查询装置2600的组件可以包括但不限于：分解模块2602、检索模块2604、重建模块2606和生成模块2608。
分解模块2602，用于将待查询路径分解成多个子路径；
检索模块2604，用于根据所述子路径和设定的查询时间范围，从第一预设长度的后缀树索引中检索获得轨迹标识集合；
重建模块2606，用于根据所述子路径和所述轨迹标识集合，重建所述轨迹标识集合中的每条轨迹在所述查询时间范围内的行动路径；
生成模块2608，用于根据全部所述轨迹标识集合的行动路径生成所述查询时间范围内的轨迹集合。
本公开提出了一种改进的基于外存的后缀树索引结构，通过改造传统后缀树，如设置树的最大高度、对每个节点记录统计值和将真实的轨迹信息记录在外存，克服了大规模轨迹数据下传统索引结构无法常驻内存的问题，同时提出了多种启发式的路径分解算法，结合精心设计的索引计值和分布式处理框架，实现了高效的查询。
针对路径时间范围查询的问题，与传统的倒排索引解决方案相比，本公开在保证正确性的前提下，通过设计高效的算法和结合分布式系统，大大提高了查询效率。
下面参照图27来描述根据本公开的这种实施方式的电子设备2700。图27显示的电子设备2700仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
如图27所示，电子设备2700以通用计算设备的形式表现。电子设备2700的组件可以包括但不限于：上述至少一个处理单元2710、上述至少一个存储单元2720、连接不同系统组件(包括存储单元2720和处理单元2710)的总线2730。
其中，存储单元存储有程序代码，程序代码可以被处理单元2710执行，使得处理单元2710执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。例如，处理单元2710可以执行如图1中所示的步骤S202、S204、S206、S2027和S227，以及本公开的路径时间查询方法中限定的其他步骤。
存储单元2720可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)27201和/或高速缓存存储单元27202，还可以进一步包括只读存储单元(ROM)27203。
存储单元2720还可以包括具有一组(至少一个)程序模块27205的程序/实用工具27204，这样的程序模块27205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
总线2730可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
电子设备2700也可以与一个或多个外部设备2740(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备交互的设备通信，和/或与使得该电子设备2700能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口2750进行。并且，电子设备2700还可以通过网络适配器2760与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器2760通过总线2730与电子设备2700的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RA标识系统、磁带驱动器以及数据备份存储系统等。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。
在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。
根据本公开的实施方式的用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (18)

1.一种路径时间查询方法，其特征在于，包括：
将待查询路径分解成多个子路径；
根据所述子路径和设定的查询时间范围，从第一预设长度的后缀树索引中检索获得轨迹标识集合；
根据所述子路径和所述轨迹标识集合，重建所述轨迹标识集合中的每条轨迹在所述查询时间范围内的行动路径；
根据全部所述轨迹标识集合的行动路径生成所述查询时间范围内的轨迹集合。
2.根据权利要求1所述的路径时间查询方法，其特征在于，还包括：
确定预设的查询时间最大值和存储空间；
根据所述查询时间最大值和所述存储空间，确定所述第一预设长度；
根据所述第一预设长度构建所述基于外存的后缀树索引。
3.根据权利要求2所述的路径时间查询方法，其特征在于，根据所述第一预设长度构建所述基于外存的后缀树索引包括：
确定所述第一预设长度，通过所述第一预设长度的滑动窗对所述后缀树索引的轨迹进行切割，以获得所述第一预设长度的子轨迹；
将所述子轨迹和经过所述子轨迹的起始时间确定为节点的内容，以生成所述后缀树索引中的节点；
对所述节点中的预设时间段的轨迹记录的数量进行计数，并将所述计数结果记录至所述节点。
4.根据权利要求3所述的路径时间查询方法，其特征在于，根据所述第一预设长度构建所述基于外存的后缀树索引还包括：
按照时空属性对所述子轨迹进行分类，并按照预设周期对所述后缀树索引中的节点进行更新。
5.根据权利要求3所述的路径时间查询方法，其特征在于，根据所述第一预设长度构建所述基于外存的后缀树索引还包括：
将所述轨迹的后缀记录写入非关系型数据库的表格存储中。
6.根据权利要求1所述的路径时间查询方法，其特征在于，在将待查询路径分解成多个子路径前，还包括：
通过spark架构构建分布式后缀树索引，包括：
从外部读入或者经由轨迹预处理得到所述查询时间范围内的匹配的子轨迹；
调用平面图形化操作生成所述子轨迹的后缀记录；
将所述后缀记录存储至外设存储设备中。
7.根据权利要求6所述的路径时间查询方法，其特征在于，通过spark架构构建分布式后缀树索引还包括：
调用存为Hadoop数据操作，将所述子轨迹的后缀记录存入到Hbase数据库中，以获得所述后缀树索引的后缀记录。
8.根据权利要求6所述的路径时间查询方法，其特征在于，通过spark架构构建分布式后缀树索引还包括：
利用聚合操作，对所述子轨迹和经过所述子轨迹的小时计数的组合进行计数；
调用存为文本文件操作，将所述子轨迹的小时计数的结果存入到hdhoop分布系统中；
将文本文件格式的小时计数的结果加载至内存，以获得所述后缀树索引。
9.根据权利要求1所述的路径时间查询方法，其特征在于，将待查询路径分解成多个子路径包括：
将所述待查询路径分解为第二预设长度的子路径，所述第二预设长度小于或等于所述第一预设长度，且所述子路径的并集为所述待查询路径的数据集。
10.根据权利要求9所述的路径时间查询方法，其特征在于，将所述待查询路径分解为第二预设长度的子路径包括：
生成所述第二预设长度的滑动窗；
通过所述第二预设长度的滑动窗对所述待查询路径进行分解，以使所述子路径的数量最少。
11.根据权利要求9所述的路径时间查询方法，其特征在于，将所述待查询路径分解为第二预设长度的子路径还包括：
确定分解后的所述子路径的小时计数；
根据所述小时计数创建第一动态转移方程；
通过对所述第一动态转移方程进行求解，返回所述分解子路径的位置，以最小化所述子路径的小时计数的总数。
12.根据权利要求11所述的路径时间查询方法，其特征在于，所述第一动态转移方程包括：
Figure FDA0002866669350000031
所述f1(i)表示对所述子路径进行分解的最小轨迹总数，所述ei表示第i个所述子路径，所述ej表示第j个所述子路径，所述c(ei：ej)表示由子路径ei至子路径ej对应的轨迹小时计数，所述H表示所述第二预设长度。
13.根据权利要求10所述的路径时间查询方法，其特征在于，将所述待查询路径分解为第二预设长度的子路径包括：
确定分解后的所述子路径的小时计数；
根据所述小时计数创建第二动态转移方程；
通过对所述第二动态转移方程进行求解，返回所述分解子路径的位置，以最小化每条所述子路径的最大的小时计数。
14.根据权利要求13所述的路径时间查询方法，其特征在于，所述第二动态转移方程包括：
Figure FDA0002866669350000032
所述f2(i)表示对所述子路径进行分解的最少最大轨迹数目，所述ei表示第i个所述子路径，所述ej表示第j个所述子路径，所述c(ei：ej)表示由子路径ei至子路径ej对应的轨迹小时计数，所述H表示所述第二预设长度。
15.根据权利要求1至14中任一项所述的路径时间查询方法，其特征在于，所述轨迹标识集合包括待查询路径的标识、所述子路径的序列和经过所述子路径的起始时间。
16.一种路径时间查询装置，其特征在于，包括：
分解模块，用于将待查询路径分解成多个子路径；
检索模块，用于根据所述子路径和设定的查询时间范围，从第一预设长度的后缀树索引中检索获得轨迹标识集合；
重建模块，用于根据所述子路径和所述轨迹标识集合，重建所述轨迹标识集合中的每条轨迹在所述查询时间范围内的行动路径；
生成模块，用于根据全部所述轨迹标识集合的行动路径生成所述查询时间范围内的轨迹集合。
17.一种电子设备，其特征在于，包括：
处理器；以及
存储器，用于存储所述处理器的可执行指令；
其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1-15中任一项所述的路径时间查询方法。
18.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，
所述计算机程序被处理器执行时实现权利要求1-15中任一项所述的路径时间查询方法。
CN202011597002.5A 2020-12-28 2020-12-28 路径时间查询方法、装置、电子设备和可读存储介质 Pending CN113806466A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011597002.5A CN113806466A (zh) 2020-12-28 2020-12-28 路径时间查询方法、装置、电子设备和可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011597002.5A CN113806466A (zh) 2020-12-28 2020-12-28 路径时间查询方法、装置、电子设备和可读存储介质

Publications (1)

Publication Number Publication Date
CN113806466A true CN113806466A (zh) 2021-12-17

Family

ID=78943590

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011597002.5A Pending CN113806466A (zh) 2020-12-28 2020-12-28 路径时间查询方法、装置、电子设备和可读存储介质

Country Status (1)

Country Link
CN (1) CN113806466A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114356939A (zh) * 2022-03-21 2022-04-15 科大天工智能装备技术（天津）有限公司 应用于城市空间中的路灯智能管理方法、装置及存储介质
CN117076726A (zh) * 2023-09-14 2023-11-17 上海交通大学 基于光线追踪相交的近似近邻搜索方法、系统、介质及设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120197900A1 (en) * 2010-12-13 2012-08-02 Unisys Corporation Systems and methods for search time tree indexes
CN107766406A (zh) * 2017-08-29 2018-03-06 厦门理工学院 一种采用时间优先搜索的轨迹相似性连接查询方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120197900A1 (en) * 2010-12-13 2012-08-02 Unisys Corporation Systems and methods for search time tree indexes
CN107766406A (zh) * 2017-08-29 2018-03-06 厦门理工学院 一种采用时间优先搜索的轨迹相似性连接查询方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RUIYUAN LI ET AL: "Efficient Path Query Processing Over Massive Trajectories on the Cloud", 《IEEE TRANSACTIONS ON BIG DATA》, vol. 6, no. 1, 1 March 2020 (2020-03-01), pages 66 - 79, XP011775441, DOI: 10.1109/TBDATA.2018.2868936 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114356939A (zh) * 2022-03-21 2022-04-15 科大天工智能装备技术（天津）有限公司 应用于城市空间中的路灯智能管理方法、装置及存储介质
CN114356939B (zh) * 2022-03-21 2022-05-24 科大天工智能装备技术（天津）有限公司 应用于城市空间中的路灯智能管理方法、装置及存储介质
CN117076726A (zh) * 2023-09-14 2023-11-17 上海交通大学 基于光线追踪相交的近似近邻搜索方法、系统、介质及设备
CN117076726B (zh) * 2023-09-14 2024-06-07 上海交通大学 基于光线追踪相交的近似近邻搜索方法、系统、介质及设备

Similar Documents

Publication Publication Date Title
EP3602351B1 (en) Apparatus and method for distributed query processing utilizing dynamically generated in-memory term maps
Bao et al. Managing massive trajectories on the cloud
CN111258978A (zh) 一种数据存储的方法
CN106372114A (zh) 一种基于大数据的联机分析处理系统和方法
CN109344157A (zh) 读写分离方法、装置、计算机设备及存储介质
CN109726225A (zh) 一种基于Storm的分布式流数据存储与查询方法
CN108509437A (zh) 一种ElasticSearch查询加速方法
CN113821573B (zh) 海量数据快速检索服务构建方法、系统、终端及存储介质
CN103646079A (zh) 一种用于图数据库搜索的分布式索引及其并行生成方法
CN114356971A (zh) 数据处理方法、装置以及系统
CN113806466A (zh) 路径时间查询方法、装置、电子设备和可读存储介质
US8396858B2 (en) Adding entries to an index based on use of the index
US9229969B2 (en) Management of searches in a database system
Hu et al. Approximation with error bounds in spark
KR101955376B1 (ko) 비공유 아키텍처 기반의 분산 스트림 처리 엔진에서 관계형 질의를 처리하는 방법, 이를 수행하기 위한 기록 매체 및 장치
CN103345527B (zh) 数据智能统计系统
CN108763323A (zh) 基于资源集和大数据技术的气象格点文件应用方法
US10872085B2 (en) Recording lineage in query optimization
CN115905630A (zh) 一种图数据库查询方法、装置、设备及存储介质
Yin et al. Efficient trajectory compression and range query processing
Li et al. Efficient path query processing over massive trajectories on the cloud
CN112597190A (zh) 点近邻轨迹查询方法、装置、电子设备和可读存储介质
CN115168474A (zh) 一种基于大数据模型的物联中台系统搭建方法
Nidzwetzki et al. BBoxDB streams: scalable processing of multi-dimensional data streams
JP2024502829A (ja) 軌跡近接クエリー方法、装置、電子デバイス及び読み取り可能な記憶媒体

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination