Distributed Trajectory Similarity Search（VLDB2017）

移动和传感设备已经变得无处不在。它们使追踪移动物体变得很容易。因此，像Uber这样的移动应用和许多物联网项目产生了大量的轨迹数据，这些数据已经无法由单机高效处理。在轨迹数据的典型查询操作中，相似性查询是一种常用但代价昂贵的操作。它适用于不同领域的应用，如交通和运输优化，天气预报和建模，以及体育分析。它也是许多重要挖掘操作(如轨迹聚类和分类)的基本操作。本文提出了一种分布式的轨迹相似性查询框架，以处理大规模轨迹集合上的轨迹相似性搜索。通过仔细考虑不同的设计选择，我们在流行的分布式数据处理引擎Spark中实现了该框架。我们的查询框架同时支持Hausdorff距离和Fréchet距离。实验结果表明，与其他方法和设计方案相比，该方法具有良好的可扩展性和查询效率。

注意：主要实现分布式轨迹查询和spark框架

阅读者总结：这篇论文的主要是采用分布式的方式处理轨迹相似性问题，1）文中最大的创新点是使用了基于片段的方式计算相似性轨迹。这里的片段是将整个轨迹数据进行切分，然后再使用MBR来剪枝。2）索引设计上采用分组，局部和全局方式管理轨迹，应该说这种思路也不是新颖，很多轨迹管理方法和查询方法，都是采用全局和局部索引相合的方式。

缺点：文中在描述分段方法和基于分段的索引设计时，写的很累赘，甚至是有点绕，明显感觉没啥干货在里面，甚至可以说大量工程进行包装。因为论文的整个核心东西很少。

方法：

提出了一种分布式环境下支持轨迹相似性搜索的通用框架。设计了一种基于段的分布式索引结构，而不是直接索引所有轨迹。这与有效的修剪算法相结合，仅使用单个片段标记远轨迹。使用两种流行的几何曲线和时间序列数据相似性度量，即离散段Hausdorff距离和离散段Fréchet距离[7]，展示了所提出框架的设计和实例化。我们还研究了在流行的分布式计算引擎Apache Spark上实现该框架所面临的挑战和设计问题。 

 

 FRAMEWORK

描述了为执行轨迹相似性搜索而设计的分布式处理框架;该框架基于分布式索引结构和一套利用分布式索引的剪枝技术。我们将研究如何在大型轨迹数据集上划分和构建分布式索引结构，并研究分布式查询处理过程如何利用离散段Hausdorff距离和离散段Fréchet距离下的索引。

The goal is to minimize computation and communication on a small number of data shuffles. 

主要有两个瓶颈。首先，将顶层分组到分区中，这样在查询时就可以快速地完全避免检查大部分分区。其次，一种高效且有效的修剪策略，因此我们只需要强力计算一小组候选轨迹的距离。我们仍然可以在每个被检查的分区内使用传统的索引(如r -树)来帮助实现剪枝目标，但与vp -树基线不同的是，我们不太关心创建单个大的层次结构。相反，这两个主要的过滤级别是最重要的。这意味着我们可以“接触”分区内每个轨迹的信息，只要它能有效地从下一个级别中非常有效地修剪这些信息。这些设计观察极大地影响了我们提出的基于分段索引的方法的策略。

 

Distributed indexing of segments

构建有效的分布式索引的关键是精心设计的分区策略，将数据划分为块，以便在查询时快速修剪大部分块。此外，我们需要确保每个分区的大小大致相同，以保持负载平衡。最后，我们需要观察内存占用情况，以确保索引结构不会占用分布式系统中任何执行器程序的堆内存。

我们的方法是对单个片段进行分区和索引。我们为每个线段创建一个MBR，用它的质心(中点)表示每个线段，然后用这些质心在这些MBR上构建r树。这将导致更高效和有效的数据分区，如图3所示。然而，在跟踪与每个片段相关的轨迹并修剪整个轨迹时，它需要更多的关注

 

 

 索引阶段：

索引过程包括三个阶段:分区、局部索引和全局索引。在本节中，我们将原则上描述这些阶段。5.2节会详细介绍如何在Apache Spark上实现两级索引策略。

 

Search procedure

搜索过程包括3个步骤:剪枝边界选择、基于索引的剪枝和最终结果。 

 

 INSTANTIATIONOFTHEFRAMEWORK

特别地，讨论了在Spark中实现分布式索引的技术，以支持在全局和局部索引中紧凑地表示每个节点上的轨迹id (TID集)，并构建辅助结构以避免在最终查询结果时重新构建完整的轨迹

 

 实验跳过.....................