Financial service database maintenance method, electronic equipment and storage medium

Abstract

The invention relates to the field of financial insurance and the technical field of computers, in particular to a financial service database maintenance method, electronic equipment and a storage medium. According to the financial service database maintenance method provided by the embodiment of the invention, data iteration duration corresponding to each piece of financial service data needs to be determined for a plurality of pieces of financial service data stored in a financial service data warehouse; aiming at a data display management component, determining a display page generation duration corresponding to each piece of financial service data; performing time length comparison on the data iteration time length and the display page generation time length to determine a target cooling time length; and configuring the updating time interval of the financial service data warehouse as the target cooling duration, so that the financial service data warehouse executes a round of service data updating operation every the target cooling duration. In this way, the data timeliness can still be taken into account when a large amount of data is efficiently processed.

Description

Technical Field

[0001] The present application relates to the fields of finance and insurance, and computer technology, and in particular to a financial business database maintenance method, electronic equipment, and storage medium. Background Art

[0002] In the financial and insurance sectors, there are high requirements for the real-time nature of business data and data analysis capabilities. Traditional data warehouse architectures include real-time architecture and offline architecture.

[0003] In the related technologies, although the real-time architecture can achieve millisecond-level data loading, its ability to process large amounts of data is limited; while the offline architecture, although good at processing massive amounts of data, often cannot meet the needs of real-time updates and can usually only update data after a certain period of time. Therefore, how to efficiently process large amounts of data while still taking into account data timeliness is still a problem that needs to be solved in the industry. Summary of the invention

[0004] The present application aims to solve at least one of the technical problems existing in the prior art. To this end, the present application proposes a financial business database maintenance method, electronic device, and storage medium, which can efficiently process a large amount of data while still taking into account the timeliness of the data.

[0005] According to the first aspect of the present application, a financial service database maintenance method includes:

[0006] For a plurality of financial business data stored in a financial business data warehouse, determining a data iteration duration corresponding to each of the financial business data;

[0007] For the data display management component, determining the generation time of the display page corresponding to each of the financial business data;

[0008] Comparing the data iteration duration with the display page generation duration to determine a target cooling duration;

[0009] The update time interval of the financial business data warehouse is configured as the target cooling time, so that the financial business data warehouse performs a round of business data update operation every time the target cooling time is exceeded.

[0010] According to some embodiments of the present application, the data iteration duration includes a data synchronization time interval, and the determining, for a plurality of financial business data stored in a financial business data warehouse, a data iteration duration corresponding to each of the financial business data includes:

[0011] For each of the financial business data in the financial business data warehouse, determining a corresponding business data source;

[0012] According to the historical data interaction record between the financial business data warehouse and the business data source, query multiple historical synchronization durations corresponding to different types of historical business data in the historical data interaction record;

[0013] The data synchronization time interval corresponding to the financial service data type is determined from the multiple historical synchronization time periods.

[0014] According to some embodiments of the present application, querying multiple historical synchronization durations corresponding to different types of historical business data in the historical data interaction record according to the historical data interaction record between the financial business data warehouse and the business data source includes:

[0015] Querying the historical data interaction records between the financial business data warehouse and the business data source to determine the historical data interaction details corresponding to each type of the historical business data;

[0016] For each type of historical business data, determine the historical sub-data synchronization duration corresponding to each piece of historical business data stored in the financial business data warehouse by the business data source from the historical data interaction details, and calculate the historical synchronization duration based on the corresponding synchronization durations of each historical sub-data.

[0017] According to some embodiments of the present application, the calculating the historical synchronization duration according to the corresponding synchronization durations of each historical sub-data includes:

[0018] Calculate the average synchronization duration of each historical sub-data of the same type of historical business data to obtain the average synchronization duration of the sub-data;

[0019] The sub-data synchronization mean duration is determined as the historical synchronization duration.

[0020] According to some embodiments of the present application, the data iteration duration also includes a data cleaning time interval, and the determining of the data iteration duration corresponding to each of the plurality of financial business data stored in the financial business data warehouse further includes:

[0021] For each of the financial business data stored in the financial business data warehouse, query the historical cleaning duration corresponding to different types of the financial business data;

[0022] The data cleaning time interval corresponding to the financial business data type is determined from the multiple historical cleaning time periods.

[0023] According to some embodiments of the present application, the data iteration duration also includes a data processing time interval, and the determining of the data iteration duration corresponding to each of the plurality of financial business data stored in the financial business data warehouse further includes:

[0024] For each of the financial business data stored in the financial business data warehouse, query the historical processing time corresponding to different types of the financial business data;

[0025] The data processing time interval corresponding to the financial business data type is determined from the multiple historical processing time periods.

[0026] According to some embodiments of the present application, the comparing the data iteration duration and the display page generation duration to determine the target cooling duration includes:

[0027] From the data synchronization time interval, the data cleaning time interval, the data processing time interval and the display page generation time interval, select the shortest time interval as the benchmark reference time interval;

