Ticket abnormality detection method and device and storage medium

Abstract

The invention provides a ticket business anomaly detection method and device, and a storage medium. The method comprises the following steps: consuming ticket card transaction track data and portrait track data occurring in a rail transit station from a distributed message queue cluster; performing collision between the user and the ticket card on the ticket card transaction track data and the portrait track data in time and space to generate a fusion track collision record; constructing a portrait fusion file for the user and the ticket card according to the fusion track collision record; and performing anomaly detection on the fusion file and the portrait fusion file. According to the embodiment, stable archives are accumulated for the user and the ticket card based on space-time collision of the user and the ticket card, ticket business inspection is carried out, the accuracy of ticket business inspection can be ensured, a distributed calculation model based on a stream processing framework supports horizontal expansion and high availability, large-scale application is met, and the efficiency of ticket business inspection is improved. Therefore, the efficiency of rail transit ticket business inspection is effectively improved.

Description

Technical Field

[0001] This invention belongs to the technical field of rail transit, and in particular relates to a method, device and storage medium for detecting ticketing anomalies. Background Technology

[0002] With the rapid expansion of urban rail transit networks and the continuous growth of passenger flow, the use of preferential tickets such as senior citizen cards and student cards has become increasingly widespread. However, this has also led to a serious problem of misuse, where some non-target groups travel by misusing tickets, causing operational losses to rail transit companies and undermining the principle of fairness.

[0003] Currently, when users use their tickets to enter and exit the station, the turnstiles will notify the ticket holders. On-site staff will assess whether the user belongs to the target group based on the notification. If the user does not belong to the target group, the staff will verify the user's identity and check whether the user is the legitimate cardholder.

[0004] However, this manual inspection method is costly, has a narrow coverage, and is highly random. It is prone to oversights in the case of large passenger flows, resulting in low efficiency of rail transit ticket inspection. Summary of the Invention

[0005] In view of this, the present invention provides a method, device and storage medium for detecting ticketing anomalies, in order to improve the efficiency of ticketing inspection in rail transit.

[0006] The first aspect of the present invention provides a ticketing anomaly detection method applied to a distributed stream processing cluster, the method comprising:

[0007] Consume ticket transaction trajectory data and facial recognition trajectory data that occur at rail transit stations from a distributed message queue cluster;

[0008] The ticket transaction trajectory data and the facial image trajectory data are compared in time and space to generate a fused trajectory collision record.

[0009] Based on the collision records of the fusion trajectory, a facial fusion profile is constructed for the user and the ticket.

[0010] Anomaly detection is performed on the fused archive and the fused portrait archive.

[0011] A second aspect of the present invention provides a ticketing anomaly detection device applied to a distributed stream processing cluster, the device comprising:

[0012] The data consumption module is used to consume ticket transaction trajectory data and facial image trajectory data that occur in rail transit stations from a distributed message queue cluster;

[0013] The spatiotemporal collision module is used to perform user-ticket collision on the ticket transaction trajectory data and the facial trajectory data in time and space to generate a fused trajectory collision record.

[0014] The profile building module is used to build a facial fusion profile for the user and the ticket based on the fusion trajectory collision record;

[0015] An anomaly detection module is used to perform anomaly detection on the fused archive and the fused portrait archive.

[0016] A third aspect of the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the ticketing anomaly detection method as described in the first aspect above.

[0017] A fourth aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the ticketing anomaly detection method as described in the first aspect above.

[0018] The fifth aspect of the present invention provides a computer program product that, when run on a computer, causes the computer to perform the ticketing anomaly detection method as described in the first aspect above.

[0019] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0020] This embodiment is applied to a distributed stream processing cluster, consuming ticket transaction trajectory data and facial image trajectory data occurring at rail transit stations from a distributed message queue cluster. It performs user-ticket collision analysis on the ticket transaction trajectory data and facial image trajectory data in both time and space to generate fused trajectory collision records. Based on these records, it constructs facial image fusion profiles for users and tickets. Anomaly detection is then performed on both the fusion profiles and the facial image fusion profiles. This embodiment accumulates stable profiles of users and tickets based on spatiotemporal collision analysis, ensuring the accuracy of ticket auditing. Furthermore, the distributed computing model based on the stream processing framework supports horizontal scalability and high availability, meeting the needs of large-scale applications and effectively improving the efficiency of rail transit ticket auditing. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of a ticketing anomaly detection method provided in an embodiment of the present invention;

