Data storage method and device, electronic equipment and storage medium

Abstract

The invention discloses a data storage method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining risk control event data corresponding to a target risk control event, determining core field data, event index field data and event detail data corresponding to the risk control event data, and storing the core field data, the event index field data and the event detail data at a first moment; storing the core field data, the event index field data and the event detail data in a recent query database at a first moment, compressing the event detail data at a second moment to obtain event detail compressed data, storing the event detail compressed data and a mapping relationship in a middle-term query database, and storing the event detail compressed data and the mapping relationship in a third moment to obtain a middle-term query database; and determining an event type of the target risk control event, and storing the event detail compressed data to a partition corresponding to the event type in a long-term query database. By adopting the embodiment of the invention, the storage efficiency of the risk control event is improved.

Description

Technical Field

[0001] The present invention relates to the field of data storage technology, and in particular to a data storage method, device, electronic device and storage medium. Background Art

[0002] In risk control systems, with the expansion of business scale and the increasing complexity of risk scenarios, risk control event data is experiencing explosive growth. Traditional data storage methods face problems such as high storage costs, low query efficiency, and chaotic data management. On the one hand, using high-cost real-time storage media for large amounts of risk control event data results in a significant waste of storage resources. On the other hand, the lack of hierarchical management of data with varying timeliness and importance makes it difficult to quickly locate target information during data queries, hindering the efficiency of risk control decision-making. Therefore, improving the storage efficiency of risk control events is an urgent issue that needs to be addressed. Summary of the Invention

[0003] The embodiments of the present application provide a data storage method, device, electronic device, and storage medium, which improve the storage efficiency of risk control events.

[0004] In a first aspect, embodiments of the present application provide a data storage method, comprising:

[0005] Obtaining risk control event data corresponding to a target risk control event; the time when the target risk control event occurs is the first moment;

[0006] Determine the core field data, event index field data, and event detail data corresponding to the risk control event data;

[0007] At the first moment, storing the core field data, the event index field data, and the event detail data in a recent query database;

[0008] At a second moment, the core field data and the event detail data are acquired from the recent query database; the second moment is after the first moment;

[0009] Compressing the event detail data to obtain event detail compressed data;

[0010] Determine a mapping relationship between a core field and the target risk control event based on the core field data and the event detail compressed data;

[0011] Storing the compressed event details data and the mapping relationship in a mid-term query database;

[0012] Deleting the core field data, the event index field data, and the event detail data in the recent query database;

[0013] At a third moment, obtaining the event detail compressed data from the mid-term query database;

[0014] Determining the event type of the target risk control event; the third moment is after the second moment;

[0015] The event details are compressed and stored in a partition corresponding to the event type in a future query database;

[0016] The event detail compressed data and the mapping relationship in the mid-term query database are deleted.

[0017] In a second aspect, an embodiment of the present application provides a data storage device, the device comprising: an acquisition unit and a processing unit;

[0018] The acquisition unit acquires risk control event data corresponding to a target risk control event; the time when the target risk control event occurs is the first time;

[0019] The processing unit is configured to determine core field data, event index field data, and event detail data corresponding to the risk control event data;

[0020] At the first moment, storing the core field data, the event index field data, and the event detail data in a recent query database;

[0021] At a second moment, the core field data and the event detail data are acquired from the recent query database; the second moment is after the first moment;

[0022] Compressing the event detail data to obtain event detail compressed data;

[0023] Determine a mapping relationship between a core field and the target risk control event based on the core field data and the event detail compressed data;

[0024] Storing the compressed event details data and the mapping relationship in a mid-term query database;

[0025] Deleting the core field data, the event index field data, and the event detail data in the recent query database;

[0026] At a third moment, obtaining the event detail compressed data from the mid-term query database;

[0027] Determining the event type of the target risk control event; the third moment is after the second moment;

[0028] The event details are compressed and stored in a partition corresponding to the event type in a future query database;

[0029] The event detail compressed data and the mapping relationship in the mid-term query database are deleted.

[0030] In a third aspect, an embodiment of the present invention provides an electronic device comprising: a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor so that the electronic device performs the method of the first aspect.

[0031] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program is executed by a processor to implement the method of the first aspect.

[0032] In a fifth aspect, an embodiment of the present invention provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, so that a computer executes the method of the first aspect.

[0033] The implementation of the present invention has the following beneficial effects:

[0034] It can be seen that the data storage method described in the embodiment of the present invention obtains the risk control event data corresponding to the target risk control event, the time when the target risk control event occurs is the first time, and determines the core field data, event index field data and event detail data corresponding to the risk control event data. At the first time, the core field data, the event index field data and the event detail data are stored in the recent query database. At the second time, the core field data and the event detail data are obtained from the recent query database; the second time is after the first time, the event detail data is compressed to obtain event detail compressed data, and based on the core field data and the event The compressed details data determines the mapping relationship between the core field and the target risk control event, stores the compressed event details data and the mapping relationship in the mid-term query database, deletes the core field data, the event index field data, and the event details data in the recent query database, and obtains the compressed event details data from the mid-term query database at a third moment; the third moment is after the second moment, determines the event type of the target risk control event, stores the compressed event details data in the partition corresponding to the event type in the long-term query database, deletes the compressed event details data and the mapping relationship in the mid-term query database, and improves the storage efficiency of risk control events. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the implementation methods or background technologies of the present application, the drawings required for use in the implementation methods or background technologies of the present application will be described below.

[0036] Figure 1 This is a flow chart of a data storage method provided by an embodiment of the present application;

[0037] Figure 2 This is a flow chart for determining a risk warning value provided by an embodiment of the present application;

[0038] Figure 3 This is a flow chart for determining a risk warning value for a target risk control event provided by an embodiment of the present application;

[0039] Figure 4 This is a flow chart for determining risk levels provided by an embodiment of the present application;

[0040] Figure 5 This is a schematic diagram of a mapping table of risk assessment values ​​and risk levels provided in an embodiment of the present application;

[0041] Figure 6 This is a flow chart of a data query method provided by an embodiment of the present application;

[0042] Figure 7 This is a structural diagram of a data storage device provided in an embodiment of the present application;

[0043] Figure 8 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] In order to enable those skilled in the art to better understand the present invention, the following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0045] The terms "first," "second," and the like in the specification and claims of this application and the accompanying drawings are used to distinguish between different objects, not to describe a particular order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.

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

[0047] See also Figure 1 , Figure 1 This is a flowchart of a data storage method provided by an embodiment of the present application, including but not limited to the following steps:

[0048] S101: Obtain risk control event data corresponding to a target risk control event.

[0049] In this embodiment, the moment when the target risk control event occurs is the first moment. Risk control events refer to abnormal behaviors or potential threats that may pose risks to enterprises or users in the fields of finance, Internet, e-commerce, etc. Risk control events mainly include account security risk control events, transaction risk risk control events, fraud risk control events, compliance risk risk control events, equipment and environment risk risk control events, and business anomaly risk control events. Account security risk control events mainly include abnormal login events, password reset abnormal events, and account information modification events; transaction risk risk control events mainly include large-value transaction events, high-frequency transaction events, cross-regional or cross-border transaction events, and abnormal transaction object events; fraud risk control events mainly include false identity registration events and phishing attack events; compliance risk risk control events mainly include fraud-related account events and gambling-related account events; equipment and environment risk risk control events mainly include equipment risk events and network environment risk events; business anomaly risk control events mainly include data anomaly events, crawler attack events, and automated attack events.

