Original data change processing method for power transaction data analysis platform

Abstract

The invention discloses an original data change processing method for a power transaction data analysis platform, and belongs to the technical field of new energy station power generation. Complete original data and a blood relationship link are formed, key business fields are reserved in all data structures, and when the updating time of the original data is changed, the original data is updated. Real-time or off-line scheduling can trigger a blood relationship task, and all downstream nodes of the whole blood relationship link can modify data of all tree nodes according to the change of updating time; according to the method, a solution and a thought are provided for a data change scene of an electric power spot transaction decision-making auxiliary system, the difference between a traditional counting warehouse and an electric power transaction industry counting warehouse is analyzed, and the problem is analyzed and the solution is given through the perspective of a standardized model, data synchronization and the like.

Description

Technical Field

[0001] The present invention belongs to the technical field of new energy station power generation, and specifically relates to a method for processing raw data changes for an electric power trading data analysis platform. Background Art

[0002] At present, the power markets in various provinces are developing rapidly. The power trading decision-making support system needs to process a large amount of data published by trading centers in different provinces. These data are highly diverse and non-standardized due to their regional characteristics, which brings severe challenges to the system integration, analysis and decision support.

[0003] In the data analysis of power transactions, crawler technology has become the key to efficiently obtain information from various public data sources. The source of data may be grid operators, exchanges, various research institutes and other institutions, or it may be public data from relevant government agencies. The data content involves key information such as electricity prices, electricity volume, supply and demand relationships, policy changes, etc., which are all crucial for decision-making analysis of power transactions. However, due to the irregular update time, non-uniform format, non-standard type of data, and the possibility of content and format changes in subsequent updates, the above problems have brought huge challenges to the data analysis of power transactions. In this case, there is an urgent need for a reasonable technical means to solve the problems of data standardization and data updating, so as to improve the quality of power transaction data analysis.

[0004] like Fig. 9 As shown in the figure, the public cloud data warehouse construction solution is one of the common solutions. Its advantages are that it uses the powerful computing power and elastic expansion capabilities of cloud computing to build an efficient and flexible data warehouse system, and greatly reduces the investment in labor and middleware operation and maintenance costs. However, this method is only suitable for traditional Internet data solutions, and is not suitable for data solution scenarios for power trading analysis. The data scenario of the Internet is historical, and the data that has occurred will not change by default, but the data in the power trading scenario is different. The data that has been disclosed in the past may be revised twice, and it is not limited to the data, including the name and type of the data item. These uncertainties have brought great troubles to the construction of the data warehouse.

[0005] like Fig.10As shown in the figure, the construction scheme of traditional data warehouse has great limitations in the power trading industry, and cannot meet the requirements of data standardization modeling and data change update scenarios. Taking the time dimension as an example, data on power trading is usually updated and revised at the beginning of the month, the end of the quarter, or the end of the year. This means that data for a certain point in time, such as power trading data on January 1, 2023, may change on January 31, June 30, and December 30, 2023. This change not only affects the accuracy of historical data, but also brings troubles to the analysis and re-testing of trading strategies based on historical data. Once there is a version difference in historical data, or new data covers old data, the originally verified strategy algorithm may fail or deviate. Summary of the invention

[0006] The purpose of the present invention is to address the current problems of data diversity and non-standardization and the lack of ability to quickly respond to changes in data published by the trading center, and propose a method for processing raw data changes for the power trading data analysis platform. The present invention forms a complete raw data and lineage relationship link and retains key business fields in all data structures. When the data published by the trading center changes, the update time of the raw data will change. Combined with real-time scheduling or offline scheduling solutions, the lineage task will be triggered. All downstream nodes in the entire lineage relationship link will modify the data of all tree nodes according to the change in update time; this application provides a complete solution and ideas for the data change scenario of the power spot trading decision support system, analyzes the differences between traditional data warehouses and data warehouses in the power trading industry, and analyzes the problem and provides a solution from the perspective of standardized models and data synchronization. The lake warehouse system of the power trading industry and the data change processing solution are the core points of this application. Existing solutions lack demonstration and implementation in this regard.

[0007] In order to solve the above technical problems, the present invention provides a method for processing raw data changes for a power trading data analysis platform, comprising:

[0008] DTS module, used to synchronize data between the database and other business systems;