[0023] Figure 2 This is a schematic diagram of a layered architecture provided in an embodiment of the present invention;

[0024] Figure 3 This is a schematic diagram of a ticketing anomaly detection device provided in an embodiment of the present invention;

[0025] Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0026] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of the present invention. However, those skilled in the art will recognize that the present application may be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted to avoid unnecessary detail that could obscure the description of the present application.

[0027] The technical solution of the present invention will be illustrated below through specific embodiments.

[0028] Reference Figure 1 The diagram illustrates a ticketing anomaly detection method provided by an embodiment of the present invention, which may specifically include the following steps:

[0029] Step 101: Consume ticket transaction trajectory data and facial image trajectory data that occur at rail transit stations from the distributed message queue cluster.

[0030] On rail transit networks (such as subways and light rail), there are multiple stations that deploy Automated Fare Collection (AFC) systems. These stations are typically divided into paid and unpaid areas, with turnstiles used to separate the paid and unpaid areas. Cameras are built into the turnstiles, or cameras that are independent of the turnstiles are installed in the public areas of the station.

[0031] The paid area refers to the area within the station where passengers pay to ride public transportation, while the unpaid area refers to the area outside the paid area within the station.

[0032] A turnstile is a terminal device used to process transactions for users entering and exiting a station. It has functions such as reading and writing boarding codes, calculating fares, and controlling the opening and closing of gates.

[0033] like Figure 2 As shown, a layered architecture can be constructed for rail transit networks, which includes the following layers:

[0034] 1. Data Access Layer

[0035] The data access layer can use distributed message queue clusters such as Kafka to receive and distribute streaming ticket transaction trajectory data from the AFC system and streaming facial recognition trajectory data from the facial recognition subsystem, supporting a message throughput of hundreds of thousands per second.

[0036] 2. Real-time computing layer

[0037] The real-time computing layer can use distributed stream processing clusters such as Spark to perform real-time computing tasks in a three-level processing model, including data cleaning, format conversion, correlation analysis, and rule matching.

[0038] The method described in this embodiment can be applied to distributed stream processing clusters (such as Spark clusters), especially three-level processing models.

[0039] 3. Business Service Layer

[0040] The business service layer can adopt microservice frameworks such as Spring Cloud to provide services such as rule engine service, file management service, audit analysis service and early warning push service, and support dynamic configuration and horizontal scaling.

[0041] 4. Data storage layer

[0042] In the data storage layer, distributed databases such as HBase can be used to store massive amounts of fusion trajectory collision records, cache databases such as Redis can be used to store hotspot whitelists and abnormal behavior rule configuration data, and relational databases such as MySQL can be used to store fusion archives and audit result data.

[0043] 5. Application Presentation Layer

[0044] The application presentation layer provides a web (web page) management platform and mobile inspection terminal applications, supporting functions such as real-time early warning display, historical query statistics, rule configuration management and report generation.

[0045] During the process of users entering or exiting the station using their tickets, the AFC system can use the turnstiles to process the data collected from the tickets, generate ticket transaction trajectory data for the user, and push the ticket transaction trajectory data to a distributed message queue cluster such as Kafka in a streaming manner. The facial recognition subsystem can use the camera to process the data collected from the user (such as performing facial image classification within the rail transit system), generate facial image trajectory data for the user, and push the facial image trajectory data to a distributed message queue cluster such as Kafka in a streaming manner.

[0046] The term "ticket" can refer to a virtual card, such as a QR code provided in various applications or NFC (Near Field Communication) in a mobile terminal, or a physical card, such as an IC (Integrated Circuit Card). This embodiment does not limit the term.

[0047] "User entry" refers to a user entering the site, which is the act of a user moving from a non-paid area to a paid area. "User exit" refers to a user leaving the site, which is the act of a user moving from a paid area to a non-paid area.

[0048] The ticket transaction data includes timestamps, gate numbers, ticket numbers, and so on.

[0049] The facial tracking data includes timestamps, camera numbers, facial images (within the rail transit system) IDs, and so on.

[0050] Step 102: Perform user and ticket collision analysis on the ticket transaction trajectory data and facial image trajectory data in terms of time and space to generate a fused trajectory collision record.