[0028] The target cooling time is configured according to the benchmark reference time.

[0029] According to some embodiments of the present application, the determining, for the data display management component, the display page generation duration corresponding to each of the financial business data includes:

[0030] Obtaining the display indicator type and display page rendering time corresponding to each of the financial business data in the data display management component;

[0031] For each display indicator type, determine the indicator data generation time corresponding to each page display indicator;

[0032] The display page generation duration is determined according to the indicator data generation time corresponding to each display indicator type and the display page rendering duration.

[0033] In a second aspect, an embodiment of the present application provides an electronic device, comprising: a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the financial business database maintenance method as described in any one of the embodiments of the first aspect of the present application.

[0034] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the storage medium stores a program, and the program is executed by a processor to implement a financial business database maintenance method as described in any one of the embodiments of the first aspect of the present application.

[0035] The financial service database maintenance method, electronic device, and storage medium according to the embodiments of the present application have at least the following beneficial effects:

[0036] According to the financial business database maintenance method of the embodiment of the present application, it is necessary to first determine the data iteration duration corresponding to each of the multiple financial business data stored in the financial business data warehouse; determine the display page generation duration corresponding to each of the financial business data for the data display management component; compare the data iteration duration and the display page generation duration to determine the target cooling duration; configure the update time interval of the financial business data warehouse to the target cooling duration, so that the financial business data warehouse performs a round of business data update operations every time the target cooling duration is exceeded. In this way, it is possible to efficiently process a large amount of data while still taking into account data timeliness.

[0037] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:

[0039] Figure 1 A flowchart of a method for maintaining a financial service database provided in an embodiment of the present application;

[0040] Figure 2 Another flowchart of the financial service database maintenance method provided in the embodiment of the present application;

[0041] Figure 3 Another flowchart of the financial service database maintenance method provided in the embodiment of the present application;

[0042] Figure 4 Another flowchart of the financial service database maintenance method provided in the embodiment of the present application;

[0043] Figure 5 Another flowchart of the financial service database maintenance method provided in the embodiment of the present application;

[0044] Figure 6 Another flowchart of the financial service database maintenance method provided in the embodiment of the present application;

[0045] Figure 7 Another flowchart of the financial service database maintenance method provided in the embodiment of the present application;

[0046] Figure 8Another flowchart of the financial service database maintenance method provided in the embodiment of the present application;

[0047] Fig. 9 It is a schematic diagram of the hardware structure of the electronic device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0048] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be understood as limiting the present application.

[0049] In the description of this application, "several" means one or more, "more" means more than two, "greater than", "less than", "exceed", etc. are understood to exclude the number itself, and "above", "below", "within", etc. are understood to include the number itself. If there is a description of "first" or "second", it is only used for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.

[0050] In the description of the present application, it should be understood that descriptions involving orientation, such as up, down, left, right, front, back, etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as a limitation on the present application.

[0051] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "illustrative embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0052] In the description of this application, it should be noted that, unless otherwise clearly defined, the terms such as setting, installing, connecting, etc. should be understood in a broad sense, and technicians in the relevant technical field can reasonably determine the specific meanings of the above terms in this application in combination with the specific content of the technical solution. In addition, the identification of specific steps below does not represent a limitation on the order of steps and execution logic. The execution order and execution logic between each step should be understood and inferred with reference to the contents described in the embodiment.

[0053] In the financial and insurance sector, the real-time nature of business data and data analysis capabilities are both highly demanded, which poses a special challenge to the data architecture in this field. Traditional data warehouse architectures are mainly divided into real-time architectures and offline architectures, each with its own advantages and limitations.

[0054] The main advantage of real-time architecture is that it can load data in milliseconds, which is critical for financial businesses that need to respond quickly to market changes and customer behavior. For example, in insurance claims or risk assessment, the ability to quickly process and analyze data and make timely decisions can significantly improve service efficiency and customer satisfaction. However, this architecture is limited in its ability to process large amounts of data, possibly because the real-time processing of large amounts of data requires high computing resources, resulting in increased costs and processing capacity bottlenecks.

[0055] Offline architecture is good at processing massive amounts of data and is suitable for scenarios that do not require immediate feedback. This architecture can perform complex queries and analyses, such as generating financial reports or conducting long-term trend analysis. However, it is usually difficult to meet the needs of real-time updates, and the data update timeliness is poor, usually only T+1 data update timeliness can be achieved. The "T" here represents today's date, and "T+1" means that today's resource flow and data will be processed and reported on the next day. In other words, under this data update mode, it is difficult to achieve real-time or same-day data updates, and there is a one-day time difference.

[0056] In the financial insurance sector, the limitations of offline architectures may lead to several problems. First, the lack of real-time nature of business data may affect risk management, for example, failure to detect and respond to high-risk behaviors in a timely manner. Second, delays in data updates may affect the effectiveness of customer service and business activities, as they rely on the latest business data for personalized recommendations and decision-making. In addition, inefficient use of computing resources is also a problem, as a large amount of computing resources may be idle during non-peak hours, resulting in a waste of costs.

