Data report generation methods and apparatus, storage media, electronic devices

Abstract

This application provides a method, apparatus, storage medium, and electronic device for generating data reports. The method includes: acquiring N data reports within a target time period, wherein the N data reports are tables recording transaction data of a target product from N recording perspectives, and N is a natural number greater than 1; performing data processing operations on the N data reports to obtain a target data table, wherein the data processing operations sequentially include: data integration, data verification, data cleaning, and data format conversion; and generating a data report for the target product based on the target data table, wherein the data report represents the changes in transaction risk of the target product within the target time period. This application solves the problem of inaccurate data report generation in related technologies, achieving the effect of accurately generating data reports.

Description

Technical Field

[0001] This application relates to the field of data processing, and more specifically, to a method and apparatus for generating data reports, a storage medium, and an electronic device. Background Technology

[0002] With societal development, people's demand for online products and services is increasing, leading to the emergence of a wide variety of products and services. However, online platforms also face various risks, such as: products and services failing to meet user needs; cyberattacks; and ethical risks posed by internal employees or external personnel. Therefore, during the operation of online platforms, it is necessary to monitor various transaction data to promptly assess the platform's operational status, predict transaction risks, and optimize operational strategies.

[0003] To monitor the operation of the network platform more quickly and effectively, data reports need to be generated. However, existing data reports are usually manually written, which takes a long time to generate and is prone to errors. Summary of the Invention

[0004] This application provides a method and apparatus for generating data reports, a storage medium, and an electronic device to at least solve the problem of inaccurate data report generation in related technologies.

[0005] According to one embodiment of this application, a method for generating a data report is provided, comprising: acquiring N data reports within a target time period, wherein the N data reports are tables recording transaction data of a target product based on N recording perspectives, and N is a natural number greater than 1; performing data processing operations on the N data reports to obtain a target data table, wherein the data processing operations sequentially include: data integration operation, data verification operation, data cleaning operation, and data format conversion operation; and generating a data report for the target product based on the target data table, wherein the data report is used to represent the changes in transaction risk of the target product within the target time period.

[0006] In one exemplary embodiment, acquiring N data reports within a target time period includes: identifying a data source based on the product type and transaction type of the target product, to determine the storage location and report format of the N data reports from the data source; configuring access permissions for a data access script to access the data source according to the storage location and report format via the access script; and downloading the N data reports from the data source.

[0007] In one exemplary embodiment, performing data processing operations on N data reports to obtain a target data table includes: performing the data integration operation on the N data reports to obtain a first data table; performing the data verification operation on the first data table to obtain a second data table; performing the data cleaning operation on the second data table to obtain a third data table; and performing the data format conversion operation on the third data table to obtain the target data table.

[0008] In an exemplary embodiment, performing the data integration operation on N data reports to obtain a first data table includes: establishing a correspondence between the first data report and the second data report based on the product identifier of the target product, wherein the first data report is a customer transaction detail table of the target product, and the second data report is a market transaction detail table of the target product, and both the first data report and the second data report are reports among the N data reports; verifying the transaction information in the second data report using a third data report, wherein the third data report is a ledger detail table among the N data reports; and merging the matching transaction information in the first data report and the second data report according to the correspondence to obtain the first data table, provided that the transaction information in the second data report is correct.

[0009] In an exemplary embodiment, performing the data verification operation on the first data table to obtain a second data table includes: obtaining a first data list and a second data list from the first data table, wherein the first data list includes customer transaction information of the target product, and the second data list includes market transaction information of the target product; if the first transaction parameter in the first data list matches the second transaction parameter in the second data list, and both the first data list and the second data list are complete, the first data table is determined to be the first data table.

[0010] In an exemplary embodiment, performing the data cleaning operation on the second data table to obtain a third data table includes: determining the data table format of the second data table and the attribute data of each column; generating multiple data cleaning instructions according to the data table format and the attribute data; and loading the multiple data cleaning instructions into the second data table to delete duplicate data, erroneous data, and fill in missing data in the second data table to obtain the third data table.

[0011] In an exemplary embodiment, performing the data format conversion operation on the third data table to obtain the target data table includes: acquiring attribute data of each column cell in the third data table; generating format conversion instructions based on the attribute data of each column cell; loading multiple format conversion instructions into the third data table to convert the data of each column cell in the third data table according to the data format in the conversion instructions, thereby obtaining the target data table.

[0012] In an exemplary embodiment, generating a data report for the target product based on the target data table includes: receiving a user request and responding to the user request; extracting data from the target data table in N columns corresponding to the request categories included in the user request, wherein the user request is used to request the generation of the data report; inputting the data in the N columns and the user request into a target model respectively to obtain the data report output by the target model, wherein the target model includes a data pivot sub-model and a data visualization sub-model, the data pivot sub-model is used to extract the data format and data content of the data in the N columns, and to extract the data report format requested in the user request, the data visualization sub-model is used to select a visualization component according to the data format and the data content, and the visualization component is used to generate a visualization graphic or chart of the data in the N columns corresponding to the data report format, thereby obtaining the data report.

[0013] In an exemplary embodiment, after generating a data report for the target product based on the target data table, the method further includes: acquiring transaction data of the target product in real time; calculating a fluctuation threshold for the transaction data using the real-time trend of the transaction data; calculating the update frequency of the data report using the fluctuation threshold; and updating the data report according to the update frequency.

[0014] According to another embodiment of this application, a data report generation apparatus is provided, comprising: a first acquisition module, configured to acquire N data reports within a target time period, wherein the N data reports are tables recording transaction data of a target product based on N recording perspectives, and N is a natural number greater than 1; a first processing module, configured to perform data processing operations on the N data reports to obtain a target data table, wherein the data processing operations sequentially include: data integration operation, data verification operation, data cleaning operation, and data format conversion operation; and a first generation module, configured to generate a data report of the target product based on the target data table, wherein the data report is used to represent the changes in transaction risk of the target product within the target time period.

[0015] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0016] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0017] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0018] This application automates the acquisition and integration of multiple data reports by sequentially performing data integration, data verification, data cleaning, and data format conversion operations on N acquired data reports, and then generates a data report for the target product based on the resulting target data table. This significantly reduces manual operations and improves data processing speed, enabling financial institutions to prepare market risk reports in a shorter time and respond quickly to market changes. Data verification and cleaning operations ensure data accuracy and integrity, reducing inconsistencies caused by human error. Data format conversion ensures all data reports are processed in a unified format, facilitating subsequent analysis and comparison. Based on an accurate and consistent target data table, the generated data report more precisely reflects changes in the transaction risk of the target product within the target time period. Therefore, it solves the problem of inaccurate data report generation in related technologies, achieving the effect of accurate data report generation. Attached Figure Description

[0019] Figure 1 This is a hardware structure block diagram of a server device for a data report generation method according to an embodiment of this application;

[0020] Figure 2 This is a flowchart of a data report generation method according to an embodiment of this application;

