User service category detection method, device, and computer equipment based on Flink

Abstract

The present application belongs to the field of data processing, and discloses a method, device, computer equipment and readable storage medium for detecting user service categories based on flink. The method includes obtaining the user behavior of the user by means of page embedding, establishing a user behavior set for the user, and judging whether the collected current user behavior meets the event triggering condition of the event filtering text. If so, all user behaviors in the user behavior set are matched with the events in the event filtering text to obtain a matching result. And a service type label is generated for the user according to the type of matching result. This method solves the technical problem that the judgment condition of classification in the prior art is too single and cannot meet the judgment of complex user behavior data, resulting in low accuracy of user classification. This case also involves blockchain technology, and the user behavior set can be stored in a blockchain node.

Description

Technical Field

[0001] The present application relates to the field of data processing, and in particular to a method, apparatus, computer device and storage medium for detecting user service categories based on Flink. Background Art

[0002] The detection of user behavior in traditional technology is usually carried out through templates. Generally, the user behavior data is matched with the abnormal template. If it matches, it means that the user corresponding to the user behavior data may be abnormal. For example, the existing technology for processing user behavior data usually obtains user behavior data, wherein the user behavior data includes event type information corresponding to the user behavior data, and determines the data matching strategy corresponding to the event type information in the user behavior data according to the correspondence between the pre-stored time type and the data matching strategy. Finally, the user behavior data is matched according to the data matching strategy to obtain the matching result. Although this method can solve the purpose of classifying users, the judgment condition of the classification is too simple and cannot meet the judgment of complex user behavior data, resulting in a technical problem of low accuracy in user classification. Summary of the invention

[0003] Based on this, it is necessary to address the above technical problems. This application provides a flink-based user service category detection method, device, computer equipment and storage medium to solve the problem that the prior art cannot accurately extract features, resulting in inaccurate user classification.

[0004] A user service category detection method based on Flink, the method comprising:

[0005] Establish a flink broadcast stream, and read the event screening text from the preset database regularly through the broadcast stream, and parse it into a json file, wherein the event screening text includes event trigger conditions and behavior events;

[0006] Write the user behaviors collected in real time through page embedding into Kafka, and generate a user behavior set for each user based on the user behaviors;

[0007] Compare the user's current user behavior with the event triggering condition to obtain a comparison result;

[0008] If the comparison result is that the current user behavior meets the event triggering condition, all user behaviors in the user behavior set of the user are matched with the behavior events in the event screening text to obtain a matching result;

[0009] If the matching result is that there is a user behavior in the user behavior set that satisfies the event screening text, a service type label is generated for the user according to the event screening text.

[0010] A user service category detection device based on Flink, the device comprising:

[0011] The text reading module is used to establish a flink broadcast stream, and to periodically read the event screening text from the preset database through the broadcast stream, and parse it into a json file, wherein the event screening text includes event triggering conditions and behavior events;

[0012] The behavior set building module is used to write the user behaviors collected in real time through page embedding into Kafka, and generate a user behavior set for each user based on the user behaviors;

[0013] A behavior comparison module is used to compare the user's current user behavior with the event triggering condition to obtain a comparison result;

[0014] A behavior matching module, for matching all user behaviors in the user behavior set of the user with the behavior events in the event screening text to obtain a matching result if the comparison result shows that the current user behavior meets the event triggering condition;

[0015] The label generation module is used to generate a service type label for the user according to the event screening text if the matching result is that there is a user behavior in the user behavior set that meets the event screening text.

[0016] A computer device comprises a memory and a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned Flink-based user service category detection method when executing the computer program.

[0017] A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned Flink-based user service category detection method are implemented.

[0018] The above-mentioned flink-based user service category detection method, device, computer equipment and storage medium establish a user behavior set for the user, and determine whether the collected current user behavior meets the event triggering condition of the event filtering text. If it does, all user behaviors in the user behavior set are matched with the events in the event filtering text to obtain a matching result. And a service type label is generated for the user according to the type of the matching result. This solves the technical problem that the classification judgment condition in the prior art is too single and cannot meet the judgment of complex user behavior data, resulting in low accuracy of user classification. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0020] Figure 1 This is a schematic diagram of the application environment of the user service category detection method based on Flink;