[0057] In summary, the technical problems faced by the financial and insurance sectors in data architecture include how to balance real-time performance and the ability to process large amounts of data, how to improve the timeliness of data updates, and how to more effectively utilize computing resources to reduce costs and improve efficiency. Solving these problems requires innovative data architecture and processing technologies to meet the growing demand for data real-time performance and analytical capabilities in the financial and insurance industries.

[0058] The present application aims to solve at least one of the technical problems existing in the prior art. To this end, the present application proposes a financial business database maintenance method, electronic device, and storage medium, which can efficiently process a large amount of data while still taking into account the timeliness of the data.

[0059] Further explanation is given below based on the accompanying drawings.

[0060] Reference Figure 1 According to the financial service database maintenance method of the embodiment of the present application, the method may include:

[0061] Step S101, determining the data iteration duration corresponding to each financial business data stored in the financial business data warehouse;

[0062] Step S102, for the data display management component, determining the generation time of the display page corresponding to each financial business data;

[0063] Step S103, comparing the data iteration time and the display page generation time to determine the target cooling time;

[0064] Step S104: configure the update time interval of the financial business data warehouse as the target cooling time, so that the financial business data warehouse performs a round of business data update operation every time the target cooling time passes.

[0065] According to the financial business database maintenance method of the embodiment of the present application, it is necessary to first determine the data iteration duration corresponding to each financial business data for multiple financial business data stored in the financial business data warehouse; determine the display page generation duration corresponding to each financial business data for the data display management component; compare the data iteration duration and the display page generation duration to determine the target cooling duration; configure the update time interval of the financial business data warehouse as the target cooling duration, so that the financial business data warehouse performs a round of business data update operations every target cooling duration. In this way, it is possible to efficiently process a large amount of data while still taking into account data timeliness.

[0066] In the financial and insurance fields, the real-time nature of business data and data analysis capabilities are two core requirements. In order to solve the problem that the real-time architecture is limited in processing large amounts of data analysis, and the offline architecture is difficult to meet the real-time update requirements, a new financial business database maintenance method can be adopted. This method includes the following steps:

[0067] In step S101 of some embodiments, it is necessary to sort out multiple financial business data stored in the financial business data warehouse and determine the data iteration duration corresponding to each financial business data. It should be noted that the data iteration duration may include the time required for each financial business data to be synchronized from the source to the financial business data warehouse, data cleaning, and data processing. For example, data synchronization may take 0.5 hours, data cleaning also takes 0.5 hours, and data processing takes 1 hour.

[0068] Reference Figure 2According to some embodiments of the present application, the data iteration duration includes a data synchronization time interval. Step S101 determines the data iteration duration corresponding to each financial business data for a plurality of financial business data stored in the financial business data warehouse, which may include:

[0069] Step S201, determining the corresponding business data source for each financial business data in the financial business data warehouse;

[0070] Step S202, querying multiple historical synchronization durations corresponding to different types of historical business data in the historical data interaction records according to the historical data interaction records between the financial business data warehouse and the business data source;

[0071] Step S203: determine a data synchronization time interval corresponding to the financial business data type from multiple historical synchronization time lengths.

[0072] In the maintenance and management of financial business data warehouses, accurately grasping the data iteration duration is the key to ensuring data real-time and decision-making efficiency. The data iteration duration covers the entire process from data generation and synchronization to the financial business data warehouse until the data is ready for analysis. The determination of this duration involves multiple steps, first identifying the data source of each financial business data, then analyzing the synchronization history of these data from the source to the financial business data warehouse, and finally deriving the synchronization time interval for each business data.

[0073] In step S201 of some embodiments, the data source corresponding to each financial business data in the financial business data warehouse is determined. The data source may include a customer management system, a market data provider, etc., and each data source may generate different types of financial business data. This step involves understanding the original source of the data and the data generation mechanism, which is crucial for subsequent data synchronization and processing.

[0074] In step S202 of some embodiments, it is necessary to analyze the historical data interaction records between the financial business data warehouse and the business data source. These historical data interaction records record in detail the frequency, time, and duration of past data synchronization. By querying these historical records, multiple historical synchronization durations corresponding to different types of historical business data can be obtained. These historical data provide valuable information to help us understand the performance and pattern of the data synchronization process in the past.

[0075] In step S203 of some embodiments, a data synchronization time interval corresponding to a specific financial business data type may be determined from these historical synchronization durations. This data synchronization time interval may be the average time it takes for financial business data to be available in the financial business data warehouse after it is generated from the source system. For example, if historical data shows that a certain type of transaction data is usually synchronized to the financial business data warehouse within step S10 minutes after it is generated, then this step S10 minutes is the data synchronization time interval for this type of data.