[0050] Risk control event data primarily includes core field data, event index field data, and event detail data. Core field data includes user ID, event ID, and risk indicators; event index field data includes data on time, space, and behavior dimensions; and event detail data includes transaction details, operation logs, device environment, and contextual information.

[0051] S102: Determine core field data, event index field data, and event detail data corresponding to the risk control event data.

[0052] In this embodiment, the core field data is the field that directly identifies the event subject and key attributes, and is usually unique and stable. The event index field data is used to quickly retrieve and filter the dimension fields of the event and support efficient queries. The event detail data contains fields for the complete context and details of the event, and usually has a large amount of data.

[0053] S103: At the first moment, the core field data, the event index field data, and the event detail data are stored in a recent query database.

[0054] In this embodiment, the risk warning value of the target risk control event is first determined based on the core field data. Figure 2 , Figure 2 This is a flow chart for determining a risk warning value provided by an embodiment of the present application, including but not limited to the following steps:

[0055] S201: Determine the transaction amount, number of historical account violations, and transaction duration corresponding to the target risk control event based on the core field data.

[0056] In this embodiment, the transaction amount directly reflects the capital risk exposure, the number of historical account violations reflects the user's historical risk profile, and abnormal transaction duration may indicate risk.

[0057] The size of the transaction amount is an intuitive indicator of risk assessment. Large transactions themselves may be accompanied by a higher risk of abnormal capital flow, such as fraudulent cash withdrawal. When the amount exceeds the normal threshold, the first risk warning value will increase significantly, directly pushing up the overall risk warning value.

[0058] The number of historical violations of an account reflects the account's risk "criminal record". If an account has frequently violated regulations in the past (such as false transactions, malicious overdrafts, etc.), it means that the account is a high-risk entity and is more likely to trigger violations again. The second risk warning value will accumulate and increase due to historical records, providing a "historical basis" for the overall risk.

[0059] Abnormal transaction duration may indicate risk. For example, normal transactions usually have a reasonable time range. If the transaction duration is extremely short or long, the third risk warning value will increase due to the abnormality of the time dimension, revealing potential problems in the operation process.

[0060] S202: Determine a first risk warning value corresponding to the transaction amount, a second risk warning value corresponding to the number of historical account violations, and a third risk warning value corresponding to the transaction duration.

[0061] In this embodiment, it may be a preset first mapping relationship between the transaction amount and the risk warning value, and the first risk warning value corresponding to the transaction amount may be determined based on the first mapping relationship.

[0062] It may be a preset second mapping relationship between the number of historical account violations and the risk warning value, and the second risk warning value corresponding to the number of historical account violations may be determined based on the second mapping relationship.

[0063] It may be a preset third mapping relationship between transaction duration and risk warning value, and the third risk warning value corresponding to the transaction duration may be determined based on the third mapping relationship.

[0064] By pre-establishing a mapping relationship between transaction amount, historical account violations, transaction duration and risk warning value (such as segmented threshold table, weight matrix), the corresponding score can be quickly matched when a risk control event occurs, without the need for complex real-time calculations, greatly improving risk response efficiency. At the same time, the mapping relationship rules are logically clear (such as "transaction amount exceeding 100,000 yuan corresponds to a 90-point warning"), which is easy for business personnel to understand and adjust, and can ensure that the output results are consistent when the same indicator is input, avoiding the difficulty of interpretation caused by the black box model. It is especially suitable for scenarios with high real-time and compliance requirements (such as financial transaction risk control), and also provides a clear iterative basis for subsequent optimization of mapping rules based on historical data.

[0065] S203: Determine a risk warning value of the target risk control event based on the first risk warning value, the second risk warning value, and the third risk warning value.

[0066] In this implementation, see Figure 3 , Figure 3 This is a flowchart of determining a risk warning value for a target risk control event provided by an embodiment of the present application, including but not limited to the following steps:

[0067] S301: Determine a first weight corresponding to the first risk warning value, a second weight corresponding to the second risk warning value, and a third weight corresponding to the third risk warning value.

[0068] In this embodiment, the sum of the first weight, the second weight, and the third weight is 1. The first weight is the impact ratio of transaction amount risk, the second weight is the impact ratio of account history violation risk, and the third weight is the impact ratio of transaction duration risk.

[0069] It can be a mapping relationship between preset risk warning values ​​and weights. Based on the mapping relationship, the first weight corresponding to the first risk warning value and the second weight corresponding to the second risk warning value can be determined. After determining the first weight and the second weight, since the sum of the first weight, the second weight and the third weight is 1, the third weight can be determined based on the first weight and the second weight.

[0070] The impact of various risk indicators varies across different business scenarios. For example, in financial transactions, the transaction amount may be more critical than the transaction duration. In this case, assigning a higher weight to the "first risk warning value" allows risk assessments to better align with actual business logic. Dynamically adjusting weights allows adaptation to risk control strategies over time. For example, if frequent account violations are detected, increasing the "second weight" can enhance sensitivity to historical violation records and improve the specificity of risk identification. The essence of weight allocation is to transform multi-dimensional risk indicators into calculable quantitative relationships, ensuring that the impact of each indicator is objectively integrated into the final risk value in the form of "weights." This prevents a single indicator from dominating the assessment results, making risk warnings more comprehensive and accurate.

[0071] S302: Calculate based on the first risk warning value, the second risk warning value, the third risk warning value, the first weight, the second weight, and the third weight to obtain a reference risk warning value.

[0072] In this embodiment, the reference risk warning value is calculated specifically according to the following formula:

[0073] Reference risk warning value = first risk warning value × first weight + second risk warning value × second weight + third risk warning value × third weight;

[0074] According to the above formula, a reference risk warning value can be obtained by calculation based on the first risk warning value, the second risk warning value, the third risk warning value, the first weight, the second weight and the third weight.

[0075] The risk warning values ​​corresponding to the transaction amount, number of historical account violations, and transaction duration are aggregated in a weighted manner to avoid a single indicator from unilaterally dominating the risk assessment. For example, if large transactions are accompanied by high-frequency violation records, weighted calculations can amplify the comprehensive risk effect and be more in line with actual risk scenarios. The weight setting can directly reflect the priority of each indicator in the risk control system. For example, the weight of the transaction amount in financial risk control is higher than the transaction duration. The formula calculation result can accurately reflect the business logic of "large transactions require more vigilance", so that the risk value is highly consistent with business needs. The calculation logic of the weighted summation is clear and intuitive. When the risk control strategy needs to be adjusted (such as strengthening account compliance assessment), it is only necessary to modify the corresponding weight to dynamically optimize the evaluation model, and the change path of the adjusted results can be traced, which facilitates model iteration and risk strategy verification.

[0076] S303: Obtain the account password modification frequency corresponding to the target risk control event.

[0077] In this embodiment, if the frequency of account password modification is significantly higher than the historical average or the industry norm, it may indicate that after a malicious login attempt was made to the account, the attacker tampered with the password to cover up the traces, and the identity of the account owner was impersonated. The tamperer ensured control through high-frequency modification. The system triggered protective modifications after detecting abnormal logins, but such situations are usually accompanied by a security verification process and need to be judged in combination with other indicators; if the password has not been modified for a long time, it may indicate that the account owner has weak security awareness, the risk of password cracking has accumulated, the account is in a "dormant" state but is illegally used, and the modification frequency does not match the actual usage scenario.