[0021] Figure 2 This is a flowchart of the user service category detection method based on Flink;

[0022] Figure 3 for Figure 2 Schematic diagram of the process of step 204;

[0023] Figure 4 Schematic diagram of a flow chart of a method for detecting user service categories based on Flink in another embodiment;

[0024] Figure 5 It is a schematic diagram of a user service category detection device based on Flink;

[0025] Figure 6 FIG. 1 is a schematic diagram of a computer device in one embodiment. DETAILED DESCRIPTION

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by technicians in the technical field of the present application; the terms used in the specification of the application herein are only for the purpose of describing specific embodiments and are not intended to limit the present application; the terms "including" and "having" and any variations thereof in the specification and claims of the present application and the above-mentioned drawings are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of the present application or the above-mentioned drawings are used to distinguish different objects, not to describe a specific order.

[0027] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0028] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0029] The flink-based user service category detection method provided in the embodiment of the present invention can be applied to Figure 1 In the application environment shown, the application environment may include a terminal 102, a network and a server 104, the network is used to provide a communication link medium between the terminal 102 and the server 104, and the network may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0030] The user can use the terminal 102 to interact with the server 104 through the network to receive or send messages, etc. Various communication client applications can be installed on the terminal 102, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0031] Terminal 102 can be various electronic devices with a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III, Moving Picture Experts Group Audio Layer 3), MP4 (Moving Picture Experts Group Audio Layer IV, Moving Picture Experts Group Audio Layer 4) players, laptop computers and desktop computers, etc.

[0032] The server 104 may be a server that provides various services, such as a background server that provides support for web pages displayed on the terminal 102 .

[0033] It should be noted that the flink-based user service category detection method provided in the embodiment of the present application is generally executed by the server / terminal, and accordingly, the flink-based user service category detection device is generally set in the server / terminal device.

[0034] It should be understood that Figure 1 The number of terminals, networks and servers in the embodiment is only for illustration. Any number of terminals, networks and servers may be provided according to the implementation requirements.

[0035] Among them, the terminal 102 communicates with the server 104 through the network. The event filtering text written by the developer or setter through the terminal 102 will be sent to TiDB after the terminal 102 receives it, and it will be parsed into a json format document in TiDB for reading, addition, deletion, modification and query operations. The server 104 obtains the event filtering text input through the terminal 102 from TiDB, compares it with the collected user behavior, and generates a service type label for the user based on the comparison result. Among them, the terminal 102 and the server 104 are connected through a network, which can be a wired network or a wireless network. The terminal 102 can be but is not limited to various personal computers, laptops, smart phones, tablets and portable wearable devices. The server 104 can be implemented with an independent server or a server cluster composed of multiple servers.

[0036] In one embodiment, Figure 2 As shown in the figure, a user service category detection method based on Flink is provided, which is applied to Figure 1 The server in the example is used as an example to illustrate, including the following steps:

[0037] Step 202: establish a flink broadcast stream, and periodically read event filter text from a preset database through the broadcast stream, and parse it into a json file, wherein the event filter text includes event trigger conditions and behavior events.

[0038] Since Flink is a distributed computing engine, when distributed computing nodes need a small data set together, a broadcast stream is usually used, that is, another process periodically reads the data source defined by the broadcast stream, and sends it to each distributed computing node through a broadcast connection. In this proposal, since we need to determine whether the user's behavior meets the event triggering conditions every time the user completes an event (user behavior), we need to read the event triggering conditions from the broadcast each time the user behavior is processed, so as to determine whether the user behavior meets the event triggering conditions in the event filtering text. The specific process is: start a Flink broadcast stream, specify the data source to be broadcast in the broadcast stream, and store it in the event database after reading, so as to provide subsequent condition judgment and acquisition.