[0009] The loading unit is used by the business system to load data from the existing database and store the data in the local database;

[0010] The message consumption component is used to start from the ODS raw data layer and use Kafka to manage message queues in real time to capture new or updated data in real time;

[0011] ETL job manager, used to schedule and manage offline ETL tasks, including data extraction, transformation, and loading;

[0012] The lineage identifier is used to identify and maintain the lineage relationship between tables, ensuring that the corresponding update operation is triggered only when there is data related to the new date in the associated lineage table.

[0013] Preferably, the loading unit includes crawling data from an existing database based on a business model on the business side, and synchronizing the crawled data to the ODS original data layer through a DTS data synchronization function.

[0014] Preferably, starting from the ODS original data layer, it is divided into real-time scheduling and offline scheduling based on the business side's consideration indicators for data, wherein real-time scheduling uses Kafka for message queue management, and offline scheduling executes ETL tasks through the Datawork scheduling system.

[0015] Preferably, the consideration indicators include timeliness requirements, update frequency of original data, and processing time of tasks; when real-time scheduling is performed, the business side will send a Kafka message for broadcasting after obtaining the data, and continuously consume message data in the form of a daemon process based on the script, and implement task scheduling triggering according to the type of message.

[0016] As a preferred method, DTS is used to synchronize database increments and changes to the ODS original data layer in real time. Based on the complete original data, key data is extracted through ETL for dimensional modeling and recorded simultaneously to form a complete original data and lineage relationship link and retain key business fields in all data structures. When the transaction center announces changes in data, the update time of the original data will change. Combined with real-time scheduling or offline scheduling solutions, the lineage task will be triggered. All downstream nodes in the entire lineage relationship link will modify the data of all tree nodes according to the changes in update time.

[0017] As a preferred option, when the transaction center announces data changes, it first needs to obtain the latest analysis data, then update the business database update timestamp, and then trigger real-time message push, trigger the data task by the script, and then update the task update_time corresponding record, and finally modify the downstream related tasks; in the offline data change process, it will go through DataWorks task scheduling, and also update the task update_time corresponding record, and modify the downstream related tasks; when update_time is equal to the data update date, the tables associated with the blood relationship link will be modified accordingly.

[0018] Preferably, the key business fields include data publication date, data acquisition creation date, data acquisition update date, and primary key columns.

[0019] Preferably, real-time data display on the business side and report calculation for complex scenarios are implemented through the data warehouse, and the results are obtained through RPC services or connection pools.

[0020] Compared with the prior art, the present invention has the following beneficial effects:

[0021] 1. This solution emphasizes the standardized layering and standardized naming design of data models in the power trading industry from the perspective of "data standardization modeling", and adds scenario solutions for data date marking based on the understanding of the power trading business, which greatly reduces the impact of changes in public data attributes on the business side and models.

[0022] 2. This solution is perfectly adapted by utilizing the lake-warehouse integrated technical solution from the aspect of "historical data changes" and combining it with standardized data structure design. When the data changes, only the changed bloodline nodes are corrected according to the bloodline relationship, which significantly improves the data quality.

[0023] 3. This solution implements "hot data update" by broadcasting messages in a targeted manner according to the data update characteristics of the market from the "data scheduling link" and performing real-time task scheduling through message monitoring.

[0024] 4. This solution uses standard hierarchical tables and result tables to meet the needs of various business scenarios. It also uses the computing power of the public cloud and the lake warehouse architecture combined with the unified specifications of data standard modeling to solve the problem. When the data changes, it is only necessary to update the update_time according to the scheduling to the blood node corresponding to the data modification date. The overall link is simpler than the traditional data warehouse, and the date partitioning solution is abandoned, which greatly reduces the data storage cost. In addition, combined with the characteristics of power trading data updates, the data scheduling is triggered through the message broadcast mechanism, which greatly reduces the computing pressure of traditional scheduling scenarios. Data tasks only need to be triggered when the data changes. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Other features, objects and advantages of the present invention will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings. The drawings are only for the purpose of illustrating preferred embodiments and are not to be considered as limiting the present invention. Also, the same reference symbols are used throughout the drawings to represent the same parts.

[0026] Figure 1 This is the architecture diagram of the ADBPG lake-warehouse integrated solution adopted by the present invention;

