A data processing method and device, electronic equipment and storage medium

Abstract

The present disclosure discloses a data processing method and device, electronic equipment and storage medium, by setting a real-time audit mechanism when data is reported, once abnormal data is identified in the data reporting process, the corresponding target abnormal level can be determined according to the target application data, and the target application data is processed based on the processing scheme corresponding to the target abnormal level, so as to realize the instant discovery and instant warning of abnormal data, realize the in-process intervention of abnormal data, can control the data in advance, and help to ensure the data quality; by ensuring the data quality, the adverse effects of incorrect data on user behavior analysis, business recommendation and other core businesses can be effectively avoided, thereby improving the stability and accuracy of analyzing various core businesses based on data.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically to a data processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the booming development of the digital music industry, the business boundaries of digital music platforms continue to expand, now encompassing diverse smart hardware such as mobile devices, game applications, and in-vehicle terminals, as well as a full-scenario access ecosystem of mini-programs within applications. To achieve cross-scenario display of music content and comprehensive perception of user behavior, open platforms typically establish connections with various access parties through application programming interfaces (APIs) or software development kits (SDKs). On the one hand, they provide music content resources to access parties; on the other hand, they collect and analyze user behavior data reported by access parties.

[0003] However, under existing technologies, open platforms typically only discover whether there are anomalies in the event tracking data reported by the access party when they need to analyze the data recorded in the logs. This results in a problem of delayed discovery of anomalies, which makes it difficult to guarantee the data quality throughout the entire process. Consequently, the stability and accuracy of data-based analysis of various core business operations are relatively low. Summary of the Invention

[0004] This disclosure provides a data processing method, apparatus, electronic device, and storage medium. By setting a real-time review mechanism during data reporting, once abnormal data is identified during the data reporting process, the corresponding target abnormality level can be determined based on the target application data. Based on the processing scheme corresponding to the target abnormality level, the target application data is processed, thereby achieving immediate detection and early warning of abnormal data and enabling in-process intervention. This allows for proactive data control and helps ensure data quality. By ensuring data quality, the adverse effects of erroneous data on core businesses such as user behavior analysis and business recommendations can be effectively avoided, thereby improving the stability and accuracy of data-based analysis of various core businesses.

[0005] In a first aspect, embodiments of this disclosure provide a data processing method, including: In response to a data reporting request for a target application, based on the target application scenario to which the target application data of the target application in the data reporting request belongs, a target scenario review rule matching the target application scenario is selected from multiple preset scenario review rules. The data reporting request is used to request that the target application data be stored in the log corresponding to the target application. The target application data is reviewed based on the target scenario review rules to obtain the review result of the target application data; If the audit result indicates data anomaly, determine the target application data type to which the target application data belongs; Based on the preset anomaly identification conditions corresponding to the target application data type, the target anomaly level of the target application data is determined; Based on the processing scheme corresponding to the target anomaly level, the target application data is processed.

[0006] Secondly, embodiments of this disclosure provide a data processing apparatus, comprising: The response unit is used to respond to a data reporting request for a target application, and based on the target application scenario to which the target application data of the target application in the data reporting request belongs, to filter out the target scenario review rules that match the target application scenario from multiple preset scenario review rules. The data reporting request is used to request that the target application data be stored in the log corresponding to the target application. An auditing unit is used to audit the target application data based on the target scenario auditing rules to obtain the auditing result of the target application data; The first determining unit is used to determine the target application data type to which the target application data belongs if the audit result is data anomaly. The second determining unit is used to determine the target anomaly level of the target application data based on the preset anomaly identification conditions corresponding to the target application data type. The processing unit is used to process the target application data based on the processing scheme corresponding to the target anomaly level.

[0007] Thirdly, embodiments of this disclosure also provide an electronic device, including a memory storing a plurality of instructions; a processor loading instructions from the memory to execute the steps of any of the data processing methods provided in embodiments of this disclosure.

[0008] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to perform the steps of any of the data processing methods provided in embodiments of this disclosure.

[0009] Fifthly, embodiments of this disclosure also provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps of any data processing method provided in embodiments of this disclosure.

[0010] The solution adopted in this disclosure embodiment can establish a real-time review mechanism when reporting data. Once abnormal data is identified during the data reporting process, the corresponding target abnormality level can be determined based on the target application data. Based on the processing scheme corresponding to the target abnormality level, the target application data can be processed, thereby achieving real-time detection and early warning of abnormal data and enabling in-process intervention. This allows for proactive data control and helps ensure data quality. By ensuring data quality, the adverse effects of erroneous data on core businesses such as user behavior analysis and business recommendations can be effectively avoided, thereby improving the stability and accuracy of data-based analysis of various core businesses. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram of a data processing system provided in the embodiments of this disclosure; Figure 2 This is a schematic flowchart of one embodiment of the data processing method provided in this disclosure. Figure 3 This is a connection diagram of the processing nodes of the code processing system provided in the embodiments of this disclosure; Figure 4 This is a schematic diagram illustrating an application scenario of the data processing method provided in this embodiment of the disclosure; Figure 5 This is a schematic diagram illustrating another application scenario of the data processing method provided in the embodiments of this disclosure; Figure 6 This is a schematic diagram illustrating another application scenario of the data processing method provided in the embodiments of this disclosure; Figure 7 This is a schematic diagram of the structure of the data processing apparatus provided in the embodiments of this disclosure; Figure 8 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0013] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure. Furthermore, in the description of the embodiments of this disclosure, the terms "first," "second," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance. Therefore, features defined with "first" or "second" may explicitly or implicitly include one or more features. In the description of the embodiments of this disclosure, "multiple" means two or more, unless otherwise explicitly specified.