[0021] Figure 3 This is a structural block diagram of a data report generation apparatus according to an embodiment of this application. Detailed Implementation

[0022] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0024] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of a server device for a data report generation method according to an embodiment of this application. For example... Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0025] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the data report generation method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0026] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0027] This embodiment provides a method for generating data reports. Figure 2 This is a flowchart of a data report generation method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0028] Step S202: Obtain N data reports within the target time period, wherein the N data reports are tables that record transaction data of the target product based on N recording perspectives, and N is a natural number greater than 1;

[0029] Optionally, the target time period specified in this embodiment is the time span used for analysis and reporting, such as a day, a week, a month, or a quarter. The selection of the target time period depends on business needs and the characteristics of market risks.

[0030] Optionally, in the N data reports, N represents the number of data reports, which are records of transaction data for the same target product based on different recording perspectives. N is a natural number greater than 1 (e.g., N equals 3 or 4), meaning that at least two or more reports record transaction information from different perspectives.

[0031] Optionally, the recording angle in this embodiment refers to different dimensions or angles of data collection and analysis, such as customer perspective, product type perspective, market change perspective, etc. Each angle's report provides information about different aspects of the transaction.

[0032] Step S204: Perform data processing operations on the N data reports to obtain the target data table. The data processing operations include, in sequence: data integration operation, data verification operation, data cleaning operation, and data format conversion operation.

[0033] Optionally, the data integration operation in this embodiment is used to merge data from multiple data reports into a unified data table, ensuring that all relevant information is included and the data format is consistent.

[0034] Optionally, the data verification operation in this embodiment is used to check whether the integrated data is complete and accurate, and to ensure data consistency. For example, it checks the matching of transaction records and the completeness of data fields.

[0035] Optionally, the data cleaning operation in this embodiment is used to remove or correct inaccurate, incomplete, or irrelevant data in the dataset, thereby improving data quality. Examples include deleting duplicate records, filling in missing values, and correcting formatting errors.

[0036] Optionally, the data format conversion operation in this embodiment is used to convert the data into a format suitable for further analysis and reporting, such as standardizing field names and data types to ensure that all data is presented in a uniform format.

[0037] Optionally, the target data table in this embodiment is a standardized data set generated after data integration, verification, cleaning and format conversion operations, used for compiling data reports.

[0038] Step S206: Generate a data report for the target product based on the target data table, wherein the data report is used to represent the changes in transaction risk of the target product within the target time period.

[0039] Optionally, the data report in this embodiment is a document or file compiled based on the target data table, used to summarize and display the changes in transaction risk of the target product within a target time period. The data report may include various charts, key indicators, and analytical conclusions.

[0040] The entity performing the above steps may be a terminal, a server, a specific processor set in the terminal or server, or a processor or processing device set up relatively independently of the terminal or server, but is not limited to these.

[0041] Through the above steps, data integration, verification, cleaning, and format conversion operations are sequentially performed on the acquired N data reports, and a data report for the target product is generated based on the resulting target data table. This automates the acquisition and integration of multiple data reports, reducing manual operations and significantly improving data processing speed. Financial institutions can then prepare market risk reports in a shorter time, enabling rapid response to market changes. Data verification and cleaning operations ensure data accuracy and integrity, reducing inconsistencies caused by human error. Data format conversion ensures all data reports are processed in a unified format, facilitating subsequent analysis and comparison. Based on an accurate and consistent target data table, the generated data report more precisely reflects changes in the transaction risk of the target product within the target time period. Therefore, it solves the problem of inaccurate data report generation in related technologies, achieving accurate data report generation.

[0042] The method in this embodiment can be applied to market risk management scenarios for financial institutions, as well as to risk management scenarios for virtual goods transactions within games. The target product can be virtual goods within the game, such as rare equipment, game currency, or in-game items. The following is a specific embodiment based on a game scenario, including the following steps:

[0043] Step 1: Obtain N data reports within the target time period:

[0044] Transaction Record Report: Retrieves transaction records between players from the game server database, including transaction time, product type, quantity, price, and account information of both parties.

[0045] Market Fluctuation Report: Analyzes the in-game market and records the price fluctuations of virtual goods, especially those with abnormal price fluctuations.

[0046] Player Credit Report: Assess players' creditworthiness and record information on players who frequently engage in suspicious transactions or have poor credit records.

[0047] Anti-fraud activity report: Collects abnormal activities recorded by the in-game anti-fraud system, such as transactions that exploit game vulnerabilities.

[0048] Inventory Report: Displays the inventory of various virtual goods held by the game operator, as well as the changes in inventory over time.

[0049] The above reports are all based on different recording perspectives, and together they constitute a comprehensive view of virtual goods transactions within the game.

[0050] Step 2: Perform data processing operations on N data reports:

[0051] Data integration operation: Integrate the data from all the above reports into a table called "In-game Transaction Risk Data Integration Table", which includes information such as player transaction records, commodity price fluctuations, and player credit assessment.

[0052] Data verification operation: Check whether the integrated data is complete and accurate. For example, verify whether the player's transaction records are consistent with the information in the player's credit report, and check whether the commodity price fluctuations are consistent with the actual market situation.

[0053] Data cleaning operations: Remove duplicate transaction records and fill in missing information. In particular, for suspicious transactions marked by the anti-fraud system, their legitimacy needs to be confirmed through additional player behavior analysis to avoid false alarms.

[0054] Data format conversion: Standardize all data fields, such as unifying transaction time to the format "YYYY-MM-DDHH:MM:SS" and currency units to the standard in-game currency units, to ensure data consistency and analyzability.

[0055] Step 3: Generate a data report based on the target data table:

[0056] Overview of Transaction Risks: Displays the transaction volume, transaction amount, and price fluctuations of virtual goods within a target time period (such as one week or one month), as well as potential market risk factors, such as transaction fraud and player credit risk.

[0057] Commodity Price Fluctuation Analysis: For specific virtual commodities, analyze their price fluctuation trends, identify commodities with abnormal price changes, and assess their impact on the game's economic system.

[0058] Player credit risk assessment: List players with high credit risk and analyze their transaction behavior to identify whether there is fraud or abuse of game rules.

[0059] Market Risk Warning: Based on the integrated data, the system automatically identifies potential market risks, such as significant fluctuations in commodity prices and abnormal player behavior, and provides warnings to game operators so that they can take preventive measures.

[0060] Risk control strategy recommendations: Based on data analysis, the report proposes control strategies for risk factors, such as adjusting virtual commodity prices and restricting the trading privileges of high-risk players.

[0061] Through the specific embodiments described above, the method of this application is also applicable to in-game market risk management. It helps game operators automatically collect and process transaction data from multiple perspectives, generating a comprehensive data report reflecting the risk status of virtual goods transactions within the game. This method not only improves the efficiency and accuracy of data processing but also ensures the real-time nature and professionalism of risk management. This is of great significance for maintaining the stability of the game's economic system, preventing fraudulent activities, and protecting players' rights.