[0051] like Figure 2 As shown, the first-level processing model in a distributed stream processing cluster (such as a Spark cluster) is a fusion trajectory collision model.

[0052] In the fusion trajectory collision model, ticket transaction trajectory data and facial image trajectory data are collided (i.e., spatiotemporal collision) between users (represented by user IDs based on facial recognition, etc.) and tickets (represented by ticket numbers based on gate recognition, etc.) in both time and space dimensions. The model determines whether the ticket transaction trajectory data and facial image trajectory data match. If a match is successful, the ticket transaction trajectory data and facial image trajectory data (two independent records) representing the event of a user using a ticket to enter or leave a station are merged into a complete fusion trajectory collision record. This establishes the association between the user and the ticket, providing a data foundation for subsequent archiving.

[0053] Generally, ticket inspections are conducted on designated types of tickets, especially those with discounts, such as senior citizen cards and student cards.

[0054] Of course, in addition to conducting ticket audits on specific types of tickets, ticket audits can also be conducted on all tickets as needed for business operations. This embodiment does not impose any restrictions on this.

[0055] During peak hours, a single station on the rail transit system can handle hundreds of transactions per second, and there is a large amount of out-of-order (i.e. late) data, which requires the system to support at least 100,000 messages per second.

[0056] In this case, the Window mechanism and the Watermark mechanism can be combined in distributed stream processing clusters such as Spark.

[0057] Window is a way to aggregate streaming data, while Watermark is a way to handle event time and late data. Combining the two can solve the problems of handling late data and infinite state expansion in window aggregation.

[0058] The event time refers to the time when the data was generated, which is the actual business time and may be out of order or late.

[0059] In the specific implementation, Figure 2 As shown, query the latency threshold configured in a distributed stream processing cluster such as Spark.

[0060] Read the gate where the ticket transaction event occurred and the first timestamp from the ticket transaction trajectory data, where the first timestamp is the event time.

[0061] Configure the window to cover the first timestamp. The window length (Window Duration) is configurable. For example, the window can be formed 2 seconds before or after the first timestamp.

[0062] Read the camera where the user movement event occurred and the second timestamp from the facial trajectory data, where the second timestamp is the event time.

[0063] If the second timestamp is within the window, the ticket transaction trajectory data will be placed within the window, the aggregation state of the window will be updated, but the final result will not be output.

[0064] Subtract the delay threshold from the second timestamp with the largest current value to obtain the water level.

[0065] If the water level exceeds the end time of the window, the positional relationship between the camera (represented by numbers or other data) and the gate (represented by numbers or other data) can be identified within the window based on a pre-set mapping relationship (indicating that they are in the same spatial location area).

[0066] If the location relationship is within the same spatial location area, the ticket transaction trajectory data and the facial trajectory data within the window will be merged into a fused trajectory collision record. The fused trajectory collision record includes complete data such as ticket information, facial information, timestamp, and location information.

[0067] Release the window and the ticket transaction trajectory data within the window.

[0068] In addition, if the distributed stream processing cluster activates the data complementation mechanism, it will compare the second timestamp of the current human trajectory data with the water level.

[0069] If the second timestamp of the current human image trajectory data is less than or equal to the water level, the positional relationship between the camera and the gate corresponding to the current human image trajectory data can be identified based on the pre-set mapping relationship (indicating that they are in the same spatial location area).

[0070] If the location relationship is within the same spatial area, the current ticket transaction trajectory data and facial image trajectory data will be merged into a fused trajectory collision record to ensure data integrity.

[0071] This embodiment provides a multi-source data real-time fusion technology, which uses spatiotemporal window-based streaming data association to achieve accurate matching under high-speed data streams and supports low-latency response.

[0072] like Figure 2 As shown, the fused trajectory collision records are stored in a distributed database (such as HBase) in the data storage layer.

[0073] Step 103: Based on the collision records of the fusion trajectory, construct a portrait fusion profile for the user and the ticket.

[0074] like Figure 2 As shown, the second-level processing model in a distributed stream processing cluster (such as a Spark cluster) is a fusion archive model.

[0075] In the fusion archive model, the details of fusion trajectory collision records within a preset time period (such as one day) can be summarized to build a human image fusion archive for the combination of user (represented by human image) and ticket, and store a long-term, valid and stable "human-ticket" relationship to provide data support for ticket inspection.