[0027] Figure 2 This is a schematic diagram of the standardized naming of data in the present invention;

[0028] Figure 3 Draw a diagram for the data warehouse business model of the present invention;

[0029] Figure 4 It is a schematic diagram of blood relationship update of the present invention;

[0030] Figure 5 This is a schematic diagram of the standardized modeling protocol for data warehouses of the present invention;

[0031] Figure 6 This is a schematic diagram of the data update process of the present invention;

[0032] Figure 7 It is a schematic diagram of the data synchronization solution of the present invention;

[0033] Figure 8 A schematic diagram of a scenario of a data warehouse hierarchical table service business of the present invention;

[0034] Fig. 9 This is a schematic diagram of a public cloud-based data solution;

[0035] Fig.10 This is a schematic diagram of the processing methods when the existing data and structure change. DETAILED DESCRIPTION

[0036] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments.

[0037] Electricity spot market: A market where operators that meet the entry requirements conduct day-ahead, intraday and real-time electricity transactions. The electricity spot market forms a market-clearing price that reflects the value of time and space through competition, and carries out auxiliary service transactions such as frequency regulation and standby.

[0038] Public cloud: generally refers to public cloud services provided by the Internet, such as Alibaba Cloud, Tencent Cloud, Huawei Cloud, etc.

[0039] Lake-warehouse integration: The lake-warehouse integration architecture refers to the integration of data lake and data warehouse functions, which can store structured data and process semi-structured or unstructured data, and realize unified data management and analysis. Through this architecture, the barriers between traditional data lakes and data warehouses can be broken, data redundancy can be reduced, and data processing processes can be simplified.

[0040] Data lake: Suitable for storing large-scale and diverse data sources, including structured, semi-structured and unstructured data. The characteristics of data lake are low storage cost and strong scalability.

[0041] Example 1: Figure 1 - Figure 8 As shown, the original data change processing method for the power transaction data analysis platform includes:

[0042] The DTS module is used to synchronize data between the database and other business systems. The loading unit is used by the business system to load data from the existing database and store the data in the local database. The message consumption component is used to start from the ODS original data layer and use Kafka for message queue management in real time to capture new or updated data in real time. The ETL job manager is used to schedule and manage offline ETL tasks, including data extraction, conversion and loading. The lineage identifier is used to identify and maintain the lineage relationship between tables to ensure that the corresponding update operation is triggered only when there is new date-related data in the associated lineage table.

[0043] like Figure 1 As shown, the core of the present invention is to design and implement a data standardization model, which is like a "housekeeper" that shields the differences in business between provinces, stores data in a standardized manner, and responds to data changes in a timely manner. The data standardization model relies on the accumulation and precipitation of the power trading industry, as well as the interpretation of the industry, so that the model is more standardized and can better meet the complex data analysis scenarios in the industry.

[0044] The solution to the original data change scenario can be divided into core steps such as "data standardization modeling", "historical data update processing", "data scheduling plan", and "application of data hierarchical table" to ensure data quality throughout the entire data processing process.

[0045] Specifically, Figure 2 and Figure 3 As shown, the loading unit includes crawling data from the existing database based on the business model of the business side, and synchronizing the crawled data to the ODS original data layer through the DTS data synchronization function. Starting from the ODS original data layer, it is divided into real-time scheduling and offline scheduling based on the business side's consideration indicators for data. Among them, real-time scheduling uses Kafka for message queue management, and offline scheduling uses the Datawork scheduling system to perform ETL tasks. The consideration indicators include timeliness requirements, update frequency of original data, and task processing time; when real-time scheduling, the business side will send Kafka messages for broadcasting after obtaining the data, and continuously consume message data in the form of a daemon based on the script, and implement task scheduling triggers according to the type of message.

[0046] The existing ETL (Extract, Transform, Load) is an important process of data integration in the data warehouse. The existing ETL includes three main steps: data extraction (Extract), data transformation (Transform) and data loading (Load).

[0047] In the prior art, data extraction is usually used as the first step in the ETL process, which involves extracting data from various data sources (such as relational databases, file systems, APIs, etc.). This embodiment extracts data from the Alibaba Cloud database, and the extracted data can be all data or incremental data within a specific time period. The extraction process may include full extraction: extracting all data from the data source. It may also include incremental extraction: only extracting data that has changed since the last extraction. In addition, data cleaning is also required: preliminary cleaning of the data during the extraction process, such as removing duplicate records, correcting erroneous data, etc.

