轨道交通数据的处理方法及装置、数据查询方法与流程

1.本技术涉及城市轨道交通技术领域，具体而言，涉及一种轨道交通数据的处理方法及装置、数据查询方法。


背景技术：

2.随着城市轨道交通建设的加快和大数据时代的到来，近几年全国范围内地铁基础数据信息资源的体量呈现快速增长态势，与此同时，各类信息应用需求更是日益复杂，对数据服务与应用支撑能力提出越来越高的要求。相关技术中对轨道交通系统进行分析时，仅以轨道交通系统中一个业务系统的数据作为数据源，数据来源和分析维度单一。
3.针对上述的问题，目前尚未提出有效的解决方案。


技术实现要素：

4.本技术实施例提供了一种轨道交通数据的处理方法及装置、数据查询方法，以至少解决由于相关技术中对轨道交通系统进行分析时数据来源单一造成的仅能从单个维度对轨道交通系统进行分析的技术问题。
5.根据本技术实施例的一个方面，提供了一种轨道交通数据的处理方法，包括：采集目标轨道交通系统中多个业务系统的系统数据；将系统数据分类为历史数据和实时数据；通过数仓架构对历史数据进行处理，得到第一处理结果，并通过数仓架构对实时数据进行处理，得到第二处理结果；根据第一处理结果生成历史数据可视图，根据第二处理结果生成实时数据可视图；以及根据第一处理结果和第二处理结果共同确定数据查询引擎的数据源。
6.可选地，将系统数据分类为历史数据和实时数据，包括：确定与系统数据对应的接口的类型，其中，接口为采集系统数据的接口；根据接口的类型对系统数据进行分类，得到分类结果，其中，分类结果包括历史数据和实时数据。
7.可选地，根据接口的类型对系统数据进行分类，包括：如果同时存在第一类型接口和第二类型接口，将与第一类型接口对应的系统数据确定为历史数据，并将与第二类型接口对应的系统数据确定为实时数据；如果只存在一种类型的接口，确定接口对应的采集频率，并将与采集频率为第一频率的接口对应的系统数据确定为历史数据，将与采集频率为第二频率的接口对应的系统数据确定为实时数据，其中，采集频率为通过接口采集系统数据的频率，第一频率低于第二频率。
8.可选地，通过数仓架构对历史数据进行处理，得到第一处理结果，包括：将多个历史数据汇聚到中心数据仓库，通过数仓架构的批处理层在中心数据仓库中获取多个历史数据，同时对多个历史数据进行批处理，得到第一处理结果，并将第一处理结果存储在离线数据的数据库中；通过数仓架构对实时数据进行处理，得到第二处理结果，包括：通过数仓架构的速度层对每个实时数据依次进行流处理，得到多个第二处理结果，并将多个第二处理结果存储在缓存中；其中，数据库和缓存中的数据用于共同生成目标视图，目标视图中包括
历史数据可视图和实时数据可视图。
9.可选地，根据第一处理结果生成历史数据可视图，包括：将第一处理结果中的数据分类为客流数据、票务数据、行车数据和路网基础数据；根据客流数据生成客流专题可视图页面；根据票务专题生成票务专题可视图页面；根据行车数据生成行车专题可视图页面；根据路网基础数据生成路网基础专题可视图页面；以及根据客流专题可视图页面、票务专题可视图页面、行车专题可视图页面和路网基础专题可视图页面共同生成历史数据可视图。
10.可选地，根据第二处理结果生成实时数据可视图，包括：将第二处理结果中的数据分类为路网调度数据、路网服务数据和用于指示售票系统服务状态的数据；根据路网调度数据生成调度服务中心可视图页面，根据路网服务数据生成乘客服务中心可视图页面，根据用于指示售票系统服务状态的数据生成自动售检票系统页面；以及根据调度服务中心可视图页面、乘客服务中心可视图页面和自动售检票系统页面生成实时数据可视图。
11.可选地，历史数据可视图和实时数据可视图在同一界面中展示。
12.根据本技术实施例的另一方面，还提供了一种数据查询方法，数据查询方法应用于移动终端，包括：接收目标对象用于查询轨道交通数据的查询请求；响应于查询请求，确定发送查询请求的移动终端，获取移动终端的第一标识信息和与移动终端对应的用户的第二标识信息，其中，第二标识信息包括：用户的企业邮箱号码和用户的手机号码；获取与数据查询引擎绑定的移动终端的第三标识信息和与移动终端对应的用户的第四标识信息，将第一标识信息和第二标识信息与第三标识信息和第四标识信息进行对比；如果第一标识信息与第三标识信息相同，且第二标识信息与第四标识信息相同，确定发送查询请求的移动终端为与数据查询引擎绑定的移动终端，并向数据查询引擎发送轨道交通数据；如果第一标识信息与第三标识信息不相同，或者第二标识信息与第四标识信息不相同，拒绝向数据查询引擎发送轨道交通数据。
13.根据本技术实施例的另一方面，还提供了一种轨道交通数据的处理装置，包括：采集模块，用于采集目标轨道交通系统中多个业务系统的系统数据；分类模块，用于将系统数据分类为历史数据和实时数据；处理模块，用于通过数仓架构对历史数据进行处理，得到第一处理结果，并通过数仓架构对实时数据进行处理，得到第二处理结果；生成模块，用于根据第一处理结果生成历史数据可视图，根据第二处理结果生成实时数据可视图；以及根据第一处理结果和第二处理结果共同确定数据查询引擎的数据源。
14.根据本技术实施例的另一方面，还提供了一种非易失性存储介质，该非易失性存储介质中存储有计算机程序，其中，非易失性存储介质所在设备通过运行计算机程序执行上述的轨道交通数据的处理方法。
15.根据本技术实施例的另一方面，还提供了一种电子设备，包括存储器和处理器，存储器中存储有计算机程序，处理器被设置为通过计算机程序上述的轨道交通数据的处理方法。
16.在本技术实施例中，采用采集目标轨道交通系统中多个业务系统的系统数据；将系统数据分类为历史数据和实时数据；通过数仓架构对历史数据进行处理，得到第一处理结果，并通过数仓架构对实时数据进行处理，得到第二处理结果；根据第一处理结果生成历史数据可视图，根据第二处理结果生成实时数据可视图；以及根据第一处理结果和第二处理结果共同确定数据查询引擎的数据源的方式，通过以轨道交通系统中的多个业务系统作
为数据源，将从多个数据源中采集到的关键指标数据进行汇聚和处理，生成处理结果，达到了性多个维度分析轨道交通系统的目的，并且根据处理结果生成历史数据看板和实时数据看板显示在移动终端中，达到了便于轨道交通系统管理者查看轨道交通系统运行状态的目的，从而实现了在移动设备中集中展示路网运营情况，提高运营管理效率的技术效果，进而解决了由于相关技术中对轨道交通系统进行分析时数据来源单一造成的仅能从单个维度对轨道交通系统进行分析技术问题。
附图说明
17.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
18.图1是根据本技术实施例的一种轨道交通数据的处理方法的流程图；
19.图2是根据本技术实施例的一种数据处理的流程图；
20.图3是根据本技术实施例的历史数据看板的示意图；
21.图4是根据本技术实施例的实时数据看板的示意图；
22.图5是根据本技术实施例的一种数据查询引擎的工作流程图；
23.图6是根据本技术实施例的一种数据查询引擎页面的示意图；
24.图7是根据本技术实施例的一种轨道交通数据的处理装置的结构图。
具体实施方式
25.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分的实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本技术保护的范围。
26.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
27.为了更好地理解本技术实施例，以下将本技术实施例中涉及的技术术语解释如下：
28.数仓架构(lambda architecture)：一种能够整合离线计算和实时计算的大数据处理架构，包括批处理层(batch layer)、速度层(speed layer)和服务层(serving layer)三层，具有低延时性。
29.批处理：指在计算机上无需人工干预的情况下执行系列程序的作业，在本技术实施例中指在特定周期/时刻对成批量的处理历史数据。
30.流(式)处理：指不断合并新数据得出计算结果，用于处理持续产生的数据；在本申
请实施例中指实时的、逐一的处理每条实时数据。
31.缓存(cache)：访问速度比一般随机存取存储器(ram)快的高速存储器，也可以指系统中用于存储数据的缓存组件。
32.断面满载率：单位时间内，运营线路单向断面客流量与相应断面客位里程的比值；断面满载率＝断面客流量/断面运力*100％。
33.断面客流量：统计期内，运营线路某一方向上相邻两站间通过的乘客数量。
34.断面运力：单位时间内，线路某断面单向的额定运输能力。
35.兑现率：实际开行列数与计划开行列数的比值。
36.清人率：每行驶一万公里清人率＝清人列数/运营公里*104，统计期内，实际开行列车因故障、事故等无法继续执行载客业务，根据调度员命令将乘客由车厢清出，其中，同一列车多次清人按照一列计算。
37.掉线率：统计期内，因车辆、乘务等原因等致使列车未完成列车运行计划所规定的任务而回场，每行驶一万公里掉线率＝掉线列数/运营公里*104。
38.在相关技术中，仅以轨道交通系统中的一个业务系统作为数据源，仅能针对单一的业务系统进行数据分析；因此存在数据来源单一，分析维度单一进而导致分析结果无法反应真实的轨道交通客流状况的问题。另外，在相关技术中仅能将分析结果显示在个人电脑(personal computer)类型的终端而无法显示在便携的移动终端，因此存在不便于轨道交通系统的运营管理者随时查看的问题，降低用户体验的问题。为了解决该问题，本技术实施例中提供了相关的解决方案，以下详细说明。
39.根据本技术实施例，提供了一种轨道交通数据的处理方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
40.图1是根据本技术实施例提供的一种轨道交通数据的处理方法的流程图，如图1所示，该方法包括如下步骤：
41.步骤s102，采集目标轨道交通系统中多个业务系统的系统数据。
42.具体实施时，本技术实施例提供的方法以系统安装包的形式被安装在移动终端设备中得以被实现。在步骤s102中，以轨道交通系统中的多个业务系统作为数据源，同时采集多个业务系统的数据，其中，多个业务系统至少包括：轨道交通指挥中心系统(traffic control center，tcc)、自动售检票系统(automatic fare collection，afc)和乘客服务系统等反映轨道交通运营状况的关键业务系统。
43.步骤s104，将系统数据分类为历史数据和实时数据。
44.在步骤s104中，将采集到的数据按照实时数据和历史数据进行分类，以采用不同的处理方式分别对历史数据和实时数据进行处理；其中，历史数据可以是相对于采集数据的日期来说的昨日轨道交通数据，也可以是相对于采集数据的日期来说的过去七日的轨道交通数据。具体的，可以通过采集数据的接口的类型来判断采集的是历史数据还是实时数据，也可以通过采集数据的接口采用的协议的类型判断采集的是历史数据还是实时数据。
45.步骤s106，通过数仓架构对历史数据进行处理，得到第一处理结果，并通过数仓架构对实时数据进行处理，得到第二处理结果。
46.在步骤s106中，在通过步骤s104将采集到的数据分类为历史数据和实时数据之后，利用数仓架构分别在数仓架构的不同数据处理层处理历史数据得到与历史数据对应的(第一)处理结果，对实时数据进行处理，得到与实时数据对应的(第二)处理结果。
47.步骤s108，根据第一处理结果生成历史数据可视图，根据第二处理结果生成实时数据可视图；以及，根据第一处理结果和第二处理结果共同确定数据查询引擎的数据源。
48.在步骤s108中，根据步骤s106中处理历史数据得到的(第一)处理结果生成用于展示历史数据的历史数据看板(即历史数据可视图)，同时，根据处理实时数据得到的(第二)处理结果生成用于展示实时数据的实时数据看板(即实时数据可视图)；并且，第一处理结果和第二处理结果将共同作为数据查询引擎的数据源，以便当数据引擎接收到查询引擎后，从数据源中筛选出符合查询请求的数据并展示，其中，数据查询引擎能够从多个维度展示轨道交通系统的数据，例如，分别从时间维度、空间维度、票种维度这三个维度展示其中的一条数据。
49.通过上述步骤，可以实现汇聚多个业务系统的数据，并针对数据的类型分别以不同的方式进行处理，以不同维度展示处理结果；使得轨道交通系统运营管理者能够从多个维度观察轨道交通的整体运营情况。同时，上述步骤提供的方法能够应用在便携移动终端中，使得轨道交通系统运营管理者能够随时观测轨道交通的整体运营情况，并及时针对运营情况做出调整。
50.根据本技术一个可选的实施例，上述步骤s104中，将系统数据分类为历史数据和实时数据，包括：确定与系统数据对应的接口的类型，其中，接口为采集系统数据的接口；根据接口的类型对系统数据进行分类，得到分类结果，其中，分类结果包括历史数据和实时数据。
51.在本实施例中，如果预先定义了采集历史数据和实时数据的接口为不同类型的接口，则可以根据采集数据的接口的类型判断采集到的系统数据的类型；或者如果预先定义了采集历史数据和实时数据的接口为相同类型的不同接口，则根据接口采用的协议的类型或者接口采集数据的频率判断采集到的系统数据的类型，进而将采集到的系统数据分类为历史数据和实时数据。
52.具体的，上一实施例提及的根据接口的类型对系统数据进行分类，包括：如果同时存在第一类型接口和第二类型接口，将与第一类型接口对应的系统数据确定为历史数据，并将与第二类型接口对应的系统数据确定为实时数据；如果只存在一种类型的接口，确定接口对应的采集频率，并将与采集频率为第一频率的接口对应的系统数据确定为历史数据，将与采集频率为第二频率的接口对应的系统数据确定为实时数据，其中，采集频率为通过接口采集系统数据的频率，第一频率低于第二频率。
53.在本实施例中，根据采集数据的接口的类型判断采集到的系统数据的类型的方法如下：判断采集系统数据的接口的类型，如果采集系统数据的接口为不同类型的接口，说明预先为历史数据和实时数据指定了不同的采集接口，例如，定义了通过第一类型接口采集历史数据，通过第二类型接口采集实时数据，则将通过第一类型接口采集的数据确定为历史数据，将通过第二类型接口采集的数据确定为实时数据。如果判断得出采集系统数据的接口均为同一类型的接口，则确定每个接口采集系统数据的频率，由于采集实时数据的频率应高于采集历史数据的频率，因此将采集数据的频率低的接口采集的系统数据确定为历
史数据，将采集数据的频率高的接口采集的系统数据确定为实时数据。例如，判断得出接口采集数据存在第一频率和高于第一频率的第二频率，则确定采集频率为第一频率的接口采集的系统数据为历史数据，并确定采集频率为第二频率的接口采集的系统数据为实时数据。
54.根据本技术另一个可选的实施例，通过数仓架构对历史数据进行处理，得到第一处理结果，包括：将多个历史数据汇聚到中心数据仓库，通过数仓架构的批处理层在中心数据仓库中获取多个历史数据，同时对多个历史数据进行批处理，得到第一处理结果，并将第一处理结果存储在离线数据的数据库中；通过数仓架构对实时数据进行处理，得到第二处理结果，包括：通过数仓架构的速度层对每个实时数据依次进行流处理，得到多个第二处理结果，并将多个第二处理结果存储在缓存中；其中，数据库和缓存中的数据用于共同生成目标视图，目标视图中包括历史数据可视图和实时数据可视图。
55.图2是数据处理的流程图，如图2所示，在本实施例中，在处理历史数据之前，首先将来自多个不同系统的大量历史数据存储在中心级数据仓库中，在处理历史数据时，首先以中心及数据仓库作为数据源，通过离线采集程序从中批量提取历史数据，并在lambda架构的批处理层对提取到的批量历史数据进行批处理生成历史数据可视图(即第一处理结果)，将历史数据可视图(即第一处理结果)存储在数据库中。如图2所示，在处理实时数据时，通过在线采集程序将分类得到的实时数据按照数据的产生时间从早到晚依次采集形成待处理的消息队列，并在lambda架构的速度层依次对每一条实时数据进行流处理生成实时数据可视图(即第二处理结果)，将实时数据可视图(即第二处理结果)存储在系统的缓存中。另外，如图2所示，当将能够实现本技术实施例提供的轨道交通数据的处理方法的应用程序安装在移动设备中时，上述存储历史数据可视图(即第一处理结果)的数据库和存储实时数据可视图(即第二处理结果)的缓存将共同作为该应用程序的数据库，用于生成展示在移动设备中的历史数据可视图(即第一处理结果)和实时数据可视图(即第二处理结果)。
56.根据本技术一些实施例，根据第一处理结果生成历史数据可视图，包括：将第一处理结果中的数据分类为客流数据、票务数据、行车数据和路网基础数据；根据客流数据生成客流专题可视图页面；根据票务专题生成票务专题可视图页面；根据行车数据生成行车专题可视图页面；根据路网基础数据生成路网基础专题可视图页面；以及根据客流专题可视图页面、票务专题可视图页面、行车专题可视图页面和路网基础专题可视图页面共同生成历史数据可视图。
57.在一些实施例中，由于历史数据可视图和实时数据可视图中展示的数据不同，在生成目标视图之前(包括历史数据可视图和实时数据可视图)，对处理历史数据得到的(第一)处理结果和处理实时数据得到的(第二)处理结果归类。图3是历史数据看板示意图，如图3所示，历史数据看板以路网基础数据，客流数据、行车数据和票务数据模块这四类数据为基础生成，因此，在生成历史数据可视图之前，将历史数据的(第一)处理结果分为客流数据、票务数据、行车数据和路网基础数据四大类，其中，路网基础专题模块展示能够反映轨道交通系统运行状况的基础数据，包括：展示视图的日期所属年份的轨道交通系统的年客运量数据，到展示视图的日期前一天为止的整个轨道交通系统的总运营里程，到展示视图的日期前一天为止轨道交通系统各个线路的总运营里程，以及，到展示视图的日期前一天为止轨道交通系统中运营车站的数量。客流专题模块展示能够反映乘客状况的数据，包括：
到展示视图的日期前一天为止轨道交通系统的总客运量，到展示视图的日期前一天为止轨道交通系统的乘客进站次数，到展示视图的日期前一天为止轨道交通系统的乘客换乘次数，以及到展示视图的日期前一天为止轨道交通系统中车辆的最大断面满载率。行车专题模块展示能够反应车辆运行状态的数据，包括：到展示视图的日期前一天为止车辆运行正点率，到展示视图的日期前一天为止列车的兑现率，到展示视图的日期前一天为止列车的掉线率，以及到展示视图的日期前一天为止列车的清人率。票务专题模块展示能够反映车票的支付方式的数据，包括：到展示视图的日期前一天为止使用一卡通支付的车票占总车票的比例，到展示视图的日期前一天为止通过互联网渠道支付的车票占总车票的比例，到展示视图的日期前一天为止通过实体票支付占总车票的比例，以及到展示视图的日期前一天为止通过其他金融渠道(如数字人民币)支付的车票占总车票的比例。将属于客流数据类的数据存储在客流数据对应的表格中，将属于票务数据类的数据存储在票务数据对应的表格中，将属于行车数据类的数据存储在行车数据对应的表格中，并将属于路网基础数据类的数据存储在路网数据对应的表格中，在终端中展示的历史数据可视图可以包括以下四个页面：用于展示客流数据的客流专题可视图页面、用于展示票务数据的票务专题可视图页面、用于展示行车数据的行车专题可视图页面、以及用于展示路网基础数据的路网基础专题页面；也可以将一个历史数据可视图页面分为四个模块，其中，一个模块展示客流数据、另一个模块展示票务数据、另一个模块展示行车数据、另一个模块展示路网基础数据。
58.根据本技术另一些实施例，根据第二处理结果生成实时数据可视图，包括：将第二处理结果中的数据分类为路网调度数据、路网服务数据和用于指示售票系统服务状态的数据；根据路网调度数据生成调度服务中心可视图页面，根据路网服务数据生成乘客服务中心可视图页面，根据用于指示售票系统服务状态的数据生成自动售检票系统页面；以及根据调度服务中心可视图页面、乘客服务中心可视图页面和自动售检票系统页面生成实时数据可视图。
59.图4是实时数据看板示意图，如图4所示，实时数据看板以调度数据、服务数据和反映售票系统和检票系统的服务状态的数据为基础生成，因此，在生成实时数据看板之前，将实时数据的(第二)处理结果分为调度数据、服务数据和售检票系统数据三大类，其中，调度数据展示在调度服务中心模块，用于反映轨道交通系统的实时运营状况，包括：展示视图当日的路网运营状态信息、展示视图当日的路网客流信息、展示视图当日的路网行车信息、展示视图当日的各个线路的行车信息、展示视图当日的各个线路的客流指标、展示视图当日的各个线路的行车指标、展示视图当日的各个线路的断面满载率、展示视图当日的各个线路的预测客流量。服务数据展示在乘客服务中心模块，用于反映面向乘客的服务系统的状态，包括：客服热线数据，如用户拨打客服热线的次数，通话时长等，以及轨道交通系统移动端数据，如轨道交通系统在移动端被访问的次数。售检票系统数据展示在自动售检票系统模块，用于反映售票系统和检票系统的运行状态，包括：展示视图当日各个线路列车进站量，展示视图当日各个检票闸机(ag)的服务数据，展示视图当日各个全自动售票机(tvm)的运服务数据，展示视图当日各个半自动售票机(bom)的服务数据，以及展示视图当日各个即时售票机(itvm)的服务数据。将属于调度数据类的数据存储在调度数据对应的表格中，将属于服务数据类的数据存储在服务数据对应的表格中，并将属于售/检票系统服务数据类的数据存储在售/检票系统服务数据对应的表格中，在终端中展示的实时数据可视图可以
包括以下三个页面：用于展示调度数据的调度服务中心可视图页面、用于展示服务数据的乘客服务中心可视图页面、以及用于展示售/检票系统服务数据的自动售检票系统页面；也可以将一个实时数据可视图页面分为三个模块，其中，一个模块展示调度数据、另一个模块展示服务数据、另一个模块展示售/检票系统服务数据。
60.根据本技术一个可选的实施例，历史数据可视图和实时数据可视图在同一界面中展示。
61.在本实施例中，图3所示的历史数据看板和图4所示的实时数据看板可以同时显示在移动终端的一个显示界面，使用户能够同时观测历史数据看板和实时数据看板反映的轨道交通系统的运营情况；或者图3所示的历史数据看板或图4所示的实时数据看板分别单独展示在移动终端的显示界面，是用户能够更清晰的观测历史数据看板或实时数据看板。
62.图5是根据本技术实施例提供的一种数据查询方法的工作流程图，数据查询方法应用于移动终端，包括以下步骤：
63.步骤s502，接收目标对象用于查询轨道交通数据的查询请求。
64.图6是数据查询引擎页面的示意图，在步骤s506中查询引擎接收来自应用程序/目标对象的查询请求，其中，用户(目标对象)在查询引擎的搜索框中输入信息可以作为查询请求，用户(目标对象)在查询引擎中的索引表中选择的信息也可以作为查询请求，查询引擎中的索引表包括存储了昨日数据的索引表(速报数据索引表)和存储了过往七日数据的索引表(终报数据索引表)。
65.步骤s504，响应于查询请求，确定发送查询请求的移动终端，获取移动终端的第一标识信息和与移动终端对应的用户的第二标识信息，其中，第二标识信息包括：用户的企业邮箱号码和用户的手机号码。
66.查询引擎下载到移动终端后，移动终端的唯一标识信息与移动终端的用户将被与查询引擎绑定，具体的，可以将移动终端的唯一编码或者其它能够唯一标识终端的标识信息与查询引擎绑定，将使用查询引擎的用户的企业邮箱或其它能够唯一标识用户的标识信息与查询引擎绑定。因此，在步骤s504中查询引擎接收到查询请求后，首先获取发送查询请求的移动终端的标识信息(即第一标识信息)，和使用查询引擎的用户的标识信息(即第二标识信息)以对发送查询请求的终端和用户进行验证。
67.步骤s506，获取与数据查询引擎绑定的移动终端的第三标识信息和与移动终端对应的用户的第四标识信息，将第一标识信息和第二标识信息与第三标识信息和第四标识信息进行对比。
68.在步骤s506中，获取与查询引擎绑定的移动终端的标识信息(即第三标识信息)和与查询引擎以及查询引擎所在的移动终端绑定的用户的标识信息(即第四标识信息)，并将在步骤s504中获取的发送查询请求的移动终端的标识信息(即第一标识信息)和与查询引擎绑定的终端的标识信息(即第三标识信息)进行对比，将发送查询请求的用户的标识信息(即第二标识信息)和与查询引擎绑定的用户的标识信息(即第四标识信息)进行对比。
69.步骤s508，如果第一标识信息与第三标识信息相同，且第二标识信息与第四标识信息相同，确定发送查询请求的移动终端为与数据查询引擎绑定的移动终端，并向数据查询引擎发送轨道交通数据。
70.在步骤s508中，根据在步骤s206中对比得到的对比结果判断是否向发送查询请求
的移动终端返回轨道交通数据；如果发送查询请求的移动终端的标识信息(即第一标识信息)与查询引擎绑定的移动终端的标识信息(即第三标识信息)相同，且使用查询引擎的用户的标识信息(即第二标识信息)与查询引擎绑定的用户的标识信息(即第四标识信息)相同，确认发送查询请求的用户以及移动终端为与查询引擎绑定的用户和移动终端，并向发送查询请求的移动终端返回轨道交通数据。其中，在查询引擎中展示轨道交通数据时，可以从时间维度、空间维度和票种维度这三个维度展示查询结果，具体的，如图6所示，时间维度方面包括：年、月、周、日、工作日、节假日等跨度较大的维度，页包括：2小时、1小时、30分钟、15分钟、10分钟、5分钟和2分钟等时间跨度较小的维度。空间维度包括：全路网、指定区域、指定的一条线路、指定一个车站等较大的维度，也包括：指定的一个站厅、指定的一个闸机、指定的一个列车断面等较小的维度。票种维度包括：展示全票种付款类型、也包括仅展示二维码票种、仅展示一票通票种、仅展示一卡通票种、以及仅展示其它类型付款的票种。
71.步骤s510，如果第一标识信息与第三标识信息不相同，或者第二标识信息与第四标识信息不相同，拒绝向数据查询引擎发送轨道交通数据。
72.在步骤s510中，如果发送查询请求的移动终端的标识信息(即第一标识信息)与查询引擎绑定的移动终端的标识信息(即第三标识信息)不同，且使用查询引擎的用户的标识信息(即第二标识信息)与查询引擎绑定的用户的标识信息(即第四标识信息)不同，确认发送查询请求的用户以及移动终端不是与查询引擎绑定的用户和移动终端，并拒绝向发送查询请求的移动终端返回轨道交通数据。
73.图7是根据本技术实施例提供的一种轨道交通数据的处理装置的结构图，如图7所示，该装置包括：采集模块70用于采集目标轨道交通系统中多个业务系统的系统数据；分类模块72，用于将系统数据分类为历史数据和实时数据；处理模块74，用于通过数仓架构对历史数据进行处理，得到第一处理结果，并通过数仓架构对实时数据进行处理，得到第二处理结果；生成模块76，用于根据第一处理结果生成历史数据可视图，根据第二处理结果生成实时数据可视图；以及根据第一处理结果和第二处理结果共同确定数据查询引擎的数据源。
74.轨道交通数据的处理装置工作时，通过采集模块70采集轨道系统多个业务系统的数据，通过分类模块72将采集模块采集到的系统数据分类为实时数据和历史数据，通过处理模块74分别对历史数据处理得到历史数据的处理结果(即第一处理结果)，对实时数据处理，得到实时数据的处理结果(即第二处理结果)；最后通过生成模块76根据历史数据的处理结果(即第一处理结果)生成历史数据可视图，根据实时数据的处理结果(即第二处理结果)生成实时数据可视图，并将历史数据的处理结果(即第一处理结果)和实时数据的处理结果(即第二处理结果)共同作为数据查询引擎的数据源。
75.需要说明的是，图7所示实施例的优选实施方式可以参见图1所示实施例的相关描述，此处不再赘述。
76.本技术实施例还提供了一种非易失性存储介质，该非易失性存储介质中存储有计算机程序，其中，非易失性存储介质所在设备通过运行计算机程序执行以上的轨道交通数据的处理方法。
77.上述非易失性存储介质用于存储执行以下功能的程序：采集目标轨道交通系统中多个业务系统的系统数据；将系统数据分类为历史数据和实时数据；通过数仓架构对历史数据进行处理，得到第一处理结果，并通过数仓架构对实时数据进行处理，得到第二处理结
果；根据第一处理结果生成历史数据可视图，根据第二处理结果生成实时数据可视图；以及根据第一处理结果和第二处理结果共同确定数据查询引擎的数据源
78.本技术实施例还提供了一种电子设备，包括存储器和处理器，存储器中存储有计算机程序，处理器被设置为通过计算机程序以上的轨道交通数据的处理方法。
79.上述电子设备中的处理器用于运行执行以下功能的程序：采集目标轨道交通系统中多个业务系统的系统数据；将系统数据分类为历史数据和实时数据；通过数仓架构对历史数据进行处理，得到第一处理结果，并通过数仓架构对实时数据进行处理，得到第二处理结果；根据第一处理结果生成历史数据可视图，根据第二处理结果生成实时数据可视图；以及根据第一处理结果和第二处理结果共同确定数据查询引擎的数据源
80.需要说明的是，上述轨道交通数据的处理装置中的各个模块可以是程序模块(例如是实现某种特定功能的程序指令集合)，也可以是硬件模块，对于后者，其可以表现为以下形式，但不限于此：上述各个模块的表现形式均为一个处理器，或者，上述各个模块的功能通过一个处理器实现。
81.上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
82.在本技术的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
83.在本技术所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
84.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
85.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
86.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对相关技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
87.以上所述仅是本技术的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。