[0062] For example, in a market risk management scenario for financial institutions, suppose a commercial bank needs to prepare a quarterly market risk report on gold derivatives. The following is a specific embodiment applying the method described in this example, including the following steps:

[0063] Step 1: Obtain N data reports:

[0064] At the end of the first quarter of 2029, the following reports will be automatically retrieved from the bank's trading system: "Summary of Gold Derivatives Transactions for Clients": From the client's perspective, this record shows all gold derivatives transactions conducted by clients during the first quarter, including transaction size, direction, execution price, and maturity date. "Gold Derivatives Transaction Records at the Flat End": From the bank's own risk management perspective, this record shows gold derivatives transactions conducted by the bank to hedge client trading risks. "Gold Derivatives Market Data": This provides information on gold market price fluctuations and trading volume during the first quarter.

[0065] Step 2: Perform data processing operations:

[0066] Data integration operation: Using data merging and splicing techniques, the data from the three reports are integrated into a table called "Quarterly Gold Derivatives Trading Data".

[0067] Data verification process: Through data comparison and integrity checks, ensure that there are no omissions or errors in the data in the "Quarterly Gold Derivatives Trading Data" and that all transaction records match the bank's trading system and financial records.

[0068] Data cleaning operations: Remove duplicate transaction records, fill in missing fields, correct formatting errors, and especially delete transaction records that have been closed out in advance but not yet settled, in order to avoid double counting of risk exposure.

[0069] Data format conversion: Standardize all data fields, for example, unify date fields to "YYYY-MM-DD" format and currency fields to "XX.XX" format, to ensure data consistency and analyzability.

[0070] Step 3: Generate a data report:

[0071] The Quarterly Report on Gold Derivatives Market Risks is generated based on the processed Quarterly Gold Derivatives Trading Data.

[0072] The report includes: "Market Risk Overview": showcasing changes in the notional balance, market value revaluation, risk exposure, and unrealized gains and losses of gold derivatives in the first quarter. "Client Trading Risk Analysis": listing the trading activities of the top ten clients in the first quarter, including trading instruments, size, risk exposure, and client credit risk assessment. "Product Type Risk Segmentation": analyzing risk exposure and market performance by type of gold derivative (e.g., options, forwards, swaps), identifying higher-risk product types. "Market Dynamics and Risk Factors": analyzing the dynamics of gold market price fluctuations and trading volume changes in the first quarter, exploring their impact on market risk. Using charts, key indicators, and detailed analysis, the report presents the bank's gold derivatives trading risk status in an intuitive and professional manner in the first quarter, providing the risk management team with crucial decision-making information.

[0073] The above embodiments demonstrate that the method described can effectively integrate, verify, clean, and transform data reports from multiple perspectives to generate a comprehensive data report reflecting changes in market risk for the target product within a target time period. This method not only improves the efficiency and accuracy of data processing but also ensures the quality of the report, helping financial institutions monitor and manage market risks in real time.

[0074] In one exemplary embodiment, acquiring N data reports within a target time period includes: identifying a data source based on the product type and transaction type of the target product, to determine the storage location and report format of the N data reports from the data source; configuring access permissions for a data access script to access the data source according to the storage location and report format via the access script; and downloading the N data reports from the data source.

[0075] Optionally, the data source is a system or platform that stores data reports, such as a bank's internal transaction system, database, file server, or an external data provider or exchange.

[0076] Optionally, target products can be categorized into different types, such as options, forwards, and swaps; transaction types generally include buying, selling, and closing out positions. When identifying data sources, it is necessary to clearly define which product type and transaction type of data are being targeted.

[0077] Optionally, the storage location refers to the specific location or path of the data report in the data source; the report format involves the data organization, such as Excel, CSV, or database table, as well as the field naming and data type.

[0078] Alternatively, a data access script is an automation tool or program used to extract data reports from a data source. The access script needs appropriate access permissions to correctly read data according to the predetermined storage location and report format.

[0079] For example, suppose the market risk management department of a financial institution needs to generate a data report on the risks of the gold derivatives market at the end of each month. The following are specific steps for implementing this embodiment, including:

[0080] Step 1: Identify Data Sources and Reports: Product Type: Gold derivatives, including gold options, gold forwards, and gold swaps. Transaction Type: Including client buy, client sell, and bank settlement. Data Source: Internal trading system (client-side transaction data), bank risk management system (settlement-side transaction data), external market data provider (gold market price data). Each data source stores data reports related to the above product and transaction types. Storage Location: Client-side transaction data is stored under the path "Trading System / Derivatives / Gold / Client Transactions"; settlement-side transaction data is stored under the path "Risk Management / Derivatives / Gold / Bank Settlement"; gold market price data is obtained from external providers via API. Report Format: Client-side and settlement-side transaction data are stored in Excel format, and market data is provided in CSV format.

[0081] Step 2: Configure access permissions for the data access script: Access script: Uses a Python script, combined with the pandas and xlrd libraries, to read data reports in Excel and CSV formats. Access permissions: Configure network access permissions (such as HTTPS access) in the script to obtain external market data, and internal system access permissions (such as database username and password) to read internal trading data.

[0082] Step 3: Download N Data Reports: Based on the configured storage location and report format, the Python script accesses the internal trading system and external market data providers respectively, downloading the "Client Gold Derivatives Transaction Details," "Bank Gold Derivatives Flat Trading Details," and "Gold Market Price Data" from the specified paths. After the data download is complete, the script will check for new data updates. If so, it will download the latest version of the report data to ensure the timeliness and accuracy of analysis and reporting. During the script's execution, access logs and error messages for each step will be recorded for subsequent debugging and auditing.

[0083] Through the specific implementation steps described above, financial institutions can automatically acquire gold derivatives trading data without manual searching and downloading, improving the efficiency and accuracy of data collection. This lays a solid foundation for subsequent data processing and the generation of market risk reports. In practical applications, the data access script may also include error handling mechanisms to ensure that the system can automatically adjust or issue alerts when the data source is unavailable or the data format changes, thereby maintaining the stability and flexibility of the data processing workflow.

[0084] In one exemplary embodiment, performing data processing operations on N data reports to obtain a target data table includes: performing the data integration operation on the N data reports to obtain a first data table; performing the data verification operation on the first data table to obtain a second data table; performing the data cleaning operation on the second data table to obtain a third data table; and performing the data format conversion operation on the third data table to obtain the target data table.

[0085] Optionally, the data integration operation is performed on the N data reports to obtain a first data table, including: establishing a correspondence between the first data report and the second data report based on the product identifier of the target product, wherein the first data report is the customer transaction details table of the target product, and the second data report is the market transaction details table of the target product, and both the first data report and the second data report are reports among the N data reports; verifying the transaction information in the second data report using a third data report, wherein the third data report is a ledger details table among the N data reports; and merging the matching transaction information in the first data report and the second data report according to the correspondence to obtain the first data table, provided that the transaction information in the second data report is correct.