[0076] In practice, within a preset time range (e.g., 3 months), the number of collisions between the same user (represented by a human image) and the ticket statistical fusion trajectory collision record is compared with a preset collision threshold (e.g., 4 times).

[0077] If the number of collisions is greater than or equal to the preset collision threshold, it indicates that there is a stable usage relationship between the user (represented by the ID of the human face, etc.) and the ticket. In this case, the collision record of the fusion trajectory will be stored in the fusion file corresponding to the user and the ticket.

[0078] Furthermore, such as Figure 2 As shown, it can be determined whether a fusion file corresponding to a user and a ticket exists in the relational database (such as MySQL) in the data storage layer.

[0079] If so, the collision record of the fusion trajectory will be added to the fusion profile in the relational database.

[0080] If not, create a new fusion profile for the user and ticket in the relational database, and write the fusion trajectory collision record into the new fusion profile in the relational database.

[0081] This embodiment provides an adaptive archive creation mechanism, which adopts an archive creation strategy that combines a sliding time window (i.e., time range) and a frequency threshold, so as to ensure the stability of the archives and adapt to changes in usage patterns.

[0082] Step 104: Perform anomaly detection on the merged archives and the portrait merged archives.

[0083] like Figure 2 As shown, the third-level processing model in a distributed stream processing cluster (such as a Spark cluster) is the ticketing audit model.

[0084] In the ticketing inspection model, anomalies are detected in the merged archives and their facial image merged archives, and ticketing inspection is carried out from the perspectives of individuals and the whole.

[0085] In specific implementations, such as Figure 2 As shown, whitelist and abnormal behavior rule configuration data can be retrieved from the cache database (such as Redis) in the data storage layer.

[0086] The whitelist is a list of users who have been verified as legitimate users of tickets (such as designated types of tickets, especially those with discounts).

[0087] The abnormal behavior rule configuration data consists of parameters for abnormal use of tickets by users (such as tickets of a specified type, especially those with discounts), which can be configured via the rule engine according to the business needs of rail transit.

[0088] The whitelist filter is used to filter the fusion trajectory collision records generated by legitimate users and tickets in the fusion file. That is, if the user and ticket corresponding to the fusion trajectory collision record in the fusion file are in the whitelist, the user and ticket can be determined to be legitimate. The fusion trajectory collision records generated by legitimate users and tickets are filtered out, reducing false alarms.

[0089] If filtering is completed, for the remaining collision records of the fusion trajectory after whitelist filtering in the fusion file, the abnormal behavior rule configuration data is used to perform progressive anomaly detection on the fusion file of the portrait fusion file and the fusion file.

[0090] The so-called progressive anomaly detection refers to performing anomaly detection on the facial images within the merged archive, and then performing anomaly detection on the entire merged archive based on the results of the anomaly detection on the facial images within the merged archive.

[0091] For example, the abnormal behavior rule configuration data includes abnormal time periods, time intervals, and abnormal thresholds set for ticket types, thereby achieving a dual filtering mechanism.

[0092] The abnormal time period is configured as the time period when the user does not conform to the normal usage pattern of the ticket. For example, for the ticket type of senior citizen card, the abnormal time period is the peak period, and for the ticket type of student card, the abnormal time period is the working period.

[0093] The first layer of the dual filtering mechanism is time anomaly detection. In the first layer of the filtering mechanism, the third timestamp is read from the portrait fusion file in the fusion file and compared with the abnormal time period.

[0094] If the third timestamp is within an abnormal time period, it is determined that there is an anomaly in the fusion trajectory collision record.

[0095] The second layer of the dual filtering mechanism is frequency anomaly detection. In the second layer of the filtering mechanism, the number of abnormal fusion trajectory collision records in the fusion archive is counted in the most recent time interval (such as 30 days), and this number is compared with the anomaly threshold (such as 12 times).

[0096] If the number is greater than or equal to the abnormal threshold, then the merged archive is determined to be abnormal.

[0097] This embodiment provides configurable rule management, supporting different audit strategies for different ticket types without requiring modification of the program code.

[0098] Furthermore, such as Figure 2 As shown, collision records of abnormal fusion trajectories are written into the abnormal fusion trajectory table, and summary information of abnormal fusion files is written into the suspected fraudulent ticket fusion file information table. Together, they form a complete chain of evidence for manual review and processing.