[0039] For example, the event filter text parsed into a JSON document can be:

[0040] The PACX_H00018745 event occurs within one hour after the HCZ_H00010802 event occurs to the user:

[0041] [{"eventType":2, event type of event triggering condition;

[0042] "timeWindow":"1h", interval time;

[0043] "eventName":"PACX_H00018745", the event name of the event trigger condition;

[0044] "sequence":[{"eventName":"HCZ_H00010802"}, execute HCZ_H00010802 and then execute PACX_H00018745;{"eventName":"PACX_H00018745"}]}]

[0045] The event filter text is the user filter information written by the developer or setter through the terminal, and the terminal can be a client. For example, it is the background management software of a property insurance or insurance company. After receiving the event filter text, the client will send it to TiDB and parse it into a json format document in TiDB for subsequent reading, addition, deletion, modification and query operations. The event filter text includes event trigger conditions and behavior events, among which the event trigger condition is also a type of behavior event. For example, the PACX_H00018745 event occurs within one hour after the user has the HCZ_H000108002 event. Then the behavior event with the ID PACX_H00018745 can be used as the event trigger condition. Among them, HCZ_H and PACX_H represent the user's actions in different modules, 00010 and 00018 represent the user's actions on different pages or links of the corresponding module, 8 or 7 represent operations such as clicking, sliding or jumping on a certain element, and 02 or 45 can represent the length of time between the last user behavior. Of course, the specific event trigger condition ID can be determined according to the specific scenario and is not limited to one. Furthermore, the event triggering condition is generally located at the last position of the behavior event in the event screening text.

[0046] Step 204, write the user behavior collected in real time through page embedding into Kafka, and generate a user behavior set for each user based on the user behavior.

[0047] Page tracking is a common data collection method for website analysis. It mainly collects user behavior data, such as page access paths, click modules, etc. Existing page tracking is generally divided into three types: manual tracking, visual tracking, and no tracking. Among them, manual tracking is to manually track in the code. It is more common. The business party that needs to call the tracking method calls the tracking method where the data needs to be collected. The advantage is that the traffic is controllable, and the business party can collect data at any location and in any scenario as needed, and the collected information is also completely controlled by the business party.

[0048] No tracking means that the front end automatically collects all events, reports tracking data, and the back end filters and calculates useful data. The advantage is that the front end only needs to load the tracking script. Usually it refers to the user connecting to the data access management interface of the user behavior analysis tool through the device, and directly operating the interactive and effective page elements (such as pictures, buttons, links, etc.) on the interface to implement data tracking, and send the tracking method of the number of effective times of the collection code. This method is what you see is what you get, skipping the code deployment, test verification and release process, greatly improving productivity.

[0049] Because this embodiment filters text based on set events, a manual point-burying method can be used to obtain the user behavior data required, thereby reducing the amount of data transmission and improving computing efficiency.

[0050] User behavior refers to the user's operation behavior on the client or the corresponding page, such as the time spent on a certain page of the website, the action of clicking on an element, the operation of searching for a keyword, etc. A user behavior may include the action of clicking on an element, the time the user stays on an element, the length of time between the previous user behavior and the time information when a certain element is clicked, etc. This information can be used to determine whether the user meets the criteria for event filtering text. These user behaviors obtained through page embedding are generally automatically saved in log files and written to Kafka for synchronization to form a user data stream, so as to facilitate the subsequent processing and analysis of user behavior data.

[0051] Kafka is a widely used message queue and a storage engine of the producer & consumer model. Our APP usually collects user behavior events on the APP and sends them to Kafka storage one by one. This is the producer. In this scenario, our FLINK acts as a consumer and reads the user data stored in Kafka in order.

[0052] The user data stream stores the user behaviors of different users. The user data stream can be classified according to user categories, and the user behaviors corresponding to the same user can be integrated as the user behavior set of the user to facilitate processing and analysis. The user behaviors in the user behavior set are sorted according to the user's operation time.