[0048] After data extraction, data transformation is performed. Data transformation is usually the second step in the ETL process, which involves cleaning, transforming and integrating the extracted data so that it can be loaded into the data warehouse. The transformation process may include the following operations: Data cleaning: remove duplicate data, correct erroneous data, handle missing values, etc. Data conversion: convert data from one format to another, such as converting the date format from YYYY-MM-DD to MM / DD / YYYY. Data integration: merge data from different data sources to resolve data inconsistencies and conflicts. Data calculation: calculate new fields or indicators according to business needs, such as calculating sales, profit margins, etc. Data mapping: map data from the structure of the source system to the structure of the target data warehouse. In the actual operation process, make choices based on different actual scenarios.

[0049] The last step is usually data loading, which involves loading the transformed data in the second step into the data warehouse or target system. The loading process involved may include the following operations: Full load: Load all transformed data into the target system at once. Incremental load: Load only the data that has changed since the last load. Data partitioning: Partition the data according to specific rules to improve query performance. Data indexing: Create indexes for data for fast retrieval. The operation steps of this step also need to be selected according to different actual scenarios.

[0050] Through the above common ETL process, data from different data sources can be effectively integrated to provide reliable data support for data analysis and decision-making.

[0051] It should be noted that for data standardization modeling, this embodiment uses a data configurator. The data configurator's solution eliminates the impact of changes in data attributes published by the trading center on the model. At the same time, the standardized naming modeling of electricity is adopted when extracting ETL data from the ODS original data layer and modeling. Assuming that the acquired data attribute items change, only the ETL statement needs to be adjusted without modifying the underlying structure table, ensuring data standardization and reducing business coupling. Business differences between provinces are shielded through standardized modeling based on the industry knowledge system, and standard hierarchical tables and result tables are used to meet the use of various business scenarios.

[0052] Furthermore, DTS is used to synchronize database increments and changes to the ODS original data layer in real time. Based on the complete original data, key data is extracted through ETL for dimensional modeling and recorded synchronously to form a complete original data and lineage relationship link and retain key business fields in all data structures. When the transaction center announces changes in data, the update time of the original data will change. Combined with real-time scheduling or offline scheduling solutions, the lineage task will be triggered. All downstream nodes in the entire lineage relationship link will modify the data of all tree nodes according to the changes in update time.

[0053] For historical data update issues: Figure 4 , Figure 5 , Figure 6 and Figure 7As shown, the issue of updating historical data is the core part of this application. Through the lake-warehouse integrated solution, the elastic expansion and computing power of the high-performance cloud ADB are used to establish a data lake for the original business data, and the increments and changes of the database are synchronized to the lake in real time through DTS (Data Transmission Service). The data lake can be understood as a complete mirror warehouse of the original database, which is also the original ODS data layer. Based on the complete original data, key data is extracted through ETL for dimensional modeling, and key business fields are retained in all data structures, such as: data release date (target_date), data acquisition creation date (create_time), data acquisition update date (update_time) and other fields. When the data published by the transaction center changes, the update time of the original data will change. Combined with the real-time scheduling solution and the offline scheduling solution, the bloodline task of the data warehouse will be triggered. All downstream nodes of the entire bloodline will modify the data of all tree nodes according to the changes in the update time, so as to ensure the timeliness and accuracy of the data. This problem is solved by leveraging the computing power of the public cloud and the lake warehouse architecture combined with a unified specification for data standard modeling. When data changes, it is only necessary to update update_time to the lineage node corresponding to the data modification date according to the schedule. The overall link is simpler than traditional data warehouses, and the date partitioning solution is abandoned, greatly reducing data storage costs.

[0054] Regarding the data scheduling solution: As mentioned above, data changes will be synchronized to the data lake through DTS, but data updates in the data hierarchical table are triggered by task scheduling. We divide task scheduling into real-time tasks and offline tasks based on the business side's requirements for data timeliness, the update frequency of original data, and the processing time of the task.

