数据处理的方法、装置和系统与流程
本发明涉及互联网技术领域，具体而言，涉及一种数据处理的方法、装置和系统。
背景技术：
针对具有海量的移动设备的定位数据，需要设计一套高效的技术方案，基于时空位置数据快速检索出与一个移动设备同行的其它移动设备。
计算移动设备的轨迹伴随的本质实际上就是要在海量的轨迹数据中找出与目标轨迹的相似度高的其它轨迹。
最原始的方案中，直接计算所有的候选轨迹与目标轨迹的相似度(或者距离)，如使用欧几里得距离、jaccard距离、frechet距离等。该方案的优点是对于小数据量的时候，简单有效；该方案的缺点就是计算复杂度很高，不能用于海量的数据的解决方案。
在相关技术中，为了降低计算量，将经纬度的定位数据使用geohash进行编码，可以将二维的空间数据转换为一维的字符串数据。这样一条时空轨迹就是由多个geohash组成的集合，每个geohash对应于一个时间区间。利用计算引擎对geohash的索引功能，将其中每一个时间的geohash与候选集中所有的其它对应时间的geohash进行求交计算，最后根据交集数量的从高到低得到伴随结果。该方案的优点：使用了geohash对经纬度的位置数据编码，使得计算引擎可以直接对geohash进行索引，在查询的时候可以直接在计算引擎上通过geohash进行求交计算，可以避免到一些完全没有交集的运算，一定程度上提升查询效率；该方案的缺点：a)geohash存在边界情况，即两个很相近的位置点对应的geohash不一样，可能存在召回丢失；b)轨迹所包含的geohash数量与伴随时间长度成正比，伴随时间越长，geohash数量越多，求交的计算量就会越大，使得该方法不适合较长时间的伴随。
针对上述从海量的轨迹数据中找出与目标轨迹的相似度高的其它轨迹的过程中海量数据带来的计算效率低的问题，目前尚未提出有效的解决方案。
技术实现要素：
本发明实施例提供了一种数据处理的方法、装置和系统，以至少解决从海量的轨迹数据中找出与目标轨迹的相似度高的其它轨迹的过程中海量数据带来的计算效率低的技术问题。
根据本发明实施例的一个方面，提供了一种数据处理的方法，包括：依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据；依据签名数据从第一类计算引擎中获取候选集合；通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象。
可选的，在得到与待查询对象轨迹相似的伴随对象之后，该方法还包括：依据伴随对象获取与待查询对象轨迹相似的设备列表。
可选的，在依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据之前，该方法还包括：依据时间片对终端进行采样，得到每个时间片的位置数据；依据每个时间片的位置数据进行哈希计算，得到签名数据；依据每个时间片的位置数据进行压缩，得到压缩后的轨迹向量数据；将签名数据和压缩后的轨迹向量数据由第二类计算引擎同步至第一类计算引擎。
进一步地，可选的，依据时间片对终端进行采样，得到每个时间片的位置数据包括：当时间片内有多个轨迹点时，通过计算多个轨迹点的位置数据均值、位置数据中位数或最后一个轨迹点的位置数据，得到时间片的位置数据。
可选的，依据时间片对终端进行采样，得到每个时间片的位置数据包括：当时间片内没有轨迹点时，将前一个时间片的位置数据或后一个时间片的位置数据确定为时间片的位置数据。
可选的，依据每个时间片的位置数据进行哈希计算，得到签名数据包括：将位置数据进行对齐处理，得到轨迹向量；从轨迹向量中随机获取轨迹点，组成局部轨迹向量；对局部轨迹向量进行哈希计算，得到签名数据。
可选的，依据每个时间片的位置数据进行压缩，得到压缩后的轨迹向量数据包括：对每个时间片的位置数据进行掩码计算，得到压缩后的轨迹向量数据。
可选的，依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据包括：获取待查询对象和待查询时间段；依据待查询对象和待查询时间段在第一类计算引擎中查询，得到待查询对象在待查询时间段的签名数据。
可选的，依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据包括：当获取待查询对象在待查询时间段的轨迹数据时，通过对轨迹数据进行分片，得到轨迹向量；依据轨迹向量进行在线签名，得到待查询对象的签名数据。
可选的，依据签名数据从第一类计算引擎中获取候选集合包括：依据签名数据的桶编号，在第一类计算引擎中进行查询，得到桶编号相同的签名数据集合；将签名数据集合确定为第一候选集。
进一步地，可选的，在将签名数据集合确定为第一候选集之后，该方法还包括：根据预设距离公式计算第一候选集中的签名数据与签名数据之间的距离；对距离进行排序，得到第二候选集。
可选的，通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象包括：通过第一类计算引擎，将第二候选集中签名数据对应的移动设备的轨迹向量数据，与待查询对象的签名数据的轨迹向量数据进行相似度计算，得到多个计算结果；依据预设顺序排列多个计算结果的相似度，将位于前n个的计算结果确定为与待查询对象轨迹相似的伴随对象。
根据本发明实施例的另一方面，还提供了一种数据处理的装置，包括：提取模块，用于依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据；获取模块，用于依据签名数据从第一类计算引擎中获取候选集合；计算模块，用于通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象。
根据本发明实施例的又一方面，还提供了一种数据处理的系统，包括：第一类计算引擎和第二类计算引擎，其中，第二类计算引擎，用于依据时间片对终端进行采样，得到每个时间片的位置数据；依据每个时间片的位置数据进行哈希计算，得到签名数据；依据每个时间片的位置数据进行压缩，得到压缩后的轨迹向量数据；将签名数据和压缩后的轨迹向量数据由第二类计算引擎同步至第一类计算引擎；第一类计算引擎，用于依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据；依据签名数据获取候选集合；通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量进行相似度计算，得到与待查询对象轨迹相似的伴随对象。
根据本发明实施例的再一方面，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述数据处理的方法。
在本发明实施例中，采用将原始的定位日志数据进行预处理、轨迹压缩存储以及轨迹签名，然后将其数据处理结果同步到实时查询引擎，以便用于在线快速检索的方式，通过依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据；依据签名数据从第一类计算引擎中获取候选集合；通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象，达到了通过轨迹签名的方式，将高维的向量数据降低到64位(16个字节)的数据中，使得索引查询得到候选集的时间可控；通过将轨迹数据进行压缩存储，极大地降低了需要检索的数据量，加速轨迹检索过程的目的，从而实现了通过随机方法获取局部向量数据然后进行hash签名，可以有效地降低噪声数据对签名的影响的技术效果，进而解决了从海量的轨迹数据中找出与目标轨迹的相似度高的其它轨迹的过程中海量数据带来的计算效率低的技术问题。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例一的数据处理的系统的结构图；
图2是根据本发明实施例一的数据处理的系统中实际签名的示意图；
图3是根据本发明实施例一的数据处理的系统中对轨迹向量进行哈希处理的示意图；
图4是本发明实施例的一种数据处理的方法的计算机终端的硬件结构框图；
图5是根据本发明实施例二的数据处理的方法的流程图；
图6是根据本发明实施例三的数据处理的装置的流程图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
本申请涉及的技术名词：
签名：将高维向量数据转换为低维向量的过程，通常用于降低计算时间复杂度。
采集密度不一致的定位数据:定位数据的采集频率在数分钟到1小时内，非恒定的频率。
有噪声的定位数据：1)定位数据的精度一般，如通过基站定位的精度；2)定位的数据可能存在噪声，如实际位置在a，而采集到的定位数据会一定概率的在与位置a相差数公里的位置b。
实施例1
根据本发明实施例的一方面，还提供了一种数据处理的系统，图1是根据本发明实施例一的数据处理的系统的结构图，如图1所示，包括：第一类计算引擎12和第二类计算引擎14，
其中，第二类计算引擎14，用于依据时间片对终端进行采样，得到每个时间片的位置数据；依据每个时间片的位置数据进行哈希计算，得到签名数据；依据每个时间片的位置数据进行压缩，得到压缩后的轨迹向量数据；将签名数据和压缩后的轨迹向量数据由第二类计算引擎14同步至第一类计算引擎12；第一类计算引擎12，用于依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据；依据签名数据从第一类计算引擎中获取候选集合；通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象。
本申请实施例提供的在数据处理系统分为两个部分，分别是数据处理部分和在线计算部分。其中，数据处理部分位于第二类计算引擎14，在线计算部分位于第一类计算引擎12；如图1所示，第一类计算引擎12可以为实时引擎，第二类计算引擎14可以为离线引擎；其中，实时引擎可以包括：ads；离线引擎可以包括：odps。
本申请实施例在进行数据处理的过程中,首先,需在离线引擎中进行数据预处理,即,将原始的定位日志数据进行预处理、轨迹压缩存储以及轨迹签名，然后将其数据处理结果同步到实时引擎；其次,由实时引擎在接收在线查询请求的情况下,依据该在线查询请求进行在线快速检索。
具体的，在离线引擎中，数据处理过程如下：
1.数据预处理：很多场景下的定位数据的采集频率通常会波动较大，使得整体的定数据密度不算高。如高频的时候可能2～3分钟就会采集一次，而低频的时候可能要1小时才会采集一次，使得每个移动设备采集到的定位数据量各不一致，也就使得不同移动设备的轨迹数据大小参差不齐。
为了使得不同设备对象的轨迹数据大小一致，在数据预处理阶段对每个移动设备的轨迹数据按时间片进行采样。如每5分钟作为一个时间片时，这样一天的轨迹就有288个时间片，即，一天24小时，每小时60分钟，每天的时间片数＝(24×60)/5＝288，每一个时间片中取一个轨迹点作为该时间片的位置数据。具体每一个时间片取位置数据的方法如下：
当某个时间片内有多个轨迹点时，可以使用多个轨迹点的均值、中位数或者最后一个轨迹点作为该时间片的位置数据。
当某个时间片内没有轨迹点时，可以使用其前一个时间片或者后一个时间片的位置数据进行补位填充。
因此，通过对原始的轨迹数据进行时间分片的方法，可以使得参差不齐的轨迹数据对齐，有助于进一步的数据处理。即，将得到预处理后的轨迹数据称作轨迹向量v。
本申请实施例通过采用时间分片的方式将轨迹数据对齐，使得轨迹数据标准化。
2.轨迹签名：尽管对原始的轨迹数据通过分片对齐完成了标准化处理，但是若在海量的轨迹向量数据中找出与目标轨迹向量(即，本申请实施例中待查询对象的轨迹向量)相似的其它轨迹向量(即，本申请实施例中与该待查询对象的轨迹向量相似的伴随对象的轨迹向量)，则需要对轨迹向量进行签名，通过签名的方法把轨迹数据转为为一个维数较低的签名，可以很大程度地提升计算效率。这里本申请实施例把一个轨迹向量变成一个64字节的签名。
轨迹签名实际上就是对轨迹数据进行hash的一种处理过程，这里本申请实施例优选使用的是lsh(局部敏感哈希，localitysensitivehashing)技术，其中，局部敏感哈希技术，能够把搜索范围集中在那些可能的相似项上面。实质上就是将可能相似的项分配到一个桶中，不相似的项分配到不同的桶中。
本申请实施例对轨迹数据的实际签名方法如图2所示，图2是根据本发明实施例一的数据处理的系统中实际签名的示意图，向量v表示通过时间分片后的轨迹数据，以此可以将一个几百维的轨迹变成一个大小为64字节的签名数据。
通常情况下，如图3所示，图3是根据本发明实施例一的数据处理的系统中对轨迹向量进行哈希处理的示意图，轨迹向量的签名数据会与轨迹向量的实际数据值很敏感，一旦数据值发生了微小的变化，那么签名数据也会波动很大，这就使得图3中的实线轨迹和虚线轨迹的签名会相差很大。而在很多真实的场景中虚线轨迹和实线轨迹实际为同行两个移动设备产生的轨迹信息，因为脏数据的存在，使得其中虚线轨迹有一处(或者少量)位置数据波动，导致直接使用通用的hash方法失效。
在一些采集数据不严格的场景下，如通过基站定位，都会或多或少的存在一定的脏数据，就如图2中的虚线轨迹所示。为了让签名结果不会过多被这种少量的噪声数据影响，所以这里本申请实施例使用了一种随机局部hash的方法来进行签名，很大程度上可以衰减噪音带来的签名波动。具体进行hash的方法如下所示。
(1)从轨迹向量中随机选择几个(如3个或者5个)轨迹点，组成局部轨迹向量v′；
(2)对局部轨迹向量v′进行hash编码，使用的hash函数是
对上述的hash方法总共进行64次操作，可以得到64个0～255的数值，共同拼接构成轨迹向量的签名，其中每4个数值构成一个分桶编号。通常只要两个轨迹向量存在一个对应的分桶编号一致，则认为它们相似，可以通过数据库等值查询完成召回。
本申请实施例通过轨迹签名的方式，将高维的向量数据降低到64位(16个字节)的数据中，使得索引查询得到候选集的时间可控；通过将轨迹数据进行压缩存储，极大地降低了需要检索的数据量，加速轨迹检索过程。
为了适应多样性的时间区间的查询请求，可以对移动设备在半天(12个小时)、1天(24小时)以及3天(72小时)等时间窗口大小的轨迹向量上进行签名处理，签名的轨迹时间窗口可以根据实际的场景调整。即，本申请实施例通过自动调整对轨迹签名的窗口大小，将超长时间的轨迹向量数据压缩到64字节的签名数据中，如对5天、10天的轨迹进行签名，可以轻松支持长时间的伴随分析。
3.轨迹压缩存储：当采用每5分钟进行一个时间分片的时候，一天的轨迹向量就有288维的数据，如果每一维数据按行存储，在本申请实施例中优选的每一行的字段结构是[移动设备编码，位置点，时间片]，就会占用288行的存储量。
而实际情况是，对于绝大部分的移动设备，是会经常性长期驻留在某一个位置点附近的(如在工作地、居住地等等)，仅仅只有在少量的时间段会有跨一定距离的移动。所以当某个移动设备持续的停留在某个位置点附近的时候，本申请实施例用掩码的方式来表示该移动设备是否停在某个位置点，降低存储量，这样每一行的字段结构就变成[移动设备编码，位置点，掩码]。当掩码中的某个bit为1的时候，表示该移动设备在该掩码bit对应的时间出现在该位置点。
通过这种掩码的方式，可以有效的降低轨迹向量所占用的行数，如对于某个区域1亿的移动设备量，原始的一天轨迹向量会占用288亿行存储，而通过掩码方式进行压缩之后，可以将一天的轨迹向量数据压缩到15亿行左右。可以加速移动设备轨迹向量的检索过程。
4.数据同步到实时引擎：将签名数据和压缩后的轨迹向量数据同步到实时计算引擎，以便方便在线检索。
在实时引擎中，在线检索过程如下：
1.预处理检索请求：
由于用户的使用习惯部分，因此实时引擎所收到的检索请求也会存在不同的方式，常见方式如下：
方式一：如果检索请求包括某目标移动设备以及要进行分析的时间段，则从实时计算引擎中拉取出要进行伴随分析的目标轨迹对应的签名数据；
方式二：如果检索请求包括某个具体的时空轨迹数据，则根据与离线处理一样的分片方法，得到轨迹向量，然后对其进行在线签名，计算得到要进行伴随分析的轨迹所对应的签名数据。
2.筛选出候选集：基于目标轨迹的签名数据所对应的16个桶编号，从实时计算引擎中找出对应时间段与目标签名的对应桶且编号一致的签名，作为初步候选集a。
将初步候选集a中的所有签名数据与目标签名进行相似度计算，得到相似度高的topn作为签名相似候选集b。
签名的相似度可以用签名间的欧式距离表示，如果签名间的欧式距离越小，则签名的相似度越高。公式如下所示。
其中s1，s2分别表示两个64字节的签名。
3.精排结果：通过实时计算引擎，拉出候选集b中签名对应的移动设备的轨迹向量数据，将其与目标的轨迹向量进行相似度精算，将相似度高的topk的结果输出，作为最终的结果。
这里定义轨迹向量的相似度公式如下所示。
其中
其中vi表示轨迹向量i；
该公式使得只要两个对应的轨迹点在一定范围内，就可以有一定的得分，能够针对这种精度不高以及存在噪声的定位数据进行数据处理。
本申请实施例提供的数据处理的系统通过随机方法获取局部向量数据然后进行hash签名，可以有效地降低噪声数据对签名的影响。
实施例2
根据本发明实施例，还提供了一种数据处理的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，图4是本发明实施例的一种数据处理的方法的计算机终端的硬件结构框图。如图4所示，计算机终端40可以包括一个或多个(图中仅示出一个)处理器402(处理器402可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器404、以及用于通信功能的传输模块406。本领域普通技术人员可以理解，图4所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端40还可包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。
存储器404可用于存储应用软件的软件程序以及模块，如本发明实施例中的数据处理的方法对应的程序指令/模块，处理器402通过运行存储在存储器404内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的数据处理的方法。存储器404可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器404可进一步包括相对于处理器402远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端40。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置406用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端40的通信供应商提供的无线网络。在一个实例中，传输装置406包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置406可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。
在上述运行环境下，本申请提供了如图5所示的数据处理的方法。图5是根据本发明实施例二的数据处理的方法的流程图。
步骤s502，依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据；
在步骤s502中，本申请实施例提供的数据处理的方法适用于由实时引擎(即，本申请实施例中的第一类计算引擎)和离线引擎(即，本申请实施例中的第二类计算引擎)组成的数据处理的系统中，在收到检索请求时，通过实时引擎提取检索请求中的待查询对象和待查询时间对应的签名数据，即，实施例1中离线引擎对数据进行预处理时生成的签名数据和轨迹向量。
步骤s504，依据签名数据从第一类计算引擎中获取候选集合；
在步骤s504中，基于步骤s502中获取的签名数据，通过实时引擎，获取与该签名数据属于同一编号的签名集合，将该签名集合确定为候选集合。
步骤s506，通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象。
在步骤s506中，基于步骤s504中获取的候选集合，计算所述后续集合中签名对应的移动设备的轨迹向量数据，将该轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，将相似度高的前k个计算结果作为最终结果，即，得到与待查询对象轨迹相似的伴随对象。
在本发明实施例中，采用将原始的定位日志数据进行预处理、轨迹压缩存储以及轨迹签名，然后将其数据处理结果同步到实时查询引擎，以便用于在线快速检索的方式，通过依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据；依据签名数据从第一类计算引擎中获取候选集合；通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象，达到了通过轨迹签名的方式，将高维的向量数据降低到64位(16个字节)的数据中，使得索引查询得到候选集的时间可控；通过将轨迹数据进行压缩存储，极大地降低了需要检索的数据量，加速轨迹检索过程的目的，从而实现了通过随机方法获取局部向量数据然后进行hash签名，可以有效地降低噪声数据对签名的影响的技术效果，进而解决了从海量的轨迹数据中找出与目标轨迹的相似度高的其它轨迹的过程中海量数据带来的计算效率低的技术问题。
可选的，在步骤s506中得到与待查询对象轨迹相似的伴随对象之后，本申请实施例提供的数据处理的方法还包括：依据伴随对象获取与待查询对象轨迹相似的设备列表。
可选的，在步骤s502中依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据之前，本申请实施例提供的数据处理的方法还包括：
步骤s498，依据时间片对终端进行采样，得到每个时间片的位置数据；
步骤s499，依据每个时间片的位置数据进行哈希计算，得到签名数据；
步骤s500，依据每个时间片的位置数据进行压缩，得到压缩后的轨迹向量数据；
步骤s501，将签名数据和压缩后的轨迹向量数据由第二类计算引擎同步至第一类计算引擎。
具体的，结合步骤s498至步骤s501，在依据获取到的待查询对象和待查询时间段从第一类计算引擎中提取待查询对象的签名数据之前，在离线引擎中进行数据预处理，即，对应实施例1中离线引擎数据处理部分，通过时间片对终端进行数据采样，得到每个时间片的位置数据，为了找出与目标轨迹向量相似的其它轨迹向量，通过时间分片后的轨迹数据(即，本申请实施例中的位置数据)，以此可以将一个几百维的轨迹变成一个大小为64字节的签名数据，进而通过对位置数据的压缩得到的轨迹向量数据，将该轨迹向量数据与签名数据一起由离线引擎同步至实时引擎。
进一步地，可选的，步骤s498中依据时间片对终端进行采样，得到每个时间片的位置数据包括：
步骤s4981，当时间片内有多个轨迹点时，通过计算多个轨迹点的位置数据均值、位置数据中位数或最后一个轨迹点的位置数据，得到时间片的位置数据。
可选的，步骤s498中依据时间片对终端进行采样，得到每个时间片的位置数据包括：
步骤s4981’，当时间片内没有轨迹点时，将前一个时间片的位置数据或后一个时间片的位置数据确定为时间片的位置数据。
结合步骤s4981和步骤s4981’，对应实施例1中，每一个时间片提取位置数据，具体如下：
提取位置数据的方式在本申请实施例中包括如下两种方式：
方式一：当某个时间片内有多个轨迹点时，可以使用多个轨迹点的均值、中位数或者最后一个轨迹点作为该时间片的位置数据。
方式二：当某个时间片内没有轨迹点时，可以使用其前一个时间片或者后一个时间片的位置数据进行补位填充。
可选的，步骤s499中依据每个时间片的位置数据进行哈希计算，得到签名数据包括：
步骤s4991，将位置数据进行对齐处理，得到轨迹向量；
步骤s4992，从轨迹向量中随机获取轨迹点，组成局部轨迹向量；
步骤s4993，对局部轨迹向量进行哈希计算，得到签名数据。
结合步骤s4991至步骤s4993，对应实施例1中的轨迹签名部分，即，通过位置数据得到轨迹向量，根据轨迹向量中随机获取的轨迹点，组成局部轨迹向量，进而基于局部轨迹向量进行哈希计算，把轨迹数据转为为一个维数较低的签名数据，可以很大程度地提升计算效率。
可选的，步骤s500中依据每个时间片的位置数据进行压缩，得到压缩后的轨迹向量数据包括：
步骤s5001，对每个时间片的位置数据进行掩码计算，得到压缩后的轨迹向量数据。
具体的，对应实施例1中的轨迹压缩存储部分：当采用每5分钟进行一个时间分片的时候，一天的轨迹向量就有288维的数据，如果每一维数据按行存储，在本申请实施例中优选的每一行的字段结构是[移动设备编码，位置点，时间片]，就会占用288行的存储量。
而实际情况是，对于绝大部分的移动设备，是会经常性长期驻留在某一个位置点附近的(如在工作地、居住地等等)，仅仅只有在少量的时间段会有跨一定距离的移动。所以当某个移动设备持续的停留在某个位置点附近的时候，本申请实施例用掩码的方式来表示该移动设备是否停在某个位置点，降低存储量，这样每一行的字段结构就变成[移动设备编码，位置点，掩码]。当掩码中的某个bit为1的时候，表示该移动设备在该掩码bit对应的时间出现在该位置点。
通过这种掩码的方式，可以有效的降低轨迹向量所占用的行数，如对于某个区域1亿的移动设备量，原始的一天轨迹向量会占用288亿行存储，而通过掩码方式进行压缩之后，可以将一天的轨迹向量数据压缩到15亿行左右。可以加速移动设备轨迹向量的检索过程。
可选的，步骤s502中依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据包括：
步骤s5021，获取待查询对象和待查询时间段；
步骤s5022，依据待查询对象和待查询时间段在第一类计算引擎中查询，得到待查询对象和待查询时间段的签名数据。
可选的，步骤s502中依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据包括：
步骤s5021’，当获取待查询对象在待查询时间段的轨迹数据时，通过对轨迹数据进行分片，得到轨迹向量；
步骤s5022’，依据轨迹向量进行在线签名，得到待查询对象的签名数据。
结合上述步骤s502中的步骤s5021和步骤s5022，以及步骤s5021’和步骤s5022’，对应实施1中实时引擎中的预处理检索请求部分，得到如下：
方式一：如果检索请求包括某目标移动设备以及要进行分析的时间段，则从实时计算引擎中拉取出要进行伴随分析的目标轨迹对应的签名数据；
方式二：如果检索请求包括某个具体的时空轨迹数据，则根据与离线处理一样的分片方法，得到轨迹向量，然后对其进行在线签名，计算得到要进行伴随分析的轨迹所对应的签名数据。
其中，方式一对应步骤s5021和步骤s5022；方式二对应步骤s5021’和步骤s5022’。
可选的，步骤s504中依据签名数据从第一类计算引擎中获取候选集合包括：
步骤s5041，依据签名数据的桶编号，在第一类计算引擎中进行查询，得到桶编号相同的签名数据集合；
步骤s5042，将签名数据集合确定为第一候选集。
进一步地，可选的，在步骤s5042中将签名数据集合确定为第一候选集之后，本申请实施例提供的数据处理的方法还包括：
步骤s5043，根据预设距离公式计算第一候选集中的签名数据与签名数据之间的距离；
步骤s5044，对距离进行排序，得到第二候选集。
具体的，结合步骤s5041至步骤s5044，对应实施例1中的筛选出候选集部分，具体如下：
基于目标轨迹的签名数据所对应的16个桶编号，从实时计算引擎中找出对应时间段与目标签名的对应桶且编号一致的签名，作为初步候选集a(即，本申请实施例中的第一候选集)。
将初步候选集a中的所有签名数据与目标签名进行相似度计算，得到相似度高的topn作为签名相似候选集b(即，本申请实施例中的第二候选集)。
签名的相似度可以用签名间的欧式距离表示，如果签名间的欧式距离越小，则签名的相似度越高。公式如下所示。
其中s1，s2分别表示两个64字节的签名。
可选的，步骤s506中通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象包括：
步骤s5061，通过第一类计算引擎，将第二候选集中签名数据对应的移动设备的轨迹向量数据，与待查询对象的签名数据的轨迹向量数据进行相似度计算，得到多个计算结果；
步骤s5062，依据预设顺序排列多个计算结果的相似度，将位于前n个的计算结果确定为与待查询对象轨迹相似的伴随对象。
具体的，结合步骤s5061和步骤s5062，对应实施例1中实时引擎中的精排结果部分，具体如下：
通过实时计算引擎，拉出候选集b中签名对应的移动设备的轨迹向量数据，将其与目标的轨迹向量进行相似度精算，将相似度高的topk的结果输出，作为最终的结果。
这里定义轨迹向量的相似度公式如下所示。
其中
其中vi表示轨迹向量i；
该公式使得只要两个对应的轨迹点在一定范围内，就可以有一定的得分，能够针对这种精度不高以及存在噪声的定位数据进行数据处理。
本申请实施例提供的数据处理的方法通过随机方法获取局部向量数据然后进行hash签名，可以有效地降低噪声数据对签名的影响。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的数据处理的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
实施例3
根据本发明实施例的另一方面，还提供了一种数据处理的装置，图6是根据本发明实施例三的数据处理的装置的流程图，如图6所示，包括：
提取模块62，用于依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据；获取模块64，用于依据签名数据从第一类计算引擎中获取候选集合；计算模块66，用于通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象。
实施例4
根据本发明实施例的再一方面，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述数据处理的方法。
实施例5
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于保存上述实施例一所提供的数据处理的方法所执行的程序代码。
可选地，在本实施例中，上述存储介质可以位于计算机网络中计算机终端群中的任意一个计算机终端中，或者位于移动终端群中的任意一个移动终端中。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据；依据签名数据从第一类计算引擎中获取候选集合；通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：在得到与待查询对象轨迹相似的伴随对象之后，依据伴随对象获取与待查询对象轨迹相似的设备列表。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：在依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据之前，依据时间片对终端进行采样，得到每个时间片的位置数据；依据每个时间片的位置数据进行哈希计算，得到签名数据；依据每个时间片的位置数据进行压缩，得到压缩后的轨迹向量数据；将签名数据和压缩后的轨迹向量数据由第二类计算引擎同步至第一类计算引擎。
进一步地，可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：依据时间片对终端进行采样，得到每个时间片的位置数据包括：当时间片内有多个轨迹点时，通过计算多个轨迹点的位置数据均值、位置数据中位数或最后一个轨迹点的位置数据，得到时间片的位置数据。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：依据时间片对终端进行采样，得到每个时间片的位置数据包括：当时间片内没有轨迹点时，将前一个时间片的位置数据或后一个时间片的位置数据确定为时间片的位置数据。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：依据每个时间片的位置数据进行哈希计算，得到签名数据包括：将位置数据进行对齐处理，得到轨迹向量；从轨迹向量中随机获取轨迹点，组成局部轨迹向量；对局部轨迹向量进行哈希计算，得到签名数据。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：依据每个时间片的位置数据进行压缩，得到压缩后的轨迹向量数据包括：对每个时间片的位置数据进行掩码计算，得到压缩后的轨迹向量数据。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据包括：获取待查询对象和待查询时间段；依据待查询对象和待查询时间段在第一类计算引擎中查询，得到待查询对象和待查询时间段的签名数据。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：依据待查询对象和待查询时间段从第一类计算引擎中获取待查询对象的签名数据包括：当获取待查询对象在待查询时间段的轨迹数据时，通过对轨迹数据进行分片，得到轨迹向量；依据轨迹向量进行在线签名，得到待查询对象的签名数据。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：依据签名数据从第一类计算引擎中获取候选集合包括：依据签名数据的桶编号，在第一类计算引擎中进行查询，得到桶编号相同的签名数据集合；将签名数据集合确定为第一候选集。
进一步地，可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：在将签名数据集合确定为第一候选集之后，根据预设距离公式计算第一候选集中的签名数据与签名数据之间的距离；对距离进行排序，得到第二候选集。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：通过第一类计算引擎将候选集合中所有签名数据的轨迹向量数据与待查询对象的签名数据对应的轨迹向量数据进行相似度计算，得到与待查询对象轨迹相似的伴随对象包括：通过第一类计算引擎，将第二候选集中签名数据对应的移动设备的轨迹向量数据，与待查询对象的签名数据的轨迹向量数据进行相似度计算，得到多个计算结果；依据预设顺序排列多个计算结果的相似度，将位于前n个的计算结果确定为与待查询对象轨迹相似的伴随对象。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
- 还没有人留言评论。精彩留言会获得点赞！