[0053] The user behavior set includes several user behaviors, and different user behaviors correspond to different behavior IDs. The trigger IDs of event filter texts with the same event trigger conditions can be the same, and the behavior IDs of the same user behavior of different users are set to be the same. Users reduce the number of event ID types in the event filter text, reduce the amount of data processing, and the amount of data comparison.

[0054] Step 206: compare the user's current user behavior with the event triggering condition to obtain a comparison result.

[0055] When matching user behavior with event trigger conditions, you only need to compare the ID of the collected user behavior with the ID of the event trigger condition. If the user's current user behavior is the same as the ID of the event trigger condition, the comparison result is obtained that the user meets the event trigger condition. If the ID is different, the comparison result is obtained that the user's user behavior does not meet the event trigger condition, and the user behavior of the user will continue to be detected until the user stops the user behavior. For users who do not meet any event filter text, a no valid operation label can be generated for them, and the detection of the behavior of such users will be reduced in the next data detection, reducing the amount of data processing.

[0056] Step 208: If the comparison result shows that the current user behavior meets the event triggering condition, all user behaviors in the user behavior set of the user are matched with the behavior events in the event screening text to obtain a matching result.

[0057] When the behavior ID of the obtained user behavior is compared with the event ID of the behavior event, the user behavior corresponding to the behavior ID that is the same as the event ID of the behavior event and in the same order is searched for matching.

[0058] If the comparison result shows that the current user behavior meets the event triggering condition, it is necessary to match and judge all user behaviors in the user behavior set to see whether the user behavior before the current user behavior meets other behavior events in the event filtering text. For example, if the current user behavior is the PACX_H00018745 event, then whether there is an event HCZ_H000108002 within one hour before the PACX_H00018745 event.

[0059] If the HCZ_H000108002 event occurs one hour before the current user behavior PACX_H00018745 event, then even if the user behavior HCZ_H000108002 event exists in the user behavior set, the user does not meet the event filter text.

[0060] If there is no match, it means that the user does not meet the event filter text, and the service type label will not be generated for him.

[0061] For example, if the current user behavior is the PACX_H00018745 event, but the user has no HCZ_H000108002 event within an hour before the PACX_H00018745 event, it means that the user does not meet the event filter text.

[0062] Optionally, if the current user behavior cannot be compared in time due to network delay, congestion, etc., it is possible to directly scan the user behavior set to determine whether there is user behavior that meets the event triggering condition.

[0063] The same user can meet multiple event filter texts, and different event filter texts do not interfere with each other. For example, the behavior ID of a user's user behavior is 03, and the event ID that meets the event trigger condition is 03. The user's user behavior 01 meets the behavior event 01, and the behavior event 01 / 02 / 03 constitutes an event filter text a, which means that the user meets the event filter text a; if the user's series of user behaviors are: 01 / 02 / 03 / 04, but at the same time the user can also meet the event filter text b (01 / 03 / 04, the order of the time ID of the behavior event in the event filter text), among which, the behavior event corresponding to the event ID 04 is the event trigger condition of the event filter text b.

[0064] That is, as long as the user's operation does not stop and the obtained user behavior is still increasing, the comparison will be continuously performed in order to obtain more event screening texts that the user meets. Furthermore, the number of event screening texts that the same user meets can be superimposed as a degree to judge whether the user is a certain type. For example, the more event screening texts a user has superimposed, the more cards and coupons of the same type will be obtained.

[0065] Specifically, in the application of a wishing tree in a certain APP, we use the event filtering text located by the user as a conditional stream, and the actual APP time generated by the user, that is, the user behavior, is the behavior stream. How do we judge whether the user's behavior stream meets the conditions? We need to connect these two streams. Whenever we read the data of the conditional stream, we store the event trigger condition in a flink mapstate structure (mapstate is a global data storage container that can be mapped in the stream and passed to another stream). Then the behavior stream reads the mapstate to obtain the user-defined conditions. At the same time, the user behavior can be read in this stream to compare the user behavior with the behavior events in the event filtering text. Combined with the event trigger conditions in the mapstate, it is judged whether the user behavior meets the event trigger conditions. The event trigger conditions are then used for matching and judgment, which reduces the data during comparison and improves efficiency.