[0055] Real-time tasks: Due to the particularity of the power trading market, data updates and releases are generally published in the morning and evening, and the time is relatively fixed and centralized. Therefore, there is no need to monitor data changes all the time. In the real-time link, there is no need to use open source middleware such as Flink, Storm, StarRocks, etc. to achieve this, reducing the resources of the scheduling engine and computing engine. The business side acquires data actively, so the update time and trigger point can be controlled. When the business side acquires market data, it will send a Kafka message for broadcasting. The Python script continuously consumes message data in the form of a daemon process, and implements task scheduling triggers based on the type of message.

[0056] Offline tasks: Offline tasks are more traditional. All our storage and computing capabilities are implemented elastically using public clouds, so our offline scheduling is managed by DataWorks. DataWorks has its own lineage relationship. When the data of a node changes, it can automatically modify the task node and all related nodes under the node. The operation process and results are visualized. In addition, DataWorks also has its own monitoring and alarm mechanism, which can push alarm information to SMS, phone, office software, etc.

[0057] It needs to be further explained that if Figure 6 As shown in the figure, when the trading center announces data changes, it first needs to obtain the latest analysis data, then update the business database update timestamp, and then trigger real-time message push, trigger the data task by the script, and then update the task update_time corresponding record, and finally modify the downstream related tasks; in the offline data change process, it will go through DataWorks task scheduling, and also update the task update_time corresponding record, and modify the downstream related tasks; when update_time is equal to the data update date, the tables associated with the blood relationship link will be modified accordingly. Combined with the characteristics of power trading data update, the data scheduling is triggered by the message broadcast mechanism, which greatly reduces the computing pressure of traditional scheduling scenarios, and only needs to trigger data tasks when data changes.

[0058] Regarding the application of data hierarchical tables: The data warehouse plays an important role in the entire software ecosystem. It integrates data from different sources and performs processes such as cleaning, integration, modeling, and calculation, ultimately providing a unified data capability view to empower the business.

[0059] Specifically, real-time data display on the business side and report calculations for complex scenarios are implemented through the data warehouse, and the results are obtained through RPC services or connection pools.

[0060] It should be noted that the real-time data display on the business side and the report calculation of complex scenarios can be achieved through the data warehouse, and the results can be obtained through RPC services or connection pools. This not only greatly improves the flexibility and creativity of the business, but also effectively addresses the challenges in power trading data analysis and improves the efficiency and accuracy of data processing. This provides more reliable data support for the power trading data analysis platform and helps promote the healthy development of the power market.

[0061] Further, such as Figure 8 The figure shows the structure of a typical data warehouse or database system, and reveals in detail the functions of each component within the system and their interactions.

[0062] First, the operational data storage area (ODS) is the basis of the system and is responsible for storing the most original business data. These data are not processed, ensuring the authenticity and real-time nature of the data. Next, the offline data storage area (ADS) is used to store historical data accumulated over a certain period of time or offline data for analysis, providing resources for subsequent data mining and decision support. The system also includes different data dimensions or subject areas such as DIM, DWD and DWS, which represent dimension tables, data warehouse detail layers and data warehouse summary layers respectively. Through these hierarchical designs, data is effectively classified and integrated.

[0063] At the front end of the system, the SAAS platform, as the client part, interacts closely with the business system to ensure the real-time data processing and rapid response to business needs. The business intelligence (BI) module is located at the high level of the system, using the underlying data to perform complex data analysis and generate reports to provide a basis for decision-making. In addition, the system also distinguishes between the Local database and the Research database, which are used for local data storage and specialized research data management respectively.

[0064] It is worth noting that the "algorithm" module in the illustrated system undertakes the key tasks of data processing and analysis, and realizes deep mining and effective use of data through a series of algorithms. The "data warehouse" as the core of the entire system is not only responsible for data integration and management, but also ensures the smooth operation of the entire data warehouse system through data flow and interaction with other components. The arrows in the figure clearly indicate the data flow and interaction methods, such as the data flow to the SAAS platform side for real-time scenarios and complex scenarios, and the process of synchronizing the result data of the data warehouse to the local for callback, which demonstrates the efficiency and flexibility of the system.

[0065] On the other hand, the present application also proposes a feasible process step of the original data change processing method for the power trading data analysis platform, including:

[0066] S1. Synchronize crawled data with other business systems through DTS;

[0067] S2. The business system loads data from the existing database and synchronizes it to the ODS original data layer;