[0099] The collision records of abnormal fusion trajectories (i.e., abnormal fusion trajectory tables) and the abnormal fusion archives (i.e., suspected fraudulent ticket fusion archive information tables) are stored in a relational database (such as MySQL).

[0100] For abnormal fusion trajectory collision records (i.e., abnormal fusion trajectory tables) and abnormal fusion files (i.e., suspected fraudulent ticket fusion file information tables), abnormal events are generated. The abnormal events are sent to the microservices in the business service layer (such as Spring Cloud) for various corresponding business processing to obtain business results. The business results are then pushed to the specified devices in the application presentation layer for display via API (Application Programming Interface) or messages.

[0101] This embodiment is applied to a distributed stream processing cluster, consuming ticket transaction trajectory data and facial image trajectory data occurring at rail transit stations from a distributed message queue cluster. It performs user-ticket collision analysis on the ticket transaction trajectory data and facial image trajectory data in both time and space to generate fused trajectory collision records. Based on these records, it constructs facial image fusion profiles for users and tickets. Anomaly detection is then performed on both the fusion profiles and the facial image fusion profiles. This embodiment accumulates stable profiles of users and tickets based on spatiotemporal collision analysis, ensuring the accuracy of ticket auditing. Furthermore, the distributed computing model based on the stream processing framework supports horizontal scalability and high availability, meeting the needs of large-scale applications and effectively improving the efficiency of rail transit ticket auditing.

[0102] It should be noted that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0103] Reference Figure 3 The diagram illustrates a ticketing anomaly detection device according to an embodiment of the present invention, applied to a distributed stream processing cluster. The device may specifically include the following modules:

[0104] The data consumption module 301 is used to consume ticket transaction trajectory data and facial image trajectory data that occur in rail transit stations from a distributed message queue cluster;

[0105] The spatiotemporal collision module 302 is used to perform user-ticket collision on the ticket transaction trajectory data and the human image trajectory data in time and space to generate a fused trajectory collision record.

[0106] The profile construction module 303 is used to construct a facial fusion profile for the user and the ticket based on the fusion trajectory collision record;

[0107] Anomaly detection module 304 is used to perform anomaly detection on the fused archive and the portrait fused archive.

[0108] In one embodiment of the present invention, the spacetime collision module 302 includes:

[0109] The delay threshold query module is used to query the delay threshold configured in the distributed stream processing cluster.

[0110] The ticket transaction trajectory data reading module is used to read the gate where the ticket transaction event occurred and the first timestamp from the ticket transaction trajectory data;

[0111] A window configuration module is used to configure a window that covers the first timestamp;

[0112] The human image trajectory data reading module is used to read the camera and second timestamp of the user movement event from the human image trajectory data;

[0113] A window aggregation module is used to place the ticket transaction trajectory data within the window if the second timestamp is located within the window.

[0114] The water level generation module is used to subtract the delay threshold from the second timestamp with the largest current value to obtain the water level.

[0115] The first positional relationship recognition module is used to identify the positional relationship between the camera and the gate within the window if the water level line exceeds the end time of the window.

[0116] The first record fusion module is used to fuse the ticket transaction trajectory data and the human image trajectory data in the window into a fused trajectory collision record if the positional relationship is in the same spatial location area.

[0117] The window release module is used to release the window and the ticket transaction trajectory data within the window.

[0118] In one embodiment of the present invention, the spacetime collision module 302 further includes:

[0119] The timestamp comparison module is used to compare the second timestamp of the current human trajectory data with the water level line if the distributed stream processing cluster starts the data complementation mechanism.

[0120] The second positional relationship recognition module is used to identify the positional relationship between the camera and the gate corresponding to the current facial trajectory data if the second timestamp of the current facial trajectory data is less than or equal to the water level line.

[0121] The second record fusion module is used to fuse the current ticket transaction trajectory data and the facial trajectory data into a fused trajectory collision record if the positional relationship is in the same spatial location area.

[0122] In one embodiment of the present invention, the file construction module 303 includes:

[0123] The collision count module is used to count the number of collisions between the same user and the ticket within a preset time range, based on the collision records of the fused trajectory.