[0076] Through the above steps S201 to S203, a reasonable data iteration duration can be determined for each financial business data in the embodiment of the present application. This duration not only includes the time interval for data synchronization, but also may cover the time required for subsequent processing steps such as data cleaning and processing. Understanding the iteration duration of each data set helps optimize the performance of the financial business data warehouse, ensure timely data updates, and ultimately support fast and accurate business decisions.

[0077] Reference Figure 3 According to some embodiments of the present application, step S202 queries the historical data interaction records between the financial business data warehouse and the business data source for multiple historical synchronization durations corresponding to different types of historical business data in the historical data interaction records, which may include:

[0078] Step S301, querying the historical data interaction records between the financial business data warehouse and the business data source to determine the historical data interaction details corresponding to each type of historical business data;

[0079] Step S302, for each type of historical business data, determine the business data source from the historical data interaction details to store the historical sub-data synchronization duration corresponding to each historical business data in the financial business data warehouse, and calculate the historical synchronization duration based on the corresponding historical sub-data synchronization duration.

[0080] In the management process of financial business data warehouse, detailed analysis of historical data interaction records is a key step in optimizing data synchronization strategy and improving data timeliness. The purpose of this process is to mine historical data to determine the most appropriate data synchronization duration for different types of business data, ensuring that the financial business data warehouse can reflect the actual business situation in a timely manner and support efficient decision-making.

[0081] In step S301 of some embodiments, by querying the historical data interaction records between the financial business data warehouse and the business data source, the historical data interaction details corresponding to each type of historical business data can be determined. This step involves combing a large amount of historical data, including but not limited to various types of business data such as transaction records, customer information updates, and market changes. These details record the entire process from the generation of data from various business systems to the final synchronization to the financial business data warehouse, providing basic data for subsequent analysis.

[0082] In step S302 of some embodiments, for each type of historical business data, it is necessary to determine from the historical data interaction details the synchronization duration of the historical sub-data corresponding to each piece of historical business data stored in the financial business data warehouse from the business data source. This means that for each type of financial business data, the time required from its generation from the source system to its successful synchronization to the financial business data warehouse can be analyzed. This duration may vary depending on factors such as the type of data, data volume, system performance, and network conditions. For example, some urgent transaction data may require real-time or near real-time synchronization, while some non-critical customer information may allow for longer synchronization intervals.

[0083] In step S303 of some embodiments, the average synchronization duration of various historical business data can be calculated based on the synchronization duration of these historical sub-data, or the bottleneck and delay point in the synchronization process can be identified. These calculation results are crucial for evaluating the effectiveness of existing data synchronization strategies.

[0084] Reference Figure 4 According to some embodiments of the present application, step S303 calculates the historical synchronization duration according to the corresponding synchronization duration of each historical sub-data, which may include:

[0085] Step S401, calculating the average synchronization duration of each historical sub-data of the same type of historical service data to obtain the average synchronization duration of the sub-data;

[0086] Step S402: determine the sub-data synchronization mean duration as the historical synchronization duration.

[0087] First, it is necessary to calculate the average synchronization time of each historical sub-data of the same type of historical business data. This step involves the analysis of a large amount of historical data, with the goal of capturing the average time spent in the data synchronization process. Specifically, for each type of business data, such as transaction data or customer information, it is necessary to collect the synchronization time of all its historical sub-data. These time durations record the time it takes for each piece of data to be generated from the source system to be successfully synchronized to the financial business data warehouse. By calculating the average of these time durations, a representative number can be obtained, namely the average sub-data synchronization time duration, which reflects the average processing efficiency of this type of data synchronization.

[0088] Next, the calculated sub-data synchronization average duration is determined as the historical synchronization duration. This historical synchronization duration is the synchronization benchmark for all business data of this type, and it is used to guide future data synchronization operations and system design. For example, if the sub-data synchronization average duration of a certain type of data is longer than that of other types of data, this may mean that the relevant data synchronization process needs to be optimized, such as by increasing network bandwidth, optimizing data transmission protocols, or enhancing data processing capabilities to shorten synchronization time.

[0089] Through the above steps S301 to S303, the embodiment of the present application can more accurately grasp the synchronization characteristics and requirements of different business data, so as to design a more reasonable data synchronization strategy. This not only helps to improve the data timeliness of the financial business data warehouse and ensure that business decisions are based on the latest data, but also improves the operating efficiency of the entire data architecture and reduces the risks caused by data delays. In the financial industry, this refined management of data synchronization duration is an important means to enhance competitiveness and ensure business continuity.

[0090] Reference Figure 5 According to some embodiments of the present application, the data iteration duration also includes a data cleaning time interval. Step S101 determines the data iteration duration corresponding to each financial business data for multiple financial business data stored in the financial business data warehouse, and may also include:

[0091] Step S501, querying the historical cleaning duration corresponding to different types of financial business data for each financial business data stored in the financial business data warehouse;