[0078] When determining the risk warning value of the target risk control event, it is necessary to first obtain the account password modification frequency corresponding to the target risk control event.

[0079] S304: Determine an optimization factor corresponding to the account password modification frequency.

[0080] In this embodiment, it may be a mapping relationship between a preset account password modification frequency and an optimization factor, so that the optimization factor corresponding to the account password modification frequency can be determined based on the mapping relationship.

[0081] S305: Optimize the reference risk warning value based on the optimization factor to obtain the risk warning value of the target risk control event.

[0082] In this embodiment, the risk warning value is calculated specifically according to the following formula:

[0083] Risk warning value = reference risk warning value × (1 + optimization factor);

[0084] According to the above formula, the reference risk warning value can be optimized based on the optimization factor to obtain the risk warning value of the target risk control event.

[0085] It can be seen that this method of calculating risk warning values ​​achieves refinement and flexibility in risk assessment through multi-dimensional weight allocation and dynamic optimization mechanisms: first, different risk warning values ​​are assigned weights and the total is 1. Weights can be allocated differently according to the importance of risks in each dimension to ensure the dominant role of core risk indicators in the results; second, a reference risk value is obtained by weighted summation, and multi-source risk information is quantitatively integrated into a unified indicator, solving the problem of data differences in different dimensions; third, the introduction of an optimization factor corresponding to the frequency of account password modification can capture dynamic risks at the user behavior level (such as high-frequency modifications may indicate account anomalies or malicious attacks), and through the adjustment of the reference value by the factor, real-time calibration of risk assessment can be achieved; finally, this mechanism takes into account the comprehensive consideration of multi-dimensional risks, and can dynamically optimize the results through behavioral data. While improving the accuracy of risk identification, it adapts to changes in risk characteristics in different business scenarios, providing a more timely and targeted basis for risk control decisions.

[0086] It can be seen that the risk warning value determination method based on core field data achieves the systematic and scientific nature of risk control assessment through the precise extraction and quantitative integration of multi-dimensional risk indicators: First, key dimensions such as transaction amount, historical account violations, and transaction duration are extracted from the core fields. These indicators cover the transaction scale, account credit history and behavioral time characteristics, and can comprehensively reflect the risk fundamentals of the target risk control event; secondly, the risk warning value is determined for each dimension separately, and differentiated assessments can be performed according to the risk characteristics of different indicators (such as triggering a high-risk warning when the transaction amount exceeds the threshold, and the historical number of violations reflects the accumulated credit risk of the account), ensuring the accurate identification of single-dimensional risks; finally, integrating multi-dimensional warning values ​​into a unified risk warning value can comprehensively consider the superimposed impact of various risk factors, avoid the one-sidedness of single indicator evaluation, and thus more accurately locate high-risk events, provide a comprehensive and objective decision-making basis for the formulation of risk control strategies, and effectively improve the integrity and effectiveness of risk identification.

[0087] Exemplarily, when the risk warning value is higher than the preset risk warning value, a warning message is generated based on the risk control event data. The warning message is used to indicate that the target risk control event has a high risk. Specifically, when the risk warning value calculated by multi-dimensional indicators exceeds a preset risk threshold (i.e., a preset risk warning value, such as 80 points), it means that the target risk control event has a high risk. At this time, the system will extract key information (such as transaction amount, account history violation records, abnormal operation time, etc.) based on the collected risk control event data (including core fields, index fields, and detailed data, etc.) to generate structured warning information. This warning information not only intuitively presents the degree of risk, but also provides a basis for the occurrence of risks, helping risk control personnel to quickly judge the nature of the event. It can also trigger the system to automatically execute corresponding strategies, such as intercepting transactions, freezing accounts, or initiating manual reviews, thereby achieving timely response and effective control of high-risk events and reducing potential losses.

[0088] Exemplarily, at the first moment, the core field data, the event index field data, and the event detail data are stored in a recent query database. Specifically, first, an appropriate database system should be selected based on the data characteristics and query requirements. Relational databases are suitable for structured data and more user-friendly for unstructured or semi-structured data. Next, a connection to the recent query database is established using a corresponding database connection tool or library, using information such as the database server address, port, username, and password. If a corresponding table does not already exist in the database to store this data, a new table should be created, specifying the table name and the names, data types, and constraints of each field. For example, a core field should be set as the primary key to ensure data uniqueness. The specific data acquired at the first moment is then inserted into the corresponding table using relevant database operation methods in a programming language. During insertion, the data should be ensured to match the table structure. To ensure data accuracy and consistency, data validation and integrity checks can also be performed, such as checking whether the data complies with constraints and whether the value range is reasonable. Finally, to maintain database performance and stability, regular maintenance and optimization work can be performed, such as clearing useless data, deleting redundant indexes, optimizing configuration parameters, and performing data backups.

[0089] It should be explained that the risk assessment value of the target risk control event also needs to be determined based on the core field data. Specifically, the risk assessment value of the target risk control event can be determined using the indicator decomposition weighted method. First, core fields such as transaction amount and account operation frequency are decomposed into independent risk indicators. Each indicator sets a scoring threshold according to business rules (for example, a transaction amount exceeding 500,000 is 80 points). Then, weights are assigned to different indicators (amount accounts for 40% and frequency accounts for 30%). Finally, the total score is calculated by weighted sum. For example, if the transaction amount is 80 points (weight 40%) and the operation frequency is 70 points (weight 30%), the comprehensive score is 80×40%+70×30%=53 points, which is used as the risk assessment value.

[0090] You can also use pre-built decision tree models to apply rule-based judgments to core fields. For example, "If the transaction amount exceeds 100,000 yuan and the transaction location is not a common location, add 60 points to the risk score; if the number of historical violations is ≥ 2, add another 30 points." This allows for multiple layers of nested conditions to map to the final score. For example, if an event triggers an amount exceeding 100,000 yuan and two violations, the risk assessment value is 60 + 30 = 90 points. This allows for direct rule combination to yield the final result.

[0091] Historical risk control event data can also be used to train models such as random forests and neural networks. By using core fields as input features, the model automatically learns the importance weights and nonlinear relationships between each field. For example, by inputting fields such as transaction amount, time interval, and address change, the model outputs a probability value from 0 to 100 as the risk assessment score. For example, an output of 0.85 corresponds to a score of 85. This method relies on data training and can capture hidden risk patterns.

[0092] For example, the risk level of the target risk control event is determined based on the risk assessment value, and the risk level includes any one of the following: high risk level, medium risk level, and low risk level. Figure 4 , Figure 4 This is a flow chart for determining risk levels provided by an embodiment of the present application, including but not limited to the following steps:

[0093] S401: When the risk assessment value is greater than or equal to a first threshold, determining that the risk level of the target risk control event is a high risk level.

[0094] In this embodiment, the first threshold is the critical value for classifying high risk, which is usually determined by business experience or historical data. For example, it is set to 80 points. If the risk assessment value of an event is 85 points (greater than 80), it is directly judged as a "high risk level", which means that the event may have serious violations or fraud risks, and high-intensity risk control measures need to be triggered immediately.