[0014] This disclosure provides a data processing method, apparatus, electronic device, and computer-readable storage medium. Specifically, this embodiment will be described from the perspective of a data processing apparatus, which can be integrated into an electronic device. That is, the data processing method of this disclosure can be executed by an electronic device. Optionally, the electronic device may include a terminal device. The terminal device may be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, or personal computer (PC), etc.

[0015] The data processing method provided in this disclosure can be applied to interactive systems, such as terminal devices and servers. The terminal can be a device that includes both receiving and transmitting hardware, i.e., a device with receiving and transmitting hardware capable of performing bidirectional communication over a bidirectional communication link. The terminal device and the server can communicate bidirectionally via a network.

[0016] Optionally, the server can be a standalone server, or a server network or server cluster, including but not limited to computers, network hosts, single network servers, multiple network server sets, or cloud servers composed of multiple servers. Cloud servers consist of a large number of computers or network servers based on cloud computing.

[0017] In one embodiment of this disclosure, the data processing method can run on a local terminal device or a server. When the game interaction method runs on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and a client device.

[0018] Please see Figure 1 , Figure 1This is a schematic diagram of a data processing system provided in an embodiment of this disclosure. The system may include at least one terminal, at least one server, at least one database, and a network. A user's terminal can connect to different servers via the network. The terminal is any device with computing hardware capable of supporting and executing software products corresponding to model generation. Furthermore, when the system includes multiple terminals, multiple servers, and multiple networks, different terminals can connect to each other through different networks and servers. The network can be a wireless network or a wired network, such as a wireless local area network (WLAN), local area network (LAN), cellular network, 2G network, 3G network, 4G network, 5G network, etc. Additionally, different terminals can also connect to other terminals or servers using their own Bluetooth networks or hotspot networks. For example, multiple users can connect online through different terminals via appropriate networks and synchronize with each other to support multi-user access. Furthermore, the system may include multiple databases coupled to different servers, and information related to the operating environment can be continuously stored in the databases while different users are using the system online.

[0019] The following detailed description is provided in conjunction with the accompanying drawings. In this embodiment, the execution subject is a terminal device as an example. It should be noted that the order of description in the following embodiments is not intended to limit the preferred order of the embodiments. Although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown in the accompanying drawings.

[0020] Please see Figure 2 , Figure 2 This is a flowchart illustrating a data processing method provided in an embodiment of the present disclosure. The specific flow of the data processing method can be summarized in steps 101 to 105, wherein: Step 101: In response to a data reporting request for a target application, based on the target application scenario to which the target application data of the target application belongs in the data reporting request, select a target scenario review rule that matches the target application scenario from multiple preset scenario review rules. The data reporting request is used to request that the target application data be stored in the log corresponding to the target application.

[0021] In this embodiment of the application, in response to a data reporting request for a target application sent by the target system of the target terminal device, a target scenario review rule matching the target application scenario can be selected from multiple preset scenario review rules based on the target application scenario to which the target application data of the target application in the data reporting request belongs. The data reporting request is used to request that the target application data be stored in the log corresponding to the target application. The target application runs on the target system of the terminal device.

[0022] For details, please refer to Figure 3 The data interaction architecture of the data processing system provided in this application embodiment is shown in the figure. The open platform management front end is responsible for interaction and configuration, the open platform gateway is responsible for unified access and control, and the open platform service is responsible for the execution of core business logic. On the user side: Administrators initiate operation requests (such as configuring parameters, viewing monitoring, and managing permissions) through the platform management front end; on the relay side: requests are first sent to the platform gateway, which performs authentication, routing, rate limiting, and other control operations before forwarding them to the corresponding platform service; on the execution side: the platform service processes the specific business logic and returns the results to the management front end through the gateway, ultimately presenting them to the administrator. External systems only need to communicate with the open platform gateway; external systems are the access parties.

[0023] The workflow of the above system structure is as follows: Administrators use the open platform associated front end to create a data acquisition request for a certain access party. The access party reports the data to the open platform gateway according to the data acquisition request. The open platform gateway uses the data rules written by the open platform service to verify the data. After the open platform gateway determines the data verification result, it returns it to the open platform management front end.

[0024] In this embodiment, the target application runs on the target system on the terminal device. The target system is the access party, which can be an application (APP) running on the terminal device. The target application can be an application running on the access party.

[0025] Step 102: Review the target application data based on the target scenario review rules to obtain the review result of the target application data.

[0026] In this embodiment of the application, normal data can be stored in a normal data log. After the step "auditing the target application data based on the target scenario audit rules to obtain the audit result of the target application data", the method further includes: If the audit result is that the data is normal, the target application data is stored in the first data log, which is used to store application data for which the audit result is normal.

[0027] Specifically, application data that passes the audit is stored in the first data log to enter the downstream processing flow.

[0028] In this embodiment, an access party only receives a unique identity identifier after successfully registering with the development platform, enabling it to report data to the platform. If the access party's data fails rule verification, the development platform restricts its interface requests, releasing the restrictions only after successful verification. Then, the terminal device of the access party reports data to the open platform's real-time interface; each terminal device with an access party reports data to the open platform's real-time interface. Upon receiving the reported data from the data reporting request, the open platform's backend service uses a rule engine to perform real-time analysis of the target application scenario and target metrics data in the reporting request to determine if the data is abnormal. If the data is normal, it proceeds to downstream processing, performing business analysis or storing the data in logs.

[0029] Step 103: If the audit result is data anomaly, determine the target application data type to which the target application data belongs.

[0030] Specifically, after receiving the data reporting request, the open platform's backend service uses a rule engine to perform real-time analysis of the target application scenario and target metric data in the reporting request to determine if the data is abnormal. If the data is abnormal, it is categorized, and the specific alarm level is determined based on the type of abnormality and its impact on the business. Specifically, abnormal data can be categorized to determine the target application data type to which the target application data belongs.