[0086] In this embodiment, the product identifier is a code or name used in transaction data to uniquely identify a specific transaction product, such as the ISIN (International Securities Identification Number) of a certain derivative or the SKU (Stock Keeping Unit) of a commodity.

[0087] The first data report can be a customer transaction details report, recording transaction details between customers and financial institutions, including customer information, transaction time, transaction type (buy / sell), transaction volume, and price. The second data report can be a market transaction details report, reflecting the financial institution's trading activities in the market, including closing trades with different counterparties and possible proprietary trading. The third data report can be a ledger details report, which is the financial institution's internal ledger recording all transactions, containing complete transaction information such as transaction number, transaction time, transaction type, counterparty, transaction volume, price, and status, used to verify the information in the market transaction details report. The correspondence is based on product identifiers, establishing a link between the customer transaction details report and the market transaction details report to ensure correct matching of transaction records during data integration.

[0088] Optionally, performing the data verification operation on the first data table to obtain the second data table includes: obtaining a first data list and a second data list from the first data table, wherein the first data list includes customer transaction information of the target product, and the second data list includes market transaction information of the target product; if the first transaction parameter in the first data list matches the second transaction parameter in the second data list, and both the first data list and the second data list are complete, then the first data table is determined to be the first data table.

[0089] In this embodiment, the first data list is a collection of data containing customer transaction information. This information typically includes detailed data about the customer's transaction, such as transaction date, transaction time, transaction product type, transaction direction (buy / sell), transaction volume, transaction price, and customer ID. The first data list is an abstract representation of the customer transaction details table, where each record (i.e., the first transaction parameter) represents a specific customer transaction.

[0090] The second data list, preceding the first data table, contains a collection of market transaction information. This information pertains to the bank's trading activities in the market, including transaction number, transaction time, product type, transaction direction, transaction volume, transaction price, and counterparty. The second data list is an abstract representation of the market transaction details table, with each record (i.e., the second transaction parameter) representing a single market transaction by the bank.

[0091] The first transaction parameter and the second transaction parameter refer to the key fields of customer transaction information in the first data list and the key fields of market transaction information in the second data list, respectively. These parameters may include product type, transaction volume, transaction price, etc., and are used to determine the matching and completeness of transaction information.

[0092] Data validation operation: After data integration, the information in the first data table is validated to ensure the consistency and accuracy of customer transaction information and market transaction information. Data validation mainly involves data integrity verification and logical consistency checks, such as confirming that all transactions have corresponding counterparties, that transaction volume and price are within reasonable ranges, and that the transaction time is reasonable.

[0093] Optionally, performing the data cleaning operation on the second data table to obtain a third data table includes: determining the data table format of the second data table and the attribute data of each column; generating multiple data cleaning instructions according to the data table format and the attribute data; loading the multiple data cleaning instructions into the second data table to delete duplicate data, erroneous data and fill in missing data in the second data table to obtain the third data table.

[0094] Optionally, the data table format refers to the structure and layout of the data in the second data table, including column names, data types, and column order. The specification of the data table format is to ensure data consistency and standardization, facilitating subsequent data cleaning, analysis, and report generation.

[0095] Attribute data refers to the specific characteristics and requirements of each column (or field) in a data table, including the data type (such as date, number, text), the data range (such as the date format should be "yyyy-mm-dd"), the data integrity requirements (such as all transaction records should contain key fields such as transaction date and transaction volume), and the logical relationship of the data (such as the transaction volume and transaction price cannot be zero at the same time).

[0096] Data cleaning instructions: Rules or commands generated based on the data table format and attribute data for data cleaning. These instructions may include specific operations such as deleting duplicate records, filling in missing values, and correcting erroneous data, aiming to improve data quality and ensure data accuracy and integrity.

[0097] Duplicate data: In a data table, if there are identical records or data points, this will be considered duplicate data. For example, two completely identical transaction records, or multiple records of the same day, the same product, and the same transaction volume, are all duplicate data and need to be identified and deleted during the data cleaning process.

[0098] Error data refers to data in a data table that does not meet the requirements of attribute data or logical rules. This may include format errors (such as incorrect date format), value range errors (such as negative transaction volume), logical errors (such as transaction date being later than the expiration date), etc.

[0099] Missing data refers to data in a data table where certain fields are not filled or are blank. For example, transaction records lacking transaction prices or counterparty information would be considered missing data and need to be identified and appropriately filled or corrected during data cleaning.

[0100] Optionally, performing the data format conversion operation on the third data table to obtain the target data table includes: obtaining attribute data of each column cell in the third data table; generating format conversion instructions based on the attribute data of each column cell; loading multiple format conversion instructions into the third data table to convert the data of each column cell in the third data table according to the data format in the conversion instructions, thereby obtaining the target data table.

[0101] Optionally, the algorithmic logic used in data integration, data validation, data cleaning, and data format conversion operations largely depends on the specific characteristics of the data and business requirements. For example, data integration operations can use the Join algorithm: merging multiple data tables into one based on a specified key (such as product identifier, customer ID, etc.). This can be accomplished using SQL's JOIN operation or Python's pandas library's merge function. If the data involves time series, timestamp alignment algorithms are used to ensure the data is merged correctly in chronological order, avoiding time misalignment. When integrating data, it may be necessary to summarize or average certain fields, which requires aggregation algorithms such as SUM and AVERAGE. Duplicate records are identified and removed by hashing or comparing key fields, ensuring that each transaction in the dataset has a unique representation.

[0102] Data validation operations can utilize several methods: Integrity validation: Statistical methods are used to check if each column contains data, ensuring no key fields are missing. Consistency validation: Relevant fields, such as transaction volume and price, are compared between the customer transaction information list (first data list) and the market transaction information list (second data list) to ensure logical consistency. Range and format validation: Regular expressions or conditional statements are used to verify if the data is within a valid range, such as whether the transaction date conforms to a specific format and whether the transaction price is within a reasonable range. Anomaly detection algorithms: Outlier detection algorithms from statistics, such as Z-score and IQR, are applied to identify and flag potentially abnormal transaction data.

[0103] Data cleaning operations include: Missing value imputation: For missing values, statistical methods (such as mean and median) can be used for imputation, or machine learning models based on other fields can be used for prediction. Error value correction: Conditional statements are used to identify illogical or unformatted error values, such as negative transaction volumes, and these values ​​are then corrected or deleted according to specific rules. Duplicate data removal: Hash tables or comparison algorithms based on key fields are used to identify and delete duplicate records, reducing data redundancy. Data type conversion: Ensure that the data types of all fields match expectations, using type conversion functions such as pandas' astype() function.