[0095] High-intensity risk control measures may include suspending all operating permissions such as login, transfer, and payment of the target account to prevent risky behaviors from continuing (such as freezing the account when a malicious login is detected); directly intercepting ongoing high-risk transactions (such as large transfers, consumption in abnormal locations) to avoid capital losses (for example, terminating the transaction when a single transaction exceeds 500,000 and the location is abnormal); temporarily reducing account permissions based on risk levels, such as reducing the large transaction limit from 1 million to 10,000, or prohibiting cross-border payment functions, requiring users to re-verify their identities through multiple methods such as "SMS verification code plus fingerprint plus face scan" to confirm the legitimacy of the operation (for example, logging in from a different location The incident can be submitted to the risk control review team, which can manually review transaction vouchers, account history and other information to determine whether it is fraud (for example, large transfers from unfamiliar accounts require uploading of transaction contracts); the transaction page can be automatically captured and communication records can be saved to form an electronic evidence package to provide support for subsequent disputes or judicial proceedings; high-risk reminders can be sent to users via SMS, software push, phone calls, etc., requiring confirmation of operations (such as notifying users immediately when account theft is detected); risk information can be synchronized with other risk control systems in real time to prevent the same entity from continuing to commit crimes in other scenarios (for example, after an account is marked, related accounts will be synchronized with warnings).

[0096] S402: When the risk assessment value is less than the first threshold and greater than the second threshold, determine that the risk level of the target risk control event is a medium risk level.

[0097] In this embodiment, the second threshold is lower than the first threshold. The second threshold is the dividing line between medium and low risk and must be lower than the first threshold (for example, if the first threshold is 80 points, the second threshold is set to 40 points). If the assessment score is 50 points (between 40 and 80), it is determined to be a "medium risk level." Such events carry a certain degree of risk, but the degree is relatively low, and require manual intervention and verification (for example, requiring the target person to confirm the legitimacy of the transaction). Only after verification is passed will subsequent processes such as data storage be carried out.

[0098] S403: When the risk assessment value is less than or equal to the second threshold, determining that the risk level of the target risk control event is a low risk level.

[0099] In this embodiment, as long as the evaluation value is less than the second threshold (for example, less than 40 points), it can be judged as low risk, indicating that the risk level of the event is extremely low and it is likely to be a normal business behavior. No additional verification or alarm is required. The core fields, event index and detailed data are directly stored in the recent query database according to the normal process for subsequent query or analysis.

[0100] See also Figure 5 , Figure 5This is a schematic diagram of a mapping table of risk assessment values ​​and risk levels provided in an embodiment of the present application.

[0101] exist Figure 5 In the risk assessment value and risk level mapping table 500, a plurality of risk levels and a corresponding risk assessment value range for each of the plurality of risk levels are included, wherein the risk levels include a high risk level, a medium risk level, and a low risk level. The risk assessment value range corresponding to the high risk level is greater than or equal to a first threshold, the risk assessment value range corresponding to the medium risk level is less than the first threshold and greater than a second threshold, and the risk assessment value range corresponding to the low risk level is less than or equal to a second threshold. The second threshold is less than the first threshold.

[0102] Exemplarily, when the risk level is the high risk level, high-risk alarm information is generated based on the risk control event data, and the step of storing the core field data, the event index field data, and the event detail data in the recent query database at the first moment is not performed.

[0103] High-risk alarm information usually needs to include key content that can clearly reflect the overall picture of the risk event and facilitate rapid response. It generally covers: basic identification of risk control events (such as event number, occurrence time, and account / subject information involved), core conclusions of risk assessment (such as risk assessment value, clear marking of "high risk level"), specific descriptions of risk characteristics (such as triggered risk rules, abnormal transaction amount / frequency / location and other core field data), recommended disposal measures (such as immediate account freezing, transaction termination and other high-intensity risk control operation guidelines), and auxiliary information related to the event, so as to form complete and warning risk notification content, and provide a clear basis for subsequent emergency response.

[0104] Exemplarily, when the risk level is the medium risk level, verification information is generated based on the risk control event data; the verification information is used for verification of the target personnel, and after the verification is passed, the step of storing the core field data, the event index field data, and the event details data in the recent query database at the first moment is continued.

[0105] Exemplarily, when the risk level is the low risk level, the step of storing the core field data, the event index field data, and the event detail data in a recent query database at the first moment is performed.

[0106] It can be seen that such a risk control process achieves a dynamic balance between risk management and business efficiency through differentiated responses to risk levels. Specifically, for high-risk events, data storage is skipped and alarm information is directly generated, triggering high-intensity measures. This can not only avoid processing delays caused by the retention of risk information, but also prioritize resources for intercepting serious risks (such as fraudulent transactions) to prevent losses from expanding. At the medium-risk level, data storage is required after the target personnel have passed verification. This not only reduces the misjudgment rate through manual review (avoiding normal business from being mistakenly intercepted), but also ensures that the data of events that have passed verification is traceable, providing a basis for subsequent analysis. Direct storage of data for low-risk events ensures the efficient flow of routine business and reduces unnecessary review links. This hierarchical processing model not only improves risk control accuracy through "fast interception of high-risk, strict verification of medium-risk, and less intervention of low-risk", but also reasonably allocates storage resources and processing priorities based on the degree of risk, thereby minimizing the impact on normal business while ensuring security, and realizing refined and intelligent management of risk prevention and control.

[0107] S104: At a second moment, the core field data and the event detail data are obtained from the recent query database.

[0108] In this embodiment, the second moment is after the first moment. After the first moment of the event (the second moment), core field data and event detail data are extracted from a high-performance recent query database. The recent database stores real-time data to ensure that the acquired data is up-to-date and complete, supporting the accuracy of subsequent processing. Only necessary fields (core fields plus detail data, omitting index fields) are extracted, reducing data transmission and processing overhead.

[0109] S105: Compress the event detail data to obtain compressed event detail data.

[0110] In this embodiment, a compression algorithm is used to compress event detail data to reduce the data volume. Detail data usually accounts for a large proportion (such as log text and binary data). After compression, 50%-80% of storage space can be saved, reducing mid-term library storage costs. The compressed data takes less time to transmit over the network or write to the database, thereby improving overall processing efficiency.

[0111] S106: Determine a mapping relationship between the core field and the target risk control event based on the core field data and the event detail compressed data.

[0112] In this embodiment, an association relationship between core fields and target risk control events is established to form a structured mapping. The mapping relationship is equivalent to a data index. Subsequently, the corresponding event details can be quickly located through the core fields to compress data, improve query efficiency, and clarify the correspondence between core indicators and the overall picture of the event, which is convenient for subsequent analysis (such as statistics on the distribution of event types corresponding to "large transactions").

[0113] S107: Storing the compressed event detail data and the mapping relationship in a mid-term query database.

[0114] In this embodiment, the compressed detailed data and mapping relationships are written into the mid-term query database. The storage period is usually several weeks to several months. The mid-term database has moderate performance and low cost, and is suitable for storing processed historical data. It avoids the performance degradation of the recent database due to data backlog, and provides data support for non-real-time scenarios (such as manual review and monthly risk control reports) without affecting the real-time business of the recent database.

[0115] S108: Delete the core field data, the event index field data, and the event detail data in the recent query database.

[0116] In this embodiment, all original data (core fields, index fields, and detail data) that have been migrated to the mid-term database are deleted from the recent query database. The recent database only retains the latest event data to ensure that it continues to support high-frequency reading and writing (such as real-time storage of new risk control events), reduce the amount of data in the database, avoid time-consuming full table scans, and ensure that the query response time for new events is maintained at the millisecond level.

[0117] It can be seen that the benefit of doing so is that multiple optimizations of data management efficiency, storage costs and system performance are achieved through phased data processing and storage strategies. Specifically, obtaining core field data and event detail data from the recent query database at the second moment can ensure timely extraction of key information after the event occurs, laying the foundation for subsequent processing, while avoiding the backlog of recent library data affecting real-time storage performance; compressing event detail data can significantly reduce data volume, reduce storage costs of mid-term query databases, and improve data transmission efficiency; establishing a mapping relationship based on core field data and compressed detail data is equivalent to building a structured index for the data, which facilitates the subsequent rapid location of related event details through core fields, enhancing the convenience and accuracy of data retrieval; combining compressed data with mapping Relationships are stored in the mid-term database, achieving the separation of hot and cold data. The mid-term database can undertake non-real-time query needs (such as historical risk control event analysis, manual review, etc.), while the recent database only retains the latest data to ensure response speed in high-frequency read and write scenarios; finally, deleting the original data in the recent database can release storage resources, avoid the decline in query efficiency caused by data redundancy, and allow the recent database to continue to focus on real-time storage and fast access to new events. The entire process uses hierarchical storage, compression processing, index construction and data cleaning to ensure data traceability while optimizing system resource allocation and balancing real-time requirements with the cost-effectiveness of long-term data management.

[0118] S109: At the third moment, the event detail compressed data is obtained from the mid-term query database.

[0119] In this embodiment, the third moment is after the second moment. At the third moment, which is chronologically later than the second moment, the compressed event detail data (i.e., the "compressed event detail data" generated by the second moment) is extracted from the mid-term query database to ensure the timing of data processing, avoid premature operations before the mid-term data has been compressed and mapped, and ensure data integrity and consistency of processing logic. At this time, the mid-term database has completed temporary storage of non-real-time data. The extraction operation at the third moment complies with the "hot and cold data hierarchical management" strategy and does not affect the mid-term database's support for other non-real-time queries.

[0120] S1010: Determine the event type of the target risk control event.

[0121] In this embodiment, the target risk control events are classified and their event types (such as fraudulent transactions, abnormal logins, illegal operations, etc.) are clarified to provide a classification basis for subsequent data archiving, facilitate the organization of historical data according to business scenarios or risk characteristics, and improve data retrieval and analysis efficiency. The standardized classification of event types is helpful for the optimization of subsequent risk control models. For example, by statistically analyzing the occurrence patterns of different types of events, risk control strategies can be adjusted in a targeted manner.

[0122] S1011: Storing the compressed event details data in a partition corresponding to the event type in a future query database.

[0123] In this embodiment, according to the event type, the compressed event detail data is stored in the corresponding partition of the forward query database (such as the "fraudulent transaction" partition, the "abnormal login" partition, etc.). Partitioning by type can realize structured archiving of data. When it is necessary to query a specific type of historical event, there is no need to traverse the entire library, and the partition can be directly located, which greatly improves the query efficiency. The forward library is usually used to store historical data with low frequency access. The compressed format further reduces storage costs. At the same time, the partitioning mechanism facilitates data backup, migration or compliance audits (such as filtering compliance data that needs to be retained by type). The temporary data of the medium-term library is transferred to the forward library, so that the medium-term library can free up space and focus on processing "sub-new" data (query requirements between the recent and long-term), ensuring that the functions of databases at all levels are clear.

[0124] S1012: Delete the compressed event detail data and the mapping relationship in the mid-term query database.

[0125] In this embodiment, the compressed data of event details transferred to the forward library from the mid-term library and its corresponding mapping relationship (i.e., the association index between the core fields and events established at the second moment) are removed to avoid data accumulation in the mid-term library, ensure its storage capacity and query performance, and continue to provide efficient support for "sub-new" data (such as risk control events in recent weeks or months). The archived data is deleted to avoid data redundancy or version conflicts between the mid-term library and the forward library, ensure the unidirectionality of data flow, and reduce management complexity. The mid-term library usually uses storage media with better performance than the forward library. Deleting historical data can reduce the occupancy of high-performance storage and reduce overall hardware costs.

[0126] It can be seen that this approach achieves efficient risk control data life cycle management through phased data management: at the third moment, compressed event detail data is extracted from the medium-term library to ensure the temporal consistency of data processing and avoid the impact of early operations on integrity; determine the event type and store the compressed data into the corresponding partition of the long-term library by type, which can not only achieve structured archiving and improve the query efficiency of specific types of historical events through partitioned storage, but also reduce long-term storage costs by using compressed formats, and provide classified data support for risk control model optimization; finally, delete the transferred data and mapping relationships in the medium-term library, which can release high-performance storage resources, avoid data redundancy conflicts, and ensure that the multiple values ​​of storage cost optimization, retrieval efficiency improvement and system stability assurance are finally achieved through the complete separation of hot and cold data.

[0127] In general, through a phased and hierarchical data management strategy, efficient circulation and storage optimization of risk control data throughout its life cycle are achieved: at the first moment when the target risk control event occurs, the core fields, index fields and detailed data are stored in the recent query database to ensure rapid response and complete retention of data in high-frequency real-time risk control scenarios; at the second moment, the detailed data is compressed and a core field mapping relationship is established before being transferred to the medium-term database. This can not only reduce storage occupancy through compression, but also retain data association logic with the help of mapping relationships. At the same time, the recent database data is deleted to free up resources and ensure real-time query performance; at the third moment, the compressed data is archived to the corresponding partition of the long-term database according to the event type, and partitioned storage is used to improve the efficiency of historical data retrieval, providing classified data support for risk control trend analysis and model iteration. Deleting the medium-term database data achieves a complete separation of hot and cold data. Finally, through the three-level architecture of "real-time response-new processing-historical archiving", while reducing storage costs, the query efficiency, data consistency and long-term traceability of the risk control system are guaranteed to meet the risk control data usage needs in different scenarios.

[0128] It should be explained that, in this embodiment, based on the data storage method, a data query method is also provided. Figure 6 , Figure 6 This is a flowchart of a data query method provided by an embodiment of the present application, including but not limited to the following steps:

[0129] S601: Obtain a data query request from a target user for detailed data of the target event.

[0130] In this embodiment, a user query request for specific event details data is received, and the target data to be retrieved is clearly identified. The user query request is the starting point for triggering data retrieval and must contain sufficient identification information (such as event identity, user identity, etc.) to locate the target data.

[0131] S602: Determine the query time corresponding to the data query request.

[0132] In this embodiment, the specific time point (query time) when the user initiates the query is recorded to determine the storage stage of the data. The query time is the key basis for deciding which database to retrieve data from, based on the "short-term-medium-term-long-term" grading strategy of the data life cycle.

[0133] S603: When the query time is between the first time and the second time, obtain first index field data corresponding to the target event detail data.

[0134] In this embodiment, if the query occurs after the time the event occurs (the first moment) and before the second moment (i.e., within a short period of time after the event occurs), the index fields used for retrieval (such as event identity, timestamp) are extracted. At this time, the data is still stored in the recent query database, and the index field is the key identifier for quick retrieval of the recent library.

[0135] S604: Query the recent query database based on the first index field data to obtain the target event detail data.

[0136] In this embodiment, the first index field is used to search in the recent library to directly obtain the uncompressed original event detail data. The recent library stores real-time data and has high performance. The index field query is efficient and can quickly return complete detail data to meet real-time query needs.

[0137] S605: When the query time is between the second time and the third time, obtain first core field data corresponding to the target event detail data.

[0138] In this embodiment, if the query occurs after the second moment and before the third moment (a long time after the event occurs), the core field is extracted as the search condition. At this time, the data has been migrated from the recent library to the mid-term library, and the core field is the index key of the mapping relationship in the mid-term library.

[0139] S606: Query the mid-term query database based on the first core field data to obtain target event detail compressed data.

[0140] In this embodiment, the corresponding mapping relationship is searched in the mid-term library through the core field to locate and obtain the compressed event detail data. The detail data in the mid-term library has been compressed and needs to be decompressed before use, but the compressed format reduces storage occupancy.

[0141] S607: Decompress the target event detail compressed data to obtain the target event detail data.

[0142] In this embodiment, a decompression operation is performed on the compressed data to restore the event detail data in the original format, and the compressed data is restored to complete details that can be read by the user to meet the query requirements.

[0143] S608: When the query time is after the third time, obtain the first event type corresponding to the target event detail data.

[0144] In this embodiment, if the query occurs after the third moment (a long period after the event occurs), the type of the target event (such as fraud or normal transaction) is determined. At this time, the data has been archived to the forward library and stored in partitions according to the event type. The type is the key dimension of retrieval.

[0145] S609: Query the long-term query database based on the first event type to obtain the compressed data of the target event details.

[0146] In this embodiment, the corresponding partition of the forward database is searched according to the event type (such as "fraudulent transaction") to obtain compressed detailed data. Partitioned storage avoids full database scanning, improves the query efficiency of long-term historical data, and the compressed format further saves storage costs.

[0147] S6010: Decompress the target event detail compressed data to obtain the target event detail data.

[0148] In this embodiment, the compressed data obtained from the forward library is decompressed and restored to the original detailed data for user query. No matter which storage stage the data is in, it can eventually be obtained and restored to the format required by the user through the corresponding strategy.

[0149] It can be seen that the core benefit of doing so is to achieve efficient data management, optimized storage costs, and a balance between query performance through time-segmented data storage strategies and hierarchical query mechanisms. Specifically, according to the different time intervals of the query moment (from the first moment to the second moment, from the second moment to the third moment, and after the third moment), the system automatically matches the corresponding database (short-term, medium-term, and long-term) and query method. In the short-term query stage, the original data is quickly retrieved from the recent library directly through the index field to meet the needs of high-frequency and real-time queries and ensure the response speed of new event data; in the medium-term query stage, the core field mapping relationship is used to retrieve compressed data, which reduces storage occupancy while retaining key information. It is suitable for processing routine queries in the medium term, taking into account efficiency and space costs; in the long-term query stage, compressed data is stored in partitions according to event types, and historical data is archived to the long-term library, which not only reduces the pressure on hot data storage, but also can quickly locate historical records by event type, facilitating compliance audits or low-frequency backtracking queries.

[0150] In summary, the implementation of the present invention has the following beneficial effects:

[0151] It can be seen that the data storage method described in the embodiment of the present invention obtains the risk control event data corresponding to the target risk control event, the time when the target risk control event occurs is the first time, and determines the core field data, event index field data and event detail data corresponding to the risk control event data. At the first time, the core field data, the event index field data and the event detail data are stored in the recent query database. At the second time, the core field data and the event detail data are obtained from the recent query database; the second time is after the first time, the event detail data is compressed to obtain event detail compressed data, and based on the core field data and the event The compressed details data determines the mapping relationship between the core field and the target risk control event, stores the compressed event details data and the mapping relationship in the mid-term query database, deletes the core field data, the event index field data, and the event details data in the recent query database, and obtains the compressed event details data from the mid-term query database at a third moment; the third moment is after the second moment, determines the event type of the target risk control event, stores the compressed event details data in the partition corresponding to the event type in the long-term query database, deletes the compressed event details data and the mapping relationship in the mid-term query database, and improves the storage efficiency of risk control events.

[0152] See also Figure 7 , Figure 7 is a structural diagram of a data storage device provided in an embodiment of the present application, wherein the data storage device 700 includes: an acquisition unit 701 and a processing unit 702;

[0153] The acquisition unit 701 acquires risk control event data corresponding to a target risk control event; the time when the target risk control event occurs is the first time;

[0154] The processing unit 702 is configured to determine the core field data, event index field data, and event detail data corresponding to the risk control event data;

[0155] At the first moment, storing the core field data, the event index field data, and the event detail data in a recent query database;

[0156] At a second moment, the core field data and the event detail data are acquired from the recent query database; the second moment is after the first moment;

[0157] Compressing the event detail data to obtain event detail compressed data;

[0158] Determine a mapping relationship between a core field and the target risk control event based on the core field data and the event detail compressed data;

[0159] Storing the compressed event details data and the mapping relationship in a mid-term query database;

[0160] Deleting the core field data, the event index field data, and the event detail data in the recent query database;

[0161] At a third moment, obtaining the event detail compressed data from the mid-term query database;

[0162] Determining the event type of the target risk control event; the third moment is after the second moment;

[0163] The event details are compressed and stored in a partition corresponding to the event type in a future query database;

[0164] The event detail compressed data and the mapping relationship in the mid-term query database are deleted.

[0165] In some possible implementations, the processing unit 702 is further specifically configured to:

[0166] Determine the risk warning value of the target risk control event based on the core field data;

[0167] When the risk warning value is higher than the preset risk warning value, a warning message is generated based on the risk control event data; the warning message is used to indicate that the risk of the target risk control event is high;

[0168] When the risk warning value is less than or equal to the preset risk warning value, the operation of storing the core field data, the event index field data, and the event detail data in a recent query database at the first moment is performed.

[0169] In some possible implementations, in determining the risk warning value of the target risk control event based on the core field data, the processing unit 702 is specifically configured to:

[0170] Determine the transaction amount, number of historical account violations, and transaction duration corresponding to the target risk control event based on the core field data;

[0171] Determine a first risk warning value corresponding to the transaction amount, a second risk warning value corresponding to the number of historical account violations, and a third risk warning value corresponding to the transaction duration;

[0172] A risk warning value of the target risk control event is determined based on the first risk warning value, the second risk warning value, and the third risk warning value.

[0173] In some possible implementations, in determining the risk warning value of the target risk control event based on the first risk warning value, the second risk warning value, and the third risk warning value, the processing unit 702 is specifically configured to:

[0174] Determine a first weight corresponding to the first risk warning value, a second weight corresponding to the second risk warning value, and a third weight corresponding to the third risk warning value; the sum of the first weight, the second weight, and the third weight is 1;

[0175] Calculating based on the first risk warning value, the second risk warning value, the third risk warning value, the first weight, the second weight, and the third weight to obtain a reference risk warning value;

[0176] Obtain the account password modification frequency corresponding to the target risk control event;

[0177] Determining an optimization factor corresponding to the account password modification frequency;

[0178] The reference risk warning value is optimized based on the optimization factor to obtain the risk warning value of the target risk control event.

[0179] In some possible implementations, the processing unit 702 is further specifically configured to:

[0180] Determine a risk assessment value of the target risk control event based on the core field data;

[0181] Determine the risk level of the target risk control event based on the risk assessment value; the risk level includes any of the following: high risk level, medium risk level, and low risk level;

[0182] When the risk level is the high risk level, high risk alarm information is generated based on the risk control event data, and the step of storing the core field data, the event index field data, and the event detail data in the recent query database at the first moment is not performed;

[0183] When the risk level is the medium risk level, verification information is generated based on the risk control event data; the verification information is used for verification of the target personnel, and after the verification is passed, the step of storing the core field data, the event index field data, and the event detail data in a recent query database at the first moment is continued;

[0184] When the risk level is the low risk level, the step of storing the core field data, the event index field data, and the event detail data in a recent query database at the first moment is performed.

[0185] In some possible implementations, in determining the risk level of the target risk control event based on the risk assessment value, the processing unit 702 is specifically configured to:

[0186] When the risk assessment value is greater than or equal to a first threshold, determining that the risk level of the target risk control event is a high risk level;

[0187] When the risk assessment value is less than the first threshold and greater than a second threshold, the risk level of the target risk control event is determined to be a medium risk level; and the second threshold is less than the first threshold;

[0188] When the risk assessment value is less than or equal to the second threshold, the risk level of the target risk control event is determined to be a low risk level.

[0189] In some possible implementations, the processing unit 702 is further specifically configured to:

[0190] Obtaining a data query request from a target user for detailed data of the target event;

[0191] Determining a query time corresponding to the data query request;

[0192] When the query time is between the first time and the second time, obtaining first index field data corresponding to the target event details data;

[0193] Querying the recent query database based on the first index field data to obtain the target event details data;

[0194] When the query time is between the second time and the third time, obtaining first core field data corresponding to the target event detail data;

[0195] Querying the mid-term query database based on the first core field data to obtain compressed target event details;

[0196] Decompressing the target event detail compressed data to obtain the target event detail data;

[0197] When the query time is after the third time, obtaining a first event type corresponding to the target event detail data;

[0198] Performing a query in the long-term query database based on the first event type to obtain compressed data of target event details;

[0199] Decompression is performed based on the target event detail compressed data to obtain the target event detail data.

[0200] See also Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided by the embodiment of this application. Figure 8 As shown, electronic device 800 includes a transceiver 801, a processor 802, and a memory 803. These are connected via a bus 804. The memory 803 is used to store computer programs and data, and the transceiver 801 can transmit the data stored in the memory 803 to the processor 802. The above program includes instructions for executing the following steps:

[0201] Obtaining risk control event data corresponding to a target risk control event; the time when the target risk control event occurs is the first moment;

[0202] Determine the core field data, event index field data, and event detail data corresponding to the risk control event data;

[0203] At the first moment, storing the core field data, the event index field data, and the event detail data in a recent query database;

[0204] At a second moment, the core field data and the event detail data are acquired from the recent query database; the second moment is after the first moment;

[0205] Compressing the event detail data to obtain event detail compressed data;

[0206] Determine a mapping relationship between a core field and the target risk control event based on the core field data and the event detail compressed data;

[0207] Storing the compressed event details data and the mapping relationship in a mid-term query database;

[0208] Deleting the core field data, the event index field data, and the event detail data in the recent query database;

[0209] At a third moment, obtaining the compressed event details data from the mid-term query database; the third moment is after the second moment;

[0210] Determining the event type of the target risk control event;

[0211] The event details are compressed and stored in a partition corresponding to the event type in a future query database;

[0212] The event detail compressed data and the mapping relationship in the mid-term query database are deleted.

[0213] In some possible implementations, the above program includes instructions for performing the following steps:

[0214] Determine the risk warning value of the target risk control event based on the core field data;

[0215] When the risk warning value is higher than the preset risk warning value, a warning message is generated based on the risk control event data; the warning message is used to indicate that the risk of the target risk control event is high;

[0216] When the risk warning value is less than or equal to the preset risk warning value, the operation of storing the core field data, the event index field data, and the event detail data in a recent query database at the first moment is performed.

[0217] In some possible implementations, in determining the risk warning value of the target risk control event based on the core field data, the program includes instructions for executing the following steps:

[0218] Determine the transaction amount, number of historical account violations, and transaction duration corresponding to the target risk control event based on the core field data;

[0219] Determine a first risk warning value corresponding to the transaction amount, a second risk warning value corresponding to the number of historical account violations, and a third risk warning value corresponding to the transaction duration;

[0220] A risk warning value of the target risk control event is determined based on the first risk warning value, the second risk warning value, and the third risk warning value.

[0221] In some possible implementations, in determining the risk warning value of the target risk control event based on the first risk warning value, the second risk warning value, and the third risk warning value, the program includes instructions for performing the following steps:

[0222] Determine a first weight corresponding to the first risk warning value, a second weight corresponding to the second risk warning value, and a third weight corresponding to the third risk warning value; the sum of the first weight, the second weight, and the third weight is 1;

[0223] Calculating based on the first risk warning value, the second risk warning value, the third risk warning value, the first weight, the second weight, and the third weight to obtain a reference risk warning value;

[0224] Obtain the account password modification frequency corresponding to the target risk control event;

[0225] Determining an optimization factor corresponding to the account password modification frequency;

[0226] The reference risk warning value is optimized based on the optimization factor to obtain the risk warning value of the target risk control event.

[0227] In some possible implementations, the above program includes instructions for performing the following steps:

[0228] Determine a risk assessment value of the target risk control event based on the core field data;

[0229] Determine the risk level of the target risk control event based on the risk assessment value; the risk level includes any of the following: high risk level, medium risk level, and low risk level;

[0230] When the risk level is the high risk level, high risk alarm information is generated based on the risk control event data, and the step of storing the core field data, the event index field data, and the event detail data in the recent query database at the first moment is not performed;

[0231] When the risk level is the medium risk level, verification information is generated based on the risk control event data; the verification information is used for verification of the target personnel, and after the verification is passed, the step of storing the core field data, the event index field data, and the event detail data in a recent query database at the first moment is continued;

[0232] When the risk level is the low risk level, the step of storing the core field data, the event index field data, and the event detail data in a recent query database at the first moment is performed.

[0233] In some possible implementations, in determining the risk level of the target risk control event based on the risk assessment value, the program includes instructions for performing the following steps:

[0234] When the risk assessment value is greater than or equal to a first threshold, determining that the risk level of the target risk control event is a high risk level;

[0235] When the risk assessment value is less than the first threshold and greater than a second threshold, the risk level of the target risk control event is determined to be a medium risk level; and the second threshold is less than the first threshold;

[0236] When the risk assessment value is less than or equal to the second threshold, the risk level of the target risk control event is determined to be a low risk level.

[0237] In some possible implementations, the above program includes instructions for performing the following steps:

[0238] Obtaining a data query request from a target user for detailed data of the target event;

[0239] Determining a query time corresponding to the data query request;

[0240] When the query time is between the first time and the second time, obtaining first index field data corresponding to the target event details data;

[0241] Querying the recent query database based on the first index field data to obtain the target event details data;

[0242] When the query time is between the second time and the third time, obtaining first core field data corresponding to the target event detail data;

[0243] Querying the mid-term query database based on the first core field data to obtain compressed target event details;

[0244] Decompressing the target event detail compressed data to obtain the target event detail data;

[0245] When the query time is after the third time, obtaining a first event type corresponding to the target event detail data;

[0246] Performing a query in the long-term query database based on the first event type to obtain compressed data of target event details;

[0247] Decompression is performed based on the target event detail compressed data to obtain the target event detail data.

[0248] It should be understood that the electronic devices in this application may include smartphones (such as Android phones, iOS phones, Windows Phone phones, etc.), tablet computers, PDAs, laptops, mobile Internet devices (MIDs) or wearable devices, or servers, edge computing nodes, etc. The above electronic devices are only examples and are not exhaustive, including but not limited to the above electronic devices.

[0249] The embodiments of the present application further provide a computer-readable storage medium, which stores a computer program. The computer program is executed by a processor to implement part or all of the steps of any one of the methods described in the above method embodiments.

[0250] The embodiments of the present application also provide a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause a computer to execute part or all of the steps of any one of the methods described in the above method embodiments.

[0251] It should be noted that for the aforementioned method implementations, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the implementations described in the specification are all optional implementations, and the actions and modules involved are not necessarily required by this application.

[0252] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0253] In the several embodiments provided in this application, it should be understood that the disclosed devices can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical or other forms.