[0031] In this application embodiment, the target application scenarios may include audio playback scenarios, video playback scenarios, user login scenarios, content search scenarios, and user transaction scenarios, etc., which are only examples for illustration, and more examples are not elaborated. Specifically, the target metric data for the audio playback scenario includes: user ID, device ID, playback behavior (such as start playback and / or end playback), song ID, song playback duration, and sound quality. The target metric data for the video playback scenario includes: user ID, device ID, playback behavior (such as start playback and / or end playback), playback duration, playback resolution, playback progress, and number of interactions (such as likes / comments / shares / favorites). The target metric data for the user login scenario includes: user ID, login timestamp, login IP address, login device identifier, and login result (success / failure). The target metric data for the content search scenario includes: search keywords, search time, number of returned results, and user click behavior. The target metric data for the user transaction scenario includes: user ID, device ID, transaction time, transaction amount, transaction channel, transaction status, number of transactions per day, and number of transfer recipients.

[0032] For example, the target application scenario could be an audio playback scenario. The target metrics for this scenario include: user ID, device ID, playback behavior (such as start and / or end of playback), song ID, song playback duration, and sound quality. In an audio playback scenario, normal data requirements are: playback duration cannot be less than 0 or greater than the song's original maximum duration; device ID and song ID must be present. Abnormal data requirements are: playback duration less than 0, or greater than the song's maximum duration; missing song ID or device ID; or device ID not conforming to the format requirements, such as (xxx, where x represents an Arabic numeral).

[0033] The application data type can be either login type or playback information type. The preset anomaly identification conditions corresponding to the login type are as follows: if the login rate increases by more than a specified percentage within a specified time period, the anomaly level is P2; if the login rate increases by more than a specified percentage within a specified time period and exceeds the specified percentage for a specified number of consecutive times within a specified time period, the anomaly level is P1; if the login rate increases by more than a specified percentage within a specified time period and exceeds the specified percentage for a specified number of consecutive times within a specified time period and continues indefinitely, the anomaly level is P0. The preset anomaly identification conditions corresponding to the playback information type can be as follows: if the missing percentage of the audio quality field and playback behavior type (start playing / end playing) is less than a specified percentage (e.g., 3%), the anomaly level is P2; or, if the percentage of records with negative song playback duration or exceeding the maximum physical duration of the song exceeds a threshold (e.g., 5%), it is judged as a P2 level anomaly; if the total amount of playback behavior data reported per unit time suddenly increases by more than a specified percentage of the historical average (e.g., 50%), it is directly judged as a P1 level anomaly; if the playback data reporting delay reaches a specified duration (e.g., 5 minutes), the anomaly level is judged as P0.

[0034] Step 104: Determine the target anomaly level of the target application data based on the preset anomaly identification conditions corresponding to the target application data type.

[0035] In this embodiment of the application, the specific alarm level can be determined based on the anomaly type and the degree of business impact. The step "determining the target anomaly level of the target application data based on the preset anomaly identification conditions corresponding to the target application data type" includes: Based on the preset anomaly identification conditions corresponding to the target application data type, determine the degree of impact of the target application data on the target application. The target anomaly level of the target application data is determined based on the degree of impact of the target.

[0036] Specifically, the step "determining the target anomaly level of the target application data based on the target impact level" includes: Based on the degree of impact of the target, the target anomaly level and target anomaly alarm information of the target application data are determined.

[0037] For example, if the target application data type is login, and the login rate increases by more than 2% within a specified time period of 10 minutes, then the target anomaly level is determined to be P2, and the target anomaly alarm message "The login rate is abnormal, please handle it in time" is determined.

[0038] Furthermore, after step "determining the target anomaly level and target anomaly alarm information of the target application data based on the target impact level", the method further includes: Based on the target anomaly level, determine the information prompting channel for the target anomaly alarm information, so as to output the target anomaly alarm information through the information prompting channel.

[0039] For example, the anomaly levels include the first anomaly level P0, the second anomaly level P1, and the third anomaly level P2. The information notification channel for the first anomaly level P0 is telephone or instant messaging, the information notification channel for the second anomaly level P1 is email or office application notification, and the information notification channel for the third anomaly level P2 is the alarm list within the open platform system.

[0040] Step 105: Process the target application data based on the processing scheme corresponding to the target anomaly level.

[0041] In this embodiment of the application, the step "processing the target application data based on the processing scheme corresponding to the target anomaly level" includes: Based on the processing scheme corresponding to the target anomaly level, the target application data is stored in the second data log, which is used to store application data whose audit result is data anomaly.

[0042] Optionally, abnormal data may be stored or not stored according to the abnormality level to ensure the accuracy of log data. The processing scheme includes a first processing scheme and a second processing scheme. The first processing scheme is used to indicate that the target application data is not stored in the log corresponding to the target application. The second processing scheme is used to indicate that the target application data is stored in the second data log corresponding to the target application.

[0043] The first data log stores application data for which the audit result is normal, while the second data log stores application data for which the audit result is abnormal. This embodiment of the application ensures the accuracy of business statistics by recording only normal data in the first data log; the second data log, as a dedicated storage medium for abnormal data, stores abnormal data independently, completely isolating normal and abnormal data and ensuring the purity of normal data. When using the target model to analyze abnormal application data, there is no need to filter out abnormal data from massive amounts of data containing both normal and abnormal data; the analysis of abnormal application data can be performed quickly directly through the target model based on the second data log, significantly shortening the time for anomaly investigation.

[0044] In one embodiment, since distorted data has no reference value, storing such data would waste storage and computing resources and could even cause the log system to crash. To avoid invalid or erroneous data consuming log system resources, a first processing scheme can be adopted: the target application data is not stored in the log corresponding to the target application, thereby avoiding the storage of massive amounts of invalid data, reducing storage costs and data throughput pressure, and ensuring the stability of the log system.