[0104] Data format conversion operations can be performed using date and time format conversion: Use Python's `datetime` library or pandas' `to_datetime()` function to convert string dates to a uniform date and time format, such as "yyyy-mm-ddHH:MM:SS". Numeric format standardization: After data cleaning, ensure all numeric fields have the same precision and format, such as uniform currency units and decimal places. Text field formatting: Clean text fields, removing extra spaces and standardizing case to improve readability and consistency. Data structure transformation: If necessary, convert wide tables to long tables, or vice versa, using pandas' `melt()` and `pivot()` functions. Standardized field naming: Ensure all field names conform to established conventions for easier subsequent data analysis and report generation.

[0105] For example, the above embodiments will be described below with reference to specific examples. Suppose a game company needs to generate a quarterly market risk report on its virtual goods transactions. The following are the specific steps for implementing this embodiment:

[0106] Step 1: Data Integration Operation: Obtain the following four data reports from the game's internal database, player transaction record system, and market analysis tools:

[0107] Player Transaction Records: Records details of virtual goods transactions between players, including transaction time, type of goods, quantity, price, and account information of both parties.

[0108] "Commodity Price Fluctuation Record": Records the changes in virtual commodity prices within a quarter, including the highest price, lowest price, and average price.

[0109] The Suspicious Transaction Activity List lists all transaction activities marked as suspicious during the quarter, including abnormal transaction amounts and excessive transaction frequency.

[0110] Player Credit Assessment Report: Based on players' historical behavior data, this report assesses players' creditworthiness, including credit rating and violation records.

[0111] Using the pandas library in Python, the above report data is integrated into a first data table named "Quarterly Virtual Goods Transaction Data Integration Table," ensuring that all relevant transaction data is included. The pandas merge function is used to perform a JOIN operation based on product identifiers. A time series alignment algorithm is used to ensure that all transaction records are correctly sorted according to transaction time.

[0112] Step 2: Data Validation Operation: Perform a data validation operation on the first data table to check the integrity and consistency of the data. For example, verify whether the quantity and price of goods in the transaction records match the data in the commodity price fluctuation records, and confirm whether the marking of suspicious transaction activities is correct. Correct or remove data that does not conform to the rules, and generate the second data table.

[0113] Step 3: Data Cleaning: Clean the second data table by removing duplicate transaction records, filling in missing product price data, correcting date format errors, and handling suspicious transactions to ensure data accuracy and quality. After this step, a third data table is generated for subsequent data format conversion. Use the pandas `dropna` function to check and mark missing values. Use the pandas `fillna` function to fill in missing values. Delete records with negative transaction volumes using conditional statements. Use the pandas `drop_duplicates` function to delete duplicate transaction records. Convert data types using the pandas `astype` function.

[0114] Step 4: Data Format Conversion: Perform data format conversion on the third data table, standardizing field names (e.g., unifying "Transaction Time" to "trans_time", "Product Type" to "item_type", etc.), adjusting numerical formats (e.g., representing prices as values ​​with a fixed decimal place), and unifying date formats (e.g., "YYYY-MM-DD") to generate the target data table, i.e., the fourth data table. Use pandas' to_datetime function to unify the format of transaction dates. Use pandas' pivot_table function to convert the transaction data from long format to wide format, facilitating the creation of multi-dimensional reports.