[0254] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0255] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or in the form of software program modules.

[0256] If the integrated unit is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a memory and includes a number of instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the various implementation methods of the present application. The aforementioned memory includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0257] Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable memory, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0258] The above is a detailed introduction to the implementation methods of the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above implementation methods is only used to help understand the method and core idea of ​​the present application. At the same time, for those skilled in the art, based on the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A data storage method, characterized in that: include: Obtaining risk control event data corresponding to a target risk control event; the time when the target risk control event occurs is the first moment; Determine the core field data, event index field data, and event detail data corresponding to the risk control event data; At the first moment, storing the core field data, the event index field data, and the event detail data in a recent query database; At a second moment, the core field data and the event detail data are obtained from the recent query database; The second moment is after the first moment; Compressing the event detail data to obtain event detail compressed data; Determine a mapping relationship between a core field and the target risk control event based on the core field data and the event detail compressed data; Storing the compressed event details data and the mapping relationship in a mid-term query database; Deleting the core field data, the event index field data, and the event detail data in the recent query database; At a third moment, obtaining the event detail compressed data from the mid-term query database; The third moment is after the second moment; Determining the event type of the target risk control event; The event details are compressed and stored in a partition corresponding to the event type in a future query database; The event detail compressed data and the mapping relationship in the mid-term query database are deleted.