技术特征：
1.一种轨道交通数据的处理方法，其特征在于，包括：采集目标轨道交通系统中多个业务系统的系统数据；将所述系统数据分类为历史数据和实时数据；通过数仓架构对所述历史数据进行处理，得到第一处理结果，并通过所述数仓架构对所述实时数据进行处理，得到第二处理结果；根据所述第一处理结果生成历史数据可视图，根据所述第二处理结果生成实时数据可视图；以及根据所述第一处理结果和所述第二处理结果共同确定数据查询引擎的数据源。2.根据权利要求1所述的方法，其特征在于，将所述系统数据分类为历史数据和实时数据，包括：确定与所述系统数据对应的接口的类型，其中，所述接口为采集所述系统数据的接口；根据所述接口的类型对所述系统数据进行分类，得到分类结果，其中，所述分类结果包括所述历史数据和所述实时数据。3.根据权利要求2所述的方法，其特征在于，根据所述接口的类型对所述系统数据进行分类，包括：如果同时存在第一类型接口和第二类型接口，将与所述第一类型接口对应的系统数据确定为所述历史数据，并将与所述第二类型接口对应的系统数据确定为所述实时数据；如果只存在一种类型的接口，确定所述接口对应的采集频率，并将与所述采集频率为第一频率的接口对应的系统数据确定为所述历史数据，将与所述采集频率为第二频率的接口对应的系统数据确定为所述实时数据，其中，所述采集频率为通过所述接口采集所述系统数据的频率，所述第一频率低于所述第二频率。4.根据权利要求1所述的方法，其特征在于，通过数仓架构对所述历史数据进行处理，得到第一处理结果，包括：将多个所述历史数据汇聚到中心数据仓库，通过所述数仓架构的批处理层在所述中心数据仓库中获取多个所述历史数据，同时对多个所述历史数据进行批处理，得到所述第一处理结果，并将所述第一处理结果存储在离线数据的数据库中；通过所述数仓架构对所述实时数据进行处理，得到第二处理结果，包括：通过所述数仓架构的速度层对每个所述实时数据依次进行流处理，得到多个所述第二处理结果，并将多个所述第二处理结果存储在缓存中；其中，所述数据库和所述缓存中的数据用于共同生成目标视图，所述目标视图中包括所述历史数据可视图和所述实时数据可视图。5.根据权利要求1所述的方法，其特征在于，根据所述第一处理结果生成历史数据可视图，包括：将所述第一处理结果中的数据分类为客流数据、票务数据、行车数据和路网基础数据；根据所述客流数据生成客流专题可视图页面；根据所述票务专题生成票务专题可视图页面；根据所述行车数据生成行车专题可视图页面；根据所述路网基础数据生成路网基础专题可视图页面；以及根据所述客流专题可视图页面、所述票务专题可视图页面、所述行车专题可视图页面和所述路网基础专题可视图页面共同生成所述历史数据可视图。6.根据权利要求1所述的方法，其特征在于，根据所述第二处理结果生成实时数据可视
图，包括：将所述第二处理结果中的数据分类为路网调度数据、路网服务数据和用于指示售票系统服务状态的数据；根据所述路网调度数据生成调度服务中心可视图页面，根据所述路网服务数据生成乘客服务中心可视图页面，根据所述用于指示售票系统服务状态的数据生成自动售检票系统页面；以及根据所述调度服务中心可视图页面、所述乘客服务中心可视图页面和所述自动售检票系统页面生成所述实时数据可视图。7.根据权利要求1至6中任意一项所述的方法，其特征在于，所述历史数据可视图和所述实时数据可视图在同一界面中展示。8.一种数据查询方法，其特征在于，所述数据查询方法应用于移动终端，包括：接收目标对象用于查询轨道交通数据的查询请求；响应于所述查询请求，确定发送所述查询请求的移动终端，获取所述移动终端的第一标识信息和与所述移动终端对应的用户的第二标识信息，其中，所述第二标识信息包括：用户的企业邮箱号码和所述用户的手机号码；获取与数据查询引擎绑定的移动终端的第三标识信息和与所述移动终端对应的用户的第四标识信息，将所述第一标识信息和所述第二标识信息与所述第三标识信息和所述第四标识信息进行对比；如果所述第一标识信息与所述第三标识信息相同，且所述第二标识信息与所述第四标识信息相同，确定发送所述查询请求的移动终端为与所述数据查询引擎绑定的移动终端，并向所述数据查询引擎发送所述轨道交通数据；如果所述第一标识信息与所述第三标识信息不相同，或者所述第二标识信息与所述第四标识信息不相同，拒绝向所述数据查询引擎发送所述轨道交通数据。9.一种轨道交通数据的处理装置，其特征在于，包括：采集模块，用于采集目标轨道交通系统中多个业务系统的系统数据；分类模块，用于将所述系统数据分类为历史数据和实时数据；处理模块，用于通过数仓架构对所述历史数据进行处理，得到第一处理结果，并通过所述数仓架构对所述实时数据进行处理，得到第二处理结果；生成模块，用于根据所述第一处理结果生成历史数据可视图，根据所述第二处理结果生成实时数据可视图；以及根据所述第一处理结果和所述第二处理结果共同确定数据查询引擎的数据源。10.一种非易失性存储介质，其特征在于，所述非易失性存储介质中存储有计算机程序，其中，所述非易失性存储介质所在设备通过运行所述计算机程序执行权利要求1至7中任意一项所述的轨道交通数据的处理方法。11.一种电子设备，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为通过所述计算机程序执行权利要求1至7中任意一项所述的轨道交通数据的处理方法。

技术总结
本申请公开了一种轨道交通数据的处理方法及装置、数据查询方法。其中，该方法包括：采集目标轨道交通系统中多个业务系统的系统数据；将系统数据分类为历史数据和实时数据；通过数仓架构对历史数据进行处理，得到第一处理结果，并通过数仓架构对实时数据进行处理，得到第二处理结果；根据第一处理结果生成历史数据可视图，根据第二处理结果生成实时数据可视图；以及根据第一处理结果和第二处理结果共同确定数据查询引擎的数据源。本申请解决了由于相关技术中对轨道交通系统进行分析时数据来源单一造成的仅能从单个维度对轨道交通系统进行分析的技术问题。进行分析的技术问题。进行分析的技术问题。


技术研发人员：孙方 于增 孙琦 李松昂
受保护的技术使用者：北京轨道交通路网管理有限公司
技术研发日：2023.06.07
技术公布日：2023/8/23