[0045] In another embodiment, since it is necessary to trace the business corresponding to the abnormal application data and solve the problem of not being able to locate the cause of the abnormal application data, a second processing solution can be adopted, which is to store the target application data in the second data log corresponding to the target application, retain the information of the abnormal application data, and support the subsequent root cause analysis of the abnormal problem using the target model.

[0046] Specifically, after the step of "determining the target anomaly level of the target application data based on the preset anomaly identification conditions corresponding to the target application data type", the method further includes: If the target anomaly level meets the preset level conditions, then the processing solution corresponding to the target anomaly level is determined to be the first processing solution; If the target anomaly level does not meet the preset level conditions, then the processing scheme corresponding to the target anomaly level is determined to be the second processing scheme.

[0047] The preset level condition can be higher than or equal to a specified anomaly level. For example, if the specified anomaly level is the second anomaly level, when the target anomaly level is the first or second anomaly level, the processing solution corresponding to the target anomaly level is determined to be the first processing solution; when the target anomaly level is the third or higher anomaly level, the processing solution corresponding to the target anomaly level is determined to be the second processing solution.

[0048] In this application embodiment, the first processing scheme is applicable to scenarios with high data anomaly levels, and the second processing scheme is applicable to scenarios with low data anomaly levels. For example, specifying the anomaly level as P0, and taking playback behavior data as the target application data as an example, if no playback behavior data is reported within a unit of time and this continues for more than a preset duration, the target anomaly level of the playback behavior data can be determined to be P0. At this time, the first processing scheme can be used, which prevents the playback behavior data from being stored in the log corresponding to the target application, thereby quickly filtering out valueless abnormal data and preventing invalid data from entering the log system. As another example, specifying the anomaly level as P0, and taking playback duration data as the target application data as an example, if a slight anomaly in playback duration is detected, the target anomaly level of the playback duration data can be determined to be P2. At this time, the second processing scheme can be used, which stores the playback duration data in the second data log corresponding to the target application, achieving isolated storage of normal data and abnormal data, and providing data support for the subsequent root cause analysis of anomaly problems by the target model.

[0049] Specifically, this application embodiment verifies the standardization and automation rules of data reporting when the access party joins the open platform to improve the accuracy of access; in addition, it sets up alarms for abnormal data indicators reported by the interface in real time, quickly discovers problems for core indicators, and intervenes as early as possible to prevent the problem from spreading; furthermore, it combines AI big data models to perform root cause analysis on abnormal data, reduces reliance on manual labor, and achieves cost reduction and efficiency improvement.

[0050] Based on the above description, the following examples will further illustrate the data processing methods of this disclosure. Please refer to [link / reference]. Figure 4 The specific implementation of the automatic verification of the access data reporting specification for the onboarding process in this disclosure is as follows: (1) The access party submits an application for onboarding and qualification materials. The platform reviews the access party's qualifications and determines whether it meets the admission requirements. Among them, the qualification materials can be the access party's business license, email address, contact person's mobile phone number, company name, and reason for application. Whether the onboarding can be completed can be determined by preset rules. (2) If the qualification review is passed, a unique identity identifier (such as API Key / Secret) will be assigned to the access party, and a matching scenario rule document (including data format and verification logic for each scenario) will be pushed. The identity identifier is a token for calling the development platform interface. Each access party has a unique identity identification number. If they do not match, the interface cannot be requested normally. (3) The access party assembles the required reporting data (such as user behavior, device status, etc.) according to the scenario rule document, and calls the platform data reporting interface to submit the assembled data; for example, the playback rule requires that the playback behavior data include data with song ID of 1, playback duration of complete playback (that is, the duration is the specific duration of the song, such as 2 minutes and 30 seconds), and sound quality of extremely high. Then the playback reporting data needs to include basic information such as song ID, song name, playback duration, user behavior type (such as start playback, end playback), sound quality level, and user membership identity; the verification process is as follows: if all the data are in compliance, the playback rule is considered to be passed; if one of them is not in compliance, the reporting verification is considered to be incorrect.

[0051] (4) The platform rules engine initiates a multi-scenario verification process: Scenario 1 (Basic Format Validation): Check the integrity, type compliance, and format of data fields (such as mobile phone number and timestamp). Scenario 2 (Business Logic Validation): Verify the logical rationality between data; for example, the song playback rules have two behavioral data: playback reporting and playback end. Both rules need to be validated to prove that it is a complete song playback report. Scenario 3 (Cross-scenario consistency verification): Compare historical or other scenario data (such as matching user level and permissions); (5) If any scenario verification fails, a structured error report (including scenario number, error fields, and correction suggestions) is generated and returned to the access party in real time; (6) The access party corrects the data according to the error report and re-executes steps 3-4 above; (7) If all scenario verifications pass, the data will be stored in the database, and the access party's status will be marked as "acceptance passed." A successful onboarding notification will be sent to the access party, granting them permission to submit formal data (or lifting the interface request restriction). The process will then end. If the access party fails to onboard, some users of the platform can still use the functions provided by the access party, but there will be a limit on the number of interface requests, with a daily limit of 10,000 total interface requests. If the limit is reached, the open platform interface will restrict the access party from using the interface functions normally.

[0052] In this embodiment of the application, the data reporting standardization and automation rules are verified when the access party joins the open platform to improve the accuracy of access.

