CN111666298A

CN111666298A - Method and device for detecting user service class based on flink, and computer equipment

Info

Publication number: CN111666298A
Application number: CN202010356623.8A
Authority: CN
Inventors: 邓煜
Original assignee: Ping An Property and Casualty Insurance Company of China Ltd
Current assignee: Ping An Property and Casualty Insurance Company of China Ltd
Priority date: 2020-04-29
Filing date: 2020-04-29
Publication date: 2020-09-15

Abstract

The application belongs to the field of data processing and discloses a method and a device for detecting user service classes based on flink, computer equipment and a readable storage medium. The method comprises the steps of obtaining user behaviors of a user in a page point burying mode, establishing a user behavior set for the user, judging whether the collected current user behaviors meet event triggering conditions of an event screening text, and if so, matching all the user behaviors in the user behavior set with events in the event screening text to obtain a matching result. And generating a service type label for the user according to the type of the matching result. The method solves the technical problem that in the prior art, the classification judgment condition is too single, the judgment of complex user behavior data cannot be met, and the classification accuracy of the user is not high. The present disclosure also relates to blockchain techniques, and the user behavior sets can be stored in blockchain nodes.

Description

Method and device for detecting user service class based on flink, and computer equipment

Technical Field

The present application relates to the field of data processing, and in particular, to a method and an apparatus for detecting a user service class based on a flink, a computer device, and a storage medium.

Background

In the conventional technology, user behavior is usually detected by a template, and user behavior data is generally matched with an abnormal template, and if the user behavior data is matched with the abnormal template, it indicates that the user corresponding to the user behavior data has the possibility of abnormality. For example, in the prior art, a processing method for user behavior data generally adopts obtaining user behavior data, where the user behavior data includes event type information corresponding to the user behavior data, determining a data matching policy corresponding to the event type information in the user behavior data according to a correspondence between a pre-stored time type and a data matching policy, and finally performing matching operation on the user behavior data according to the data matching policy to obtain a matching result. Although the method can achieve the purpose of classifying the users, the classification judgment condition is too single, the judgment of complex user behavior data cannot be met, and the technical problem of low user classification accuracy is caused.

Disclosure of Invention

Based on this, it is necessary to provide a method and an apparatus for detecting a user service class based on a flink, a computer device and a storage medium, so as to solve the problem that in the prior art, features cannot be accurately extracted, which results in inaccurate classification of users.

A method for detecting user service class based on flink, the method comprising:

establishing a flink broadcast stream, reading an event screening text from a preset database at regular time through the broadcast stream, and analyzing the event screening text into a json file, wherein the event screening text comprises event triggering conditions and behavior events;

writing user behaviors collected in real time through page embedding points into kafka, and generating a user behavior set for each user according to the user behaviors;

comparing the current user behavior of the user with the event trigger condition to obtain a comparison result;

if the comparison result is that the current user behaviors meet the event triggering condition, matching all the user behaviors in the user behavior set of the user with the behavior events in the event screening text to obtain a matching result;

and if the matching result is that the user behaviors meeting the event screening text exist in the user behavior set, generating a service type label for the user according to the event screening text.

A flink-based user service class detection apparatus, the apparatus comprising:

the system comprises a text reading module, a data processing module and a data processing module, wherein the text reading module is used for establishing a flink broadcast stream, reading an event screening text from a preset database at regular time through the broadcast stream, and analyzing the event screening text into a json file, wherein the event screening text comprises event triggering conditions and behavior events;

the behavior set building module is used for writing the user behaviors collected in real time through page embedded points into kafka and generating a user behavior set for each user according to the user behaviors;

the behavior comparison module is used for comparing the current user behavior of the user with the event trigger condition to obtain a comparison result;

the behavior matching module is used 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;

and the tag generation module is used for generating a service type tag for the user according to the event screening text if the matching result indicates that the user behaviors meeting the event screening text exist in the user behavior set.

