论文信息：The VLDB Journal (2021) 30:287–310
Ziquan Fang·Lu ChenYunjun Gao·Lu Pan·Christian S. Jensen
摘要
随着具有gps功能的设备的大量使用，越来越多的人和车辆的运动轨迹数据正在变得可用，这在许多应用领域非常有用，如交通、交通管理和基于位置的服务。因此，出现了许多针对离线或在线设置的轨迹数据管理和分析系统。但是，有些应用程序同时需要离线和在线分析。例如，在交通管理场景中，历史轨迹数据的离线分析可用于交通规划目的，而流轨迹的在线分析可用于拥堵监测目的。现有的轨迹分析系统往往分别进行离线和在线轨迹分析，效率低下。在本文中，我们提出了一个混合和高效的框架，称为dragoon，基于Spark，以支持离线和在线大轨迹管理和分析。该框架具有一个可变的弹性分布式数据集模型，包括RDD共享、RDD 更新和RDD镜像，它支持历史和流轨迹的混合存储。它还包含一个实时分配器，能够有效地分发轨迹数据，并支持离线和在线分析。因此，Dragoon提供了一个混合分析管道。对几个典型的轨迹查询和挖掘任务的支持显示了Dragoon的灵活性。一项使用真实和合成轨迹数据集的广泛实验研究表明，dragonoon(1)与最先进的系统UlTraMan具有类似的离线轨迹查询性能;(2)在轨迹编辑过程中，与UlTraMan相比，可减少多达两倍的存储开销;(3)与流行的流处理框架(如Flink和Spark streaming)相比，可扩展性提高至少40%;(4)在线轨迹数据分析的性能平均提高了一倍。
关键词
轨迹系统·数据管理·数据分析·分布式处理
1.介绍
现有的轨迹管理系统提供了次优的支持，因为它依赖于多个系统来实现离线和在线分析，这迫使用户不断地在离线和在线系统之间切换，以完成上述混合分析场景。此外，它的效率也很低，因为(i)在提取、转换和加载(ETL)历史轨迹数据与流化轨迹数据时需要重复类似的轨迹预处理过程，(ii)在不同的离线或在线场景下会产生磁盘存储复制。因此，我们的目标是开发一个有效的混合轨迹管理和分析系统。
在本文中，我们介绍了一种新型的混合高效的大轨迹管理系统dragoon，用于离线和在线分析。如图1所示，Dragoon被设计成一个整体解决方案，它支持历史和流轨迹数据预处理、管理和分析在一个系统中完整的流水线。为了开发这样一个系统，我们考虑了两种方法。第一个是扩展现有的离线或面向批处理系统(例如，Spark[54])，以增强其流轨迹的在线实时处理能力。第二种是扩展现有的在线或面向流的系统(例如:Flink[3])，使其具有管理和处理大规模历史轨迹数据的能力。尽管如此，我们观察到在线系统或框架在处理数据更新[50]方面存在局限性，这在设计这样的轨迹管理系统时是不能忽视的。更具体地说，在线系统的数据更新机制是流驱动的和被动的，这意味着只有当新的数据到达时才触发数据更新，而没有任何传入的数据时就不会发生更新。相比之下，许多现实世界的应用程序需要轨迹编辑[49]或轨迹清理[22]，即使没有传入的轨迹数据，也会调用数据更新。为此，我们采用第一种方法，将第二种方法作为未来的研究方向。具体来说，我们选择扩展Spark平台来实现Dragoon系统，因为Spark是一个在学术和工业领域都被广泛使用和高效的离线分布式处理系统。注意，Spark Streaming也扩展了Spark来处理流数据。然而，它只能以批处理的方式处理流轨迹，即采用微批处理策略，将流切割成几个数据rdd，并分别管理这些rdd。相比之下，我们的目标是开发一个单一系统，通过增强Spark core的存储层，以混合方式管理历史轨迹和流轨迹，在此基础上，Spark core能够进行更好的混合轨迹分析。当采用第一种方法时，存在以下两个关键挑战：
挑战一:如何扩展Spark以支持流轨迹数据的动态统一存储?现有的Spark Streaming通过将数据流切割成数据批量来存储流数据，其中每个数据批量都可以被视为一个弹性分布式数据集(RDD)[54]。然而，这样的rdd是不可变的和只读的，并且任何对RDD的更新(例如，map或union操作)都会创建一个新数据的RDD。在流轨迹设置或轨迹数据编辑场景中，数据更新频繁发生。因此，我们的目标是提供动态存储，可以支持有效的数据更新，这可以避免不必要的数据复制和时间成本。为了解决这个问题，我们提出了一个可变RDD模型，称为mRDD，它包括RDD共享、RDD更新和RDD镜像。具体来说，RDD Share检测RDD中可以共享的那些未改变的部分;RDD Update为不同的更新相关场景提供了三种更新策略;RDD Mirror支持有效的读写访问控制，避免分布式环境下并发读写造成的数据冲突和不一致。mRDD模型是为了与spark的原始RDD模型兼容而设计的，因此Dragoon能够通过混合方式在mRDD中存储历史和流轨迹数据。具体来说，在考虑系统数据平衡的同时，分区器可以根据不同的轨迹特征(例如轨迹的id、空间或时间信息)，将历史轨迹和流轨迹切割到多个数据分区进行并行处理。同时，将同一数据分区内的历史轨迹和流轨迹合并在一起，实现统一高效的存储。
挑战二:如何建立离线和在线轨迹数据分析的混合处理流水线?
用于离线和在线轨迹分析的技术是不同的。离线技术侧重于历史轨迹数据的管理和批处理，而在线技术则侧重于轨迹流的实时处理。有鉴于此，Dragoon基于其混合存储提供了一个混合数据分析流水线。此外，Dragoon还实现并支持包含轨迹编辑和ID/Range/kNN (ID/Range/kNN)查询的离线分析案例，以及包含在线ID/Range/kNN查询和实时协同运动模式检测的在线分析案例。
基于提出的mRDD模型，Dragoon能够作为一个可扩展、高效、灵活的混合平台，用于离线和在线大轨迹数据管理和分析。综上所述，本文的贡献如下:
-我们提出了一种混合高效的系统，用于整合离线和在线可伸缩轨迹数据管理和分析。
-我们提供了一个可变的RDD模型，带有实时分区，以混合方式管理底层存储的历史轨迹和流轨迹。
-我们为历史轨迹数据和流轨迹数据设计了一个混合分析管道，并通过显示和支持典型的离线和在线轨迹查询和挖掘任务来展示其实用性。
-在真实和合成轨迹数据集上进行的大量实验，为Dragoon的效率和可扩展性提供了见解，还包括与现有的最先进的轨迹处理系统或框架进行比较。
2.相关工作
在这一节中，我们继续简要地调查相关的系统架构，并澄清它们与dragoon之间的区别。
2.1离线/在线轨迹分析系统
首先，离线轨迹系统可以批量处理历史轨迹数据，有集中式和分布式两种类型。突出的轨迹存储或分析集中系统包括BerlinMOD[21]、Tra-jStore[17]和SharkDB[42]，仅举几例。然而，由于单台机器的能力有限，它们无法扩展到大量的轨迹数据管理和分析。
分布式的MapReduce[18]框架和开源的Hadoop[1]和Spark[4]实现，使得多个分布式轨迹管理或分析系统得以存在。CloST[39]基于hadoop，对大轨迹数据提供分布式查询处理。location - tionspark[40]、Simba[47]和Elite[48]是基于spark的，它们利用特定的分区和索引策略，利用创新的存储方案来管理大轨迹数据。目前还存在几种分布式大轨迹数据分析系统。Shang et al.[38]提出了DITA，它也是基于spark的，支持top-ktrajectory相似度连接。Xie等人提出了一个基于spark的分布式轨迹相似度搜索查询框架。Yuan等人[52]在考虑路网的情况下，继续研究Spark平台上的轨迹相似度搜索和加入。此外，提供分布式存储和处理的云和其他基于模式(例如，分布式NoSQL)的轨迹系统[10,28,29,36]也存在。
最近，一个名为UlTraMan[20]的高效平台提出，为大轨迹数据的ETL、存储、管理和分析提供统一的管道。通过提供操作界面，用户可以在单个系统中完成各种脱机轨迹数据分析。上述系统都是为支持离线管理和分析静态轨迹和历史轨迹而设计的，因此无法支持流轨迹的实时处理。这是因为轨迹数据流是无界的，是实时到达的，而上述轨迹系统的存储和处理引擎都是为静态历史数据设计的。有鉴于此，我们提出的Dragoon采用了一个灵活的框架，用于离线和在线轨迹数据管理和分析。请注意，Dragoon的离线组件共享了最先进的系统奥特曼的所有特性，包括可扩展、高效和统一，因为Dragoon使用的离线技术与UlTraMan类似。主要的区别是我们在Dragoon中提出了mRDD模型，它与Spark的原始RDD兼容，但可以在底层存储中实现高效的数据更新。
随着实时轨迹数据分析在现实生活中的应用越来越重要。实时事件检测[35])，在线轨迹系统正在开发中，用于流轨迹处理。现有的在线轨迹数据系统旨在高效地存储[10]、查询[9,30,34,43]和挖掘[14,32]轨迹流。尽管如此，它们还是分别处理存储、查询和挖掘任务，目前还没有像Dragoon这样的统一系统来支持大流轨迹数据管理和分析的完整流程。随着最近分布式流处理的出现，提出了几种通用的分布式流处理平台[2 - 5,16,25]。然而，它们并没有充分利用轨迹数据的特性。相比之下，Dragoon充分考虑了轨迹的特征，如Id、空间和时间信息，支持对轨迹流的高效动态管理。尽管基于流轨迹分析平台的轨迹体系结构已被研究[56,57]，但那些在线轨迹系统关注的是最新轨迹流的实时处理，这对于大规模、由于被动更新的限制，离线轨迹数据管理和分析，正如我们在第1节中讨论的。相比之下，我们提出了基于Spark扩展的mRDD模型的Dragoon系统，该系统既支持在线流轨迹数据管理，也支持离线轨迹数据管理(如轨迹数据编辑)。
2.2通用的混合方法
混合系统能够在单个系统中处理历史数据和流数据，并且存在几种通用的混合系统。Kumar等人对mapreduce进行了在线扩展，以支持批量数据处理，但仍面临第1节中提到的被动更新的局限性。随着Lambda架构[24]的出现，几个混合系统[7,8,11,15,19,50]被开发出来，它们结合了两个平台来处理历史数据和流数据。例如，Summingbird[11]结合了Hadoop和Storm，其中Hadoop用于离线处理，而Storm用于在线处理。基于lambda的系统的想法很简单，但它们必须维护两个独立的系统或不同的运营商api，以支持混合分析，而我们的目标是开发一个单一的系统，以支持离线和在线数据管理和分析。换句话说，我们的目标是一个统一的系统，以支持历史和流轨迹数据分析。此外，上述系统均未对目标轨迹数据进行处理。据我们所知，Dragoon是第一个以混合轨迹数据管理和分析为目标的提案，其中包括对其实施的详细描述。
虽然Spark可以通过其扩展Spark Streaming或Structured streams以混合方式处理数据，但这些系统不支持高效和可伸缩的混合轨迹管理和分析。有两个原因可以解释这一点。首先，Spark Streaming是核心Spark API的扩展，通过将数据流划分为数据批处理，然后使用Spark引擎处理每个数据批处理，支持流处理，我们称之为微批处理[4]。尽管如此，每批流轨迹数据仍然是基于不可变数据的，并且在Spark中是单独管理的。因此，由于使用不可变rdd进行更新会导致大量冗余数据存储，Spark Streaming无法支持高效的离线分析。另一方面，结构化流是Spark SQL引擎的一个扩展，它通过在UnboundedTable中添加结构化数据来支持流处理。然而，由于轨迹数据具有重要的时空特性，通常不能像结构化数据那样存储在表中。例如，基于这种表的管理，不方便构建空间STR树[27]索引。值得注意的是，为了支持Spark SQL[47]中的索引，需要进行重要的内部修改，但由于[20]的结构化存储方案，这种灵活性受到了限制。相比之下，我们增强了Spark Core的历史和流轨迹数据的底层存储机制。在此基础上，我们开发了dragoon系统，这是一个混合的、高效的大轨迹管理系统，用于离线和在线分析。
3.背景
在本节中，我们继续介绍Dragoon系统实现的相关背景，包括Spark中的弹性分布式数据集，以及轨迹的混合管理和分析。
3.1弹性分布式数据集
弹性分布式数据集(RDD)是Spark的核心概念。具体来说，数据RDD是一组数据，在分布式环境中可以逻辑地划分为多个数据分区，每个数据分区是整个数据集的一个子集，对应于底层存储层中的一个物理数据块。RDD的数据分区可以发送到分布式环境中的不同节点，每个节点可以管理RDD的多个分区。此外，每个节点都有一个块管理器来控制发送给它的数据分区，因此计算可以在不同的节点上并行执行。请注意，尽管Spark中最近提出的Dataset概念进行了更深入的优化，但它更适合于半结构化和结构化数据。相比之下，RDD可以提供更低层、更通用的数据管理和访问。
但由于RDD的模型是不可变的(即RDD的分区是只读的，不能直接修改)，因此在涉及轨迹数据管理场景(如轨迹编辑)时存在一定的局限性。这是因为RDD上的任何数据更新都会创建一个新的RDD。例如，在Fig.2a中，原始RDD_o包含三个数据对象(o1,o2, 和o3)，其中o1为轨迹编辑时需要编辑的数据对象。在Spark的不可变RDD中进行数据更新的一个简单解决方案如下:(i)使用filter对原始RDD_o进行操作得到一个RDD_e和另一个RDD_u，其中RDD_e包含需要编辑的RDD_o的o1, RDD_u表示RDD_o中其余保持不变的数据对象;(ii)使用map操作更新RDD_e并得到RDD_r（即编辑后的RDD）;(iii)在RDD_u和RDD_r之间使用联合操作来提供一个新的和“更新后”的RDD_n给用户;（iv)为未来可能的轨迹编辑返回RDD_n。如图2a所示，我们所需要的只是轨迹编辑的最终结果RDD_n，但在上述的编辑处理过程中，由于rdd的不变性，产生了几个中间的、不必要的数据rdd(如RDD_e、RDD_r、RDD_u)，产生了大量的数据拷贝。存储成本将进一步加剧，因为数据更新在轨迹管理场景中非常常见。因此，支持直接更新操作的可变数据RDD对于轨迹编辑场景是必要的。在此基础上，我们可以执行一个简单的数据更新操作，如图2b所示。
此外，可变RDD不仅可以提供一种有效的方法来处理上述轨迹编辑场景，还可以实现高效的在线轨迹分析任务。虽然Spark Streaming可以用于流轨迹处理，但它只是将新到达的轨迹点转换为数据批处理，并将其存储在新创建的数据RDD中。然后，Spark Streaming将此新的RDD添加到历史数据集的末尾。在这种情况下，对轨迹流的数据按时间信息分别进行管理和排序，这对于某些轨迹分析来说效率很低。以在线范围查询为例，其目的是寻找特定空间区域的轨迹，Spark Streaming需要访问每个数据批来得到最终的结果。而配备mRDD的Dragoon系统可以将相邻的位置存储在同一个RDD中，即新到达的位置根据空间信息插入到之前对应的RDD中。基于此，Dragoon只访问少量(而不是全部)rdds，得到最终的在线范围查询结果。基于此，我们在Spark RDD下扩展了历史轨迹和流轨迹数据的底层存储，在此基础上，我们开发了一个用于离线和在线分析的混合大轨迹管理系统。
3.2混合管理和分析
运动物体(如人、车辆)产生的轨迹数据可分为历史轨迹数据和流轨迹数据。这两类数据的管理和分析是不同的。我们首先描述了轨迹管理阶段，然后提出了轨迹分析阶段。
在轨迹数据管理方面，历史轨迹数据和流轨迹数据的存储格式不同。历史轨迹数据，也称为静态或批量轨迹数据，通常由轨迹点的序列表示，并存储在文件块中。相反，流轨迹数据，也被称为动态或无界轨迹数据，通常作为最新的轨迹点加载到主存储器中，用于后续的实时处理。
在轨迹数据分析方面，历史轨迹数据需要离线批处理，而流轨迹数据需要在线实时处理。对于历史数据，现有的工作旨在通过使用各种优化技术(如数据分区[20,47]和轨迹索引结构[33])实现高可伸缩性和效率。对于流数据，现有工作[14]的目标是实现高吞吐量和低响应延迟的实时处理。然而，一些现实世界的应用程序需要离线和在线分析，我们称之为混合分析。例如，在交通管理应用程序中，历史轨迹的离线分析可以用于更好的交通规划目的，而流轨迹的在线分析可以用于交通监控，以实时检测拥堵。现有的轨迹数据管理和分析的研究倾向于分别解决这些问题，从而导致为用户提供混合分析的方法效率低下。相比之下，dragon -goon提出了一种基于Spark的混合方法，在单个系统中同时支持离线的历史轨迹分析和在线的流轨迹分析。
3.3Chronicle map
Chronicle map是一种流行的存储技术，用于高频交易(HFT)领域的低延迟和多进程访问，比如交易和金融市场应用程序。对于Dragoon的实现Chronicle Map具有两个关键特性，包括堆外内存持久存储和嵌入键值存储，如下所述。(1)堆内存持久化。为了支持更高的分布式数据计算和处理性能，原始的基于RDD的Spark选择将数据缓存到堆上内存，这可能会对GC (garbage collector)造成较大的开销，特别是在大数据处理方面。相比之下，Chronicle Map采用了离堆内存机制，不仅可以提供与Spark内置内存缓存相似的处理性能，而且可以显著减轻GC压力，提供更好的数据可伸缩性。换句话说，这一特性为dragoon大轨迹数据管理提供了基本保障。(2)嵌入式键值存储。回想一下，我们的目标是一个混合和高效的大轨迹管理系统，用于离线和在线分析，因此，高效的数据访问是必需的，特别是在线轨迹管理和分析。幸运的是，Chronicle Map提供了一个嵌入式键值存储，它支持对不同数据格式进行高效和随机的数据访问。例如，键可以指向一个移动对象的ID，而值可以表示它的各种轨迹格式。具体来说，这些格式可以表示一个观测到的GPS点，一个由几个GPS点组成的子轨迹，或者这个移动物体的整个轨迹。而且，我们在之前的工作中也证实了它的有效性。通过将chronicle Map无缝集成到Spark作为底层存储引擎，Dragoon可以为离线和在线轨迹数据分析提供高效、可伸缩、灵活的轨迹管理。
4.系统概述
在本节中，我们将对dragoon进行概述，包括加载、预处理、混合管理和混合分析，如图3所示。
加载：第一阶段，dragoon从静态轨迹数据源中获取历史轨迹数据，或从流态轨迹源中连续加载最新轨迹数据。
预处理：处理包括格式转换、数据分区和索引构造。首先，将原始轨迹数据表示为一个GPS记录序列(id,l,t)， 其中id表示一个移动对象的id, l表示包含经纬度的位置，t表示该位置被观测的时间。接下来，可以根据特定的分区规则将历史轨迹和流轨迹划分为几个数据分区。如图3所示，用数据分区p_i(1≤i≤n)对轨迹数据进行分区。最后，索引的构造包括每个数据分区上的本地索引构造和所有数据分区上的全局索引构造，详细信息将在第6节中提供。
混合管理：为了同时管理历史和流轨迹数据，我们设计了混合存储，这是Dragoon的核心部分。混合存储在物理上基于Chronicle Map。为了存储混合轨迹数据，我们需要合并流轨迹和历史轨迹。合并过程不是Spark中实现的简单合并操作，而是需要能够支持物理Chronicle Map层的数据更新。为了支持数据更新，我们设计了mRDD模型，详见第5节。此外，本地索引和全局索引也存储在Chronicle Map中，在数据更新处理后需要更新。
混合分析：混合分析包括对历史轨迹数据的离线分析和对流轨迹数据的在线分析。具体来说，dragoon支持两种在线分析，如图3所示。第一类在线分析称为最新在线分析，主要关注观测到的移动物体的最新位置数据值。第二种类型的在线分析称为周期在线分析，是对移动物体的最新位置数据和以前的历史轨迹数据(即与某一最近时间段相关的数据)进行的分析。混合分析的细节在第6节中给出。
5.混合存储
连续采集流轨迹数据。我们的系统Dragoon将传入的数据附加到以前的数据分区中，这将导致底层存储对每个到达的轨迹点进行更新，而不是使用小批量策略，将传入的数据分成小批量并单独管理它们。但是，Spark原有的RDD是不可变的，任何对RDD的更新都会创建一个新的RDD，导致不必要的数据拷贝导致存储成本很高。因此，如何支持流数据的频繁RDD更新是实现混合存储的关键。有鉴于此，我们提出了一个可变RDD(mRDD)模型，该模型旨在与Spark的原始RDD模型兼容。mRDD模型包括三个部分，即RDD共享、RDD更新和RDD镜像，以支持历史和流轨迹数据的混合存储。在本节的下一个部分中，我们将按顺序详细说明这三个部分。为了区分，我们使用mRDDs来表示我们提出的Dragoon的mRDD模型，而我们使用RDDs来表示spark的原始RDD模型。
5.1RDD 共享
在Spark中，数据在逻辑上存储在分布式的数据分区中，在物理上存储在分布式的数据块中。也就是说，每个数据分区对应底层存储层的一个数据块。受多版本数据结构[41]的启发，我们开发了一种有效的跨不同rdd的数据共享机制，称为rdd共享。当RDD中有数据更新时，RDD Share首先识别出没有数据更新的数据分区，然后在新创建的数据RDD中直接重用那些最近没有更新的数据分区。这种机制可以避免大量不必要的数据拷贝用于数据更新处理。
在Spark中，一个RDD的数据分区被管理在一个RDD特定的空间中，因此不同的数据RDD被维护在不同的存储空间中。为了支持不同RDD之间的RDD共享，我们为每个数据分区(即物理数据块)分配一个唯一的ID，如图4所示。为了为数据空间中的每个数据分区生成一个唯一的ID，我们将RDD的ID和该数据分区在其数据RDD中的序列号结合起来。例如，在图4中，数据分区ID“rdd_1-p_1”是将RDD ID中“rdd1”和所属数据RDD中的数据分区的序列号“p1”组合而成的。
在Spark的原始RDD设计中，每个数据分区只属于一个特定的数据RDD，并且每个RDD只管理自己的数据分区。当一个数据RDD被释放时，它的数据分区也被释放。然而，在我们的mRDD模型中，每个数据分区可以在多个mRDD之间共享。因此，需要对每个数据分区的生命周期进行单独维护，以支持一致性数据管理。换句话说，当一个RDD被释放时，如果它的数据分区与其他mrdd共享，那么它的数据分区就不能被释放。如图4所示，数据分区“rdd1-p2”由RDD1和RDD2共享。当RDD1被系统释放时，它的数据分区“rdd1-p2”不能被直接释放，因为它也被另一个rdd2共享。否则，可能会出现不一致的数据问题。为了避免数据分区的错误释放，我们在每个节点中扩展了块管理器，引入了引用表，它为每个数据分区维护一个引用计数。data分区的引用计数表示共享该data分区的mrdds的个数。参考表的一个例子如图4所示，其中数据分区rdd1-p1的参考计数为1，因为它只被mRDD1使用，而数据分区“rdd1-p2”的参考计数为2，因为它被mRDD1和mRDD2共享。
当RDD创建一个数据分区时，将该数据分区对应的新行插入到引用表中，并将其引用计数初始化为1。当一个新的RDD共享这个数据分区时，它的引用计数增加1。类似地，当共享该数据分区的RDD被释放时，该数据分区对应的引用计数减1。最后，当一个数据分区的引用计数等于0时，该数据分区及其物理数据块可以被安全释放。注意，参考表可以使用chronicles map实现。此外，Dragoon系统中的每个节点都由其块管理器维护一个参考表。
RDD共享机制可以在不同的数据RDD之间共享数据分区，并将RDD的生命周期与其数据分区的生命周期解耦。假设有一个RDD，它有1000个数据分区，只有一个分区需要更新，这可能是由轨迹数据编辑或传入的流轨迹管理引起的。为了支持这些类型的数据更新，Spark创建了一个新的RDD来维护一个更新后的分区，并复制其余的999个分区。相比之下，我们的系统dragoon创建了一个新的RDD，它维护更新的分区，但共享其余的999个分区。因此，RDD共享可以避免由于数据更新而产生的大量不必要的数据拷贝。
5.2 RDD 更新
在这个小节中，我们详细说明了如何更新那些由于轨迹编辑或轨迹流管理而需要更新的数据分区，我们称之为RDD更新。RDD更新包含三种不同的数据更新策略，包括newest-only策略、share-append策略和share-update策略，在轨迹管理中提供了对不同相关更新场景的支持。为了展示如何使用这三种更新策略在我们的mrdd上执行数据更新，我们使用如图5所示的运行示例，其中包括四个移动物体o1,o2,o3, 和o4。在time0，它们的位置根据移动物体的id信息分别存储在四个数据分区(即P1、P2、P3和p4)中，其中o1(0)表示o1在时间0的位置。在time1时，移动物体o1和o3分别生成新的位置o1(1)和do3(1)。因此，在这个运行的例子中，Dragoon对于这两个新的位置更新有三个更新策略。(i)以这两个新地点取代旧值;(ii)将这两个新地点附加在历史数据的末尾;(iii)将这两个新位置插入到相应的历史数据分区中。在本小节的下一部分，我们将继续使用运行的示例详细介绍这三种更新策略的工作方式，并分析每种更新策略的优势、缺点和适应的场景。
newest - only更新策略假设用户只关注对象移动时最新的位置数据值，这意味着移动对象的历史轨迹数据值可以直接忽略。这种场景在流设置中很常见，其中有状态流和无状态流计算都是基于最新数据的。此外，在编辑和清理轨迹数据时，通常只存储最新的正确值，以节省存储空间。newest - only策略不需要创建一个新的RDD来进行更新，而是直接将旧mrdd中的旧值替换为新值。具体来说，为了执行更新，我们首先确定数据分区的位置，然后，我们直接更新这个数据分区。这里，数据分区是可变的，因为它是由Chronicle Map[20]实现的。但是，RDD及其数据分区不会在逻辑上发生改变。如图5a所示，在两次数据更新后，p1中的o1(0)被o1(1)取代，p3中的eo3(0)被o3(1)取代。newest - only更新策略是有用的，原因如下三。
——首先，Newest - only策略提供了使用Chronicle Map在rdd中进行高效数据更新的可能性，这在许多应用场景中都是必需的，比如轨迹编辑、轨迹清理和流轨迹处理。
——其次，Newest- only更新策略不会为数据更新操作创建新的RDD，与原始Spark相比，避免了数据复制相关的开销。
——最后，当数据更新时，最新策略总是在mrdd中保存最新的数据。因此，在连续实时提取数据时，可以不间断地直接获取最新的数据值，这在流轨迹处理设置中是有意义的。
然而，Newest- only更新策略有两个局限性。首先，它用最新的新数据值替换以前的数据值，因此，历史轨迹数据不再可用于进一步的分析。因此，Newest-Only策略不能支持周期在线分析。其次，它更新了分布式环境中的数据，这可能会导致同时读写数据时数据不一致。因此，我们需要在读取或写入mrdd之前引入访问权限，这会导致一些额外的时间成本，这将在“RDD镜像”小节中详细介绍。
share - append更新策略假设最新的数据值被追加到历史数据值的末尾，其中历史数据不需要更新。这个场景与历史分析一致，其中包括流轨迹的最新位置和以前的位置。一个例子是找到在过去30分钟[37]中一起移动的移动物体的轨迹。Share- append策略基于RDD Share，将新数据放在新创建的数据分区中。Share-Append的一个例子如图5b所示，其中包含两个更新的位置o1(1)和do3(1)的新数据分区p5和p6被追加到历史存储空间的末尾。使用Share-Appendupdate策略有三个优势。
——首先，Share-Append更新策略不会显著影响数据分布。具体来说，当历史数据在系统中均匀分布时，share - append数据更新不会产生偏态分布。
——第二，Share-Append下的数据分区是根据轨迹的时间信息自然划分的，有利于进行时间滤波的轨迹分析。
——最新数据维护在新创建的数据分区中，对共享数据分区没有影响。因此，使用Share-Append策略可以将共享的数据分区视为不可变的，从而避免了并发读写导致的数据不一致问题。
尽管Share-Append策略很简单，而且不会导致历史轨迹数据的更新，但它有两个缺点。首先，数据根据时间信息进行分布。获得不同的数据分布(例如:轨迹的空间信息)，历史数据需要周期性的重新划分和重建索引。第二，虽然一次更新不会对数据分布产生显著影响，但连续的数据更新可能会导致查询性能下降。
Share-Update更新策略假设每次只更新整个数据集的一小部分。这是因为移动对象在特定时间生成的位置比整个数据集中所有存档的历史位置要少得多。Share- update策略基于RDD Share，即新创建的RDD共享数据分区而不改变数据，并通过插入新的传入数据来复制其余的数据分区。注意，与neest - only策略不同，share - update中的更新是一个插入操作，而不是替换操作。Share-Update的一个例子如图5c所示，其中p1中的数据被更新为o1(0,1)，而p3data被更新为o3(0,1)。Share- update将rdupdate机制与RDD共享相结合，具有以下优点。
——首先，轨迹数据可以使用不同的数据分区策略进行划分，以支持灵活的数据平衡和高效的全局管理。
——第二，新的传入数据可以均匀分布到不同的集群节点，以提高并行性和整体性能。
——最后，最新的轨迹数据保存在新复制的数据分区中，不会影响这些共享数据分区。
Share-Update策略可以有效地克服Newest- only和share -追加策略的缺点。尽管如此，它仍然需要额外的时间成本来应用写和读权限，就像Newest-Only更新策略一样。
综上所述，dragoon系统提供了三种不同的数据更新策略，以形成针对不同轨迹相关更新场景的RDD更新。此外，每种更新策略都基于不同的假设，并有自己的优势和适应场景。值得一提的是，Dragoon提出的mRDD模型与Spark原有的RDD模型是完全兼容的。因此，mrdd中现有的transformation和action操作与RDD支持的操作是一样的。mRDD引入了更新机制来支持高效的数据更新，而数据更新属于Spark惰性计算之后的一种转换操作。
5.3RDD镜像
在最初的RDD设计中，RDD是只读的，不能直接更新;因此，不存在任何数据不一致。然而，正如前面所讨论的，我们引入了mRDD模型来支持mRDD中的数据更新，这使得RDD是可写可读的。为了避免并发的数据读写导致的数据不一致，数据更新需要权限控制和锁定机制来管理权限。由于可变RDD中的数据是在数据分区的粒度上存储和管理的，读写权限也可以在数据分区的粒度上进行控制。
在本小节中，我们将介绍RDD镜像机制，该机制进一步扩展了块管理器中的引用表，从而在分布式环境中实现读写权限和锁。具体来说，RDD 镜像记录了每个数据分区的权限信息(即一个读数和一个写标志)，如图4所示。当数据分区的写标志为0时，表示没有任务在写该数据分区;否则，当它的write标志为1时，它表示一个任务正在写这个数据分区。读计数记录并发运行的次数。如图4所示，假设数据分区rdd1-p2目前正在被两个应用程序读取，其读取计数为2。
当任务向一个RDD申请读写权限时，会创建一个可用于恢复的RDD镜像。RDD Mirror通过“RDD Share”共享所有未更改的分区，并更新更改后的数据分区的权限信息。在建立RDD镜像之前，RDD镜像需要检查权限冲突。当reference count和权限信息都更新成功后，RDD镜像建立完全。RDD镜像可以分为可读RDD镜像和可写RDD镜像。
可读RDD镜像当应用程序读取一个RDD时，需要获得读权限才能为该RDD创建可读镜像。可读RDD镜像与原始RDD共享所有的数据分区，并检查每个数据分区的写标志。如果存在写标志为1的数据分区，则读权限请求失败;否则，如果数据分区的所有写标志为0，则其读计数增加1。在读取完成后，它们的读取计数减少1。
可写RDD mirror当应用程序更新RDD时，需要申请写权限，并创建该RDD的可写镜像。可写RDD镜像要求其数据块不被其他任务读写，即每个数据分区的读次数和写标志都为0。在图4中，如果应用程序对rdd1-p2发出写权限请求，由于rdd1-p2的读次数为2，请求将失败。如果这个写权限请求没有冲突，我们将RDD中所有数据分区的写标志设置为1。完成写入后，写入标志设置为0。
5.4 容错
在这一小节中，我们将介绍与分布式处理过程和读写权限相关的Dragoon系统的容错机制。首先，Spark平台提供了多个级别的数据持久性，包括任务和进程级别。如果一个RDD没有被缓存，它可以被认为是在任务级被持久化了，这意味着如果任务失败，数据将会丢失。当缓存的RDD(内存或磁盘)在进程级被持久化时，这表示如果任务失败，数据可以被恢复，但如果进程崩溃，数据就会丢失。为了在更高的层次上持久化数据，用户必须手动和定期使用其他服务(例如HDFS)保存数据，这既不方便又耗时。
在Dragoon中，保存在Chronicle Map存储中的轨迹数据在运行时通过可靠的服务透明地保存。此外，这种持久性不会牺牲内存中数据访问的性能。为了实现这一点，一个Chronicle Map实例默认是在共享内存中的文件上创建的(例如，Linux下的/dev/shm)。该文件中的数据可以在任务失败时保存，并且可以以内存速度访问。此外，为了作为一个可靠的分布式存储，应用了一些技术来防止历史数据和流数据存储的失败。例如，dragoon会异步备份共享内存或磁盘上的文件到一个可靠的文件系统(如HDFS)，这样数据就可以在任务失败或节点崩溃时存活下来。因此，丢失的数据可以在spark计算机制下自动重新加载。此外，在Dragoon中更新数据mrdd时，将RDD 镜像功能集成到每个节点的块管理器中，实现读写权限和锁。此外，在Chronicle Map中，每个更新请求都保存为一个日志文件，以确保按顺序执行数据更新。
6.混合分析
在本节中，我们将详细介绍历史和流轨迹数据的混合分析流水线。如第4节所述，流水线包含四个阶段，即加载、预处理、管理和分析。因此，我们分别给出了离线和在线轨迹数据分析管道的四个阶段的详细信息。
6.1离线分析流水线
历史轨迹数据的离线分析管道是简单的，因为整个轨迹数据集是预先知道的，可以立即加载到Dragoon系统，以便后续处理。
加载：第一步是加载整个历史轨迹数据集。历史轨迹数据集通常存储在HDFS系统中，因此可以并行加载到dragoon中。在这个阶段，提供了一个可定制的数据加载器来支持不同的文件格式(例如，txt, csv，或xml)。
预处理：第二阶段包括格式转换(如轨迹指向段)、数据划分和索引构建。可定制的数据分区如下所示，该数据分区利用轨迹的不同特征(如id、空间或时间信息)对考虑轨迹不同特征的加载轨迹数据进行分区。换句话说，具有相同或相似id/空间位置/时间特征的轨迹将被发送到相同的数据分区进行并行处理。
——IDPartitioneris基于Spark的HashPartitioner，伪代码如算法1所示。它需要输入整个历史轨迹数据和分区键值。对于S中的每个轨迹T，算法首先计算它所属的数据分区的partitionidof(第2行)。ID表示生成此轨迹t的移动对象的ID。接下来，它将T发送到这个数据分区，其中具有相同partitionids的轨迹将被分配到相同的数据分区(第3行)。
——GridPartitioneris受grid索引[44]的启发，伪代码见算法2。它以整个历史轨迹数据集和网格宽度作为输入。对于S中的每个轨迹T的每个位置，算法首先计算属于(第3行)的空间网格单元格的网格。r.l是这个GPS记录r的空间位置，包括r. l.s 和r.l.y。接下来，它将r发送到相应的数据分区，其中相同空间网格单元中的位置被分配到相同的数据分区(第4行)。
———STRPartitioneris受到STR树[27]的启发，其伪代码在算法3中给出。它以整个历史轨迹数据集和r -树的叶节点数作为输入。算法首先对整个轨迹数据集S进行随机采样(第2行)，得到一个采样的数据集SampleDataset，然后利用样本数据集，应用STR算法[27]和n_nodes构建一个r -树(第3行)。它根据r树将S划分为几个大小大致相等的不相交的数据分区(第4-7行)。与以前的GridPartitioner相比，STRPartitioner可以实现更好的负载平衡，因为它根据整个数据集的数据分布来划分数据集
——TimePartitioneris也是基于spark的HashPartitioner的，伪代码见算法4。它还接受整个历史轨迹数据集和一个分区键值作为输入。对于每条轨迹的每条GPS记录，算法首先根据GPS记录的时间信息计算属于(第3行)的数据分区的partitionid。值得一提的是。time表示生成该GPS记录时的特定时间戳。接下来，TimePartitioner将把每个r发送到相应的数据分区，表明具有类似时间戳的轨迹被分发到相同的数据分区(第4行)。
使用不同的轨迹数据分配器，Dragoon系统可以支持更灵活的数据平衡。在数据分区之后，Dragoon将构建本地索引和全局索引，类似于在UlTra-Man[20]中完成的方式。具体来说，Dragoon在每个数据分区中建立一个本地索引，然后根据所有数据分区的特性建立一个全局索引。例如，为了构建一个全局r-树，Dragoon需要从每个数据分区收集pid和mbr，其中pid是分区ID, MBR是分区的空间最小边界。
管理：历史轨迹数据管理包括如何存储数据和索引。Dragoon的存储是基于Chronicle Map实现的，Chronicle Map是一种离堆内存和嵌入式键值存储，设计用于低延迟和多进程访问。我们之所以采用Chronicle Map来存储轨迹数据，是因为它提供了高效的数据更新，并且可以缓解Spark中的垃圾收集器的压力。与Spark相比，我们基于Chronicle Map的系统具有更好的可伸缩性，这在第8节的实验中得到了证实。
分析：离线轨迹分析包含历史轨迹数据的典型查询和挖掘任务。利用全局索引对离线分析进行全局过滤，从而加速离线分析的速度，然后利用每个数据分区的本地索引对离线分析结果进行局部分析。关于我们在本工作中关注的历史轨迹数据的离线分析任务的更多细节将在在Sect.7中讨论。
6.2在线分析流水线
流式轨迹数据在线分析管道如图6所示。流轨迹数据的在线分析不仅需要关注最新的轨迹数据值，还需要将最新的轨迹数据与历史轨迹数据进行融合。值得一提的是，最新的数据是在最近的时间点到达的数据。对于最新的在线分析，我们的目标是所有移动对象的最新空间数据值，而不是最新时间点的新传入数据。这是因为不是所有移动的物体都会在每个时间点更新它们的位置。例如，在图5中，最新的(即新到达的)数据包括o_1(1)和o_3(1)，而四个移动对象在t1时刻的最新数据值都是o1(1)、o2(0)、o3(1)和o4(0)，其中o2和o4在time1时刻不更新位置。另外，后者是我们重点关注的最新在线分析。相比之下，另一时期的在线分析，我们的目标是最新和以前的数据值的移动对象。
加载：在第一阶段，dragoon不断地从轨迹流读取新到达的数据。系统读取数据流的方式与Spark Streaming类似，Spark Streaming读取最近几秒(例如，每5秒)的数据流，每批流数据作为一个独立的RDD处理。离线分析中使用的定制数据加载器也可以在这里使用。
预处理：虽然在线和离线轨迹预处理都需要基于轨迹id、空间位置或时间信息的数据划分过程和索引构建过程，但在线和离线预处理之间存在一些差异。首先，离线轨迹数据划分以整个历史轨迹数据集为输入，只执行一次数据划分，而流轨迹数据由实时分块器进行划分，实时分块器以每次观察到的运动对象的轨迹数据点为输入，并实时执行每次数据分区。其次，离线分析的索引构造通常也只执行一次，并且(本地和全局)索引通常不需要更新。然而，在流轨迹设置中，不仅数据分区中的轨迹数据需要在下一个合并过程阶段更新，本地和全局索引也需要更新。
——在线IdPartitioner类似于离线轨迹预处理的IdPartitioner，伪代码如算法5所示。不同的是，在线IdPartitioner将新到达的轨迹点的集合S_t和一个分区键值 k作为输入。对于S_t中的每个GPS点r，算法首先计算该数据分区的partitionid(第2行)。接下来,它将r发送给相应的数据分区(第3行)。请注意,mRDD更新过程,新到达的轨迹点的合并历史轨迹数据,将在第二阶段执行。与算法1不同，算法5每次都重复上述处理。
———在线GridPartitioner，伪代码如算法6所示，该算法与算法2类似。唯一不同的是，在线方法以t时刻新到达的轨迹点集合St作为输入，而离线方法以整个轨迹数据作为输入。注意，后续的合并过程将通过将新数据与该数据分区中的历史轨迹数据合并来执行。但是，每次移动对象生成的所有位置的网格单元都是固定的，这可能会导致倾斜分区。为了获得更好的数据分区和数据平衡，还提供了Online STRPartitioner，如下所示。
———Online STRPartitioneris也类似于离线轨迹预处理的strpartitioner，其伪代码见算法7。它以t时刻新到达的轨迹点的集合St作为输入，而不是整个轨迹数据集。与在线GridPartitioner相比，在线STR-Partitioner能够实现更好的负载平衡，因为它根据每个St的数据分布实时划分数据集。
——在线TimePartitioner可以通过Dragoon的Share-Append策略轻松实现，因为轨迹流是按照时间顺序来实现的。因此，本文略述具体算法。
管理：在线轨迹管理包括将新到达的轨迹点与历史轨迹数据进行合并的过程。在前一个预处理阶段的实时分区程序可以一直生成相同的分区(如IDPartitioner和gridpartitioner)，或者在不同的时间生成不同的分区（如 TimePartitioner和STRPartitioner)。在前一种情况下，我们使用基于mRDD模型的Newest - only或share - update策略直接将partitioned St分配到相应的现有数据分区，如图6中红色的“Merge1”所示。在后一种情况下，我们使用Share-Append策略将新创建的数据分区添加到现有的分区中，以实现图6中的“Merge2”。在合并过程中，可写RDD镜像和可读RDD镜像同时使用，避免了数据的不一致性:一个用于更新处理，另一个用于结果读取处理。此外，本地索引和全局索引在数据合并后也需要更新。
分析:流式轨迹数据在线分析包括最新在线分析和周期在线分析，如图6所示。最新的在线分析只考虑所有移动对象的最新数据。而周期在线分析需要给定时间段内的最新数据和历史数据。关于轨迹流在线分析的更多细节将在第7节中讨论。
7.分析案例研究
我们通过几个典型的离线和在线轨迹数据分析案例研究展示了Dragoon的灵活性，包括(在线)ID查询、(在线)范围查询、(在线)最近邻(kNN)查询、离线轨迹编辑和轨迹流上的实时协同运动模式检测。
首先，O= < o1,o2，…，om >是一个移动物体的集合，其中每个oi∈O(1≤i≤m)是一个移动物体，它可以产生如下定义的轨迹或流轨迹。
定义一(轨迹).由移动的物体i(1≤i≤m)在地理空间中生成的轨迹Ti，通常用按时间顺序排列的gps记录序列表示，即Ti= < r1,r2，…，rn >。每个GPS recordrj(1≤j≤n)∈Tican表示为一个三元组(id,l,time)，其中是objectoid(id=i)在timestamp时间戳的空间位置。注意，它通常由年龄空间坐标集(经度、纬度)组成。
定义二(流轨迹).由移动物体o_i(1≤i≤m)产生的流轨迹也是一个GPS记录的时序序列，即STi= < r1,r2，…>。注意，不同于轨迹T_i，运动物体的流动轨迹是无界的。
因此，一个静态轨迹数据集(STD)包含了所有由o生成的轨迹，即STD= < T1,T2，…，Tm >。动态轨迹数据集(DTD)包含由o生成的所有流轨迹，即DTD= < ST1,ST2，…，STm >。在续集中，我们分别介绍了基于历史轨迹数据和流态轨迹数据的典型离线和在线轨迹分析案例。此外，对这些分析案例的实验评估将在第8节详细介绍。
7.1轨迹编辑
给定一个静态轨迹数据集STD，可能存在噪声采样点[57]。例如，当GPS接收器在城市峡谷和卫星能见度较差时，可能会发生不准确的位置。为了消除这些轨迹噪声点，采用了轨迹编辑操作。具体来说，轨迹编辑的目的是将有噪声的轨迹点更新为正确的轨迹点。如图2a所示，由于rdd的不变性，Spark中轨迹编辑会导致很多不必要的数据复制。相比之下，Dragoon提供了mRDD模型，可以直接更新数据rdds，如图2b所示，为轨迹数据的管理和维护提供了更有效、更强大的机制。
7.2ID查询和在线ID查询
ID查询和在线ID查询的目的是根据ID信息找到一个特定的轨迹，这在轨迹监控场景中非常有用，如下所述。
定义3(ID查询和在线ID查询).给定一个特定的ID, ID查询和在线ID查询分别查找由运动对象oi生成的STD中的轨迹T_i和DTD中的流轨迹ST_i ，其中i= ID。
对于离线ID查询，IdPartitioner首先根据移动对象的ID将整个轨迹数据划分为多个数据分区，从而实现后续的并行处理。如算法1所示，如果设置k= 10000，则IdPartitioner可以将id介于0 ~ 10000之间的移动对象分配给数据分区p0，将id介于10001 ~ 20000之间的移动对象分配给数据分区p1，以此类推。然后，我们在每个分区中构建一个本地Hash索引，其中对象ID作为键，轨迹点作为值。由于Chronicle Map 本身是一个哈希映射，因此可以基于Chronicle Map 存储轻松地实现本地哈希索引。接下来，可以根据所有数据分区的特性构建全局索引。分区的特性包括分区ID和该数据分区中的移动对象ID范围。考虑到上面描述的例子，全局索引包含< (P0.ID，[0,10000])， (P1.ID，[10001,20000])，…>。最后，ID查询可以使用全局索引根据给定ID过滤不必要的数据分区，并且可以使用局部Hash索引直接找到最终结果。
对于在线ID查询，实时的IdPartitioner根据流轨迹的ID将在时间t(S_t)上新到达的轨迹点分配给几个数据分区，然后将它们与每个数据分区中的历史位置合并。在线ID查询是最新的在线分析的一个实例，因为它返回流轨迹的当前位置，其ID每次都等于给定的ID;因此，在线ID查询是在每个时间点上对所有流轨迹的当前位置进行的。因此，第5节中介绍的三种不同的更新策略都可以用于合并处理。此外，我们还需要在轨迹合并后更新本地和全局索引。
7.3范围查询和在线范围查询
范围查询和在线范围查询的目的是在一定的空间范围范围内查找轨迹，在流量监控和热点检测[57]等应用中非常有用，定义如下。
定义4(范围和在线范围查询).给定特定的空间搜索区域Q、一个STD和一个DTD，范围查询查找STD中与Q相交的轨迹，而在线范围查询查找DTD中当前空间位置位于q内的流轨迹。注意，搜索区域Q通常表示为一个矩形< [minx,miny]，[maxx,maxy] >。
对于离线范围查询，我们采用GridPartitioner基于轨迹空间信息对STD进行分区，在每个数据分区上建立一个局部的r树，在整个轨迹数据集STD上建立一个全局的网格索引。全局网格索引可以过滤那些没有与搜索区域Q相交的数据分区，然后利用局部r树对候选分区进行范围查询，得到最终结果。
对于在线范围查询，在线GridPartitioner首先用于从流轨迹中划分新的传入点(St)，然后将传入点与相应数据分区的历史数据合并。在线范围查询也是最新的在线分析实例。它返回当前位置包含在搜索区域q中的运行轨迹，并对所有流轨迹的最新位置执行查询。因此，可以使用这三种更新策略来合并数据。同时，在数据合并后更新相应的本地索引和全局索引。
7.4KNN查询和在线KNN查询
kNN查询和在线kNN查询旨在为特定的空间位置找到最精确的轨迹，这对于基于位置的服务非常有用，如轨迹分类和车辆共享[13]，如下所定义。
定义 5(kNN查询和在线kNN查询).给定某个位置l,一个STD，一个DTD和一个正整数k>=1,,k近邻查询找到在STD中和l最近的k条轨迹,即Rk = {Ti | 1≤i≤k d (Ti, l)≤d (Tj,l) (Tj /∈Rk)},和在线KNN查询发现在DTD中的k条流轨迹,也就是说,工作= {STi | 1≤≤k d (STi.rt l)≤d (STj.rt l) (STj /∈工作)}。请注意，位置l到轨迹Ti或STi之间的距离计算(Ti,l)和d(STi,l)遵循工作[13]，尽管其他距离函数也可以在Dragoon系统中实现。
对于离线kNN查询，我们采用strpartitioner[47]根据轨迹数据的空间信息对其进行统一划分。在这里，使用R-tree变体[20]来提高knn查询效率，其中R-tree的每个节点保持最小边界矩形(MBR)和包含在MBR中的不同轨迹的计数。在knn查询期间，使用全局过滤来获得具有相同轨迹计数的候选数据分区，然后，在候选分区中分别执行localkNN查询。最后，候选分区的局部结果按照它们到查询位置的距离升序排序，然后返回全局top-k轨迹。
对于在线kNN查询，我们在全局r -树索引中使用mbr而不是STRPartitioner来从流轨迹中划分最新的位置。这是因为strpartitioner可能会为数据合并带来额外的成本，如6.2节所述。接下来，我们合并数据并更新本地和全局索引。与在线ID和Range查询类似，在线kNN查询是最新在线分析的一个实例。在线kNN查询每次返回k条轨迹，其当前位置最接近查询位置;因此，它是在所有流轨迹的最新位置上执行的。因此，这三种更新策略都可以用于数据合并。
7.5协同运动模式检测
协同运动模式检测旨在发现满足特定时空约束[14]的协同运动目标，包括紧密度、显著性M、持续时间K、连续性L和连接度g。这在许多应用中都是有用的，比如未来运动预测。实时协同运动模式检测是周期在线分析的一个例子，因此，我们必须考虑每个流轨迹的最新位置和历史位置。
我们直接采用最先进的方法[14]进行实时协同运动模式挖掘。但是，Dragoon的底层系统与flink平台不同，可以实现更好的可扩展性。这是因为，为了实现高性能，Flink中的状态存储是基于堆上内存的，这对垃圾收集器(GC)有很大的压力，特别是对于大轨迹数据的维护和处理。相比之下，我们的系统使用Chronicle Map进行物理存储，它是离堆内存，在保证效率的同时减轻了GC压力。此外，Flink中状态维护的流轨迹数据在流分析完成后发布。相比之下，Dragoon提供了流轨迹数据的永久存储，因此，这些数据可以用于未来的后续轨迹分析。
由于实时协同运动模式检测是周期在线分析的一个实例，因此不再采用newest - only更新策略。这是因为newest- only策略直接丢弃了移动对象之前的位置值。协同移动模式检测方法在查询过程中更新索引，进一步提高查询效率。另外,中间结果(如。集群)也需要被存储。该方法包含聚类和枚举两个阶段。在聚类阶段，可以使用Share-Append和Share-Update策略合并数据;对于枚举阶段，只能使用Share-Update策略，因为我们需要根据ID对数据进行分区，以实现并行模式检测(即，ID分区在方法[14]中使用)。
8 实验评估
在本节中，我们将用第7节中讨论的典型轨迹分析案例来评估dragoon的性能，并将其与现有的最新型的离线轨迹管理系统UlTraMan以及包括spark Streaming和Flink在内的通用在线处理系统进行比较。回想一下，Dragoon的核心组件是mRDD模型，基于该模型，混合轨迹数据分析包括离线和在线分析可以被有效支持。因此，在后续的实验中，我们评估了dragoon的两个组件，即mRDD模型和混合轨迹数据分析的性能。(i)为了验证mRDD模型的性能，我们首先报告基于mRDD模型的离线轨迹编辑的性能，然后，我们报告在线轨迹查询期间的数据更新性能。这是因为，在执行在线ID/范围/kNN查询分析时，dragoon首先将新到达的轨迹点与底层存储中的历史轨迹数据合并。此合并过程主要基于mRDD模型，评估了dragoon提供的三种更新策略(Newest-Only、Share-Append、Share-Update)。(ii)为了评估混合轨迹数据分析的性能，我们使用了几个典型的离线(即ID/范围/kNN查询)和在线(即实时运动模式检测和ID/范围/kNN查询)轨迹分析案例，如第7节所讨论的。
在我们的实验中，我们使用了两个现实生活中的数据集(例如:例如，GeoLife和Taxi)和一个合成数据集(即Brinkhoff)，其详细信息包括轨迹数、位置数、快照数、平均长度和数据大小，总结在表1中
-GeoLife:这个数据集保存了每个用户3年以上的GPS记录。gps信息的采集是周期性的，91%的轨迹采样间隔为5s。
-Taxi:该数据集由中国杭州的出租车生成。轨迹由出租车的车牌号识别，每条轨迹代表一辆出租车3个月的轨迹，每5秒采样一次。
- Brinkhoff:该数据集由Brinkhoff生成器生成。轨迹是在拉斯维加斯城市的真实道路网络上生成的。运动物体的位置每1秒更新一次，物体以随机但合理的方向和速度沿着道路网络移动。
实验参数设计如表2
在实验中，我们研究了五个参数的不同设置对性能的影响，如表2中总结的，其中默认值以粗体显示。这里，n代表在轨迹编辑中对静态轨迹数据集的编辑次数。第二，o_r表示离线轨迹分析案例中运动物体w.r.t的百分比，表示在线分析过程中每次更新的运动物体的百分比。此外，ξ表示(online) range查询中使用的查询区域w.r.t，即包含所有轨迹点的整个区域的大小。k表示(在线)kNN查询中的k。n表示Dragoon系统的从工作节点数。另外，实时协同运动模式检测中使用的参数设置为之前工作中默认值[14]，即M=15,K=180,L=30, g =30。注意，在下面的实验中，我们采用L1范数作为轨迹两个位置之间的相似距离进行简化。但是，它很容易支持其他距离函数。
性能指标(i)对于ID/Range/kNN查询和轨迹编辑，执行时间(即每个查询或编辑的平均处理时间)被用来评估它们的性能。(ii)对于在线id /Range/kNNquery和协同移动模式检测，我们使用时延和吞吐量作为性能指标。更具体地说，对于在线ID/Range/kNN查询，我们分别验证更新和查询处理阶段。在更新阶段，目标是找到相应的数据分区，然后将新到达的轨迹点插入到历史数据分区中，更新延迟表示将当前St(所有到达timet的点)插入到历史轨迹中的平均时间，而整个更新表示系统每秒插入的次数。在查询阶段处理中，查询延迟被定义为每个在线ID/Range/kNN查询的平均响应时间，并且整个查询表示系统每秒处理的ID/Range/kNN查询的数量。我们还报告了在数据更新处理场景中系统的内存占用情况，包括在线ID/Range/kNN查询的轨迹编辑和更新阶段。
9.总结
在本文中，我们提出了一种新型的、混合的、高效的弹道数据管理和分析系统——dragoon系统。为了同时支持历史轨迹和流轨迹的管理，龙骑采用了mRDD模型，包括RDD Share、RDD Update和RDD Mirror。RDD Update提供了三种针对不同场景的更新策略，分别是:newest - only、Share- append和Share-Update; RDD Mirror提供了在分布式环境下避免数据一致性的读写控制。此外，Dragoon的混合分析管道为历史轨迹和流轨迹提供支持。对大型真实和合成数据集的实验研究提供了对Dragoon的可伸缩性和性能的洞察力，并与最先进的系统进行了比较，得出了以下结果:
-对于历史轨迹数据，dragoon在离线轨迹查询方面的性能与现有轨迹系统UlTraMan相当。然而，在轨迹编辑场景中，dragoon可以减少多达两倍的存储开销。
-对于流轨迹数据，尽管现有的通用流系统Spark streaming和Flink能够在小工作量的情况下提供更高的更新效率，但Dragoon至少实现了40%的可伸缩性，并为最新的在线分析提供了平均两倍的性能改进
-Share-Append更新效率最高，而Newest-Only查询效率最高。但是，newtest - only不适合周期在线分析，Share-Append只支持时态数据划分。
未来，应用dragoon进行更大的轨迹数据管理和处理，设计更有效的指标来支持更多类型的轨迹数据分析(如离线轨迹相似度计算和在线子轨迹聚类)是值得关注的。此外，扩展mRDD模型用于通用大数据管理或开发另一个新的数据集增强模型用于大结构化数据分析也是一个很有前途的方向。