[0066] Step 210: If the matching result is that there is a user behavior in the user behavior set that satisfies the event screening text, a service type tag is generated for the user according to the event screening text.

[0067] The event filter texts that a user behavior satisfies can be zero or multiple. A service type label can be generated for the user based on the event filter texts that the user satisfies. Specifically, the Flink connect operator can be used to implement the connection between user behavior and event filter texts. The Flink connect operator is a connection operation provided by Flink for two streams, namely, datastream objects. It is mainly used to merge two or more data sets of different data types. After the merger, the data type of the original data set will be retained. Among them, datastream is the API for Flink to write stream processing jobs. It is a JAVA object. When processing stream data, the stream is abstracted as this object. It contains a series of operation methods, such as map, filter, etc. When the user needs to merge two stream data, such as the broadcast stream composed of the above event filter text and the behavior stream including user behavior, the content of the connection can be customized by rewriting its processfunction method through the Flink Connect operator.

[0068] Specifically, for example, in the Wishing Tree activity, we rewrote the process function, which mainly consists of 4 parts:

[0069] (1) Define a hash table to store user behavior, namely mapstate;

[0070] (2) Override processBroadcastElement to process the values ​​returned in the broadcast stream, that is, all conditions;

[0071] (3) Override processElement, which is also the most complex and is used to process user events;

[0072] (4) And determine whether the implementation part of the event screening text is satisfied.

[0073] The logical steps are: insert the user behavior into the event list of the user in the hash table, get the set of all user behaviors of the current user, and determine whether the event triggering condition is triggered. If not, end the calculation and enter the next data. If triggered, judge the user's behavior list and time filter text. If the user meets a certain event filter text, for example, output the integral value agreed upon by the event filter text and the user name to the downstream. If not, judge the next event filter text until all event filter texts are polled.

[0074] For example, in a certain APP wishing tree activity, the main content of its event triggering conditions is: users can receive corresponding points after completing certain fixed tasks, thereby achieving the application effect of increasing user interest. If the user clicks "Go to complete the task - check violations" and the user behavior of checking violations occurs within an hour, it means that the user meets the corresponding event filtering text. Then, a tag for receiving corresponding points can be generated for the user based on the event filtering text. Users with this service type tag can receive a number of points, which can be exchanged for some services.

[0075] This method serves as the backend data support for the Wishing Tree activity. By monitoring the user's embedded data, it can determine in real time whether the user's behavior meets the requirements for issuing points.

[0076] Furthermore, after generating a service type label for the user according to the event screening text, it also includes:

[0077] A service type is generated for the user according to the service type tag, wherein the service type is used to instruct the user to update the service type tag.

[0078] Specifically, three types of conditions can be configured, because the event screening text is diverse, for example, there are three types: (1) the user has a fixed event XX times within XX time, (2) the user has a certain event (3) the user has event B within X time after event A. For users who meet the corresponding event screening text, a specified service type tag is generated, and finally the specified service type, such as physical card, service, reminder, etc., is sent according to the service type tag. These service types are used to instruct users to perform corresponding operations, such as consuming card, completing service, and executing reminder operations, thereby updating their own service type tags. Every time a user completes a service, it means that the user has lost a corresponding service type tag. For example, when the user obtains a service type of card, if the card is used, the corresponding service type tag of the user can be subtracted. When the user has only one service type tag corresponding to a card and it has been subtracted, it is necessary to re-judge whether the user belongs to the service type tag before regenerating the service type for the user. In this way, the purpose of accurate detection of user categories is achieved.

[0079] In the above-mentioned flink-based user service category detection method, a user behavior set is established for the user, and it is determined whether the collected current user behavior meets the event triggering condition of the event filtering text. If it meets the condition, all user behaviors in the user behavior set are matched with the events in the event filtering text to obtain a matching result. A service type label is generated for the user according to the type of the matching result. This solves the technical problem that the classification judgment condition in the prior art is too simple and cannot meet the judgment of complex user behavior data, resulting in low accuracy in user classification.

