一种派单链路故障确定方法、装置、设备及存储介质与流程

1.本技术涉及计算机技术领域，具体涉及一种派单链路故障确定方法、装置、设备及存储介质。


背景技术：

2.目前，派单链路的故障分析旨在收到派单失败反馈时能够及时快速定位派单失败的链路节点，分析派单链路断点的原因。现有的技术方案的主要有两类：第一类技术方案主要针对日志的存储查询，比如elk(elasticsearch,logstash,kibana)实时日志分析平台，第二类技术方案采用嵌入程序的方式进行埋点采集。
3.然而，一方面，elk在处理大数据量时，聚合统计速度和响应速度较慢；同时，elk通过定时器发现派单系统数据库的变化之后才同步数据，会出现延迟，无法实现实时存储查询；同时，由于elk的聚合查询能力比较差，不适合多聚合查询的场景。另一方面，采用嵌入程序的方式进行埋点采集会影响程序的性能，对于一些日志量非常大的程序，使用这样和业务系统耦合的方式进行埋点采集，容易影响业务系统的正常运行。因此，需要提供更加高效的技术方案。


技术实现要素：

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.图8是本技术实施例提供的一种派单链路故障确定方法的服务器的硬件结构框图。
具体实施方式
26.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
27.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
28.以下介绍本技术实施例提供的一种派单链路故障确定方法，图1为本技术实施例提供的一种派单链路故障确定方法的流程示意图。需要说明的是，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图1所示，上述方法可以包括：
29.s101，响应于派单链路的故障分析任务，生成对列式数据库的查询语句，上述查询语句包括目标字段的查询参数，上述目标字段为司机标识字段和/或订单标识字段，上述列式数据库用于存储基于消息队列和流式处理框架对网约车派单系统的日志数据进行解析、分流和拆分处理后得到的派单日志数据。
30.在本说明书实施例中，故障分析任务的类型可以包括：司机接单失败的故障分析任务和订单派单失败的故障分析任务，查询语句可以包括：目标字段的查询参数和其他字段的查询参数，具体的，根据故障分析任务的类型，确定对应的目标字段。目标字段可以包括：司机标识字段和/或订单标识字段，其他字段可以包括：城市字段和派单时间字段。
31.在本说明书实施例中，如图2所示，在上述响应于派单链路的故障分析任务，生成对列式数据库的查询语句之前，上述方法还可以包括：
32.s201，采集上述网约车派单系统的日志数据。
33.具体的，通过filebeat(日志文件数据采集器)对网约车派单系统的日志数据进行采集。
34.s203，基于派单统计字段的目标格式对上述日志数据进行数据解析，生成上述目
标格式的日志数据。
35.在本说明书实施例中，派单统计字段可以包括但不限于：订单创建时间(createtime)、订单标识(orderno)、业务线(serviceline)、网约车应用程序名称(appname)、动作节点(action)、城市(citycode)、司机标识(driverno)、起点(origin)、链路跟踪标识(traceid)、业务场景(scenes)、业务消息(message)。
36.s205，将上述目标格式的日志数据传输到上述消息队列的第一消息通道。
37.具体的，上述消息队列可以包括kafka(消息引擎系统)，上述第一消息通道可以为kafka中的线程调度话题(topic)。kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理存入的所有动作流数据，并且可以有效的削峰填谷，防止程序在流量突然增大的时候因为无法及时处理数据导致程序崩溃。
38.s207，基于上述流式处理框架对上述第一消息通道中的日志数据进行分流处理，得到分流后的日志数据。
39.在本说明书实施例中，上述流式处理框架可以包括：flink(分布式处理引擎)，flink是一个能够支持高吞吐、低延迟、高性能的流处理任务的分布式流式数据处理框架。
40.在一个可选的实施例中，如图3所示，上述基于上述流式处理框架对上述第一消息通道中的日志数据进行分流处理，得到分流后的日志数据可以包括：
41.s301，获取预设日志匹配规则，上述预设日志匹配规则包括与上述派单统计字段关联的多种业务关键字。
42.具体的，可以基于flink从目标数据库中读取预设日志匹配规则，该目标数据库可以包括但不限于：mysql(关系型数据库管理系统)。
43.具体的，该预设日志匹配规则可以包括但不限于：与上述派单统计字段关联的多种业务关键字。可选的实施例中，上述多种业务关键字可以包括与网约车应用程序名称和/或派单时间。
44.s303，从上述第一消息通道中读取上述日志数据。
45.具体的，按照预设读取周期从第一消息通道中读取日志数据，具体的，预设读取周期可以基于日志分流的实际需求进行预先设置，例如，可以为10分钟或30分钟。
46.s305，基于上述多种业务关键字对上述日志数据进行分流处理，得到上述分流后的日志数据。
47.具体的，基于不同的分流需求，预设不同的业务关键字，将上述日志数据与不同的业务关键字进行正则匹配，得到对应的匹配日志数据，将对应的匹配日志数据作为分流后的日志数据。
48.由以上实施例可见，通过flink对上游第一消息通道中的日志数据进行拆分，根据不同的分流需求将日志数据分流到下游第二消息通道中的不同的topic中，从而下游的实时派单日志处理任务只需要读取对应的分流后的日志数据即可，避免了日志数据的重复读取，提升派单日志处理效率。
49.s209，将上述分流后的日志数据传输到上述消息队列的第二消息通道。
50.具体的，上述第二消息通道可以为kafka中的链路跟踪话题(topic)。在实际应用中，采用kafka作为消息队列可以有效的削峰填谷，防止程序在流量突然增大的时候因为派单日志处理不过来导致程序崩溃，提升派单日志处理效率和实时性。
51.s211，基于上述流式处理框架将上述第二消息通道中的日志数据存储到上述列式数据库的上述派单日志表。
52.具体的，上述列式数据库可以包括：clickhouse数据库，clickhouse可以快速写入大量数据，并且支持聚合分析日志数据。
53.在一个具体的实施例中，如图4所示，上述基于上述流式处理框架将上述第二消息通道中的日志数据存储到上述列式数据库的上述派单日志表可以包括：
54.s401，基于上述目标字段，对上述第二消息通道中的日志数据进行拆分处理，得到与上述目标字段对应的多条日志数据。
55.在一个可选的实施例中，当目标字段为司机标识时，某条日志数据的司机标识字段可能包括满足派单圈选条件的多个司机标识，基于该多个司机标识对该条日志数据进行拆分处理，分别得到每个司机标识对应的日志数据。
56.s403，基于上述流式处理框架将上述多条日志数据写入上述派单日志表。
57.在一个可选的实施例中，上述列式数据库可以包括多个以不同目标字段为索引主键的派单日志表，其中第一派单日志表以司机标识为索引主键，第二派单日志表以订单标识为索引主键。具体的，将上述多条日志数据分别基于不同的目标字段进行排序，然后写入到对应的派单日志表中。
58.由以上实施例可见，将派单日志数据基于不同的统计需求写到列式数据库不同的派单日志表中，以满足不同的数据查询需求，提升聚合查询效率。
59.在一个具体的实施例中，如图5所示，在上述基于上述流式处理框架将上述第二消息通道中的日志数据存储到上述列式数据库的上述派单日志表之后，上述方法还可以包括：
60.s501，生成上述第二消息通道中的日志数据在上述派单日志表中的派单日期分区信息。
61.具体的，可以基于一周7天设置派单日志表的7个派单日志表的派单日期分区。
62.s503，基于上述目标字段的预设索引粒度，生成上述派单日期分区信息对应的每个派单日期分区的索引标记文件。
63.具体的，基于预设索引粒度，将每个派单日期分区中的每一段派单日志数据生成一条索引标记信息，并基于每条索引标记信息对应行的派单日志数据，生成每个派单日期分区的primary.idx，即索引标记文件。以派单日志表的主键为订单标识、预设索引粒度为默认值8192行为例，当前有一组一亿行的派单日志数据，主键范围从1～100,000,000，将该组派单日志数据存储到目标派单日期分区后按照8192行为一个数据块，共有12208个数据块，确定的索引标记信息分别为1，8193，16635
……
，基于每条索引标记信息对应行的派单日志数据，生成索引标记文件。
64.s505，对上述每个派单日志分区中的每列派单日志数据分别进行压缩存储，生成上述每列派单日志数据对应的派单日志压缩文件和派单日志标记文件。
65.具体的，每列派单日志数据都对应一个单独存储该列派单日志数据的bin文件(二进制文件)，即派单日志压缩文件。例如，driverno.bin存放的是司机标识列的压缩数据。每列派单日志数据经过数据排序、压缩处理后，最后以压缩数据块的形式写入bin文件中。每个压缩数据块由头信息和压缩数据组成。头部信息包括校验和、数据压缩算法、数据压缩前
大小和压缩后大小组成。压缩数据由压缩粒度(granule)组成，压缩粒度的大小可以结合预设索引粒度进行设置。
66.具体的，派单日志标记文件(mrk文件)用于表征索引标记文件(primary.idx)中索引标记信息与派单日志压缩文件(bin文件)中派单日志的位置信息的映射关系。索引标记文件中的每条索引标记信息对应派单日志标记文件中的每条位置记录信息，位置记录信息可以包括：索引标记信息对应的压缩数据块在bin文件中的偏移量、每条派单日志数据在压缩数据块中的偏移量。
67.由以上实施例可见，利用列式数据库的索引机制，生成派单日期分区信息、索引标记文件、派单日志压缩文件和派单日志标记文件，以便于对派单日志表进行快速聚合查询，提升对派单链路的分析能力。
68.s103，基于上述目标字段的查询参数以及上述列式数据库的索引机制，对上述列式数据库中的派单日志表进行聚合查询，得到与上述查询语句关联的目标派单日志，上述派单日志表以上述目标字段为索引主键。
69.在一个具体的实施例中，如图6所示，上述基于上述目标字段的查询参数以及上述列式数据库的索引机制，对上述列式数据库中的派单日志表进行聚合查询，得到与上述查询语句关联的目标派单日志可以包括：
70.s601，根据上述目标字段，确定上述派单日志表中的待查询派单日志表。
71.具体的，当目标字段为司机标识时，确定以司机标识为索引主键的待查询派单日志表；当目标字段为订单标识时，确定以订单标识为索引主键的待查询派单日志表。
72.s603，根据上述查询语句和上述待查询派单日志表的派单日期分区信息，确定上述待查询派单日志表中的待查询派单日期分区。
73.具体的，根据查询语句中派单时间字段的查询参数和上述派单日期分区信息，确定待查询派单日期分区。
74.s605，根据上述查询参数和上述待查询派单日期分区的派单日志索引标记文件，确定上述查询参数对应的目标索引标记信息。
75.具体的，根据目标字段的查询参数确定对应的目标索引标记信息，从而确定需要读取的目标数据块。例如，以目标字段为订单标识、预设索引粒度为默认值8192行为例，当需要查询订单标识>500以及订单标识<12258的派单日志时，目标索引标记信息为0和1，需要读取第0个和第1个数据块。
76.s607，根据上述目标索引标记信息和上述待查询派单日期分区的派单日志标记文件，确定上述目标派单日志在上述待查询派单日期分区的派单日志压缩文件中的目标位置信息，上述派单日志标记文件用于表征上述索引标记文件中索引标记信息与上述派单日志压缩文件中派单日志的位置信息的映射关系。
77.具体的，根据目标索引标记信息对应派单日志标记文件中的位置记录信息，位置记录信息，确定目标索引标记信息对应的目标压缩数据块在派单日志压缩文件中的第一偏移量以及目标派单日志在目标压缩数据块中的第二偏移量。
78.s609，根据上述目标位置信息，从上述派单日志压缩文件中得到上述目标派单日志。
79.具体的，根据上述第一偏移量和上述第二偏移量，对上述派单日志压缩文件进行
解压得到上述目标派单日志。
80.由以上实施例可见，利用列式数据库的索引机制，能够对派单日志表进行快速聚合查询，减少查询时延，提升派单日志处理的实时性。
81.在一个可选的实施例中，目标派单日志可以包括司机接单失败日志和/或订单派单失败日志，上述基于上述目标字段的查询参数以及上述列式数据库的索引机制，对上述列式数据库中的派单日志表进行聚合查询，得到与上述查询语句关联的目标派单日志可以包括：
82.当上述目标字段为上述司机标识字段时，基于上述司机标识字段的查询参数以及上述列式数据库的索引机制，对上述列式数据库中的派单日志表进行聚合查询，得到上述司机接单失败日志。
83.当上述目标字段为上述订单标识字段时，基于上述订单标识字段的查询参数以及上述列式数据库的索引机制，对上述列式数据库中的派单日志表进行聚合查询，得到上述订单派单失败日志。
84.s105，根据上述目标派单日志，确定上述派单链路的故障节点，上述故障节点为导致司机接单失败的第一动作节点和/或导致订单派单失败的第二动作节点。
85.在实际应用中，司机接单的动作节点可以包括但不限于：司机在线状态检查、司机服务类型检查、司机接单状态变更检查；订单派单的动作节点可以包括但不限于：圈选备选司机、过滤不匹配司机、对备选司机进行顺位排序、确定第一顺位司机、向第一顺位司机推送派单消息。根据目标派单日志，确定失败的动作节点，从而确定派单链路的故障节点。
86.由以上本技术书实施例可见，利用本技术实施例提供的技术方案，一方面，可以通过基于消息队列和流式处理框架对网约车派单系统的日志数据进行解析、分流和拆分处理后得到的派单日志数据并写入到列式数据库，利用消息队列有效的削峰填谷，并基于流式处理框架的反压机制控制派单日志数据的流入量，实现对大数据量的低时延处理，提升派单日志数据处理系统的稳健性，避免程序崩溃；另一方面，派单日志数据处理系统与业务系统完全隔离，避免和业务系统耦合带来的问题；另一方面，基于列式数据库的列式存储机制，能够减少派单日志数据写入的时延，提升派单日志数据存储的实时性，另一方面，响应于派单链路的故障分析任务，生成对列式数据库的查询语句，所述查询语句包括目标字段的查询参数，所述目标字段为司机标识字段和/或订单标识字段；基于所述目标字段的查询参数以及所述列式数据库的索引机制，对所述列式数据库中的派单日志表进行聚合查询，得到与所述查询语句关联的目标派单日志，所述派单日志表以所述目标字段为索引主键；根据所述目标派单日志，确定所述派单链路的故障节点，所述故障节点为导致司机接单失败的第一动作节点和/或导致订单派单失败的第二动作节点，通过烈士数据库的索引机制，能够快速扫描派单日志表，提升对派单日志聚合查询的效率，从而快速定位派单链路的故障节点；另一方面，基于不同的目标字段，从不同的维度确定派单链路的故障节点，提升派单链路故障定位的准确度。
87.本技术实施例提供了一种派单链路故障确定装置，如图7所示，上述装置包括：
88.查询语句生成模块710，用于响应于派单链路的故障分析任务，生成对列式数据库的查询语句，上述查询语句包括目标字段的查询参数，上述目标字段为司机标识字段和/或订单标识字段，上述列式数据库用于存储基于消息队列和流式处理框架对网约车派单系统
的日志数据进行解析、分流和拆分处理后得到的派单日志数据；
89.聚合查询模块720，用于基于上述目标字段的查询参数以及上述列式数据库的索引机制，对上述列式数据库中的派单日志表进行聚合查询，得到与上述查询语句关联的目标派单日志，上述派单日志表以上述目标字段为索引主键；
90.故障节点确定模块730，用于根据上述目标派单日志，确定上述派单链路的故障节点，上述故障节点为导致司机接单失败的第一动作节点和/或导致订单派单失败的第二动作节点。
91.在本说明书实施例中，上述装置还可以包括：
92.日志采集模块，用于采集上述网约车派单系统的日志数据；
93.数据解析模块，用于基于派单统计字段的目标格式对上述日志数据进行数据解析，生成上述目标格式的日志数据；
94.第一数据传输模块，用于将上述目标格式的日志数据传输到上述消息队列的第一消息通道；
95.数据分流模块，用于基于上述流式处理框架对上述第一消息通道中的日志数据进行分流处理，得到分流后的日志数据；
96.第二数据传输模块，用于将上述分流后的日志数据传输到上述消息队列的第二消息通道；
97.数据存储模块，用于基于上述流式处理框架将上述第二消息通道中的日志数据存储到上述列式数据库的上述派单日志表。
98.在一个可选的实施例中，上述数据分流模块可以包括：
99.预设日志匹配规则获取单元，用于获取预设日志匹配规则，上述预设日志匹配规则包括与上述派单统计字段关联的多种业务关键字；
100.日志数据读取单元，用于从上述第一消息通道中读取上述日志数据；
101.分流处理单元，用于基于上述多种业务关键字对上述日志数据进行分流处理，得到上述分流后的日志数据。
102.在一个具体的实施例中，上述数据存储模块可以包括：
103.拆分处理单元，用于基于上述目标字段，对上述第二消息通道中的日志数据进行拆分处理，得到与上述目标字段对应的多条日志数据；
104.数据写入单元，用于基于上述流式处理框架将上述多条日志数据写入上述派单日志表。
105.在一个具体的实施例中，上述装置还可以包括：
106.派单日期分区信息生成单元，用于生成上述第二消息通道中的日志数据在上述派单日志表中的派单日期分区信息；
107.索引标记文件生成单元，用于基于上述目标字段的预设索引粒度，生成上述派单日期分区信息对应的每个派单日期分区的索引标记文件；
108.压缩存储单元，用于对上述每个派单日志分区中的每列派单日志数据分别进行压缩存储，生成上述每列派单日志数据对应的派单日志压缩文件和派单日志标记文件。
109.在一个具体的实施例中，聚合查询模块720可以包括：
110.待查询派单日志表确定单元，用于根据上述目标字段，确定上述派单日志表中的
frequency，rf)模块，其用于通过无线方式与互联网进行通讯。
119.本领域普通技术人员可以理解，图8所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器800还可包括比图8中所示更多或者更少的组件，或者具有与图8所示不同的配置。
120.本技术实施例还提供了一种存储介质，上述存储介质可设置于服务器之中以保存用于实现方法实施例中一种的派单链路故障确定方法相关的至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述方法实施例提供的派单链路故障确定方法。
121.可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
122.由上述本技术提供的派单链路故障确定方法、装置、设备或存储介质的实施例可见，利用本技术实施例提供的技术方案，一方面，可以通过基于消息队列和流式处理框架对网约车派单系统的日志数据进行解析、分流和拆分处理后得到的派单日志数据并写入到列式数据库，利用消息队列有效的削峰填谷，并基于流式处理框架的反压机制控制派单日志数据的流入量，实现对大数据量的低时延处理，提升派单日志数据处理系统的稳健性，避免程序崩溃；另一方面，派单日志数据处理系统与业务系统完全隔离，避免和业务系统耦合带来的问题；另一方面，基于列式数据库的列式存储机制，能够减少派单日志数据写入的时延，提升派单日志数据存储的实时性，另一方面，响应于派单链路的故障分析任务，生成对列式数据库的查询语句，所述查询语句包括目标字段的查询参数，所述目标字段为司机标识字段和/或订单标识字段；基于所述目标字段的查询参数以及所述列式数据库的索引机制，对所述列式数据库中的派单日志表进行聚合查询，得到与所述查询语句关联的目标派单日志，所述派单日志表以所述目标字段为索引主键；根据所述目标派单日志，确定所述派单链路的故障节点，所述故障节点为导致司机接单失败的第一动作节点和/或导致订单派单失败的第二动作节点，通过烈士数据库的索引机制，能够快速扫描派单日志表，提升对派单日志聚合查询的效率，从而快速定位派单链路的故障节点；另一方面，基于不同的目标字段，从不同的维度确定派单链路的故障节点，提升派单链路故障定位的准确度。
123.需要说明的是：上述本技术实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
124.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
125.本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件
来完成，也可以通过程序来指示相关的硬件完成，上述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
126.以上上述仅为本技术的较佳实施例，并不用以限制本技术，凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。