[0053] Based on the above description, the following examples will further illustrate the data processing methods of this disclosure. Please refer to [link / reference]. Figure 5 The abnormal data alarm process for real-time interface requests provided in this embodiment is as follows: (1) The terminal device reports data to the real-time interface, and the background service receives the request; (2) The rule engine performs real-time analysis on the core scenarios and core indicator data in the request to determine whether the data is abnormal. If the data is normal, it proceeds to the downstream processing flow; if the data is abnormal, it continues to the next step. (3) Classify the abnormal data and determine the specific alarm level based on its abnormality type and the degree of business impact; (4) Issue tiered alarms. If it is an emergency / serious error, a P0 level alarm will be triggered; if it is a normal business anomaly, a P1 level alarm will be triggered; if it is a minor anomaly or warning, a P2 level alarm will be triggered. The information notification channel for P0 level alarms is telephone or instant message, the information notification channel for P1 level alarms is email or office application notification, and the information notification channel for P2 level alarms is the alarm list in the open platform system.

[0054] (5) For P0 or P1 level alarms, notify operations and development to intervene and handle them; for P2 level alarms, log them and monitor them continuously.

[0055] In this embodiment, during the processing of the real-time data reporting interface, upon receiving a user request, the system performs real-time streaming analysis on key indicator data within the core business scenario using a rule engine to accurately identify data anomalies. For data deemed abnormal, it is automatically categorized based on its anomaly type and the degree of impact on the business, triggering a matching multi-level tiered alarm mechanism to achieve closed-loop management from accurate perception to rapid response.

[0056] In this embodiment of the application, the method further includes: Obtain the target application logs and at least one data verification rule of the target application; The data verification rules are used to verify each application data in the target application log to obtain the verification results corresponding to each application data under each data verification rule. Based on the verification results, filter out abnormal application data whose verification results are abnormal from the target application logs; The abnormal application data is analyzed using the target model to obtain data analysis results; Based on the data analysis results, determine the target alarm level and target alarm content for the abnormal application data; The target alarm level and the target alarm content are output through the information notification channel corresponding to the target alarm level.

[0057] In this embodiment, the data verification rules may include data query statements (such as Hive SQL) for different types of application data. Each data query statement may have a custom threshold. For example, different access providers may have different requirements regarding the sensitivity of daily active users (DAU), monthly active users (MAU), and login rate fluctuations, thus resulting in different thresholds. For instance, a data query statement for daily active users might identify data as abnormal if the increase in daily active users exceeds a specified percentage, and a data query statement for login rate might identify data as abnormal if the login rate exceeds a specified percentage. Then, multiple data query statements included in the data verification rules can be used to verify each application data in the target application log to obtain the verification result for each application data under each data verification rule. If the data does not meet the threshold corresponding to the data query statement, the verification result is normal, and the data is considered normal. If the data meets the threshold corresponding to the data query statement, the verification result is abnormal, and the data is considered abnormal application data. Based on each verification result, abnormal application data with abnormal verification results is filtered out from the target application log.

[0058] Furthermore, the abnormal application data is analyzed using a target model to obtain data analysis results. Specifically, the degree of impact of the abnormal application data on the business can be determined as the data analysis result. For example, if the data analysis result indicates that the abnormal application data will lead to an urgent or verification error, then the target alarm level for the abnormal application data is determined to be P0, and the corresponding target alarm content is "This anomaly will lead to a major error"; if the data analysis result indicates that the abnormal application data will lead to a normal business anomaly, then the target alarm level for the abnormal application data is determined to be P1, and the corresponding target alarm content is "This anomaly is a normal anomaly"; if the data analysis result indicates that the abnormal application data will lead to a minor anomaly or warning, then the target alarm level for the abnormal application data is determined to be P2, and the corresponding target alarm content is "This anomaly is a minor anomaly".

[0059] In this embodiment, the target model can be an Artificial Intelligence (AI) model, such as a combination of one or more of the following: a time-series big data model, a large language model (LLM), a graph big data model, and a machine learning model. Specifically, the time-series big data model can handle anomaly detection, feature extraction, and root cause localization of anomalies; the large language model can take the output results of other models and combine them with business knowledge bases, data metadata, etc., to complete root cause analysis, cross-dimensional diagnosis, and decision suggestions for anomalies; the graph big data model can locate the root cause of anomalies based on the correlation characteristics between devices corresponding to anomaly data; and the machine learning model can extract abnormal application data, which is then used by other models to complete the root cause analysis of the anomalies.

[0060] Based on the above description, the following examples will further illustrate the data processing methods of this disclosure. Please refer to [link / reference]. Figure 6 The data analysis provided in this disclosure embodiment is as follows: (1) The data center uses a collector to collect raw user log files and write them to an offline Hive table; machine log files are used to reduce the service pressure on the data center and improve the writing efficiency of logs. The data center only needs to uniformly schedule collection tasks to collect log files, thereby avoiding a sudden large number of logs from affecting the performance of the collection center; (2) Obtain the access party's custom and platform-wide data verification rules (such as daily and weekly comparisons of single-user multi-device data) and Hive SQL query statements. Different access parties have different requirements for the sensitivity of data fluctuations such as DAU, MAU, and login rate, and will set different thresholds. These SQL scripts will schedule computing resources (such as MapReduce and Spark engines) to run data analysis, and perform various operations including correlation queries, aggregation calculations, and trend comparisons, thereby completing multi-dimensional correlation rule verification and identifying potential data fluctuations, logical contradictions, or abnormal indicators. (3) Deeply analyze abnormal data using AI big data models to extract abnormal features, such as the daily or weekly increase or decrease in the number of new devices exceeding the rule threshold. For example, an abnormal feature might be an abnormal increase in the DAU of a certain access provider. This would be analyzed in conjunction with the access provider's historical DAU, MAU, login rate, retention rate, and data reporting behavior. Diagnosis is performed from multiple perspectives, including data source, specific values, and business characteristics, based on abnormal indicator data. Furthermore, abnormal alarms are recorded in the database for follow-up on subsequent abnormal handling progress.