[0080] In one embodiment, step 204 includes: obtaining the user's click and / or slide action of the page element and the duration of stay on the page element, and generating user behavior according to the action, duration of stay and the number of the page element and writing it into Kafka.

[0081] Specifically, the user may click to obtain the "check violation" operation. When detecting the specific operation of the user, it is also necessary to obtain the duration between the action and the previous action as the dwell duration.

[0082] If there is an action of "collecting 1 point" between the user's actions of clicking "go complete the task" and "check violations", and the interval between the action of "collecting 1 point" and the action of "check violations" is 10 seconds, and the interval between the action of clicking "go complete the task" and the action of "check violations" is 5 seconds, then it can be confirmed that the interval between the actions of "go complete the task" and "check violations" is 15 seconds, and the stay time is 15 seconds.

[0083] This embodiment will accurately obtain the user's actions, action duration, and the duration between the two actions through the method of embedding points and write them into Kafka. Kafka has the advantages of high throughput and low latency. It can process hundreds of thousands of messages per second, with the lowest latency of only a few milliseconds. It can quickly process the embedded point data, achieve the purpose of quickly classifying users, and improve the efficiency of data processing.

[0084] In one embodiment, Figure 3 As shown, step 204 also includes:

[0085] Step 302, set a unique user ID for each user.

[0086] Step 304: construct a data table with the user ID as the key value.

[0087] Step 306: collect user behaviors according to the user ID, and write the user behaviors into a data table as a user behavior set.

[0088] Step 308: regularly delete user behaviors before a preset time from the data table to update the user behavior set.

[0089] Specifically, a mapstate data structure is defined, which is a global hash table. When a user behavior data is read, this behavior data is added to the value with the user id as the key (the value is a container of a list structure). This data table stores multiple user ids and the user behavior data corresponding to the user ids. The expired user behavior data (data older than 3 hours) is periodically judged and removed to reduce the data storage capacity on the server. Therefore, we can obtain all operation records of all users in the past 3 hours from this hash table as a user behavior set.

[0090] This embodiment reduces the data storage volume on the server side, improves data storage efficiency, and increases the data volume for data comparison and the comparison speed by periodically determining expired user behavior data (data older than 3 hours) and removing it.

[0091] In one embodiment, Figure 4 As shown, before step 206, it also includes:

[0092] Step 402, detecting whether the event screening text includes an offline tag;

[0093] Step 404: if the offline tag is included, the user's offline tag is obtained, and the user's offline tag is compared with the offline tag to filter the user to obtain the filtered user.

[0094] Specifically, the offline tag is a conditional tag that limits the user in the event triggering condition, such as limiting the user's age to between 20 and 30 years old, and the gender to male. If the detection result includes any of the above offline tags, the user needs to be screened according to the offline tag. In addition to the behavior flow, each user also corresponds to the user's offline data. The user's offline data includes the user's offline tag, which is mapped with the user and generally stored in the offline database. If the server detects that there is an offline tag in the event screening text, it will obtain the user's offline tag from the offline database to determine whether the user meets the requirements of the offline tag. For example, the user's inherent attributes such as gender, age, native place, and occupation; if the offline tag limits the user's gender to male, then as long as the user's offline tag in the user's offline data is integrated to screen the user, the behavior of the user with male gender is obtained to determine whether it meets the event triggering condition. Through this embodiment, the accuracy of user screening is improved, the number of behavioral data comparisons is reduced, and the comparison efficiency is improved.

[0095] It should be understood that although Figure 2-Figure 4The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 2-Figure 4 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages do not necessarily have to be executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages does not have to be sequentially, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0096] In one embodiment, Figure 5 As shown, a user service category detection device based on Flink is provided, and the user service category detection device based on Flink corresponds to the user service category detection method based on Flink in the above embodiment. The user service category detection device based on Flink includes:

[0097] The text reading module 502 is used to establish a flink broadcast stream, and read the event screening text from the preset database regularly through the broadcast stream, and parse it into a json file, wherein the event screening text includes event triggering conditions and behavior events;

[0098] The behavior set building module 504 is used to write the user behaviors collected in real time through page embedding into Kafka, and generate a user behavior set for each user based on the user behaviors;

[0099] The behavior comparison module 506 is used to compare the current user behavior of the user with the event triggering condition to obtain a comparison result;

[0100] The behavior matching module 508 is used to match all user behaviors in the user behavior set with the behavior events in the event screening text to obtain a matching result if the comparison result shows that the current user behavior meets the event triggering condition;

[0101] The label generation module 510 is used to generate a service type label for the user according to the event screening text if the matching result is that there is a user behavior in the user behavior set that meets the event screening text.

[0102] Furthermore, the behavior set construction module 504 includes:

[0103] The ID generation submodule is used to set a unique user ID for each user;

[0104] The data construction submodule is used to construct a data table with user ID as the key value;

[0105] The behavior collection submodule is used to collect user behaviors according to user IDs and write the user behaviors into a data table as a user behavior set;

[0106] The behavior set update submodule is used to periodically delete user behaviors before a preset time from the data table to update the user behavior set.

[0107] Furthermore, the behavior comparison module 506 includes:

[0108] The first ID acquisition submodule is used to acquire the behavior ID of the current user behavior and the event ID of the event triggering condition;

[0109] The ID comparison submodule is used to compare whether the behavior ID is consistent with the event ID and obtain the comparison result.

[0110] Furthermore, before the behavior comparison module 506, the method further includes:

[0111] The tag detection submodule is used to detect whether the event screening text includes offline tags;

[0112] The user screening submodule, if included, obtains the user's offline tag, and screens the user by comparing the user's offline tag with the offline tag to obtain the screened user.

[0113] Furthermore, the behavior matching module 508 includes:

[0114] The second ID acquisition submodule is used to acquire the behavior ID of the user behavior and the event ID of the behavior event;

[0115] The behavior matching submodule is used to query and match user behaviors corresponding to behavior IDs that are identical to the event IDs of the behavior events and in the same order.

[0116] The above-mentioned flink-based user service category detection device establishes a user behavior set for the user, and determines whether the collected current user behavior meets the event triggering condition of the event screening text. If it does, all user behaviors in the user behavior set are matched with the events in the event screening text to obtain a matching result. And a service type label is generated for the user according to the type of the matching result. This solves the technical problem that the classification judgment condition in the prior art is too simple and cannot meet the judgment of complex user behavior data, resulting in low accuracy of user classification.

[0117] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 6As shown. The computer device includes a processor, a memory, a network interface and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store user data. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a user service category detection method based on flink is implemented. By establishing a user behavior set for the user, and judging whether the collected current user behavior meets the event triggering condition of the event filtering text, if it meets, all user behaviors in the user behavior set are matched with the events in the event filtering text to obtain a matching result. And a service type label is generated for the user according to the type of the matching result. It solves the technical problem that the judgment condition of the classification in the prior art is too single and cannot meet the judgment of complex user behavior data, resulting in low accuracy of user classification.

[0118] Among them, technicians in this technical field can understand that the computer device here is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to microprocessors, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable gate arrays (Field-Programmable Gate Array, FPGA), digital processors (Digital Signal Processor, DSP), embedded devices, etc.

[0119] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0120] In one embodiment, a computer-readable storage medium is provided on which a computer program is stored. When the computer program is executed by a processor, the steps of the method for detecting user service categories based on Flink in the above embodiment are implemented, for example Figure 2 Steps 202 to 210 shown in the figure, or, when the processor executes the computer program, the functions of each module / unit of the user service category detection device based on Flink in the above embodiment are implemented, for example Figure 5The functions of modules 502 to 510 are shown. To avoid repetition, they will not be described here. By establishing a user behavior set for the user, and judging whether the current user behavior collected meets the event triggering condition of the event screening text, if it meets the condition, all user behaviors in the user behavior set are matched with the events in the event screening text to obtain a matching result. And a service type label is generated for the user according to the type of the matching result. This solves the technical problem that the judgment condition of classification in the prior art is too single and cannot meet the judgment of complex user behavior data, resulting in low accuracy of user classification.