[0092] Step S502: determine a data cleaning time interval corresponding to the financial business data type from a plurality of historical cleaning time intervals.

[0093] In the maintenance and management of financial business data warehouses, data iteration duration is a key consideration, which directly affects the real-time nature of data and the timeliness of decision-making. Data iteration duration includes not only the data synchronization time interval, but also the data cleaning time interval. For multiple financial business data stored in the financial business data warehouse, determining the data iteration duration corresponding to each financial business data is the basis for achieving efficient data updates.

[0094] In step S501 of some embodiments, for each type of historical business data, it is necessary to determine from the historical data interaction details the synchronization duration of the historical sub-data corresponding to each piece of historical business data stored in the financial business data warehouse by the business data source. This step requires a detailed review of the historical data to identify the time it takes for the data to be generated from the source system to become available in the financial business data warehouse. These historical sub-data synchronization durations reflect the actual efficiency of data synchronization and provide a basis for determining the data synchronization time interval.

[0095] In step S502 of some embodiments, a data cleaning time interval corresponding to the financial business data type can be determined from multiple historical sub-data synchronization time intervals. This time interval is a key parameter in the data cleaning process, which affects the frequency and speed of updating the financial business data warehouse. By calculating the average of the historical sub-data synchronization time intervals, the sub-data synchronization average time interval can be obtained, and this time interval can be determined as the historical synchronization time interval, which provides an important reference for determining the data iteration time interval.

[0096] Through the above steps S501 to S502, by querying the historical data interaction records, analyzing the historical sub-data synchronization duration, and calculating the sub-data synchronization average duration, the data iteration duration corresponding to the financial business data can be determined. This process is of great significance for optimizing the performance of the financial business data warehouse, ensuring timely data updates, and supporting fast and accurate business decisions.

[0097] Reference Figure 6 According to some embodiments of the present application, the data iteration duration also includes a data processing time interval. Step S101 determines the data iteration duration corresponding to each financial business data for a plurality of financial business data stored in the financial business data warehouse, and may also include:

[0098] Step S601, querying the historical processing time corresponding to different types of financial business data for each financial business data stored in the financial business data warehouse;

[0099] Step S602: Determine a data processing time interval corresponding to the financial business data type from a plurality of historical processing time periods.

[0100] In the financial business data warehouse, data iteration time is a key metric, which covers the entire process of data synchronization from the source system to the financial business data warehouse, and then through cleaning and processing, and finally becoming usable information. Among them, the data processing time interval is an important part of the data iteration time, which directly affects the timeliness of the decision-making supported by the financial business data warehouse.

[0101] In step S601 of some embodiments, in order to determine the data iteration duration corresponding to each financial business data, it is necessary to conduct a detailed analysis of each financial business data stored in the financial business data warehouse. First, for each financial business data stored in the financial business data warehouse, it is necessary to query the historical processing duration corresponding to different types of financial business data. This step involves detailed recording and analysis of the historical data processing process to obtain the actual time required for data processing. This duration information can be obtained through the log system of the financial business data warehouse and the historical records of the monitoring tool.

[0102] In step S602 of some embodiments, it is necessary to determine the data processing time interval corresponding to the financial business data type from these multiple historical processing times. This usually means performing statistical analysis on the historical processing time data, such as calculating the mean, median or other statistical measures to determine a representative data processing time interval. This data processing time interval will serve as a key influencing factor for the data iteration duration. And determining the data processing time interval is crucial for optimizing the performance of the financial business data warehouse. By understanding the processing time of different types of data, the embodiments of the present application can determine the bottleneck links in data processing in subsequent steps, and take corresponding optimization measures, such as increasing processing resources, optimizing algorithms or improving data processing logic. This can not only improve the efficiency of data processing, but also shorten the data iteration duration, thereby speeding up the update frequency of data in the financial business data warehouse and meeting the needs for real-time performance and decision support.

[0103] Reference Figure 7 According to some embodiments of the present application, step S103 compares the data iteration duration and the display page generation duration to determine the target cooling duration, which may include:

[0104] Step S701, selecting the shortest time interval among the data synchronization time interval, the data cleaning time interval, the data processing time interval and the display page generation time interval as a benchmark reference time interval;

[0105] Step S702: configure a target cooling time according to a benchmark reference time.

[0106] In the maintenance process of the financial business data warehouse, determining the target cooling time is a key step to ensure real-time data updates and improve decision-making efficiency. It should be emphasized that the target cooling time refers to the time interval for updating data in the financial business data warehouse, which should match the data iteration time (including data synchronization, cleaning, and processing) and the data display page generation time.

[0107] In step S701 of some embodiments, it is necessary to select the shortest time length from the data synchronization time interval, data cleaning time interval, data processing time interval and display page generation time length as the benchmark reference time length. This step involves accurate measurement and comparison of the time required for each link in the entire data flow. For example, if data synchronization requires 0.5 hours, data cleaning requires 0.5 hours, data processing requires 1 hour, and data display page generation requires 0.3 hours, then the display page generation time length is the shortest, and 0.3 hours is selected as the benchmark reference time length.