[0061] (4) Based on the results of AI root cause analysis, abnormal events are classified, and the specific alarm level is determined according to the type of abnormality and the degree of business impact. The alarm content includes: abnormal description, abnormal indicator value, root cause analysis conclusion, and abnormal discovery time. For example, the abnormality of the target indicator at the P0 level is a 30% drop in DAU; the abnormality of the target indicator at the P1 level is a 20% drop in play rate, etc.

[0062] In this embodiment, a log file collector is responsible for collecting raw logs from machine log files in real time. After the collected data is written to a data warehouse such as Hive, SQL is generated using preset rules for multi-dimensional verification and analysis (such as month-on-month verification) to identify potential anomalies. Upon detecting an anomaly, an AI model is activated for root cause analysis to quickly locate the source of the problem (such as a program bug or human error). Finally, the system automatically classifies the anomaly based on the root cause and triggers tiered alarms (such as P0 / P1 / P2), notifying the responsible personnel via email, internal communication software, and instant messaging, achieving differentiated responses.

[0063] This application provides an open platform data feedback system that constructs a comprehensive data quality management system covering pre-verification, real-time alerting, and post-analysis. By introducing a rule engine to perform real-time streaming analysis of core indicators, it can accurately identify and classify data anomalies and trigger corresponding tiered alert mechanisms. The system deeply integrates the intelligent analysis capabilities of AI large-scale models, achieving automated verification, anomaly detection, and intelligent processing of feedback data. This design significantly improves the accuracy and reliability of the data feedback process while greatly reducing reliance on manual verification, effectively achieving cost reduction and efficiency improvement, and providing high-quality assurance for data-driven business decisions.

[0064] This disclosure provides a full-chain automated management architecture, constructing a comprehensive, integrated quality management system covering the entire process from pre-reporting (pre-verification), during reporting (in-process alerting), to post-reporting (post-analysis), achieving closed-loop management from entry point to analysis. Furthermore, it deeply integrates the intelligent analysis capabilities of AI big data models for real-time anomaly detection, data anti-counterfeiting identification, and automatic diagnosis of anomaly root causes, replacing manual experience-based judgment. Further, it sets up a real-time rule engine and tiered alerts, using the rule engine to perform real-time streaming analysis and verification of core indicators, automatically classifying abnormal data, and triggering different levels of tiered alerts for in-process intervention. This application also includes a standardization and intelligent diagnostic mechanism: establishing unified data specifications and automated verification standards to enforce consistency of reported data; and using intelligent analysis to automatically locate and analyze the root causes of anomalies.

[0065] In summary, the embodiments of this disclosure provide a data processing method. By setting a real-time review mechanism during data reporting, once abnormal data is identified during the data reporting process, the corresponding target anomaly level can be determined based on the target application data. Based on the processing plan corresponding to the target anomaly level, the target application data can be processed, thereby achieving immediate detection and early warning of abnormal data, enabling in-process intervention and pre-emptive data control, which helps ensure data quality. By ensuring data quality, the adverse effects of erroneous data on core businesses such as user behavior analysis and business recommendations can be effectively avoided, thereby improving the stability and accuracy of data-based analysis of various core businesses.

[0066] This embodiment also provides a data processing device, which can be specifically integrated into a terminal device. For example, such as Figure 7 As shown, the data processing device may include: The response unit 201 is configured to respond to a data reporting request for a target application, and based on the target application scenario to which the target application data of the target application belongs in the data reporting request, to select a target scenario review rule that matches the target application scenario from multiple preset scenario review rules, and the data reporting request is used to request that the target application data be stored in the log corresponding to the target application; The review unit 202 is used to review the target application data based on the target scenario review rules to obtain the review result of the target application data; The first determining unit 203 is used to determine the target application data type to which the target application data belongs if the audit result is data anomaly. The second determining unit 204 is used to determine the target anomaly level of the target application data based on the preset anomaly identification conditions corresponding to the target application data type. The processing unit 205 is used to process the target application data based on the processing scheme corresponding to the target anomaly level.

[0067] In some embodiments, the data processing apparatus includes a processing subunit for: Based on the preset anomaly identification conditions corresponding to the target application data type, determine the degree of impact of the target application data on the target application. The target anomaly level of the target application data is determined based on the degree of impact of the target.

[0068] In some embodiments, the data processing apparatus includes a processing subunit for: Based on the degree of impact of the target, the target anomaly level and target anomaly alarm information of the target application data are determined.

[0069] In some embodiments, the data processing apparatus includes a processing subunit for: Based on the target anomaly level, determine the information prompting channel for the target anomaly alarm information, so as to output the target anomaly alarm information through the information prompting channel.

[0070] In some embodiments, the data processing apparatus includes a processing subunit for: If the audit result is that the data is normal, the target application data is stored in the first data log, which is used to store application data for which the audit result is normal.

[0071] In some embodiments, the data processing apparatus includes a processing subunit for: Based on the processing scheme corresponding to the target anomaly level, the target application data is stored in the second data log, which is used to store application data whose audit result is data anomaly.

[0072] In some embodiments, the processing scheme includes a first processing scheme and a second processing scheme, wherein the first processing scheme is used to indicate that the target application data is not stored in the log corresponding to the target application; and the second processing scheme is used to indicate that the target application data is stored in the second data log corresponding to the target application.

[0073] In some embodiments, the data processing apparatus includes a processing subunit for: If the target anomaly level meets the preset level conditions, then the processing solution corresponding to the target anomaly level is determined to be the first processing solution; If the target anomaly level does not meet the preset level conditions, then the processing scheme corresponding to the target anomaly level is determined to be the second processing scheme.

[0074] In some embodiments, the data processing apparatus includes a processing subunit for: Obtain the target application logs and at least one data verification rule of the target application; The data verification rules are used to verify each application data in the target application log to obtain the verification results corresponding to each application data under each data verification rule. Based on the verification results, filter out abnormal application data whose verification results are abnormal from the target application logs; The abnormal application data is analyzed using the target model to obtain data analysis results; Based on the data analysis results, determine the target alarm level and target alarm content for the abnormal application data; The target alarm level and the target alarm content are output through the information notification channel corresponding to the target alarm level.