A computer device comprising a memory and a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the flink-based user service class detection method when executing the computer program.

A computer-readable storage medium, in which a computer program is stored, which, when being executed by a processor, carries out the steps of the above flink-based user service class detection method.

According to the method, the device, the computer equipment and the storage medium for detecting the user service class based on the flink, the user behavior set is established for the user, whether the collected current user behavior meets the event triggering condition of the event screening text or not is judged, and if the collected current user behavior meets the event triggering condition, all the user behaviors in the user behavior set are matched with the events in the event screening text, so that a matching result is obtained. And generating a service type label for the user according to the type of the matching result. The technical problem that in the prior art, the classification judgment condition is too single, the judgment of complex user behavior data cannot be met, and the classification accuracy of the user is not high is solved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments of the present invention will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive labor.

FIG. 1 is a schematic diagram of an application environment of a method for detecting a class of user service based on flink;

FIG. 2 is a flowchart illustrating a method for detecting a class of user service based on flink;

FIG. 3 is a schematic flow chart of step 204 in FIG. 2;

FIG. 4 is a flowchart illustrating a method for flink-based user service class detection in another embodiment;

FIG. 5 is a schematic diagram of a flink-based user service class detection apparatus;

FIG. 6 is a diagram of a computer device in one embodiment.

Detailed Description

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "including" and "having," and any variations thereof, in the description and claims of this application and the description of the above figures are intended to cover non-exclusive inclusions. The terms "first," "second," and the like in the description and claims of this application or in the above-described drawings are used for distinguishing between different objects and not for describing a particular order.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The method for detecting the user service class based on the flink provided by the embodiment of the invention can be applied to the application environment shown in fig. 1. The application environment may include a terminal 102, a network for providing a communication link medium between the terminal 102 and the server 104, and a server 104, wherein the network may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

A user may use the terminal 102 to interact with the server 104 over a network to receive or send messages, etc. The terminal 102 may have installed thereon various communication client applications, such as a web browser application, a shopping application, a search application, an instant messaging tool, a mailbox client, social platform software, and the like.

The terminal 102 may be various electronic devices having a display screen and supporting web browsing, including but not limited to a smart phone, a tablet computer, an e-book reader, an MP3 player (Moving Picture Experts Group audio Layer III, mpeg compression standard audio Layer 3), an MP4 player (Moving Picture Experts Group audio Layer IV, mpeg compression standard audio Layer 4), a laptop portable computer, a desktop computer, and the like.

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

It should be noted that the method for detecting a user service type based on a flink provided in the embodiment of the present application is generally executed by a server/a terminal, and accordingly, the device for detecting a user service type based on a flink is generally disposed in a server/a terminal device.

It should be understood that the number of terminals, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Wherein, the terminal 102 communicates with the server 104 through the network. And (3) a developer or a setter screens the text through the event written by the terminal 102, and the terminal 102 sends the text to the TiDB after receiving the text, and analyzes the text into a json format document in the TiDB for storage so as to read, add, delete, modify and check. The server 104 obtains the event filtering text input through the terminal 102 from the TiDB, compares the event filtering text with the collected user behaviors, and generates a service type tag for the user according to the comparison result. The terminal 102 and the server 104 are connected through a network, the network may be a wired network or a wireless network, the terminal 102 may be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices, and the server 104 may be implemented by an independent server or a server cluster formed by a plurality of servers.

In an embodiment, as shown in fig. 2, a method for detecting a user service class based on flink is provided, which is described by taking the method applied to the server in fig. 1 as an example, and includes the following steps:

step 202, establishing a flink broadcast stream, reading an event screening text from a preset database at regular time through the broadcast stream, and analyzing the event screening text into a json file, wherein the event screening text comprises event triggering conditions and behavior events.