[0124] The fusion archive storage module is used to store the fusion trajectory collision record in the fusion archive corresponding to the user and the ticket if the number of collisions is greater than or equal to a preset collision threshold.

[0125] In one embodiment of the present invention, the fused archive storage module includes:

[0126] The merged file determination module is used to determine whether a merged file corresponding to the user and the ticket exists in the relational database; if yes, the incremental storage module is called; otherwise, the new storage module is called.

[0127] An incremental storage module is used to add the fusion trajectory collision records to the fusion archive in the relational database;

[0128] A new storage module is added to create a new fusion profile for the user and the ticket in the relational database, and to write the fusion trajectory collision record into the new fusion profile in the relational database.

[0129] In one embodiment of the present invention, the anomaly detection module 304 includes:

[0130] The cache data retrieval module is used to retrieve whitelist and abnormal behavior rule configuration data from the cache database;

[0131] The whitelist filtering module is used to filter collision records of the fusion trajectory generated by the legitimate user and the ticket in the fusion file using the whitelist; if the filtering is completed, the configuration rule detection module is called.

[0132] A configuration rule detection module is used to perform progressive anomaly detection on the portrait fusion file and the fusion file in the fusion file using the abnormal behavior rule configuration data.

[0133] In one embodiment of the present invention, the abnormal behavior rule configuration data includes an abnormal time period, a time interval, and an abnormal threshold, and the configuration rule detection module includes:

[0134] Read the third timestamp from the fused portrait archive in the fused archive;

[0135] The anomaly determination module is used to determine that the fusion trajectory collision record is abnormal if the third timestamp is within the abnormal time period.

[0136] The data statistics module is used to count the number of abnormal fusion trajectory collision records in the fusion archive within the most recent time interval;

[0137] The file anomaly determination module is used to determine that the fused file is abnormal if the number is greater than or equal to the anomaly threshold.

[0138] In one embodiment of the present invention, it further includes:

[0139] A recording and storage module is used to store the fused trajectory collision records in a distributed database;

[0140] An anomaly storage module is used to store the collision records of the fusion trajectory that are abnormal and the fusion files that are abnormal into a relational database;

[0141] An abnormal event generation module is used to generate abnormal events for the collision records of the fusion trajectory that have abnormalities and the fusion archive that have abnormalities.

[0142] The business processing module is used to send the abnormal event to the microservice for business processing and obtain the business result;

[0143] The business results push module is used to push the business results to designated devices for display.

[0144] The present invention provides a ticketing anomaly detection device, which can be used to implement the steps in the aforementioned ticketing anomaly detection method embodiments.

[0145] It should be noted that the module division in the various ticketing anomaly detection devices provided in the above embodiments is illustrative and only represents one logical functional division. In actual implementation, other division methods are also possible. Furthermore, the functional modules in the various embodiments of this invention can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0146] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of the embodiments of the present invention can be embodied in the form of a computer program product, which is stored in a computer storage medium and includes several instructions to cause an electronic device or processor to execute all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned computer storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0147] Furthermore, the ticketing anomaly detection device and the ticketing anomaly detection method provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0148] Reference Figure 4 The diagram illustrates an electronic device according to an embodiment of the present invention. Figure 4 As shown, the electronic device in this embodiment of the invention includes: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the above-described ticketing anomaly detection method embodiment. Alternatively, when the processor executes the computer program, it implements the functions of each module in the above-described ticketing anomaly detection device embodiment.

[0149] For example, the computer program may be divided into one or more modules, which are stored in the memory and executed by the processor to complete this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which can be used to describe the execution process of the computer program in the electronic device.

[0150] The electronic device may be a desktop computer, a cloud server, or other computing device. The electronic device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 4 This is merely one example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than illustrated, or combine certain components, or different components. For example, the electronic device may also include input / output devices, network access devices, buses, etc.

[0151] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0152] The memory can be an internal storage unit of the electronic device, such as a hard drive or RAM. Alternatively, it can be an external storage device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc. Furthermore, the memory can include both internal and external storage units. The memory is used to store the computer program and other programs and data required by the electronic device. The memory can also be used to temporarily store data that has been output or will be output.

[0153] This invention also discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the ticketing anomaly detection method as described in the foregoing embodiments.

[0154] This invention also discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the ticketing anomaly detection method as described in the foregoing embodiments.