2. The method according to claim 1, wherein The method further comprises: Determine the risk warning value of the target risk control event based on the core field data; When the risk warning value is higher than the preset risk warning value, a warning message is generated based on the risk control event data; the warning message is used to indicate that the risk of the target risk control event is high; When the risk warning value is less than or equal to the preset risk warning value, the operation of storing the core field data, the event index field data, and the event detail data in a recent query database at the first moment is performed.

3. The method according to claim 2, wherein The determining the risk warning value of the target risk control event based on the core field data includes: Determine the transaction amount, number of historical account violations, and transaction duration corresponding to the target risk control event based on the core field data; Determine a first risk warning value corresponding to the transaction amount, a second risk warning value corresponding to the number of historical account violations, and a third risk warning value corresponding to the transaction duration; A risk warning value of the target risk control event is determined based on the first risk warning value, the second risk warning value, and the third risk warning value.

4. The method according to claim 3, wherein The determining the risk warning value of the target risk control event based on the first risk warning value, the second risk warning value, and the third risk warning value includes: Determine a first weight corresponding to the first risk warning value, a second weight corresponding to the second risk warning value, and a third weight corresponding to the third risk warning value; the sum of the first weight, the second weight, and the third weight is 1; Calculating based on the first risk warning value, the second risk warning value, the third risk warning value, the first weight, the second weight, and the third weight to obtain a reference risk warning value; Obtain the account password modification frequency corresponding to the target risk control event; Determining an optimization factor corresponding to the account password modification frequency; The reference risk warning value is optimized based on the optimization factor to obtain the risk warning value of the target risk control event.