Since the Flink is a distributed computing engine, when distributed computing nodes need a data set with a small data volume, a broadcast stream mode is usually adopted, that is, another process is started to read a data source defined by the broadcast stream at regular time, and the data source is sent to each distributed computing node in a broadcast connection mode after being read. In the present proposal, since it is necessary to determine whether the user behavior satisfies the event trigger condition after the user completes an event (user behavior) each time, it is necessary to read the event trigger condition from the broadcast every time the user behavior is processed, so as to determine whether the user behavior satisfies the event trigger condition in the event filtering text. The specific process comprises the following steps: and starting a Flink broadcast stream, designating a data source needing broadcasting in the broadcast stream, reading the data source, and storing the data source into an event database to be used for subsequent condition judgment and acquisition.

For example, the event filtering text parsed into json format document may be:

a PACX _ H00018745 event occurs within one hour after the user's occurrence of HCZ _ H00010802 event:

[ { "eventType":2, event type of event trigger condition;

the interval is time Window and 1 h;

"eventName": PACX _ H00018745", the event name of the event trigger condition;

"sequence" [ { "eventName": HCZ _ H00010802"}, HCZ _ H00010802 is executed followed by PACX _ H00018745 in sequence; { "eventName": PACX _ H00018745"} ] }

The event filtering text is user filtering information written by a developer or a setter through a terminal, and the terminal can be a client. Such as background management software for certain insurance or insurance. And after receiving the event screening text, the client sends the event screening text to the TiDB, and analyzes the event screening text into a json format document in the TiDB so as to facilitate subsequent reading, adding, deleting, modifying and checking operations. The event filtering text comprises an event triggering condition and an action event, wherein the event triggering condition is also one of the action events. For example, a PACX _ H00018745 event occurs within one hour after the user has occurred HCZ _ H000108002 event. Then an action event with ID PACX _ H00018745 may be used as an event trigger condition. Wherein HCZ _ H, PACX _ H represents the action of the user in different modules, 00010 and 00018 represent the action of the user on elements such as different pages or links of corresponding modules, 8 or 7 represent the operation of clicking, sliding or jumping on an element, and 02 or 45 may represent the time length between actions of the user on the distance. Of course, the ID of a specific event trigger condition may be determined according to a specific scenario and is not limited to one. Further, the event trigger condition is typically the last bit of the behavior event located in the event filtering text.

And step 204, writing the user behaviors collected in real time through page embedding points into kafka, and generating a user behavior set for each user according to the user behaviors.

The page embedding point is a common data acquisition mode for website analysis, and generally mainly acquires user behavior data, such as an access path of a page, a click module, and the like. Existing page burial points are generally divided into three types: manual buried points, visual buried points, and non-buried points. The method has the advantages that the flow is controllable, the service party can collect data in any scene at any place according to needs, and the collected information is completely controlled by the service party.

The non-embedded point is that the front end automatically collects all events, reports embedded point data, and filters and calculates useful data by the back end. Generally, a user connects a data access management interface of a user behavior analysis tool through equipment, and directly operates interactive page elements (such as pictures, buttons, links and the like) which have effects after interaction on the interface to realize data embedding, and issues an embedding mode of acquiring effective return numbers of codes. The mode can be seen as the result, the processes of code deployment, test verification and version sending are skipped, and the productivity is greatly improved.

In the embodiment, because the text is screened based on the set event, the user behavior data required by the user can be acquired by adopting a manual point burying mode, the data transmission amount is reduced, and the calculation efficiency is improved.

The user behavior is an operation behavior of a user on a client or a corresponding page, such as a time spent on a certain page of a website, an action of clicking a certain element, an operation of searching a certain keyword, and the like, one user behavior may include an action of clicking a certain element, a time spent by the user on a certain element, a time length spaced between the user behavior and the last user behavior, time information when clicking a certain element, and the like, all of which may determine whether the user meets the basis of an event screening text, and the user behaviors obtained by a page point burying manner are generally automatically stored in a log file and written in kafka for synchronization to form a user data stream, so as to facilitate subsequent processing and analysis of user behavior data.

Kafka is a very widely used message queue, a storage engine for a producer & consumer model, and our APP usually collects behavior events of users on the APP, and sends the behavior events to Kafka storage, which is the producer. And our FLINK in this scenario is taken as a consumer, and the user data already stored in Kafka is read out in sequence.

The user data streams are stored with user behaviors of different users, the user data streams can be classified according to user categories, the user behaviors corresponding to the same user are integrated to be used as a user behavior set of the user, processing and analysis are facilitated, and the user behaviors in the user behavior set are sorted according to the operation time of the user.

The user behavior set comprises a plurality of user behaviors, and different user behaviors correspond to different behavior IDs. The trigger IDs of the event screening texts with the same event trigger condition can be the same, the behavior IDs of the same user behavior of different users are set to be the same, and the number of the event ID types in the event screening texts is reduced by the users, so that the data processing amount and the data comparison amount are reduced.

And step 206, comparing the current user behavior of the user with the event trigger condition to obtain a comparison result.

When the user behavior is matched with the event trigger condition, the acquired ID of the user behavior is only required to be compared with the ID of the event trigger condition. If the current user behavior of the user is the same as the ID of the event trigger condition, obtaining a comparison result that the user meets the event trigger condition, if the ID is different, obtaining a comparison result that the user behavior of the user does not meet the event trigger condition, and continuing to detect the user behavior of the user until the user stops the user behavior. The user who does not accord with any event screening text can generate no effective operation label for the user, the detection of the behavior of the user is reduced during the next data detection, and the data processing amount is reduced.

And 208, if the comparison result shows that the current user behaviors meet the event triggering condition, matching all the user behaviors in the user behavior set of the user with the behavior events in the event screening text to obtain a matching result.

When the behavior ID of the acquired user behavior is compared with the event ID of the behavior event, the user behavior corresponding to the behavior ID which is the same as the event ID of the behavior event and has the same sequence is inquired for matching.

If the comparison result is that the current user behavior meets the event triggering condition, all the user behaviors in the user behavior set need to be matched and judged to see whether the user behavior before the current user behavior meets other behavior events in the event screening text. For example, if the current user behavior is that a PACX _ H00018745 event has occurred, then there is no event HCZ _ H000108002 one hour before the PACX _ H00018745 event.

Wherein if the HCZ _ H000108002 event is one hour before the occurrence of the PACX _ H00018745 event, the user does not conform to the event screening text even if there is a HCZ _ H000108002 event in the user behavior collection.

If not, the user is not in accordance with the event screening text, and the service type label is not generated.

For example, if the current user behavior is a PACX _ H00018745 event, but the user does not have HCZ _ H000108002 event within one hour before the PACX _ H00018745 event, then the user is said not to conform to the event screening text.

Optionally, if the current user behaviors cannot be compared in time due to network delay, congestion, and the like, whether a user behavior meeting the event trigger condition exists in the user behavior set may be directly scanned to determine.

The same user can accord with a plurality of event screening texts, and different event screening texts do not interfere with each other, for example, if the behavior ID of the user behavior of a certain user is 03 which meets the event triggering condition, the user behavior 01 of the user meets the behavior event 01, and the behavior event 01/02/03 forms an event screening text a, it indicates that the user meets the event screening text a; if the user has a series of user behaviors: 01/02/03/04, but at the same time, the user can also satisfy the event filtering text b (01/03/04, the order of the time IDs of the behavior events in the event filtering text), wherein the behavior event corresponding to the event ID 04 is the event trigger condition of the event filtering text b.

That is, as long as the user operation is not stopped, the obtained user behavior is increased, and the comparison is continuously performed, so as to obtain more event filtering texts that the user conforms to. Further, the number of the event filtering texts that the same user conforms to may be overlapped, as a degree for determining that the user is of a certain type, for example, the more the number of the event filtering texts of a user is overlapped, the more the tickets of the same type are obtained.

Specifically, under the application of a wish tree of an APP, an event screening text positioned by a user is used as a condition stream, APP time actually generated by the user, namely user behavior, is a behavior stream, and how to judge whether the behavior stream of the user meets the condition, the two streams need to be connected, after data of the condition stream is read, an event triggering condition is stored in a flink mapstate structure (mapstate is a global data storage container, can operate map in the stream and is transmitted into another stream), then the behavior stream reads the mapstate, namely a condition defined by the user can be obtained, simultaneously, the user behavior can be read in the stream, comparison of the user behavior with behavior events in the event screening text is realized, whether the user behavior meets the event triggering condition is judged by combining the event triggering condition in the mapstate, matching judgment is carried out through the event triggering condition, the data in comparison is reduced, and the efficiency can also be improved.

And step 210, if the matching result is that the user behaviors meeting the event screening text exist in the user behavior set, generating a service type label for the user according to the event screening text.

The event filtering text satisfied by one user behavior may be zero or multiple. A service type tag may be generated for the user based on the event screening text satisfied by the user. Specifically, a Flink connect operator may be adopted to implement the connection between the user behavior and the event filtering text. The Flink connect operator is a connection operation provided by Flink for two streams, namely datastream objects, and is mainly used for merging data sets of two or more different data types, and the data types of the original data sets are reserved after merging, wherein datastream is an API for writing stream processing jobs by Flink, is a JAVA object, and when processing stream data, a stream is abstracted as the object. It includes a series of operation modes, such as map, filter, etc. When a user needs to merge two pieces of stream data, for example, the broadcast stream composed of the above event filtering texts and the behavior stream including user behaviors, the processing function method can be rewritten by the Flink Connect operator, so that the content of the connection can be customized.

Specifically, such as in a wish tree activity, we have rewritten the process function, which mainly contains 4 parts:

(1) defining a hash table (mapstate) for storing user behaviors;

(2) overwrite processBroadcastElement, process the value returned in the broadcast stream, i.e., all conditions;

(3) duplicating processElement, also the most complex, is to process user events;

(4) and judging whether the implementation part of the event screening text is satisfied.

The logic steps are as follows: inserting user behaviors into an event list of the user in a hash table, taking a set of all user behaviors of the current user, judging whether an event trigger condition is triggered or not, if not, ending the round of calculation to enter next data, if so, judging the behavior list of the user and a time screening text, if the user meets a certain event screening text, for example, outputting an integral value appointed by the event screening text and the name of the user to the downstream, and if not, judging the next event screening text until all the event screening texts are polled.

For example, in an APP wish tree activity, the main contents of the event trigger conditions are: when the user completes certain fixed tasks, the corresponding points can be obtained, and the application effect of improving the user interest is achieved. If the user clicks the user behavior of 'finishing task and checking violation' and then the user behavior of checking violation occurs in one hour, the user meets the corresponding event screening text, a label for picking up corresponding points can be generated for the user according to the event screening text, the user with the service type label can pick up a plurality of points, and the corresponding points can be exchanged for some services.

The method is used as the back-end data support of the wishing tree activity, and achieves the purpose of judging whether the user behavior meets the point sending requirement in real time by monitoring the data of the buried point of the user.

Further, after generating the service type tag for the user according to the event filtering text, the method further includes:

and generating a service type for the user according to the service type label, wherein the service type is used for indicating the user to update the service type label.

Specifically, three types of conditions can be configured, because the event filtering text is various, for example, there are three types: (1) XX times during XX times a user has occurred with a fixed event, (2) a user has occurred with an event (3) a user has occurred with an a event and X times thereafter has occurred with a B event. And finally, sending the specified service type, such as a real card ticket, a service, a reminder and the like, according to the service type label, wherein the service types are used for indicating the user to perform corresponding operations, such as card ticket consumption, service completion and reminding execution, so that the service type label of the user is updated, and when the user completes a certain service, the user loses a corresponding service type label. For example, when the service type obtained by the user is a ticket, if the ticket is used, the corresponding service type tag of the user may be subtracted, and when the user has only one service type tag corresponding to the ticket and is subtracted, it is necessary to determine whether the service type tag belongs to the service type tag again for the user, and then the service type may be generated again for the user. The purpose of accurately detecting the user category is achieved through the method.

In the method for detecting the user service class based on the flink, a user behavior set is established for the user, whether the collected current user behavior meets the event triggering condition of the event screening text or not is judged, and if the collected current user behavior meets the event triggering condition of the event screening text, all user behaviors in the user behavior set are matched with the events in the event screening text to obtain a matching result. And generating a service type label for the user according to the type of the matching result. The technical problem that in the prior art, the classification judgment condition is too single, the judgment of complex user behavior data cannot be met, and the classification accuracy of the user is not high is solved.

In one embodiment, step 204 comprises: acquiring the action of clicking and/or sliding the page element by the user and the stay time of the user on the page element, and generating the user behavior according to the action, the stay time and the number of the page element and writing the user behavior into kafka.

Specifically, the user may click to obtain the operation of checking the violation, and when the specific operation of the user is detected, the time length between the action and the previous action needs to be obtained as the stay time length.

If an action of picking up 1 point exists between actions of clicking to finish a task and checking violation by a user, the action of picking up 1 point is 10 seconds apart from the action of checking violation, and the action of clicking to finish the task is 5 seconds apart from the action of clicking to finish the task, the action of checking violation is confirmed to be 15 seconds apart from the action of finishing the task, and the stay time is 15 seconds.

The embodiment accurately acquires the actions and the action duration of the user and the interval duration between the two actions through a point burying mode and writes the actions and the action duration into the kafka, the kafka has the advantages of high throughput and low delay, hundreds of thousands of messages can be processed per second, the delay is only a few milliseconds at the minimum, the point burying data can be quickly processed, the purpose of quickly classifying the user is achieved, and the data processing efficiency is improved.

In one embodiment, as shown in FIG. 3, step 204 further comprises:

in step 302, a unique user ID is set for each user.

And step 304, constructing a data table with the user ID as a key value.

And step 306, collecting user behaviors according to the user ID, and writing the user behaviors into a data table as a user behavior set.

And step 308, deleting the user behaviors before the preset time from the data table at regular time to update the user behavior set.

Specifically, a mapstate data structure is defined, which is a global hash table, and when a piece of user behavior data of a user is read, the behavior data is added to a value with the user id as a Key (the value is a list structure container). The data table stores a plurality of user ids and user behavior data corresponding to the user ids. And (3) judging and removing the expired (data before more than 3 hours) user behavior data at regular time, and reducing the data storage capacity of the server, so that all operation records of all users in near 3 hours can be taken from the hash table as a user behavior set.

According to the embodiment, the expired user behavior data (data before more than 3 hours) is judged at regular time and removed, so that the data storage capacity of the server is reduced, the data storage efficiency is improved, the data volume of data comparison is increased, and the comparison speed is increased.

In one embodiment, as shown in fig. 4, before step 206, the method further includes:

step 402, detecting whether the event screening text comprises an offline label;

step 404, if the offline tag is included, obtaining a user offline tag of the user, and screening the user by comparing the user offline tag with the offline tag to obtain the screened user.

Specifically, the offline tag is a condition tag defined for the user in the event trigger condition, such as defining the user to be between 20 and 30 years of age, the gender to be male, and the like. If the detection result includes any one of the above offline tags, the user needs to be screened according to the offline tag. The method comprises the steps that each user corresponds to behavior streams and also comprises user offline data, the user offline data comprise offline labels of the users, the offline labels are mapped with the users and generally stored in an offline database, and if the server side detects that the offline labels exist in event screening texts, the server side can acquire the user offline labels of the users from the offline database to judge whether the users meet requirements of the offline labels. Inherent attributes of the user such as the user's gender, age, native place, occupation, etc.; if the offline tag limits the gender of the user to be male, the user is screened by integrating the user offline tag in the user offline data to obtain the behavior of the user with the gender of male, and then whether the behavior meets the event triggering condition is judged. The accuracy of screening the user is improved through the embodiment, the quantity of behavior data comparison is reduced, and the comparison efficiency is improved.

It should be understood that although the various steps in the flowcharts of fig. 2-4 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least some of the steps in fig. 2-4 may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, and the order of performing the sub-steps or stages is not necessarily sequential, but may be performed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

In one embodiment, as shown in fig. 5, a flink-based user service class detection apparatus is provided, where the flink-based user service class detection apparatus corresponds to the flink-based user service class detection method in the foregoing embodiment one to one. The flink-based user service class detection device comprises:

the text reading module 502 is configured to establish a flink broadcast stream, read an event screening text from a preset database at a fixed time through the broadcast stream, and analyze the event screening text into a json file, where the event screening text includes event triggering conditions and behavior events;

a behavior set constructing module 504, configured to write the user behaviors collected in real time through page embedding points into kafka, and generate a user behavior set for each user according to the user behaviors;

a behavior comparison module 506, configured to compare a current user behavior of the user with an event trigger condition to obtain a comparison result;

a behavior matching module 508, configured to match all user behaviors in the user behavior set of the user with behavior events in the event screening text to obtain a matching result if the comparison result indicates that the current user behavior meets the event triggering condition;

and a tag generation module 510, configured to generate a service type tag for the user according to the event screening text if the matching result indicates that the user behavior meeting the event screening text exists in the user behavior set.

Further, the behavior set building module 504 includes:

the ID generation submodule is used for setting a unique user ID for each user;

the data construction submodule is used for constructing a data table with the user ID as a key value;

the behavior collection submodule is used for collecting user behaviors according to the user ID and writing the user behaviors into the data table to be used as a user behavior set;

and the behavior set updating submodule is used for deleting the user behaviors before the preset time from the data table at regular time so as to update the user behavior set.

Further, the behavior comparison module 506 includes:

the first ID acquisition submodule is used for acquiring a behavior ID of the current user behavior and an event ID of an event trigger condition;

and the ID comparison submodule is used for comparing whether the behavior ID is consistent with the event ID or not to obtain a comparison result.

Further, before the behavior comparison module 506, the method further includes:

the label detection submodule is used for detecting whether the event screening text comprises an offline label or not;

and the user screening submodule acquires the user offline label of the user if the user offline label is included by hand, and screens the user by comparing the user offline label with the offline label to obtain the screened user.

Further, the behavior matching module 508 includes:

the second ID acquisition submodule is used for acquiring the behavior ID of the user behavior and the event ID of the behavior event;

and the behavior matching submodule is used for inquiring the user behaviors which are the same as the event IDs of the behavior events and are corresponding to the behavior IDs with the same sequence for matching.

The flink-based user service class detection device establishes a user behavior set for the user, judges whether the collected current user behavior meets the event triggering condition of the event screening text, and performs matching operation on all user behaviors in the user behavior set and the events in the event screening text if the collected current user behavior meets the event triggering condition of the event screening text to obtain a matching result. And generating a service type label for the user according to the type of the matching result. The technical problem that in the prior art, the classification judgment condition is too single, the judgment of complex user behavior data cannot be met, and the classification accuracy of the user is not high is solved.

In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as shown in fig. 6. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile 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 an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing user data. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a flink-based user service class detection method. The user behavior set is established for the user, whether the collected current user behavior meets the event triggering condition of the event screening text or not is judged, and if yes, all the user behaviors in the user behavior set are matched with the events in the event screening text, so that a matching result is obtained. And generating a service type label for the user according to the type of the matching result. The technical problem that in the prior art, the classification judgment condition is too single, the judgment of complex user behavior data cannot be met, and the classification accuracy of the user is not high is solved.

As will be understood by those skilled in the art, the computer device is a device capable of automatically performing numerical calculation and/or information processing according to a preset or stored instruction, and the hardware includes, but is not limited to, a microprocessor, an Application Specific Integrated Circuit (ASIC), a Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), an embedded device, and the like.