[0068] S3. Extract ETL data from the ODS original data layer, extract the primary key, business field, and timestamp information of the original table for dimensional modeling, and form a wide table DIM;

[0069] S4. The DIM loads the processed data into the DW layer for further processing into DWD, DWS and ADS.

[0070] Among them, DIM (dimension table): used to store business-related static information or dimensional data. DWD (detailed fact wide table): performs operations such as cleaning and conversion on the original data to form a fine-grained detailed fact table. DWS (summary fact wide table): further aggregates and summarizes on the basis of DWD to form a higher-level fact table. ADS (analysis service layer): the final data presentation and analysis layer for query and use by reports or other data analysis tools.

[0071] DIM is further processed into detailed data and summary data in DWD (DataWarehouse Detail) and DWS (DataWarehouse Summary) formats. In the ADS layer, data services are provided using tables such as TableA, TableB, and TableC. Each table contains primary key, business field, and timestamp information.

[0072] This application provides a complete solution and ideas for the data change scenario of the power spot trading decision-making support system, analyzes the differences between traditional data warehouses and data warehouses in the power trading industry, and analyzes the problem and provides solutions from the perspectives of standardized models and data synchronization. The lake warehouse system of the power trading industry and the data change processing solution are the core points of this application. Existing solutions lack demonstration and implementation in this regard.

Claims

1. A method for processing raw data changes in a power trading data analysis platform, characterized in that: include: DTS module, used to synchronize data between the database and other business systems; The loading unit is used by the business system to load data from the existing database and store the data in the local database; The message consumption component is used to start from the ODS raw data layer and use Kafka to manage message queues in real time to capture new or updated data in real time; ETL job manager, used to schedule and manage offline ETL tasks, including data extraction, transformation, and loading; The lineage identifier is used to identify and maintain the lineage relationship between tables, ensuring that the corresponding update operation is triggered only when there is data related to the new date in the associated lineage table.

2. The original data change processing method for the power transaction data analysis platform according to claim 1 is characterized in that: The loading unit includes crawling data from an existing database based on a business model on the business side, and synchronizing the crawled data to the ODS original data layer through a DTS data synchronization function.

3. The original data change processing method for the power transaction data analysis platform according to claim 1 is characterized in that: Starting from the ODS original data layer, it is divided into real-time scheduling and offline scheduling based on the business side's consideration indicators for data. Among them, real-time scheduling uses Kafka for message queue management, and offline scheduling executes ETL tasks through the Datawork scheduling system.

4. The original data change processing method for the power transaction data analysis platform according to claim 3 is characterized in that: The consideration indicators include timeliness requirements, update frequency of original data, and task processing time. When real-time scheduling is performed, the business side will send a Kafka message for broadcast after obtaining the data, and continuously consume message data in the form of a daemon process based on the script, and implement task scheduling triggering according to the type of message.

5. The original data change processing method for the power transaction data analysis platform according to claim 1 is characterized in that: DTS is used to synchronize the increments and changes of the database to the ODS original data layer in real time. Based on the complete original data, key data is extracted through ETL for dimensional modeling and recorded synchronously to form a complete original data and lineage relationship link and retain key business fields in all data structures. When the transaction center announces changes in data, the update time of the original data will change. Combined with real-time scheduling or offline scheduling solutions, the lineage task will be triggered. All downstream nodes in the entire lineage relationship link will modify the data of all tree nodes according to the changes in update time.

6. The original data change processing method for the power transaction data analysis platform according to claim 5 is characterized in that: When the transaction center announces data changes, it first needs to obtain the latest analysis data, then update the business database update timestamp, and then trigger real-time message push. The script triggers the data task, and then updates the task update_time corresponding record, and finally the downstream related tasks are modified. In the offline data change process, it will be scheduled by DataWorks task, and the task update_time corresponding record will also be updated, and the downstream related tasks will be modified. When update_time is equal to the data update date, the tables associated with the blood relationship link will be modified accordingly.

7. The original data change processing method for the power transaction data analysis platform according to claim 5 is characterized in that: The key business fields include data publication date, data acquisition creation date, data acquisition update date, and primary key columns.

8. The original data change processing method for the power transaction data analysis platform according to claim 1 is characterized in that: Real-time data display on the business side and report calculations for complex scenarios are both implemented through the data warehouse, and the results are obtained through RPC services or connection pools.

Images