5. The method according to claim 1, wherein The method further comprises: Determine a risk assessment value of the target risk control event based on the core field data; Determine the risk level of the target risk control event based on the risk assessment value; the risk level includes any of the following: high risk level, medium risk level, and low risk level; When the risk level is the high risk level, high risk alarm information is generated based on the risk control event data, and the step of storing the core field data, the event index field data, and the event detail data in the recent query database at the first moment is not performed; When the risk level is the medium risk level, verification information is generated based on the risk control event data; the verification information is used for verification of the target personnel, and after the verification is passed, the step of storing the core field data, the event index field data, and the event detail data in a recent query database at the first moment is continued; When the risk level is the low risk level, the step of storing the core field data, the event index field data, and the event detail data in a recent query database at the first moment is performed.

6. The method according to claim 5, wherein Determining the risk level of the target risk control event based on the risk assessment value includes: When the risk assessment value is greater than or equal to a first threshold, determining that the risk level of the target risk control event is a high risk level; When the risk assessment value is less than the first threshold and greater than a second threshold, the risk level of the target risk control event is determined to be a medium risk level; and the second threshold is less than the first threshold; When the risk assessment value is less than or equal to the second threshold, the risk level of the target risk control event is determined to be a low risk level.

7. The method according to any one of claims 1 to 6, wherein: The method further comprises: Obtaining a data query request from a target user for detailed data of the target event; Determining a query time corresponding to the data query request; When the query time is between the first time and the second time, obtaining first index field data corresponding to the target event details data; Querying the recent query database based on the first index field data to obtain the target event details data; When the query time is between the second time and the third time, obtaining first core field data corresponding to the target event detail data; Querying the mid-term query database based on the first core field data to obtain compressed target event details; Decompressing the target event detail compressed data to obtain the target event detail data; When the query time is after the third time, obtaining a first event type corresponding to the target event detail data; Performing a query in the long-term query database based on the first event type to obtain compressed data of target event details; Decompression is performed based on the target event detail compressed data to obtain the target event detail data.

8. A data storage device, characterized in that The device comprises: an acquisition unit and a processing unit; The acquisition unit acquires risk control event data corresponding to a target risk control event; the time when the target risk control event occurs is the first time; The processing unit is configured to determine core field data, event index field data, and event detail data corresponding to the risk control event data; At the first moment, storing the core field data, the event index field data, and the event detail data in a recent query database; At a second moment, the core field data and the event detail data are acquired from the recent query database; the second moment is after the first moment; Compressing the event detail data to obtain event detail compressed data; Determine a mapping relationship between a core field and the target risk control event based on the core field data and the event detail compressed data; Storing the compressed event details data and the mapping relationship in a mid-term query database; Deleting the core field data, the event index field data, and the event detail data in the recent query database; At a third moment, obtaining the event detail compressed data from the mid-term query database; Determining the event type of the target risk control event; the third moment is after the second moment; The event details are compressed and stored in a partition corresponding to the event type in a future query database; The event detail compressed data and the mapping relationship in the mid-term query database are deleted.

9. An electronic device, characterized in that: The method comprises a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the one or more programs include instructions for executing the steps in the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and the computer program is executed by a processor to implement the method according to any one of claims 1 to 7.

Images