Those skilled in the art will appreciate that the architecture shown in fig. 6 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and the computer program when executed by a processor implements the steps of the method for detecting a flink-based user service class, such as the steps 202 to 210 shown in fig. 2, or the processor implements the functions of the modules/units of the device for detecting a flink-based user service class, such as the modules 502 to 510 shown in fig. 5. To avoid repetition, further description is omitted here. The user behavior set is established for the user, whether the collected current user behavior meets the event triggering condition of the event screening text or not is judged, and if yes, all the user behaviors in the user behavior set are matched with the events in the event screening text, so that a matching result is obtained. And generating a service type label for the user according to the type of the matching result. The technical problem that in the prior art, the classification judgment condition is too single, the judgment of complex user behavior data cannot be met, and the classification accuracy of the user is not high is solved.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. 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. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions.

The block chain referred by the application is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. A block chain (Blockchain), which is essentially a decentralized database, is a series of data blocks associated by using a cryptographic method, and each data block contains information of a batch of network transactions, so as to verify the validity (anti-counterfeiting) of the information and generate a next block. The blockchain may include a blockchain underlying platform, a platform product service layer, an application service layer, and the like.

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for those skilled in the art, without departing from the spirit and scope of the present invention, several changes, modifications and equivalent substitutions of some technical features may be made, and these changes or substitutions do not make the essence of the same technical solution depart from the spirit and scope of the technical solution of the embodiments of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A method for detecting user service class based on flink is characterized in that the method comprises the following steps:

2. The method of claim 1, wherein writing user behavior collected in real time through page landfilling to kafka comprises:

acquiring the action of clicking and/or sliding the page element by the user and the stay time of the page element, and generating the user behavior writing kafka according to the action, the stay time and the number of the page element.

3. The method of claim 1, wherein generating a set of user behaviors for each user according to the user behaviors comprises:

setting a unique user ID for each user;

constructing a data table with the user ID as a key value;

collecting user behaviors according to the user ID, and writing the user behaviors into a data table as the user behavior set;

and deleting the user behaviors before the preset time from the data table at regular time to update the user behavior set.

4. The method of claim 3, wherein comparing the current user behavior of the user with the event trigger condition to obtain a comparison result comprises:

acquiring a behavior ID of the current user behavior and an event ID of the event trigger condition;

and comparing whether the behavior ID is consistent with the event ID to obtain the comparison result.

5. The method of claim 3, wherein matching all user behaviors in the user behavior set of the user with behavior events in the event filter text comprises:

acquiring a behavior ID of a user behavior and an event ID of the behavior event;

and inquiring user behaviors corresponding to the behavior IDs which are the same as the event IDs of the behavior events and have the same sequence for matching.

6. The method of claim 1, further comprising, prior to said comparing the current user behavior of the user to the event trigger condition:

detecting whether the event screening text comprises an offline label;

and if the offline label is included, acquiring a user offline label of the user, and screening the user by comparing the user offline label with the offline label to obtain the screened user.

7. The method of claim 1, after generating a service type tag for the user according to the event filtering text, further comprising:

and generating a service type for the user according to the service type label.

8. A flink-based user service class detection apparatus, comprising:

9. A computer device comprising a memory and a processor, the memory storing a computer program, wherein the processor implements the steps of the method of any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 7.