一种基于大数据系统的导航与位置服务的方法与流程
本发明涉及移动位置服务技术领域，具体涉及一种基于大数据系统的导航与位置服务的方法。
背景技术
位置服务(locationbasedservice，简称lbs)是近年来新兴的移动计算服务。随着室内外无缝定位技术和增强系统技术的发展，定位精度不断提高，在日常的生产、生活过程中，大众对位置服务的需求也日趋增长。车联网(internetofvehicles，简称iov)、移动社交网络、微博等新兴互联网应用日新月异，一方面，内置在手机、车载导航等移动设备中的gps，wi-fi等定位设备可以直接获得移动对象任意时刻准确的位置信息，并经过各种途径发布这些采集的位置信息，比如，移动社交网络的一些新型应用可以发布任意时刻用户所处的位置信息；另一方面，近期得到广泛应用的可穿戴设备等传感设备采集到的加速度、光学影像等数据经过处理后也可以准确地确定使用者的位置信息。在这种环境下，各种应用所使用的数据集在体量和复杂性上均已达到了“大”数据的层次，并逐步形成了位置大数据。其特点是数据体量大，信息碎片化，准确性较低，半结构化等，数据来源混杂、数据异构性大、数据价值密度低，实时性强但时空标识定义欠严格或欠精确。
在以上位置大数据特点影响下，基于位置数据的大数据服务将面临的如下几个方面的问题与挑战：
1)位置大数据具有典型的体量大、更新速度快、多元性和价值密度低等大数据特性。因此过去那些性能、容量、扩展性等受限，且管理复杂的集中式数据计算模式已不再适用于对具有这样一些特性的大数据进行存储与处理，因此亟需设计一种去中心化/自组织的分布式位置服务大数据系统原型架构，涵盖数据传输、存储、处理、分享、检索、分析及可视化等不同阶段，实现位置大数据的高效管理。
2)在位置大数据环境下，大规模数据对象的使用必然导致用户并发控制问题的存在。与传统网络服务应用层并发控制机制不同，在位置服务大数据系统中，用户的并发控制涉及服务访问、接口访问、数据访问等多个不同的层次，因此，需要在构建位置服务大数据系统过程中，研究层次化并发实时大容量用户访问方法，实现高效的用户并发访问处理过程。
3)在多源信息与位置服务融合方面，位置信息多源异构的特点使得信息在挖掘过程中存在着关联分析困难、价值难以挖掘的问题。为此，研究针对文本、图、表等多维信息挖掘处理算法，并基于智慧城市多样化数据及位置实现数据挖掘分析是本课题面临的主要难题之一。
4)位置大数据既直接包含用户的隐私信息，又隐含了用户的个性习惯、健康状况、社会地位等其他敏感信息。位置大数据的不当使用，会给用户各方面的隐私带来严重威胁。因此，在构建位置大数据系统过程中，亟需设计针对用户数据的安全保护机制，支撑位置大数据系统的正常运行。
然而，现有方法被证明准确率低、异常检测不完整、处理效率低下，目前为止还没有研究出针对该问题高效的、成熟的解决方案。
上海网罗电子科技有限公司申请的专利“一种基于位置信息的大数据任务的管理系统及方法”(申请号：cn201510486304.8申请日期：2015年8月10日公开号：cn105163277a公开日：2015年12月16日)，公开了一种基于位置信息的大数据任务的管理系统及方法，该方法包括设置于数据管理的区域的多个传感器，用于采集待管理的移动设备发射至传感器位置的信号强度数据；数据收集器，用于收集传感器采集到的信号强度数据，将信号强度数据进行数据化处理；核心数据分发服务器，用于将数据化处理后的信号强度数据进行分析，获得不同移动设备的设备标识，根据不同移动设备的设备标识为每一个移动设备创建一个对应的信息队列，将各个移动设备的信号强度数据发送到相应的信息队列；时序队列服务器，用于将每一个信息队列中的信号强度数据根据时序进行排序形成时序队列，根据预设的时间窗口从时序队列中选取对应数量的信号强度数据以数据组合的方式进行输出。
中国科学技术大学申请的专利“一种基于大数据的城市区域智能停车场导航和管理系统”(申请号：cn201610715357.7申请日期：2016年8月24日公开号：cn106128160a公开日：2016年11月16日)，公开了一种基于大数据的城市区域智能停车场导航和管理系统。所述方法的具体实施方式包括：由基于大数据的控制管理平台，由车主客户端、中央服务器端和停车场管理客户端三部分组成，车主客户端选用智能显示端，能够实现车主身份识别，定位导航，出入停车场以及一键付费功能，所述的定位导航功能是基于gps定位和lbs功能的地图交互原理实现的；所述的中央服务器端是大数据最核心的处理、交互中心；所述的停车场管理客户端，通过设置权限等级可以实现管理端身份识别，停车场定位，停车场管理以及信息推送。
沈阳建筑大学申请的专利“一种基于云计算和大数据的导航方法”(申请号：cn201610150671.5申请日期：2016年3月16日公开号：cn105716620a公开日：2016年6月29日)，提出了一种基于云计算和大数据的导航方法。所述方法的具体实施方式包括：通过存储车辆实时上传的行驶数据，并由此解析出车辆出行特点和路径在不同交通状况下的交通状态预设值，和计算出路径在各状况下各个时刻的交通归一化新息平方并存储。然后在用户进行导航时，实时进行道路预测和道路规划服务，定时发送导航指导信息给导航终端。导航终端，提供车辆行驶数据给终端服务器和接受来自服务器终端的导航指导信息。本发明在实时运算中，对不符合条件的交通初步预测结果进行重新预测，大大减小了服务器终端实时运算的负担。可对路径的未来交通状况作出快速及更准确的预测、从中选择最优导航路径的基于云计算和大数据的导航方法。
现有的专利在大数据位置导航中主要涉及车载系统中，同时现有的基于位置数据的大数据分析中的数据均直接依赖于各种传感器。当传感器覆盖范围狭小的时候，数据不全面的问题十分明显。
技术实现要素：
为了克服现有技术的不足，本发明提供一种基于大数据系统的导航与位置服务的方法。本发明要解决的技术问题通过以下技术方案实现：
本发明实施例提供一种基于大数据系统的导航与位置服务的方法，包括以下几个步骤：
步骤1：在服务器中安装cloudera-manager，利用cloudera-manager在服务器系统中安装分布式内存计算框架、分布式文件系统、数据仓库工具、日志采集系统和分布式消息订阅系统，构成大数据系统；
步骤2：搭建mashup网络聚合平台；
步骤3：利用所述mashup网络聚合平台、所述日志采集系统和所述分布式消息订阅系统软件采集用户签到信息，将所述用户签到信息记为原始数据；
步骤4：对所述原始数据进行数据清洗，得到第一数据，将所述第一数据存入所述分布式文件系统中；
步骤5：利用所述分布式内存计算框架对所述第一数据进行处理，获取用户的活动停留点序列和活动时间；
步骤6：构建路线图模型，将用户的活动停留点序列和活动时间输入路线图模型中，并根据用户发起的路线查询请求实现路线推荐。
在本发明的一个实施例中，所述步骤4包括：
利用数据操作模块对所述原始数据进行去重处理以实现数据清洗，得到所述第一数据。
在本发明的一个实施例中，所述步骤5包括：
从所述第一数据中选取用户在固定周期内的多个活动位置停留点，构建用户的活动停留点序列，并记录用户的活动时间；
将用户的活动停留点序列和活动时间存储于数据仓库工具提供的关系型数据库中，供地理信息系统gis可视化展示调用。
在本发明的一个实施例中，所述步骤6之后还包括：
步骤7：分析用户的兴趣和行为模式，对用户进行服务推荐。
在本发明的一个实施例中，所述步骤7包括：
步骤71：对用户的多个活动位置停留点采用fpgrowth算法或apriori算法进行频发集项挖掘，分析得到用户的兴趣和行为模式；
步骤72：对用户的实时位置数据进行处理，并根据用户的兴趣和行为模式向用户进行服务推荐。
在本发明的一个实施例中，所述步骤72还包括：
步骤721：根据用户的兴趣和行为模式的相似性进行聚类分析，筛选出多个共性游客，并展示给用户。
在本发明的一个实施例中，所述步骤721还包括：
从筛选出的多个共性游客的活动停留点中查找当前用户没有停留过的地点；
利用协同过滤算法计算用户对所述没有停留过的地点的兴趣度，并进行兴趣度排序，按照兴趣度从高到低的顺序推荐并展示给用户。
在本发明的一个实施例中，用户通过web应用或移动终端应用发起路线查询需求。
在本发明的一个实施例中，用户发起路线查询需求时输入时间和/或地点信息。
本发明的有益效果在于：
1、本发明实施例提出了结合互联网中各种位置数据的网络聚合，对采集的数据进行大数据分析，得到用户的行为模式和兴趣特点，从而实现相对准确的、完整的路线及服务推荐，并动态实现轨迹数据的可视化展示；本发明技术方案实现了位置数据的动态扩容存储，解决了现有技术中大数据量的高效存储、处理和查询问题，满足数据的增量分析以及低延迟推荐功能，轨迹路线的可视化展示。
2、本发明方法中，位置数据的来源取自互联网中，数据量众多且不同于其他专利和系统中直接使用传感器的方式，并且结合用户数据进行聚类等数据挖掘，根据用户分析结果、时间、位置对用户进行服务推荐、路线推荐，在一定程度上解决了已有推荐方法准确率低、速度慢的缺陷，并可使用在景区导航等特殊领域。
附图说明
图1为本发明的流程图；
图2为mashup应用结构图；
图3为路线推荐流程图；
图4为服务推荐流程图；
图5为聚类算法训练过程示意图；
图6为预定义规则示意图；
图7为网格合并过程示意图；
图8为经过转换后的网格属性示意图；
图9(a)-图9(c)为局部区域中进行边推测的过程示意图；
图10(a)-图10(b)为局部区域间的网格关系计算过程示意图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图对本发明的具体实施方式做详细的说明。
实施例一
下面结合附图对本发明进行详细说明：
本发明实施例提供一种基于大数据系统的导航与位置服务的方法，包括以下几个步骤：
步骤1：在服务器中安装cloudera-manager，利用cloudera-manager在服务器系统中安装分布式内存计算框架、分布式文件系统、数据仓库工具、日志采集系统和分布式消息订阅系统，构成大数据系统；
步骤2：搭建mashup网络聚合平台；
步骤3：利用所述mashup网络聚合平台、所述日志采集系统和所述分布式消息订阅系统软件采集用户签到信息，将所述用户签到信息记为原始数据；
步骤4：对所述原始数据进行数据清洗，得到第一数据，将所述第一数据存入所述分布式文件系统中；
步骤5：利用所述分布式内存计算框架对所述第一数据进行处理，获取用户的活动停留点序列和活动时间；
步骤6：构建路线图模型，将用户的活动停留点序列和活动时间输入路线图模型中，并根据用户发起的路线查询请求实现路线推荐。
在本发明的一个实施例中，所述步骤4包括：
利用数据操作模块对所述原始数据进行去重处理以实现数据清洗，得到所述第一数据。
在本发明的一个实施例中，所述步骤5包括：
从所述第一数据中选取用户在固定周期内的多个活动位置停留点，构建用户的活动停留点序列，并记录用户的活动时间；
将用户的活动停留点序列和活动时间存储于数据仓库工具提供的关系型数据库中，供地理信息系统gis可视化展示调用。
在本发明的一个实施例中，所述步骤6之后还包括：
步骤7：分析用户的兴趣和行为模式，对用户进行服务推荐。
在本发明的一个实施例中，所述步骤7包括：
步骤71：对用户的多个活动位置停留点采用fpgrowth算法或apriori算法进行频发集项挖掘，分析得到用户的兴趣和行为模式；
步骤72：对用户的实时位置数据进行处理，并根据用户的兴趣和行为模式向用户进行服务推荐。
在本发明的一个实施例中，所述步骤72还包括：
步骤721：根据用户的兴趣和行为模式的相似性进行聚类分析，筛选出多个共性游客，并展示给用户。
在本发明的一个实施例中，所述步骤721还包括：
从筛选出的多个共性游客的活动停留点中查找当前用户没有停留过的地点；
利用协同过滤算法计算用户对所述没有停留过的地点的兴趣度，并进行兴趣度排序，按照兴趣度从高到低的顺序推荐并展示给用户。
在本发明的一个实施例中，用户通过web应用或移动终端应用发起路线查询需求。
在本发明的一个实施例中，用户发起路线查询需求时输入时间和/或地点信息。
本发明实施例提出了结合互联网中各种位置数据的网络聚合，对采集的数据进行大数据分析，得到用户的行为模式和兴趣特点，从而实现相对准确的、完整的路线及服务推荐，并动态实现轨迹数据的可视化展示；本发明技术方案实现了位置数据的动态扩容存储，解决了现有技术中大数据量的高效存储、处理和查询问题，满足数据的增量分析以及低延迟推荐功能，轨迹路线的可视化展示。
实施例二
如图1所示，本发明的基本流程如图1所示。
第一数据即用户的地理位置数据，以车载或者移动传感器方式获取，通过网络上传互联网。
利用网络聚合工具mashup结合flume日志收集工具和kafka消息系统收集互联网中的位置数据信息存入分布式文件系统hdfs中，对收集到的原始数据通过去重操作实现数据清洗，并将处理后的数据存入hdfs中。
gis展示模块从hdfs中读取数据，并利用分布式计算框架对这些数据进行统计分析，分析结果按情况分别存入hive和关系型数据库中，由相应的web应用调用并结合百度地图等工具进行可视化展示。
对hdfs中的用户数据进行聚类，将用户进行类型划分，根据划分类型进行精准服务推荐。
采用rick算法算法，通过离线计算方式对hdfs中的数据进行处理，得出路线推荐模型，通过实时计算方式，针对用户发起的路线规划请求，获得top-k条符合用户要求的路线。
软件架构模型搭建如下所示。
先利用开源大数据平台管理工具cloudera-manager搭建完整的大数据系统。
在解决棘手的大数据分析和处理问题时，主要的企业和大型机构往往采用性能稳定的开源软件基础架构hadoop服务。在hadoop生态系统中，规模最大、知名度最高的公司则是cloudera，我们的大数据软件基础架构由cloudera-manager来实现和完成。通过cloudera+cdh的方式，可以方便的将所需要的大数据服务(hadoop，spark，hive等)安装到集群中，并提供统一的集群监控和管理。
在服务器中安装cloudera-manager，利用cloudera-manager在系统中安装分布式内存计算框架spark、分布式文件系统hdfs、海量日志采集系统flume、分布式消息订阅系统kafka等分布式软件。在数据存储和管理方面，主要是基于hadoop的hdfs分布式文件系统，将海量数据在集群上进行多副本冗余存储，为数据的高可用性、高吞吐量、高可靠性提供了保障。而数据分析主要是批数据处理分析与实时数据分析两部分组成。其中批数据处理分析主要是运用hadoop的mapreduce计算模型。而实时数据处理分析主要是通过spark与storm实现。spark主要是用于基于内存的数据处理，可以独立运行，也可以运行于hadoop之上作为hadoop的补充。spark为了使程序运行速度快，提供了支持任意操作图和内存分布数据集的通用执行模型，以提供比hadoop更快速的交互式查询，优化工作负载，支持大型且低延迟的数据分析应用。
数据采集方面采用了mashup网络聚合平台。
mashup并非新技术，而是在web2.0这个理念框架下的一种应用形式。mashup作为快速整合数据的一种应用开发模式，能够非常快速的把与某个主题相关的两个以上不同地方的信息整合在一起，形成具有统一体验的应用或网站，以满足情景式应用的需求。情景式mashup应用要求能够比较快速的构建，利用开放api和工具就成为最佳的选择。mashup的精髓在于提供新的服务，这就是所谓的“1+1>2”，从组合中获取新的价值。用两个或多个数据源作为输入，能产生的输出却不仅仅是这些输入的简单相加。
如图2所示，mashup由三部分组成：内容提供者、mashup站点、客户端。在lbs方面，mashup通过利用各种开放接口，可以将各类信息，比如旅游信息、交通信息、天气信息、房产信息、购物餐饮信息等与地图信息聚合在一起，从而可以给用户提供更全面的基于位置的咨询与服务。其中的信息的聚合通过mashup站点进行实现，并可以复用。
内容提供者，主要是用来提供mashup继承所需要的信息内容，他们一般相互独立，在相关的web协议下提供者可以将自己拥有的数据或内容对外提供，这也将方便数据检索。对于一些非免费的数据源没有对外提供接口，开发者可以通过网络爬虫技术获取，前提是非免费数据不涉及版权。
mashup站点是mashup逻辑所在地，负责将聚集的多项数据资源或者服务封装起来。响应程序对聚集到的资源及服务的调用，可以直接在浏览器通过客户端脚本生成内容，及在混搭的web页面嵌入代码及引用的各种api库。
客户端可以是web浏览器也可以是移动app，应用程序通过客户端将服务提供给用户，将服务信息以个性化的方式呈现。
本发明使用雅虎pipes搭建mashup网络聚合平台。
雅虎pipes是一个可以把互联网上的数据整合起来并进行操纵的强大工具。它提供了许多模块可以获取数据和对数据进行操纵。这些模块可以以类似unix管道的方式串联起来，从而完成复杂的功能。比如把多个订阅源组合成一个，然后进行过滤和排序操纵，最后输出新的单个订阅源。雅虎pipes提供的模块非常丰富，大概可以分为下面几类：
a)数据源模块：用来获取各种类型的数据源，为其它模块提供数据来源。数据源模块能够处理的数据源类型有atom/rss订阅源、csv、xml、json数据和html页面等。
b)用户输入模块：用来获取用户的输入。用户输入的值可以作为pipes运行时候的参数。比如一个pipe可以用来查询某个城市的餐馆信息，就可以使用用户输入模块将城市名称作为参数暴露出来。这样不同的用户可以根据其需要输入不同的城市名称来获得其需要的餐馆信息。用户可以输入的数据类型有url、数字、文本、日期和地理位置等。
c)数据操作模块：用来对数据进行处理。这些是雅虎pipes中核心的模块，可以进行的数据处理操作包括过滤、排序、合并、拆分、去头、去尾、去重、倒序、重命名、计数等。
d)字符串处理模块：用来对字符串进行处理。这些模块提供的功能包括字符串拼接、执行正则表达式、替换、提取子字符串、分词、提取术语和翻译等。
e)其它模块：这些模块所提供的功能包括构建url、构建日期、构建地理位置、格式化日期和进行简单数学运算等。
具体到示例mashup应用来说，使用雅虎pipes的基本思路是：从互联网上找到合适的订阅源作为数据来源，使用相应的模块获取这些数据，然后通过合并模块把订阅源整合起来，考虑到可能出现的重复，再通过去重模块删除标题重复的订阅源条目。然后使用雅虎pipes中的订阅源获取模块(fetchfeed)来获取内容。
下面将分别针对路线推荐和服务推荐并结合附图进行实施例描述。
示例一：路线推荐
如图3所示，路线推荐实现过程如下：
数据采集：整个应用的设计方案就是跟踪历史用户的浏览路线，以用户在景区内的签到数据作为st(space-time)数据来源，进一步分析挖掘出价值信息，作为后续的实时路线推荐依据。我们假设，在同一时刻，会有数以百计的用户进行点击签到行为，认为数据来源在每隔1-2分钟会产生一个兆级数据量，为了保证数据能够完整不出错的采集，将采用一个高可用的数据采集框架进行数据采集。flume就是在这样一个技术要求下产生的实时日志采集框架，可以很好的满足条件。数据在采集的同时需要将数据存储到系统文件中，在这里采用的是hdfs分布式文件系统。flume负责数据的采集，数据最终存储到hdfs文件系统下的某个位置。由于可能某个时刻采集的数据量非常大而且具有突发性，这个时候如果直接将数据写入到hdfs中，可能会造成写失败。kakfa作为一个中间件系统，可以在producer端连接flume，consumer端连接hdfs,起到了一个数据缓冲的作用。分布式文件系统作为签到数据的存储系统这个时候，就需要使用一个可以缓冲数据的通道连接flume和hdfs。，由于其分布性的特点，数据不是存储在单服务器上，而是根据其策略分布在集群下的某些服务器上，既增大了容错性也提高了效率。
数据处理过程：整个数据处理的过程采用rick算法。rick算法不同于以往基于道路图的路线推荐算法，该算法是在没有道路网络信息的前提下研究的城市路线推荐应用研究。数据源是一组高采集率的基于gps定位的历史轨迹数据，可能是社交应用的签到数据，带有地图标记社交照片，出租车的出行轨迹数据，或者其它形式数据。直接进行原始数据的计算将会是一个非常耗时的过程，而且也没有必要。该算法采取的减少计算量，便于数据建模的方式是地图网格化。分布式内存计算框架spark应用sparkstreaming结合graphx图计算，以及mlib机器学习，对hdfs中经过第四步骤处理的历史轨迹数据进行分析并构建基础路线图模型。先进行数据导入和筛选，为了系统能够达到最佳路线推荐的目的，需要做大量的前期工作。之所以能够智能地推荐，是系统预处理了大量的轨迹数据，对数据进行建模分析，智能推荐功能才能够在建模基础上有效且快速的进行。想要建模，那么就需要原始数据——用户历史签到数据。由于签到的位置分布比较广，有必要将签到位置集中到某地区。所有可以先根据经纬度筛选出景点标签，然后根据筛选后的景点标签筛选轨迹，目的是减少无效轨迹数量。接着进行网格划分，签到位置在理论上是不会重复的，如果将每个签到点作为一个顶点进行计算的化，这个数据量是不可想象的，而且也没有必要。目前最流行且受欢迎的方法是将区域进行网格化，凡是可以映射进一个网格的都作为一个点进行处理。接着进行网格合并，在划分好网格，获得网格集后，需要进行进一步合并网格。在合并网格前，需要简单说明下合并网格的作用：由于不确定轨迹的子轨迹之间可能具有相似性，通过时空上的相似性合并一些临近网格，在网格群中形成一个个独立的局部区域。如果查询的两个坐标位置刚好映射在某个局部区域内，那么推荐路线优先可以在这个局部区域内优先推断。当查询的路线是跨区域的，同样可以先行计算区域内的子路线然后再在区域之间选择恰当的路线。因此网格合并的主要优点是在不失去可靠性的前提下，降低了路线图模型的规模，减少寻找最短路径过程中所花费的时间。在建立局部区域集后，进行网格间的关系计算。每条有向边包含了两个属性，连接连接支持量和移动时间。通过上述操作，获取了路线图的模型所需的顶点集合和边集合。接下来可以用graphx，构建出一个完整的图模型g＝(v,e)。至此，整个图模型已经能够完全构建出来了。
用户在实时查询路线的时候，之所以能够及时的反馈，那是因为查询是基于后台已经完成的路线图进行的。路线图构建是个非常耗时的过程，是通过已有的签到数据进行分析完成的。历史签到数据先从用户客户端采集进分布式文件系统的某个目录下，spark使用sparkstreamingapi对指定目录下的数据进行读取并进行内存计算。使用spark进行内存计算的好处很明显，由于整个计算过程是在内存中完成的，不会频繁进行磁盘读写，大大降低了处理时间。sparkstreaming能够以一定的频率对输入数据进行分析，在我们的应用中，我们初步设定频率为1h，也就是每过一小时就将近1h的历史轨迹数据集进行再分析，构建出新的路线图，这样可以动态的推荐最佳路线，也更加的贴近实际。sparkstreaming结合graphx图计算，以及mlib机器学习，可以构建出一张路线图模型。在路线图模型的基础上，只要用户输入景区内需要经过的几个景点和时间要求，那么将很快得出top-k条符合用户要求的路线。
具体的，构建rick路线图模型，将用户的活动停留点序列和活动时间输入rick路线图模型中，并根据用户发起的路线查询请求实现路线推荐。实施过程包括：
6.1依据步骤4中存储在分布式文件系统hdfs中的第一数据，分布式内存计算框架spark在构建图模型模块阶段利用分布式内存计算框架spark，根据经纬度筛选出景点标签，然后根据筛选后的景点标签筛选客户签到位置；
6.2将步骤6.1中筛选后的客户签到位置按照区域进行网格划分，这个操作是构建图模型模块的基础条件，通过位置网格化的方式降低计算量，映射进同一个网格的签到位置都作为一个点进行处理，这些点构成建立路线图模型所需的顶点集合v，这些点中任意两点间的连线形成的有向边构成建立路线图模型所需的边集合e；
6.3通过时空上的相似性将一些临近网格进行合并，形成独立的局部区域集；接下来我们分析一下网格合并的策略：
6.31预定义规则，如图6所示：
规则1：
规则2：
6.31相邻网格间的连接支持数：
接下来将通过简单例子介绍连接支持数的概念。在图6中，假设存在(traja1,timea1),(traja2,timea2),(traja3,timea3)分别表示存在三条轨迹traja1,traja2,traja3从
前后点的合并稍有不同，前点使用规则1进行合并，后点使用规则2进行合并。
如图7所示，
6.4在建立局部区域集后，分别进行局部区域内的网格间的关系计算和局部区域间的关系计算。任意两个网格间的有向边的连接支持量和移动时间两个属性值。在进行计算之前需要将网格集内部数据进行适当调整，有利于边计算。
最后得到的网格集中每个网格包含如下信息：
1)本网格a所属区域rid；
2)所有下一个连续节点所在网格b的信息，包含：
网格b所属区域rid；
两个网格间移动时间列表。
这样计算后的网格集直接作为图模型的顶点序列。下面在图8中展示这部分输出的局部数据：
如图8所示，在网格(50,39)中存在如下信息：该网格隶属于rid＝206的区域。在历史轨迹中存在经过(50,39)网格，而下一个签到点网格为(48,40)的轨迹2条，所花时间分别为44s，102762s。存在经过(50,39)网格，而下一个签到点网格为(25,31)的轨迹2条，所花时间分别为3040s，708048s。存在经过(50,39)网格，而下一个签到点网格为(39,32)的轨迹1条，所花时间分别为34s。存在经过(50,39)网格，而下一个签到点网格为(42,58)的轨迹1条，所花时间分别为17170245s。
每条有向边e包含了两个属性，连接支持量e.s和移动时间e.t。通俗讲，连接支持量就是经过两个连续的相邻网格的轨迹经过次数。转移时间就是每次经过这条边所需的时间求平均值。根据区域的定义，一块区域有一系列相互连接的网格组成。因此可以首先在区域内的满足邻里关系的网格间构建虚拟的双向边。为了去推测出边的真实方向，转移支持,以及移动时间，采用了基于推测方式的最短路径法，在这里使用了dijkstra算法。
给出一块区域和一组不确定轨迹集，利用经过区域的不确定轨迹去得出区域内的边信息。对于经过指定区域内的每条轨迹，先推测出一条轨迹连续的两个点之间的最短路径。如图9(a)-图9(c)所示，用一个例子阐明了边推测的过程。正如图9(a)所示，四条不确定轨迹经过这块区域。举例，在图9(b)中，一条不确定轨迹p1→p2→p3(虚线正方形表示)经过了这块区域，可以通过dijkstra算法推测出p1→p2的最短路径，p2→p3的最短路径。在找到两个连续的点之间的最短路径后，等分分割移动时间，将均分后的时间添加到每条边的移动时间表上。另外，最短路径的每条边添加tid到对应的轨迹列表上，然后在最短路径上的每条边上的转移支持累计加一。如果在两个连续的点之间存在多条最短路径，那么需要对这几条路径对应的边进行数据更新。在这里，加入tp1→p2＝10min,tp2→p3＝16min,那么可以将时间进行均分，p1→p2根据边的条数均分为2份，p2→p3均分为4份，前者每条时间t＝5min,后者每条时间t＝4min，将这个时间值添加到边属性的时间列表中，连接支持数相应累加1。在计算完所有的轨迹后，轨迹信息已经全部注入到边中，这个时候可以使用map将边集rdd进行转化，转化后的边集rdd元素中的信息只有两个参数：连接支持数，转移平均时间(将上一个边集rdd中的时间列表数据平均化，得出平均值)。
通过使用历史不确定轨迹去推测出区域内的边信息，进一步淘汰那些多余的边以及转移支持量＝0的边。下面来举例说明多余的边的定义，已知g和g’空间相邻，对应一条边e1，如果在这块区域内存在来自g→g”的边e2和来自g’‘→g’的边e3，满足：
1)g和g”空间相邻，g”和g’空间相邻。
2)(e1.s+e2.s)/2≥e1.s
3)|e2.t+e3.t-e1.t|/max{(e2.t+e3.t),e1.t}≤θ，其中θ是一个给定的时间限制系数。
如图9(c)所示，经过删减所剩下的边，其中每条边的移动时间设定为这条边所有移动时间的平均时间。
接下来在区域间进行边的构建。类似的，利用历史不确定轨迹产生区域间的边。如果一条不确定轨迹从一块区域的一个网格转移到另一块区域的某个网格上的话，一条边直接在两个网格间产生。接下俩删减区域间多余的边。给出一条从区域a的g到区域b的g’的边e1，如果存在一条从g到g’de可选的路径ei→...→ej,满足：
1)∑jk＝iek.s>e.s,
2)
需要指出：一条多余的边的信息在被删除前应该将信息迁移到替换路线上。一条边的移动时间均分后添加到可替换的路线的每条边上。另外，多余的边上的轨迹列表应该用来更新替换路线上的每条边上信息。
如图10(a)-图10(b)经过上述的操作将得到一个完备的边集合。
6.5sparkgraphx提供了一整套流水作业的图计算解决方案。根据步骤6.2和步骤6.4中的顶点集合和边集合信息可以构建出一个完整的图模型g＝(v，e)；
6.6当用户发起路线推荐查询需求时，如果要查询的多个坐标位置刚好映射在同一个局部区域内，分布式内存计算框架spark使用sparkstreamingapi(对否)结合sparkstreaming和graphx,流式地接收查询请求，在该局部区域采用遍历算法快速得到top-k条符合用户需求的路线，并将其展示给用户；
6.7当用户发起路线推荐查询需求时，如果要查询的多个坐标位置是跨区域的，结合sparkstreaming和graphx,流式地接收查询请求，并采用图计算中的遍历算法，先行计算单个局部区域的子路线，再在各个局部区域之间选择恰当的路线作为推荐路线，并将其展示给用户。
实施例二：服务推荐
服务推荐的主要过程概括如下：
1、用户历史轨迹的收集和存储。
2、周边地理位置他人历史轨迹收集。
3、利用用户历史轨迹数据进行数据挖掘，分析用户兴趣和行为模式。
4、对所有人的历史轨迹数据进行数据挖掘，通过聚类算法分析不同人群的兴趣和行为模式。
5、根据第4步的数据分析和挖掘结果，将第3步的用户按照兴趣和行为模式最相近的原则进行归类，找出其所属人群。
6、根据所属人群对周边地理位置中的路线和服务选择对该用户进行近似推荐。
服务推荐的具体实现描述如下：
应用sparkstreaming对实时位置数据进行处理，历史轨迹在该过程中发挥核心作用。使用历史轨迹的原因主要是实时位置数据的稀疏性，某用户短时间的位置数据到达系统后只能形成短距离的轨迹，具有极大地偶然性，无法帮助算法对该用户进行任何分析判断。而对某用户进行推荐的时候，一方面需要了解用户自身的诸多个人信息(譬如喜好习惯，行为模式等)，另一方面通过其他用户的轨迹信息了解大众对周边地理位置的喜好特征(判断并寻找轨迹密集的位置场所)。整合信息后按照不同时间不同场合进行推荐。除了挖掘个人位置数据分析该用户的行为、生活模式、经验和意图，综合多人轨迹数据得到热门区域或经典路线，更进一步去了解人与人之间的相关性。两个用户的轨迹特征存在大量的相似性时，两个用户之间的相关性也较大。基于此我们既可以把与用户a相似性高的用户去过但他仍未去过的轨迹推荐给用户a。
整体工作可以分为两个部分进行：训练阶段和测试阶段。
系统的训练阶段：首先来分析位置数据的特征，由于移动定位技术的普遍性和易获取性以及移动终端数的日益增长，系统获取的轨迹采样率高(即每条形成的轨迹是由一个用户以相隔几秒钟的频率不间断的组成的)。故总体上数据的获取处理过程中通信、存储的代价不断加大，各种能源的消耗也急剧增加。上万用户一天的位置数据量可能达到上tb，对于系统的负担过于沉重。另一方面轨迹本身也存在很多冗余，几分钟几小时内的位置数据可能极度相似，只需选取具有代表性的点，即可满足任务的需求。轨迹是由地图上一系列时间确定的地理坐标点组成，每个用户的活动由一段时间的轨迹数据体现。通过轨迹检测停留的点，这里的点指的是一组实际的位置数据，一个用户的历史轨迹可以为一组停留点序列。这样既表达了用户的行为的重点，又减少了数据量，极大地减轻了系统负担。得到模型后，根据用户的特征模型，使用基于物品的协同过滤算法来完成推荐过程。一方面可以采用一些算法例如fpgrowth,apiori等对频发集项(聚类模型)进行挖掘，得到用户的行为模式，习惯爱好，生活规律。另一方面利用接收到的实时数据不断完善模型，同时不定时地向用户做出适合的推荐。而且，挖掘与该用户附近模型相似的用户，可用于路线推荐和朋友推荐。利用历史轨迹为用户找出最相似的n个潜在的朋友，完成朋友推荐。接下来还可以在这些潜在的朋友的轨迹路线中寻找该用户未曾去过的地点，然后对这些地点使用协同过滤算法来估计该用户对其兴趣度，最后把地点按照兴趣度从高到低排序，推荐给用户。训练过程如图5所示。
系统的测试阶段：测试功能的完备性以及推荐的准确率。主要的工作内容是系统源源不断地接收流数据模拟器发送的不同用户的数据。为了提高测试运行效率，选用10名用户的连续10天的轨迹数据进行测试位置数据的时间间隔是数十秒，数据总量大概在1亿条左右。而模拟器发送数据的间隔是1秒，数据量是10条。因此测试能够模拟实际情况，对实际有指导意义和参考价值。
以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施方式仅限于此，对于发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单的推演或替换，都应当视为属于本发明由所提交的权利要求书确定专利保护范围。
综上所述，本文中应用了具体个例对本发明提供的一种基于大数据系统的导航与位置服务的方法的实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方案及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制，本发明的保护范围应以所附的权利要求书为准。
- 还没有人留言评论。精彩留言会获得点赞！