[0121] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0122] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0123] The blockchain referred to in this application is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

[0124] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0125] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for those of ordinary skill in the art, without departing from the concept of the present application, several modifications, improvements or equivalent replacements of some technical features can be made, and these modifications or replacements do not make the essence of the same technical solution depart from the spirit and scope of the technical solution of each embodiment of the present invention, and all belong to the protection scope of the present application. Therefore, the protection scope of the patent of this application shall be subject to the attached claims.

Claims

1. A user service category detection method based on Flink, characterized in that: The method comprises: Establish a flink broadcast stream, and read the event screening text from the preset database regularly through the broadcast stream, and parse it into a json file, wherein the event screening text includes event trigger conditions and behavior events; Write the user behaviors collected in real time through page embedding into Kafka, and generate a user behavior set for each user based on the user behaviors; Compare the user's current user behavior with the event triggering condition to obtain a comparison result; If the comparison result is that the current user behavior meets the event triggering condition, all user behaviors in the user behavior set of the user are matched with the behavior events in the event screening text to obtain a matching result; If the matching result is that there is a user behavior in the user behavior set that satisfies the event screening text, generating a service type label for the user according to the event screening text; Wherein, generating a user behavior set for each user according to the user behavior includes: Set a unique user ID for each user; Construct a data table with user ID as key value; Collect user behaviors according to the user ID, and write the user behaviors into a data table as the user behavior set; Periodically deleting user behaviors before a preset time from the data table to update the user behavior set; The comparing the current user behavior of the user with the event triggering condition to obtain the comparison result includes: Obtain the behavior ID of the current user behavior and the event ID of the event triggering condition; Comparing the behavior ID with the event ID to see if they are consistent, and obtaining the comparison result; The step of matching all user behaviors in the user behavior set of the user with the behavior events in the event screening text includes: Obtain the behavior ID of the user behavior and the event ID of the behavior event; The query is performed to match the user behaviors corresponding to the behavior IDs that are the same as the event ID of the behavior event and in the same order.

2. The method according to claim 1, characterized in that The user behaviors collected in real time through page embedding are written into Kafka, including: The user's click and / or slide action on the page element and the duration of stay on the page element are obtained, and the user behavior is generated and written into Kafka according to the action, duration of stay and page element number.

3. The method according to claim 1, characterized in that Before comparing the current user behavior of the user with the event triggering condition, the method further includes: Detecting whether the event screening text includes an offline tag; If the offline tag is included, the user offline tag of the user is obtained, and the user is screened by comparing the user offline tag with the offline tag to obtain the screened user.

4. The method according to claim 1, characterized in that: After generating a service type label for the user according to the event screening text, the method further includes: A service type is generated for the user according to the service type label.

5. A flink-based user service category detection device, which executes the flink-based user service category detection method according to any one of claims 1 to 4 during operation, characterized in that: include: The text reading module is used to establish a flink broadcast stream, and to periodically read the event screening text from the preset database through the broadcast stream, and parse it into a json file, wherein the event screening text includes event triggering conditions and behavior events; The behavior set building module is used to write the user behaviors collected in real time through page embedding into Kafka, and generate a user behavior set for each user based on the user behaviors; A behavior comparison module is used to compare the user's current user behavior with the event triggering condition to obtain a comparison result; A behavior matching module, for matching all user behaviors in the user behavior set of the user with the behavior events in the event screening text to obtain a matching result if the comparison result shows that the current user behavior meets the event triggering condition; The label generation module is used to generate a service type label for the user according to the event screening text if the matching result is that there is a user behavior in the user behavior set that meets the event screening text.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 4 are implemented.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented.

Images