[0108] The purpose of selecting the benchmark reference time is to ensure that the update operation of the financial business data warehouse will not be affected by the delay of a certain link, so as to ensure the real-time nature of the data. If the update frequency of the financial business data warehouse is lower than the benchmark reference time, the real-time nature of the data cannot be guaranteed, because the delay of the data in a certain link will cause the delay of the entire data process.

[0109] In step S702 of some embodiments, the target cooling time is configured according to the benchmark reference time. This means that the update time interval of the financial business data warehouse is set to be equal to or shorter than the benchmark reference time. For example, if the benchmark reference time is 0.3 hours, then the target cooling time can be set to 0.3 hours or shorter to ensure that the financial business data warehouse is updated every 0.3 hours, thereby ensuring the real-time nature of the data.

[0110] In this way, the financial business data warehouse can perform a round of business data update operations every target cooling time to ensure timely data updates. This not only improves the real-time nature of the data. In addition, this configuration method also helps optimize the use of system resources and avoid unnecessary pressure on system performance due to overly frequent data updates.

[0111] In short, by comparing the data iteration time and the display page generation time, and selecting the shortest time as the benchmark reference time, financial institutions can reasonably configure the target cooling time, thereby ensuring that the financial business data warehouse can reflect the actual business situation in a timely manner and support efficient decision-making. This method helps to improve the performance of the financial business data warehouse, optimize the data processing process, and ultimately improve the competitiveness of financial institutions.

[0112] In step S102 of some embodiments, for the data analysis report or dashboard in the data display management component, it is necessary to determine the duration of data processing and page rendering. This step is to measure the time required for the data display management component to convert multiple financial business data into information that can be understood by users, which is crucial to ensure that users can obtain data analysis results in a timely manner.

[0113] Reference Figure 8According to some embodiments of the present application, step S102 determines the generation time of the display page corresponding to each financial business data for the data display management component, which may include:

[0114] Step S801, obtaining the display indicator type and display page rendering time corresponding to each financial business data in the data display management component;

[0115] Step S802, for each display indicator type, determining the indicator data generation time corresponding to each page display indicator;

[0116] Step S803, determining the display page generation duration according to the indicator data generation time corresponding to each display indicator type and the display page rendering duration.

[0117] In the framework of the financial business data warehouse, the data display management component converts the processed data into visual information. Determining the generation time of the display page corresponding to each financial business data is an important step to ensure that the data can be presented to the user in a timely manner. According to some embodiments of the present application, this process can be completed through a series of meticulous operations.

[0118] In step S801 of some embodiments, it is necessary to obtain the display indicator type and display page rendering time corresponding to each financial business data in the data display management component. This step involves a detailed analysis of the data display requirements to clarify which data will be displayed and the display format of these data. For example, transaction data may need to be displayed in the form of a chart, while customer information may be presented in the form of a list. Understanding these indicator types helps determine the complexity of data display and thus estimate the time required for page rendering.

[0119] In step S802 of some embodiments, for each display indicator type, it is necessary to determine the indicator data generation time corresponding to each page display indicator. This step requires analyzing and measuring the time from the completion of data processing to the time when the indicator data is ready to be rendered. This includes operations such as data aggregation, calculation, and conversion, which may be automatically completed by BI tools. For example, if an indicator needs to calculate the total transaction amount in the past hour, then the time of this calculation process will directly affect the generation time of the indicator data.

[0120] In step S803 of some embodiments, the total time required to generate a display page is determined based on the indicator data generation time and the display page rendering time corresponding to each display indicator type. This step is to add the data generation time and the page rendering time to obtain the total time required to generate a display page. For example, if the generation of a certain indicator data requires 0.2 hours, and the page rendering requires 0.1 hours, then the total time required to generate the display page is 0.3 hours.

[0121] In step S103 of some embodiments, by comparing the data iteration time and the display page generation time, a target cooling time is determined, that is, the minimum common time interval between processing data and displaying data is determined. This target cooling time will be used as the time interval basis for data update operations.

[0122] In the financial insurance field, the real-time and efficiency of data processing are crucial, so determining the target cooling time has become a key step in optimizing the data architecture. The target cooling time refers to the minimum value between the data iteration time and the display page generation time, which will be used as the time interval benchmark for data update operations.

[0123] The data iteration duration can cover the entire process from data source synchronization to the financial business data warehouse, including data extraction, cleaning, processing and other links, until the data reaches a state that can be used by the data display management component. The duration of this process will be affected by factors such as the amount of data, the complexity of the data processing process, and the performance of the financial business data warehouse. For example, if data synchronization takes 0.5 hours, data cleaning also takes 0.5 hours, and data processing takes 1 hour, the data iteration duration in this case is 1 hour.