[0115] Step 5: Generate Data Report: Based on the target data table, use report generation tools (such as Python's matplotlib library for plotting, pandas library for data analysis, and Jinja2 template engine for generating report text) to automatically generate the "Quarterly Virtual Commodity Trading Market Risk Report." The report includes, but is not limited to, the following:

[0116] "Overview of Virtual Goods Trading Risks": This section displays the trading volume, transaction amount, price fluctuation range, and market risk trends of virtual goods within a quarter.

[0117] "Analysis of Suspicious Transaction Activities": This section provides a detailed list and analysis of transactions marked as suspicious, including information such as transaction amount, transaction time, products involved, and players.

[0118] Player Credit Risk Assessment: Based on integrated transaction data and credit assessment reports, analyze player credit risk and identify high-risk players.

[0119] "Market Risk Warning and Response Strategies": Based on data analysis, the system automatically identifies potential market risk factors, such as abnormal price fluctuations and player fraud, providing early warnings to game operators and suggesting corresponding risk control strategies.

[0120] Through the specific implementation steps outlined above, game companies can systematically process and analyze virtual goods transaction data, ensuring data accuracy and consistency while improving the efficiency and professionalism of report preparation. This plays a crucial role in managing in-game market risks, preventing fraud, and maintaining the stability of the game's economic system. Furthermore, this approach helps game companies better understand player behavior and optimize game design and operational strategies.

[0121] For example, a specific implementation in a financial scenario includes the following steps:

[0122] Bank objective: To generate a monthly report on market risks related to precious metal derivatives.

[0123] Step 1: Data integration operation:

[0124] First data report: "Client Precious Metals Derivatives Transaction Details".

[0125] Second data report: "Detailed Statement of Bank Precious Metals Derivatives Market Transactions".

[0126] The third data report: "Detailed Statement of Precious Metals Derivatives Trading Ledger".

[0127] Product Identifier: ISIN code for precious metal derivatives.

[0128] Use Python's pandas library to establish a mapping between the customer transaction table and the market transaction table based on the ISIN code (product identifier).

[0129] Verify market transaction records against the transaction ledger details to ensure data accuracy.

[0130] Merge the matching transaction information from the two detail tables to generate the "Precious Metals Derivatives Transaction Integration Table" (i.e., the first data table).

[0131] Step 2: Data validation operation:

[0132] The "Client Precious Metals Derivatives Transaction List" and the "Bank Precious Metals Derivatives Market Transaction List" are separated from the "Precious Metals Derivatives Transaction Consolidation Table".

[0133] Verify the consistency of transaction parameters between the two lists, such as transaction volume and transaction price, which should match the records in the transaction ledger.

[0134] If the transaction parameters match and the data is complete, the validity of the data table is confirmed, and the "Verified Precious Metals Derivatives Transaction Table" (i.e., the second data table) is obtained.

[0135] Step 3: Data cleaning operation:

[0136] Clarify the data format and attribute data requirements for the "Verified Precious Metals Derivatives Transaction Table".

[0137] Generate data cleaning instructions, such as deleting duplicate transactions, correcting transaction date formats, and filling in counterparty information.

[0138] Execute the cleaning instruction to obtain the "Cleaned Precious Metals Derivatives Trading Table" (i.e., the third data table).

[0139] Step 4: Data format conversion operation:

[0140] Based on the attribute data requirements, obtain the format requirements for fields such as date and price in the "Cleaned Precious Metals Derivatives Trading Table".

[0141] Generate format conversion instructions, such as uniformly converting date fields to "yyyy-mm-dd" format, and ensuring that numeric fields use a fixed decimal point.

[0142] Apply format conversion instructions to ensure that each record in the data table conforms to a uniform data format, resulting in the "Standardized Precious Metals Derivatives Trading Table" (i.e., the target data table).

[0143] Through the above examples, companies in both the gaming and financial industries can adopt a systematic approach to process and prepare data, laying a solid data foundation for generating high-quality market risk reports. This approach not only improves the accuracy and efficiency of data processing but also ensures data consistency and standardization, providing a reliable data source for subsequent data analysis and report generation. Furthermore, through data cleaning and format conversion, companies can effectively reduce errors and omissions in the data processing process, improving the accuracy and timeliness of market risk assessment.

[0144] In an exemplary embodiment, generating a data report for the target product based on the target data table includes: receiving a user request and responding to the user request; extracting data from the target data table in N columns corresponding to the request categories included in the user request, wherein the user request is used to request the generation of the data report; inputting the data in the N columns and the user request into a target model respectively to obtain the data report output by the target model, wherein the target model includes a data pivot sub-model and a data visualization sub-model, the data pivot sub-model is used to extract the data format and data content of the data in the N columns, and to extract the data report format requested in the user request, the data visualization sub-model is used to select a visualization component according to the data format and the data content, and the visualization component is used to generate a visualization graphic or chart of the data in the N columns corresponding to the data report format, thereby obtaining the data report.

[0145] Optionally, in this embodiment, the target data table is a standardized dataset that has undergone data integration, verification, cleaning, and format conversion, ready for data analysis and report generation.

[0146] User requests are requests triggered automatically by business analysts, risk managers, or the system, and are used to specify the report type, format, analysis dimensions, and data range.

[0147] The request category is the classification of report types included in the user's request, such as market risk analysis reports, customer activity overview reports, trend forecast reports, etc.

[0148] The data in the N-list cells are multiple subsets of data extracted from the target data table according to the user's request, with each subset corresponding to different analysis dimensions or reporting requirements.

[0149] The target model plays a central role in generating data reports, and it consists of two main parts: a data pivoting sub-model and a data visualization sub-model. The target model aims to extract data from the target data table, perform multi-dimensional analysis, and present the analysis results to the user in an intuitive visual format. Below is a detailed description of the target model:

[0150] The pivot table sub-model is used to extract data from N tables and summarize and pivot the data according to the analysis dimensions specified in the user request. The core of this sub-model lies in its ability to flexibly handle data from different tables and dynamically generate pivot tables based on business needs. The following are the key functions and implementation methods of the pivot table sub-model:

[0151] Multidimensional data aggregation: It can aggregate data based on multiple dimensions such as time, product type, and customer classification, and calculate statistical indicators such as sum, average, maximum, and minimum values.

[0152] Dynamic data filtering: Data is filtered based on specific conditions in the user's request (such as date range, product type, transaction volume threshold, etc.), and only data records that meet the requirements are retained.

[0153] Data pivoting and cross-analysis: It can perform complex pivoting analysis on data, such as calculating the market share of different product types at different time periods, or analyzing the transaction behavior of different customers on specific products.

[0154] Outlier detection and handling: During the pivot table process, it can detect and mark outlier values, such as extreme values ​​and missing values, and provide options to correct or delete these outliers.

[0155] Data format conversion: Ensure that the data format used in the pivot table process is consistent with the requirements of the target data report, such as date format and decimal precision.

[0156] Python's widely used data processing and analysis libraries offer powerful data structures and manipulation capabilities, such as DataFrames and Series, suitable for pivoting and filtering data. SQL is a structured query language used for data querying and summarizing, suitable for pivoting operations in large database environments.

[0157] The purpose of the data visualization sub-model is to present the data output by the pivot table sub-model in the form of charts or graphs, making it easier for users to understand and analyze. This sub-model needs to select the most suitable visualization components based on the characteristics of the data and user preferences, and generate the corresponding charts. The following are the key functions and implementation methods of the data visualization sub-model:

[0158] Chart type selection: Based on the data report format and data characteristics, automatically or manually select the most suitable chart type, such as line chart, bar chart, pie chart, scatter plot, heat map, etc.

[0159] Chart generation: Use chart generation libraries or tools, such as Matplotlib, Seaborn, Plotly, Power BI, etc., to generate visual charts based on data format and content.

[0160] Chart style customization: The chart style can be customized according to user needs, such as color, title, legend, axis, etc., to improve the aesthetics and professionalism of data reports.

[0161] Interactive chart creation: Where applicable, create interactive charts that allow users to explore data by using the mouse or touching the screen, such as by hovering to view specific values ​​or by dragging to adjust the time range.

[0162] Chart layout and integration: Arrange multiple charts in a reasonable layout and integrate them into a complete data report. This may involve page design, layout adjustment and application of report templates.

[0163] Matplotlib and Seaborn: Important Python libraries for data visualization, offering rich chart types and customization options. Plotly: An interactive charting library supporting dynamic updates and user interaction, suitable for visualizing real-time data reports. Power BI and Tableau: Business intelligence tools for creating complex visualization dashboards and reports, supporting multiple data sources and advanced data visualization features.

[0164] The overall process of the target model includes:

[0165] Receive user requests: Obtain report generation requests submitted by users through the interface or API. The request should include the type, format, and analysis dimensions of the data report.

[0166] Data Extraction and Pivot: The data pivot sub-model extracts the data specified by the user from the target data table and performs data aggregation, filtering, and pivot analysis.

[0167] Chart type selection and generation: The data visualization sub-model selects the appropriate chart type based on the data pivot results and reporting requirements, and generates the corresponding visualization chart.

[0168] Report integration and delivery: Integrate charts and other text information into the final data report, output the report according to the user's requested format (such as PDF, Word, online report, etc.), and send it to the user via email, system interface, or API interface.

[0169] The advantage of the target model lies in its ability to automatically and efficiently process large amounts of data and present it to users in an easy-to-understand visual format, significantly improving the speed and accuracy of data report generation. Furthermore, through flexible configuration and parameter settings, the target model can adapt to different business scenarios and user needs, exhibiting high scalability and adaptability.

[0170] For example, in the scenario of financial derivatives trading risk reporting, the target model can be configured with multiple predefined analytical dimensions and chart types to suit the needs of decision-makers at different levels. For business departments, the model may generate charts that include market trends, trading volume, and customer behavior; while for senior management, the model may focus on advanced views of key indicators such as risk exposure, profit forecasts, and market stability.

[0171] In scenarios involving transactions within a game, the target model needs to adapt to the game's data structure and analytical requirements, such as transaction frequency, player behavior patterns, and changes in market supply and demand. This may involve more user interaction design and game data analysis skills.

[0172] In summary, the target model, through the combined capabilities of its data pivoting and data visualization sub-models, provides users with a fast, accurate, personalized, and intuitive data report generation solution, improving the efficiency of data analysis and the timeliness of decision-making.

[0173] In an exemplary embodiment, after generating a data report for the target product based on the target data table, the method further includes: acquiring transaction data of the target product in real time; calculating a fluctuation threshold for the transaction data using the real-time trend of the transaction data; calculating the update frequency of the data report using the fluctuation threshold; and updating the data report according to the update frequency.

[0174] Optionally, in this embodiment, real-time transaction data refers to transaction information generated in the market in real time, including but not limited to transaction price, transaction volume, transaction time, etc., which is usually obtained through API interface or real-time data stream technology.

[0175] The volatility threshold is a quantitative indicator used to measure the magnitude of market volatility, calculated based on the changing trends of historical and real-time trading data. When market volatility exceeds this threshold, it is considered a significant change in market conditions, requiring appropriate response measures to be triggered.

[0176] Update frequency refers to the periodic time interval between the generation and updating of data reports, which can be regular (such as daily, weekly, or monthly) or event-driven (such as when market fluctuations exceed a certain threshold).

[0177] Dynamic report updates: This is an automated process that automatically adjusts the content and update frequency of data reports based on market conditions and data changes to ensure the timeliness and accuracy of the reports.

[0178] For example, in in-game trading scenarios, real-time transaction data can be obtained: game operators use real-time data collection systems, such as Kafka or Redis Streams, to continuously collect transaction data between players in the game, including transaction time, transaction volume, and transaction price.

[0179] Calculate the volatility threshold: Using a sliding window statistical method, monitor the average and standard deviation of a commodity's trading price over a past period (e.g., the most recent hour) in real time. Calculate the real-time volatility based on the standard deviation and compare it with historical volatility. Set the volatility threshold to 1.5 times the historical volatility.

[0180] Calculation update frequency: If the real-time volatility exceeds the volatility threshold, the system will automatically adjust the update frequency from once a day to once every 4 hours in order to respond quickly to market changes.

[0181] Dynamic Report Updates: The system periodically extracts new data segments from real-time transaction data based on the update frequency and integrates them with historical data. It then re-executes data integration, verification, cleaning, and format conversion operations to update the target data table. An updated "Quarterly Transaction Risk Analysis Report" is generated, highlighting periods of abnormal price fluctuations and transaction details. If volatility exceeds the threshold for multiple consecutive periods, the system automatically sends an alert email to the game operations team, prompting them to pay attention to market volatility.

[0182] For example, in the scenario of precious metal derivatives trading in banks.

[0183] Real-time access to transaction data: Banks continuously obtain real-time transaction data of precious metal derivatives through API interfaces with major global precious metal exchanges and trading platforms, including information such as trading volume, trading price, and counterparties.

[0184] Calculate the volatility threshold: Based on time series analysis, calculate the mean and volatility of precious metal prices over a past period (e.g., the most recent week). Set a volatility threshold based on the calculated volatility; for example, set the volatility threshold to 1.2 times the volatility of the past week.

[0185] Calculate update frequency: If real-time monitoring shows that precious metal price fluctuations exceed the fluctuation threshold, the system will automatically adjust the market risk report update frequency from once a month to once a week or once a day.

[0186] Dynamic Report Updates: Based on the adjusted update frequency, the system automatically retrieves new datasets from real-time trading data and merges them with historical data. It then re-executes data cleaning and format conversion operations to update the target data table, the "Standardized Precious Metals Derivatives Trading Table." Using data pivoting and visualization sub-models, it generates the latest "Monthly Precious Metals Derivatives Market Risk Report," highlighting the instruments and time periods exhibiting abnormal price fluctuations. If volatility remains high, the system automatically adds dimensions to risk analysis, such as adding stress test scenarios or introducing advanced analytical models, to more comprehensively assess market risk.

[0187] Through the above examples, we can see that the acquisition and analysis of real-time transaction data not only improves the timeliness of data reports but also dynamically adjusts the update frequency according to market changes, ensuring that the report content remains synchronized with the latest market conditions. This is of great significance for quickly responding to market fluctuations and effectively managing and controlling risks. In the financial and gaming industries, this dynamic reporting update mechanism has become an important tool for improving data analysis capabilities and risk management efficiency.

[0188] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0189] This embodiment also provides a data report generation apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0190] Figure 3 This is a structural block diagram of a data report generation apparatus according to an embodiment of this application, such as... Figure 3 As shown, the device includes:

[0191] The first acquisition module 32 is used to acquire N data reports within a target time period, wherein the N data reports are tables that record transaction data of the target product based on N recording angles, and N is a natural number greater than 1.

[0192] The first processing module 34 is used to perform data processing operations on N data reports to obtain a target data table. The data processing operations include, in sequence: data integration operation, data verification operation, data cleaning operation, and data format conversion operation.

[0193] The first generation module 36 is used to generate a data report of the target product based on the target data table, wherein the data report is used to represent the changes in the transaction risk of the target product within the target time period.

[0194] In an exemplary embodiment, the first acquisition module 32 includes: a first identification unit, configured to identify a data source based on the product type and transaction type of the target product, so as to determine the storage location and report format of N data reports from the data source; a first configuration unit, configured to configure the access permissions of a data access script, so as to access the data source according to the storage location and the report format through the access script; and a first download unit, configured to download N data reports from the data source.

[0195] In an exemplary embodiment, the first processing module 34 includes: a first integration unit, configured to perform the data integration operation on N data reports to obtain a first data table; a first verification unit, configured to perform the data verification operation on the first data table to obtain a second data table; a first cleaning unit, configured to perform the data cleaning operation on the second data table to obtain a third data table; and a first conversion unit, configured to perform the data format conversion operation on the third data table to obtain the target data table.

[0196] In an exemplary embodiment, the first integration unit includes: a first establishment submodule, configured to establish a correspondence between a first data report and a second data report based on the product identifier of the target product, wherein the first data report is a customer transaction detail table of the target product, the second data report is a market transaction detail table of the target product, and both the first data report and the second data report are reports among N data reports; a first verification submodule, configured to verify the transaction information in the second data report using a third data report, wherein the third data report is a ledger detail table among N data reports; and a first merging submodule, configured to merge the matched transaction information in the first data report and the second data report according to the correspondence, provided that the transaction information in the second data report is correct, to obtain the first data table.

[0197] In an exemplary embodiment, the first verification unit includes: a first acquisition submodule, configured to acquire a first data list and a second data list from the first data table, wherein the first data list includes customer transaction information of the target product, and the second data list includes market transaction information of the target product; and a first matching submodule, configured to determine the first data table as the first data table if a first transaction parameter in the first data list matches a second transaction parameter in the second data list, and both the first data list and the second data list are complete.

[0198] In an exemplary embodiment, the first cleaning unit includes: a first determining submodule, configured to determine the data table format of the second data table and the attribute data of each column; a first generating submodule, configured to generate a plurality of data cleaning instructions according to the data table format and the attribute data; and a first loading submodule, configured to load the plurality of data cleaning instructions into the second data table to delete duplicate data, erroneous data and fill in missing data in the second data table to obtain the third data table.