[0075] This disclosure provides a data processing apparatus. A response unit 201 responds to a data reporting request for a target application. Based on the target application scenario to which the target application data belongs in the data reporting request, a target scenario review rule matching the target application scenario is selected from multiple preset scenario review rules. The data reporting request requests that the target application data be stored in the log corresponding to the target application. An review unit 202 reviews the target application data based on the target scenario review rule to obtain a review result. A first determination unit 203, if the review result indicates data anomaly, determines the target application data type to which the target application data belongs. A second determination unit 204, based on preset anomaly identification conditions corresponding to the target application data type, determines the target anomaly level of the target application data. A processing unit 205 processes the target application data based on a processing scheme corresponding to the target anomaly level. This disclosure embodiment can establish a real-time review mechanism during data reporting. Once abnormal data is identified during the data reporting process, the corresponding target anomaly level can be determined based on the target application data. Based on the processing plan corresponding to the target anomaly level, the target application data can be processed, thereby achieving immediate detection and early warning of abnormal data and enabling in-process intervention. This allows for proactive data control and helps ensure data quality. By ensuring data quality, the adverse effects of erroneous data on core businesses such as user behavior analysis and business recommendations can be effectively avoided, thereby improving the stability and accuracy of data-driven analysis of various core businesses.

[0076] Accordingly, this disclosure also provides an electronic device, which can be a terminal, such as a smartphone, tablet computer, laptop computer, touch screen, game console, personal computer (PC), personal digital assistant (PDA), or other terminal device. Alternatively, the electronic device can be a server.

[0077] like Figure 8 As shown, Figure 8This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. The electronic device 300 includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored in the memory 302 and executable on the processor. The processor 301 and the memory 302 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0078] The processor 301 is the control center of the electronic device 300. It connects various parts of the electronic device 300 via various interfaces and lines. By running or loading software programs and / or units stored in the memory 302, and by calling data stored in the memory 302, it executes various functions and processes data of the electronic device 300, thereby providing overall monitoring of the electronic device 300. The processor 301 can be a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), etc., and can implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this disclosure.

[0079] In this embodiment of the disclosure, the processor 301 in the electronic device 300 loads the instructions corresponding to the processes of one or more applications into the memory 302 according to the following steps, and the processor 301 runs the applications stored in the memory 302 to realize various functions, such as: In response to a data reporting request for a target application, based on the target application scenario to which the target application data of the target application in the data reporting request belongs, a target scenario review rule matching the target application scenario is selected from multiple preset scenario review rules. The data reporting request is used to request that the target application data be stored in the log corresponding to the target application. The target application data is reviewed based on the target scenario review rules to obtain the review result of the target application data; If the audit result indicates data anomaly, determine the target application data type to which the target application data belongs; Based on the preset anomaly identification conditions corresponding to the target application data type, the target anomaly level of the target application data is determined; Based on the processing scheme corresponding to the target anomaly level, the target application data is processed.

[0080] The electronic device provided in this disclosure can set a real-time review mechanism when reporting data. Once abnormal data is identified during the data reporting process, the corresponding target abnormality level can be determined based on the target application data. Based on the processing scheme corresponding to the target abnormality level, the target application data can be processed, thereby realizing the immediate detection and early warning of abnormal data and enabling in-process intervention. This allows for proactive data control and helps ensure data quality. By ensuring data quality, the adverse effects of erroneous data on core businesses such as user behavior analysis and business recommendations can be effectively avoided, thereby improving the stability and accuracy of data-based analysis of various core businesses.

[0081] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0082] Optional, such as Figure 8 As shown, the electronic device 300 also includes: a touch display screen 303, a radio frequency circuit 304, an audio circuit 305, an input unit 306, and a power supply 307. The processor 301 is electrically connected to the touch display screen 303, the radio frequency circuit 304, the audio circuit 305, the input unit 306, and the power supply 307. Those skilled in the art will understand that... Figure 8 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0083] The touch display screen 303 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 303 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 301. It can also receive and execute commands from the processor 301. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 301 to determine the type of touch event. Subsequently, the processor 301 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the touch display screen 303 to achieve input and output functions. However, in some embodiments, the touch panel and the touch display screen 303 can be implemented as two independent components to achieve input and output functions. That is, the touch display screen 303 can also be used as part of the input unit 306 to achieve input functions.

[0084] The radio frequency circuit 304 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices.

[0085] Audio circuitry 305 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuitry 305 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 305, converted back into audio data, and then processed by processor 301 before being transmitted via radio frequency circuitry 304 to, for example, another electronic device, or output to memory 302 for further processing. Audio circuitry 305 may also include an earphone jack to facilitate communication between peripheral headphones and electronic devices.

[0086] The input unit 306 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0087] Power supply 307 is used to supply power to various components of electronic device 300. Optionally, power supply 307 can be logically connected to processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 307 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0088] although Figure 8 As not shown in the diagram, the electronic device 300 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0089] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0090] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0091] Therefore, embodiments of this disclosure provide a computer-readable storage medium storing a plurality of computer programs, which can be loaded by a processor to execute any of the data processing methods provided in embodiments of this disclosure. The computer program can execute the steps of the following data processing method: In response to a data reporting request for a target application, based on the target application scenario to which the target application data of the target application in the data reporting request belongs, a target scenario review rule matching the target application scenario is selected from multiple preset scenario review rules. The data reporting request is used to request that the target application data be stored in the log corresponding to the target application. The target application data is reviewed based on the target scenario review rules to obtain the review result of the target application data; If the audit result indicates data anomaly, determine the target application data type to which the target application data belongs; Based on the preset anomaly identification conditions corresponding to the target application data type, the target anomaly level of the target application data is determined; Based on the processing scheme corresponding to the target anomaly level, the target application data is processed.