[0155] This invention also discloses a computer program product that, when run on a computer, causes the computer to execute the ticketing anomaly detection method described in the foregoing embodiments.

[0156] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A ticket abnormality detection method characterized by comprising: The method is applied to a distributed stream processing cluster, and comprises: Consuming ticket card transaction track data and portrait track data occurring in a rail transit station from a distributed message queue cluster; Colliding the ticket card transaction track data and the portrait track data in time and space to generate a fusion track collision record; Constructing a portrait fusion profile for a user and a ticket card according to the fusion track collision record; Performing anomaly detection on the fusion profile and the portrait fusion profile.

2. The method of claim 1, wherein, The colliding the ticket card transaction track data and the portrait track data in time and space to generate a fusion track collision record comprises: Querying a delay threshold configured in the distributed stream processing cluster; Reading a gate and a first timestamp of a ticket card transaction event from the ticket card transaction track data; Configuring a window covering the first timestamp; Reading a camera and a second timestamp of a user movement event from the portrait track data; If the second timestamp is located in the window, placing the ticket card transaction track data in the window; Subtracting the delay threshold from the second timestamp with the largest current value to obtain a water line; If the water line exceeds an end time of the window, identifying a positional relationship between the camera and the gate in the window; If the positional relationship is in a same spatial position region, fusing the ticket card transaction track data and the portrait track data in the window into a fusion track collision record; Releasing the window and the ticket card transaction track data in the window.

3. The method of claim 2, wherein, The colliding the ticket card transaction track data and the portrait track data in time and space to generate a fusion track collision record further comprises: If the distributed stream processing cluster starts a complement mechanism, comparing the second timestamp of the current portrait track data with the water line; If the second timestamp of the current portrait track data is less than or equal to the water line, identifying a positional relationship between the camera corresponding to the current portrait track data and the gate; If the positional relationship is in a same spatial position region, fusing the current ticket card transaction track data and the portrait track data into a fusion track collision record.

4. The method of claim 1, wherein, The constructing a portrait fusion profile for a user and a ticket card according to the fusion track collision record comprises: In a preset time range, counting a collision number of the fusion track collision record for a same user and a same ticket card; If the collision number is greater than or equal to a preset collision threshold, storing the fusion track collision record into a fusion profile corresponding to the user and the ticket card.

5. The method of claim 4, wherein, The storing the fusion track collision record into a fusion profile corresponding to the user and the ticket card comprises: Judging whether the fusion profile corresponding to the user and the ticket card exists in a relational database; If yes, adding the fusion track collision record to the fusion profile in the relational database; If not, a new fusion profile is created for the user and the ticket card in the relational database, and the fusion track collision record is written into the new fusion profile in the relational database.

6. The method of claim 1, wherein, The anomaly detection on the fusion profile and the portrait fusion profile includes: Pulling white list and abnormal behavior rule configuration data from a cache database; Filtering the fusion track collision record generated by the user and the ticket card in the fusion profile using the white list; If the filtering is completed, performing progressive anomaly detection on the portrait fusion profile and the fusion profile in the fusion profile using the abnormal behavior rule configuration data.

7. The method of claim 6, wherein, The abnormal behavior rule configuration data includes an abnormal time period, a time interval, and an abnormal threshold, and the progressive anomaly detection on the portrait fusion profile and the fusion profile in the fusion profile using the abnormal behavior rule configuration data includes: Reading a third timestamp from the portrait fusion profile in the fusion profile; If the third timestamp is within the abnormal time period, determining that the fusion track collision record is abnormal; Counting the number of fusion track collision records that are abnormal in the fusion profile in the latest time interval; If the number is greater than or equal to the abnormal threshold, determining that the fusion profile is abnormal.

8. The method according to any one of claims 1 to 7, characterized in that, Further including: Storing the fusion track collision record into a distributed database; Storing the fusion track collision record that is abnormal and the fusion profile that is abnormal into a relational database; Generating an abnormal event for the fusion track collision record that is abnormal and the fusion profile that is abnormal; Sending the abnormal event to a microservice for business processing to obtain a business result; Pushing the business result to a designated device for display.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the ticket anomaly detection method in any one of claims 1-8.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program is executed by the processor to implement the ticket anomaly detection method in any one of claims 1-8.

Images