[0124] It should be noted that the display page generation time refers to the time required for the data display management component to convert the processed financial business data into charts, reports or dashboards and present them to the user. This includes the final processing of the data, page rendering and other steps. This time is affected by factors such as the performance of the data display management component, page complexity, and user interface design. For example, if the data display management component takes 0.5 hours to process and render the data into a page, the display page generation time is 0.5 hours.

[0125] When determining the target cooling time, these two time periods need to be compared. The target cooling time is the minimum of the data iteration time and the display page generation time. The reason for selecting the minimum value as the target cooling time is to ensure that the flow of data will not be restricted by bottlenecks due to delays in a certain link. In this way, the embodiment of the present application can support the fastest link to achieve real-time update and display of data.

[0126] After determining the target cooling time, the update operation of the financial business data warehouse can be configured and optimized according to this time. For example, if the target cooling time is 0.5 hours, the financial business data warehouse can be set to update every 0.5 hours to ensure the real-time nature of the data. In this way, the latest data analysis results can be obtained every 0.5 hours, so that business decisions can be made faster. In this way, the embodiment of the present application can meet the demand for data real-time while ensuring data processing efficiency.

[0127] In step S104 of some embodiments, the update time interval of the financial business data warehouse is configured as the target cooling time, so that the financial business data warehouse can perform a round of business data update operation every target cooling time. In this way, while ensuring data processing efficiency, the timeliness of data can be taken into account to achieve faster business decision support.

[0128] In the financial insurance field, the real-time performance of data processing is critical to decision-making. Therefore, the reasonable configuration of the update time interval of the financial business data warehouse has become an important means to improve data processing efficiency. In this context, configuring the update time interval of the financial business data warehouse as the target cooling time is an effective way to ensure the real-time performance of data.

[0129] It should be emphasized that the target cooling time is the minimum time unit determined based on the data iteration time (including the time required for data synchronization, cleaning, processing, etc.) and the data display page generation time (the time required for business intelligence tools to process and display data). This time is the longest waiting time that can be accepted by the embodiment of the present application to ensure that the real-time update and processing of data will not be delayed due to improper design of the embodiment of the present application.

[0130] In an embodiment of the present application, the update time interval of the financial business data warehouse is set to the target cooling time, which means that the financial business data warehouse will periodically perform the update operation of the business data according to this time interval. For example, if the target cooling time is 0.5 hours, the financial business data warehouse will be updated every 0.5 hours, which can ensure the freshness of the data and meet the business needs for real-time data. The advantage of this configuration method is that it can take into account the processing power of the embodiment of the present application while ensuring the timeliness of the data. By accurately controlling the time point of data update, the resources of the embodiment of the present application can be maximized, and excessively frequent data processing can be avoided to cause unnecessary pressure on the performance of the embodiment of the present application. At the same time, it also helps to reduce data redundancy and inconsistency, because all data update operations are uniformly performed at predetermined time intervals.

[0131] In addition, this configuration helps improve data availability. When users request data, they can expect to get the latest updated data after the target cooling period, which is particularly important for financial businesses that need to respond quickly to market changes. For example, business areas such as transaction monitoring, risk assessment, and customer service all require real-time or near real-time data support to ensure the accuracy and timeliness of decision-making.

[0132] It should be understood that configuring the update time interval of the financial business data warehouse as the target cooling time is an effective strategy to balance data real-time and data processing efficiency. It can not only ensure the timely update of data, but also optimize the use of computing resources in the embodiments of this application, improve the efficiency and quality of data processing, and thus provide strong data support for business decisions related to finance and insurance.

[0133] In some more specific embodiments, if data synchronization, cleaning, and processing take 0.5 hours, 0.5 hours, and 1 hour respectively, and the data processing and page rendering of the data analysis report / dashboard in the data display management component take 0.5 hours, then the entire financial business data warehouse and business intelligence link complete a data update in 2.5 hours, and the target cooling time (minimum processing time) is 0.5 hours. By executing data updates cyclically every 0.5 hours, the latest massive data can be obtained for analysis in a shorter time, effectively balancing the efficiency and real-time performance of data processing.

[0134] Reference Fig. 9 , Fig. 9 The hardware structure of an electronic device of another embodiment is illustrated. The electronic device may include:

[0135] The processor 901 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application;

[0136] The memory 902 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store an operating system and other application programs. When the technical solution provided in the embodiment of this specification is implemented by software or firmware, the relevant program code is stored in the memory 902, and the processor 901 calls and executes the financial business database maintenance method of the embodiment of this application;

[0137] Input / output interface 903, used to implement information input and output;

[0138] Communication interface 904, used to realize communication interaction between the device and other devices, which can be realized through wired mode (such as USB, network cable, etc.) or wireless mode (such as mobile network, WI FI, Bluetooth, etc.);