[0199] In an exemplary embodiment, the first conversion unit includes: a second acquisition submodule, configured to acquire attribute data of each column cell in the third data table; a second generation submodule, configured to generate format conversion instructions based on the attribute data of each column cell; and a second loading submodule, configured to load multiple format conversion instructions into the third data table to convert the data of each column cell in the third data table according to the data format in the conversion instructions, thereby obtaining the target data table.

[0200] In an exemplary embodiment, the first generation module includes: a first receiving unit, configured to receive a user request and respond to the user request by extracting data from the target data table in N columns corresponding to the request categories included in the user request, wherein the user request is used to request the generation of the data report; and a first input unit, configured to input the data in the N columns and the user request into a target model respectively to obtain the data report output by the target model, wherein the target model includes a data pivot sub-model and a data visualization sub-model, the data pivot sub-model being configured to extract the data format and data content of the data in the N columns, and to extract the data report format requested in the user request, the data visualization sub-model being configured to select a visualization component according to the data format and the data content, and the visualization component being configured to generate a visualization graphic or chart of the data in the N columns corresponding to the data report format, thereby obtaining the data report.

[0201] In one exemplary embodiment, the above apparatus further includes: a second acquisition module, configured to acquire transaction data of the target product in real time after generating a data report of the target product based on the target data table; a first calculation module, configured to calculate a fluctuation threshold of the transaction data using the real-time changing trend of the transaction data; a second calculation module, configured to calculate the update frequency of the data report using the fluctuation threshold; and a first update module, configured to update the data report according to the update frequency.

[0202] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0203] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0204] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0205] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0206] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0207] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0208] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0209] The embodiments described herein also provide a computer program that includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps in any of the above method embodiments.

[0210] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0211] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0212] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for generating a data report, characterized in that, include: Obtain N data reports within a target time period, wherein the N data reports are tables that record transaction data of the target product based on N recording perspectives, and N is a natural number greater than 1; Data processing operations are performed on N data reports to obtain a target data table. The data processing operations include, in sequence, data integration, data verification, data cleaning, and data format conversion. The data integration operation on the N data reports includes: establishing a correspondence between a first data report and a second data report based on the product identifier of the target product. The first data report is the customer transaction details table of the target product, and the second data report is the market transaction details table of the target product. Both the first data report and the second data report are reports among the N data reports. The transaction information in the second data report is verified using the third data report, wherein the third data report is a ledger detail table among N data reports; If the transaction information in the second data report is correct, the matching transaction information in the first data report and the second data report is merged according to the correspondence to obtain a first data table. If the matching transaction information in the first data report and the second data report includes a time series, the matching transaction information in the first data report and the second data report is merged in chronological order using a timestamp alignment algorithm. A data report for the target product is generated based on the target data table, wherein the data report is used to represent the changes in the transaction risk of the target product within the target time period.

2. The method according to claim 1, characterized in that, Retrieve N data reports within a target time period, including: Identify the data source based on the product type and transaction type of the target product, so as to determine the storage location and report format of N data reports from the data source; Configure access permissions for the data access script to access the data source according to the storage location and the report format; Download N data reports from the data source.

3. The method according to claim 1, characterized in that, Performing data processing operations on N data reports to obtain a target data table further includes: Perform the data validation operation on the first data table to obtain the second data table; Perform the data cleaning operation on the second data table to obtain the third data table; The data format conversion operation is performed on the third data table to obtain the target data table.

4. The method according to claim 3, characterized in that, Perform the data validation operation on the first data table to obtain a second data table, including: Obtain a first data list and a second data list from the first data table, wherein the first data list includes customer transaction information of the target product, and the second data list includes market transaction information of the target product; If the first transaction parameter in the first data list matches the second transaction parameter in the second data list, and both the first data list and the second data list are complete, then the first data table is determined to be the second data table.

5. The method according to claim 3, characterized in that, Perform the data cleaning operation on the second data table to obtain a third data table, including: Determine the data table format of the second data table and the attribute data of each column; Generate multiple data cleaning instructions according to the data table format and the attribute data; Multiple data cleaning instructions are loaded into the second data table to delete duplicate data, erroneous data, and fill in missing data, thereby obtaining the third data table.

6. The method according to claim 3, characterized in that, Performing the data format conversion operation on the third data table to obtain the target data table includes: Obtain the attribute data of each column in the third data table; Format conversion instructions are generated based on the attribute data of each column. Multiple format conversion instructions are loaded into the third data table to convert the data in each column of the third data table according to the data format in the conversion instructions, thereby obtaining the target data table.

7. The method according to claim 1, characterized in that, Generate a data report for the target product based on the target data table, including: Receive a user request and respond to the user request, extract data from the target data table from N list cells corresponding to the request categories included in the user request, wherein the user request is used to request the generation of the data report; The data in the N columns and the user request are respectively input into the target model to obtain the data report output by the target model. The target model includes a data pivot sub-model and a data visualization sub-model. The data pivot sub-model is used to extract the data format and data content of the data in the N columns, and to extract the data report format requested in the user request. The data visualization sub-model is used to select visualization components according to the data format and data content. The visualization components are used to generate visualization graphics or charts of the data in the N columns corresponding to the data report format to obtain the data report.

8. The method according to claim 1, characterized in that, After generating a data report for the target product based on the target data table, the method further includes: Real-time acquisition of transaction data for the target product; The fluctuation threshold of the transaction data is calculated using the real-time trend of the transaction data. The update frequency of the data report is calculated using the fluctuation threshold; The data report is updated according to the stated update frequency.

9. A data report generation apparatus, characterized in that, include: The first acquisition module is used to acquire N data reports within a target time period, wherein the N data reports are tables that record transaction data of the target product based on N recording angles, and N is a natural number greater than 1. The first processing module is used to perform data processing operations on the N data reports to obtain a target data table. The data processing operations include, in sequence: data integration operation, data verification operation, data cleaning operation, and data format conversion operation. The first processing module includes: a first integration unit, configured to perform the data integration operation on N data reports; the first integration unit includes: a first establishment submodule, configured to establish a correspondence between a first data report and a second data report based on the product identifier of the target product, wherein the first data report is a customer transaction detail table of the target product, and the second data report is a market transaction detail table of the target product, and both the first data report and the second data report are reports among the N data reports; a first verification submodule, configured to verify the transaction information in the second data report using a third data report, wherein the third data report is a ledger detail table among the N data reports; and a first merging submodule, configured to merge the matching transaction information in the first data report and the second data report according to the correspondence, if the transaction information in the second data report is correct, to obtain a first data table, wherein if the matching transaction information in the first data report and the second data report includes a time series, a timestamp alignment algorithm is used to merge the matching transaction information in the first data report and the second data report in chronological order. The first generation module is used to generate a data report for the target product based on the target data table, wherein the data report is used to represent the changes in the transaction risk of the target product within the target time period.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 1 to 8.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 8.

Images