[0092] Because the computer program stored in this storage medium can set up a real-time auditing mechanism when data is reported, once abnormal data is identified during the data reporting process, the corresponding target anomaly level can be determined based on the target application data. Based on the processing plan corresponding to the target anomaly level, the target application data can be processed, thereby achieving immediate detection and early warning of abnormal data, enabling in-process intervention of abnormal data, and allowing for pre-emptive data control, which helps to ensure data quality. By ensuring data quality, the adverse effects of erroneous data on core businesses such as user behavior analysis and business recommendations can be effectively avoided, thereby improving the stability and accuracy of data-based analysis of various core businesses.

[0093] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0094] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0095] Since the computer program stored in the computer-readable storage medium can execute any of the data processing methods provided in the embodiments of this disclosure, the beneficial effects that any of the data processing methods provided in the embodiments of this disclosure can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0096] According to one aspect of this disclosure, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in the various optional implementations of the above embodiments.

[0097] In the above embodiments of the data processing apparatus, computer-readable storage medium, electronic device, and computer program product, the descriptions of each embodiment have different focuses. Parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes and beneficial effects of the data processing apparatus, computer-readable storage medium, computer program product, electronic device, and their corresponding units described above can be referred to the description of the data processing methods in the above embodiments, and will not be repeated here.

[0098] The foregoing has provided a detailed description of a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product provided by the embodiments of this disclosure. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this disclosure. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this disclosure. Therefore, the content of this specification should not be construed as a limitation of this disclosure.

Claims

1. A data processing method, characterized in that, include: In response to a data reporting request for a target application, based on the target application scenario to which the target application data of the target application in the data reporting request belongs, a target scenario review rule matching the target application scenario is selected from multiple preset scenario review rules. The data reporting request is used to request that the target application data be stored in the log corresponding to the target application. The target application data is reviewed based on the target scenario review rules to obtain the review result of the target application data; If the audit result indicates data anomaly, determine the target application data type to which the target application data belongs; Based on the preset anomaly identification conditions corresponding to the target application data type, the target anomaly level of the target application data is determined; Based on the processing scheme corresponding to the target anomaly level, the target application data is processed.

2. The method according to claim 1, characterized in that, The step of determining the target anomaly level of the target application data based on preset anomaly identification conditions corresponding to the target application data type includes: Based on the preset anomaly identification conditions corresponding to the target application data type, determine the degree of impact of the target application data on the target application. The target anomaly level of the target application data is determined based on the degree of impact of the target.

3. The method according to claim 2, characterized in that, Determining the target anomaly level of the target application data based on the target impact level includes: Based on the degree of impact of the target, the target anomaly level and target anomaly alarm information of the target application data are determined.

4. The method according to claim 3, characterized in that, After determining the target anomaly level and target anomaly alarm information of the target application data based on the target impact level, the method further includes: Based on the target anomaly level, determine the information prompting channel for the target anomaly alarm information, so as to output the target anomaly alarm information through the information prompting channel.

5. The method according to claim 1, characterized in that, After reviewing the target application data based on the target scenario review rules to obtain the review result of the target application data, the method further includes: If the audit result is that the data is normal, the target application data is stored in the first data log, which is used to store application data for which the audit result is normal.

6. The method according to claim 1, characterized in that, The processing scheme based on the target anomaly level, which processes the target application data, includes: Based on the processing scheme corresponding to the target anomaly level, the target application data is stored in the second data log, which is used to store application data whose audit result is data anomaly.

7. The method according to claim 1, characterized in that, The processing scheme includes a first processing scheme and a second processing scheme. The first processing scheme is used to indicate that the target application data is not stored in the log corresponding to the target application. The second processing scheme is used to indicate that the target application data is stored in the second data log corresponding to the target application.

8. The method according to claim 7, characterized in that, After determining the target anomaly level of the target application data based on preset anomaly identification conditions corresponding to the target application data type, the method further includes: If the target anomaly level meets the preset level conditions, then the processing solution corresponding to the target anomaly level is determined to be the first processing solution; If the target anomaly level does not meet the preset level conditions, then the processing scheme corresponding to the target anomaly level is determined to be the second processing scheme.

9. The method according to claim 1, characterized in that, The method further includes: Obtain the target application logs and at least one data verification rule of the target application; The data verification rules are used to verify each application data in the target application log to obtain the verification results corresponding to each application data under each data verification rule. Based on the verification results, filter out abnormal application data whose verification results are abnormal from the target application logs; The abnormal application data is analyzed using the target model to obtain data analysis results; Based on the data analysis results, determine the target alarm level and target alarm content for the abnormal application data; The target alarm level and the target alarm content are output through the information notification channel corresponding to the target alarm level.

10. A data processing apparatus, characterized in that, include: The response unit is used to respond to a data reporting request for a target application, and based on the target application scenario to which the target application data of the target application in the data reporting request belongs, to filter out the target scenario review rules that match the target application scenario from multiple preset scenario review rules. The data reporting request is used to request that the target application data be stored in the log corresponding to the target application. An auditing unit is used to audit the target application data based on the target scenario auditing rules to obtain the auditing result of the target application data; The first determining unit is used to determine the target application data type to which the target application data belongs if the audit result is data anomaly. The second determining unit is used to determine the target anomaly level of the target application data based on the preset anomaly identification conditions corresponding to the target application data type. The processing unit is used to process the target application data based on the processing scheme corresponding to the target anomaly level.

11. An electronic device, characterized in that, The device includes a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to perform the steps of the data processing method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the data processing method as described in any one of claims 1 to 9.

Images