[0139] A bus 905 that transmits information between various components of the device (e.g., the processor 901, the memory 902, the input / output interface 903, and the communication interface 904);

[0140] The processor 901 , the memory 902 , the input / output interface 903 and the communication interface 904 are connected to each other in communication within the device via a bus 905 .

[0141] The embodiment of the present application further provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, so that the computer device executes and implements the above-mentioned financial service database maintenance method.

[0142] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present disclosure described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "comprises" and "comprising" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0143] It should be understood that in the present disclosure, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0144] It should be understood that in the description of the embodiments of the present application, the meaning of multiple (or multiple items) is more than two, greater than, less than, exceed, etc. are understood to not include the number, and above, below, within, etc. are understood to include the number.

[0145] In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

[0147] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0148] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure is essentially 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, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present disclosure. The aforementioned storage medium may include: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

[0149] It should also be understood that the various implementations provided in the embodiments of the present application can be combined arbitrarily to achieve different technical effects.

[0150] The above is a specific description of the implementation methods of the present disclosure, but the present disclosure is not limited to the above implementation methods. Technical personnel familiar with the art can also make various equivalent modifications or substitutions without violating the spirit of the present disclosure. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present disclosure.

Claims

1. A method for maintaining a financial business database, characterized in that: include: For a plurality of financial business data stored in a financial business data warehouse, determining a data iteration duration corresponding to each of the financial business data; For the data display management component, determining the generation time of the display page corresponding to each of the financial business data; Comparing the data iteration duration with the display page generation duration to determine a target cooling duration; The update time interval of the financial business data warehouse is configured as the target cooling time, so that the financial business data warehouse performs a round of business data update operation every time the target cooling time is exceeded.

2. The method according to claim 1, characterized in that The data iteration duration includes a data synchronization time interval, and the step of determining the data iteration duration corresponding to each of the plurality of financial business data stored in the financial business data warehouse includes: For each of the financial business data in the financial business data warehouse, determining a corresponding business data source; According to the historical data interaction record between the financial business data warehouse and the business data source, query multiple historical synchronization durations corresponding to different types of historical business data in the historical data interaction record; The data synchronization time interval corresponding to the financial service data type is determined from the multiple historical synchronization time periods.

3. The method according to claim 2, characterized in that The querying, according to the historical data interaction record between the financial business data warehouse and the business data source, a plurality of historical synchronization durations corresponding to different types of historical business data in the historical data interaction record comprises: Querying the historical data interaction records between the financial business data warehouse and the business data source to determine the historical data interaction details corresponding to each type of the historical business data; For each type of historical business data, determine the historical sub-data synchronization duration corresponding to each piece of historical business data stored in the financial business data warehouse by the business data source from the historical data interaction details, and calculate the historical synchronization duration based on the corresponding synchronization durations of each historical sub-data.

4. The method according to claim 3, characterized in that The calculating the historical synchronization duration according to the corresponding synchronization durations of the historical sub-data includes: Calculate the average synchronization duration of each historical sub-data of the same type of historical business data to obtain the average synchronization duration of the sub-data; The sub-data synchronization mean duration is determined as the historical synchronization duration.

5. The method according to claim 2, characterized in that: The data iteration duration also includes a data cleaning time interval. The determining of the data iteration duration corresponding to each of the plurality of financial business data stored in the financial business data warehouse further includes: For each of the financial business data stored in the financial business data warehouse, query the historical cleaning duration corresponding to different types of the financial business data; The data cleaning time interval corresponding to the financial business data type is determined from the multiple historical cleaning time periods.

6. The method according to claim 5, characterized in that The data iteration duration also includes a data processing time interval. The determining of the data iteration duration corresponding to each of the plurality of financial business data stored in the financial business data warehouse further includes: For each of the financial business data stored in the financial business data warehouse, query the historical processing time corresponding to different types of the financial business data; The data processing time interval corresponding to the financial business data type is determined from the multiple historical processing time periods.

7. The method according to claim 6, characterized in that The comparing the data iteration duration with the display page generation duration to determine the target cooling duration includes: From the data synchronization time interval, the data cleaning time interval, the data processing time interval and the display page generation time interval, select the shortest time interval as the benchmark reference time interval; The target cooling time is configured according to the benchmark reference time.

8. The method according to claim 1, characterized in that The determining, for the data display management component, the generation time of the display page corresponding to each of the financial business data includes: Obtaining the display indicator type and display page rendering time corresponding to each of the financial business data in the data display management component; For each display indicator type, determine the indicator data generation time corresponding to each page display indicator; The display page generation duration is determined according to the indicator data generation time corresponding to each display indicator type and the display page rendering duration.

9. An electronic device, characterized in that: include: A memory and a processor, wherein the memory stores a computer program, and the processor implements the financial business database maintenance method as described in any one of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The storage medium stores a program, and the program is executed by a processor to implement the financial business database maintenance method as described in any one of claims 1 to 8.

Images