A power grid data service orchestration method, device and storage medium

Abstract

The application discloses a kind of power grid data service arrangement method, equipment and storage medium.The method comprises: obtaining the service-data blood relationship coupling graph of power grid data service;According to service-data blood relationship coupling graph, the parameterization expression of pre-set operation constraint is carried out, and operation constraint parameter set is obtained, and operation constraint model is constructed according to operation constraint parameter set;According to service-data blood relationship coupling graph and operation constraint model, candidate execution path set is generated;Comprehensive evaluation is carried out to candidate execution path set based on path evaluation model, and target execution path is determined from candidate execution path set according to comprehensive evaluation result;According to target execution path, power grid data service is executed.The service node and data object node are jointly included in the coupling graph modeling in the application, so that the service arrangement can identify the blood relationship between service and data;Various constraint conditions are considered simultaneously in the candidate path generation stage, which improves the service scheduling efficiency and enhances the path execution stability.

Description

Technical Field

[0001] This invention relates to the field of power grid data processing technology, and in particular to a power grid data service orchestration method, device and storage medium. Background Technology

[0002] As power grid companies continuously improve their digitalization and informatization levels, a large amount of cross-system, cross-platform, and cross-professional data is generated in business processes such as dispatching and operation, equipment status awareness, marketing services, customer management, load forecasting, and decision support. To improve data reuse efficiency, power grid companies typically build data catalogs, data sharing platforms, interface service platforms, algorithm service platforms, and unified data centers to provide data processing capabilities to business systems through interface services, batch processing tasks, or algorithm services.

[0003] In existing technologies, power grid data service orchestration is typically implemented using manual configuration processes, fixed scripts, static rules, workflow engines, or task scheduling platforms. These solutions generally abstract service nodes as ordinary task nodes and execute them sequentially, in parallel, or with retries or failure alerts based on preset dependencies. However, these solutions suffer from at least the following problems: Service orchestration only uses service nodes as nodes and establishes task dependencies. The generation relationship between service nodes and data objects is not included in a unified graph structure, resulting in a lack of topological basis for the traceability link between data and services. In addition, the power grid data service orchestration process does not consider the various boundary conditions that exist in the actual operating environment. It only generates paths according to a fixed topological order or static priority, which is prone to execution failure due to unmet boundary conditions during actual operation. Summary of the Invention

[0004] This invention provides a power grid data service orchestration method, device, and storage medium to solve the technical problems in the prior art where service orchestration only uses service nodes as nodes and establishes task dependencies, does not incorporate the generation relationship between service nodes and data objects into a unified graph structure, and fails to comprehensively consider various operational constraints, leading to easy path execution failures.

[0005] In a first aspect, embodiments of the present invention provide a power grid data service orchestration method, comprising: Service-data lineage coupling diagram for obtaining power grid data services; The preset operational constraints are parameterized according to the service-data lineage coupling diagram to obtain the operational constraint parameter set, and an operational constraint model is constructed based on the operational constraint parameter set. A set of candidate execution paths is generated based on the service-data lineage coupling graph and the operational constraint model; The candidate execution path set is comprehensively evaluated based on the path evaluation model, and the target execution path is determined from the candidate execution path set based on the comprehensive evaluation results. The power grid data service is executed according to the target execution path.

[0006] In a second aspect, embodiments of the present invention provide an electronic device, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the power grid data service orchestration method according to any embodiment of the present invention.

[0007] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute and implement the power grid data service orchestration method described in any embodiment of the present invention.

[0008] The technical solution of this invention involves obtaining a service-data lineage coupling graph of a power grid data service; parameterizing preset operational constraints according to the service-data lineage coupling graph to obtain an operational constraint parameter set; constructing an operational constraint model based on the operational constraint parameter set; generating a candidate execution path set based on the service-data lineage coupling graph and the operational constraint model; comprehensively evaluating the candidate execution path set based on a path evaluation model; and determining a target execution path from the candidate execution path set based on the comprehensive evaluation result; and executing the power grid data service according to the target execution path. Compared with existing technologies, this invention incorporates service nodes and data object nodes into the coupling graph modeling, enabling service orchestration to identify the lineage association between services and data; through the parameterized expression and modeling of multi-dimensional operational constraints, multiple constraints can be considered simultaneously during the candidate path generation stage; and through the comprehensive evaluation of the path evaluation model, the target path selection has an executable safety margin. Therefore, this solves the technical problems of coarse-grained path generation and incomplete constraint consideration in existing power grid data service orchestration, achieving beneficial effects such as improving service scheduling efficiency and enhancing path execution stability.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0011] Figure 1 A flowchart of a power grid data service orchestration method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of a power grid data service orchestration method provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the structure of a power grid data service orchestration system provided in Embodiment 3 of the present invention; Figure 4 A schematic diagram of the structure of an electronic device for implementing the power grid data service orchestration method of this embodiment of the invention. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] Example 1 Figure 1This is a flowchart of a power grid data service orchestration method provided in Embodiment 1 of the present invention. This embodiment is applicable to automated orchestration scenarios for power grid data services. The method can be executed by a power grid data service orchestration system, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes: S110, Service-Data Lineage Coupling Diagram for Obtaining Power Grid Data Services.

[0015] The service-data lineage coupling graph is a graph-structured data model used to describe the dependencies and transmission relationships between various services and their input and output data in power grid data services. Through this coupling graph, it is possible to trace the available service links backward from business objectives, or to deduce the service execution path forward from the data source.

[0016] In this step, a pre-constructed service-data lineage coupling graph of the power grid data service is obtained. Specifically, the service-data lineage coupling graph includes service nodes and data object nodes; the service nodes and the data object nodes are connected through at least one of the following: data lineage edges, service call edges, substitution edges, and result reuse edges.

[0017] In this embodiment, the service node represents a schedulable data service, such as an algorithm service, a cleaning service, a fusion service, or a business application service. The service node may include input data description, output data description, service version, interface address, resource consumption model, call quota, historical success rate, and running status information. The data object node represents the data input or output by the service node, such as data products, data tables, indicator items, model results, or intermediate results. The data object node may include data source, field structure, definition rules, collection cycle, update time, quality indicators, business domain, and security level information. The data lineage edges connect data object nodes and are used to represent the source-derived relationship between data objects, that is, one data object is generated by another data object through processing, transformation or derivation.

[0018] The service call edge connects the service nodes and is used to represent the call dependency relationship or the pre- and post-execution relationship between data services. That is, the execution of one service node depends on the execution result of another service node or needs to be executed before / after another service node.

[0019] The substitution edge connects service nodes that have a substitutable relationship, indicating that the service nodes are substitutable when a preset substitution condition is met. That is, when two service nodes can produce the same or equivalent data output under specific business objectives, field coverage, data lineage, caliber rules, timeliness windows, and quality thresholds, a substitution edge can be established between the two service nodes.

[0020] The result reuse edge connects the completed node and the subsequent node, indicating that the completed result can be reused by the subsequent path. That is, when the output result of a service node or data object node has been completed and its lineage, timeliness and quality still meet the requirements of the subsequent path, the result can be directly reused by the subsequent path without re-executing the upstream service.

[0021] Optionally, as a specific implementation method, the construction of the service-data lineage coupling graph includes: collecting various service and data object information through a service registry, interface management platform, data catalog, data quality management platform, scheduling logs, and monitoring system to form a unified service description model and data object description model. The collected content includes at least: unique service identifier, service version, service type, input / output field structure, input / output data object identifiers, data source, data definition, service system, interface call method, resource consumption model, call quota, time window, historical success rate, historical latency distribution, anomaly type distribution, and data quality detection indicators.

[0022] By setting up dual-type nodes—service nodes and data object nodes—and defining various edge types such as data lineage edges, service call edges, substitution edges, and result reuse edges, the service-data lineage coupling graph can comprehensively describe all reachable generation paths from raw data to business target results, providing a complete graph structure foundation for subsequent candidate path generation.

[0023] S120. The preset operational constraints are parameterized according to the service-data lineage coupling diagram to obtain the operational constraint parameter set, and an operational constraint model is constructed according to the operational constraint parameter set.

[0024] In this step, business requirements and the operating environment are transformed into a computable multidimensional constraint model. Specifically, based on the attribute information of each node and edge in the service-data lineage coupling graph, pre-defined operational constraints related to the operation of power grid data services (such as various boundary conditions and limiting factors) are transformed into computable parameter forms, resulting in an operational constraint parameter set. Then, a unified operational constraint model is constructed based on this operational constraint parameter set. This operational constraint model is used to verify the feasibility of candidate paths during subsequent path generation and selection.

[0025] Among them, operational constraints refer to the boundary conditions and limiting conditions that need to be met during the path execution process. Optionally, the operational constraints include at least one of the following: data quality constraints, timeliness constraints, resource constraints, interface call quota constraints, execution relationship constraints, substitution equivalence constraints, and result reuse constraints.

[0026] The data quality constraint, the timeliness constraint, the resource constraint, and the interface call quota constraint are used to limit the boundary conditions during the path execution process; the execution relationship constraint is used to limit the execution order between service nodes; the substitution equivalence constraint is used to limit the service substitution conditions; and the result reuse constraint is used to limit the result reuse conditions.

[0027] Specifically, the data quality constraints limit the completeness, accuracy, consistency, outlier ratio, missing value rate, and quality confidence of key data objects in the path; the timeliness constraints limit service node response latency, data object freshness, total path execution time, and business completion time window; the resource constraints limit the upper limits of resource consumption such as CPU, memory, bandwidth, storage, concurrency, and interface call quotas; the interface call quota constraints limit the maximum number of calls to each service interface per unit time. The execution relationship constraints limit the execution order between service nodes, including pre- and post-dependencies and parallel execution relationships between service nodes. The substitution equivalence constraints limit service substitution conditions, i.e., the lower limits that substitute services must meet in terms of field coverage, consistency of definitions, lineage similarity, and quality confidence. The result reuse constraints limit result reuse conditions, i.e., completed data objects can only be used as reuse anchors for subsequent paths if the timeliness window, quality detection results, and lineage consistency conditions are met.

[0028] By setting and classifying the above-mentioned multidimensional operational constraints, we can comprehensively parameterize the various boundary conditions and limiting conditions in the path execution process, providing a complete constraint basis for the generation and screening of candidate paths.

[0029] Optionally, the alternative edges can be constructed in the following ways: The substitution equivalence between each two service nodes is calculated based on substitution evaluation indicators; the substitution evaluation indicators include at least one of the following factors: field coverage, field mapping relationship, data source lineage similarity, statistical consistency, time window overlap, and historical quality confidence. If the substitution equivalence between the two service nodes is greater than a preset threshold, then the substitution edge is established between the two service nodes.

[0030] Among them, substitution equivalence is a quantitative indicator used to measure the degree of substitutability between two service nodes under a specific business objective. The higher the substitution equivalence, the stronger the substitutability between the two service nodes.

[0031] In this embodiment, the substitution equivalence can be calculated based on substitution evaluation indicators, which include at least one of the following factors: field coverage, field mapping relationship, data source lineage similarity, statistical consistency, time window overlap, and historical quality confidence. Field coverage refers to the degree to which the output fields of one service node cover the output fields of another service node. Field mapping relationship refers to the corresponding mapping relationship between the output fields of two service nodes. Data source lineage similarity refers to the similarity between the lineage paths of the data sources upon which two service nodes depend. Statistical consistency refers to the degree of consistency between the statistical standards (such as calculation rules, summary dimensions, time range, etc.) of the output data of two service nodes. Time window overlap refers to the degree of overlap between the effective time windows of the output data of two service nodes. Historical quality confidence refers to the degree of credibility of the output data quality meeting the standards, derived from the statistics of the historical operating data of the service nodes.

[0032] This application calculates the substitution equivalence degree based on multiple factors such as field coverage, lineage similarity, caliber consistency, timeliness overlap, and historical quality confidence. Only service nodes that reach the substitution equivalence threshold can establish substitution edges. This avoids simply regarding services with similar interface names or similar output fields as substitutable services, ensuring that substitution relationships are established based on a comprehensive judgment of field coverage, lineage similarity, caliber consistency, timeliness overlap, and quality confidence. It is particularly suitable for scenarios with complex cross-system data calibers in the power grid.

[0033] S130. Generate a set of candidate execution paths based on the service-data lineage coupling graph and the operation constraint model.

[0034] The candidate execution path set includes multiple candidate execution paths. A candidate execution path refers to an executable service call link that starts from the target data object, passes through service nodes and data object nodes, and meets the running constraints.

[0035] In this step, after receiving the target data object of the business and obtaining the constructed runtime constraint model, based on the topological relationship provided by the service-data lineage coupling graph and combined with the various boundary conditions defined by the runtime constraint model, several execution paths that satisfy the constraint requirements from the original data to the business target data are searched in the coupling graph, generating a candidate execution path set consisting of multiple feasible execution paths. Each path in the generated candidate path set is a potential execution solution that can achieve the business objective.

[0036] Specifically, candidate dependency closures corresponding to the target data object are determined from the service-data lineage coupling graph, and constraint path search is performed on the candidate dependency closures according to the runtime constraint model. Finally, multiple candidate execution paths that satisfy the runtime constraints are generated on the subgraph, forming a set of candidate execution paths.

[0037] For example, starting from the target data object node, the process first traces back to the service node and upstream data object node that can generate the data object, forming a candidate dependency closure. Then, based on the hard constraints in the runtime constraint model (such as security level, version compatibility, field coverage, and minimum quality threshold), nodes and edges that do not meet the conditions are pruned. Finally, according to the runtime constraint model, a constraint path search is performed in the pruned coupled graph to obtain multiple candidate execution paths that satisfy runtime constraints such as data quality constraints, timeliness constraints, resource constraints, and interface call quota constraints. Each candidate execution path also carries a set of reusable nodes, a set of potential switching anchors, and an estimated switching cost for subsequent path evaluation and dynamic switching.

[0038] S140. The candidate execution path set is comprehensively evaluated based on the path evaluation model, and the target execution path is determined from the candidate execution path set according to the comprehensive evaluation results.

[0039] The path evaluation model refers to a model built based on historical operational data and real-time status data, used to comprehensively evaluate candidate paths and output comprehensive evaluation results. The comprehensive evaluation results refer to the evaluation information output by the path evaluation model after evaluating each candidate execution path in the candidate execution path set, including at least one of the following evaluation results: comprehensive cost value of the candidate path, constraint satisfaction probability, minimum constraint relaxation, and executability confidence.

[0040] In this step, based on a pre-built or dynamically generated path evaluation model, each candidate execution path in the candidate execution path set is quantitatively analyzed and comprehensively compared from multiple preset evaluation dimensions to generate evaluation results that reflect the comprehensive performance of each candidate path. Then, based on the comprehensive evaluation results, an optimal path is selected from the candidate execution path set according to a preset selection strategy, and this path is determined as the final target execution path for execution.

[0041] For example, a path evaluation model is constructed based on historical operational data and real-time status data. This model is used to quantitatively analyze and comprehensively compare each candidate execution path in the candidate execution path set from multiple preset evaluation dimensions. These preset evaluation dimensions include, but are not limited to, service operation reliability, data quality assurance, resource consumption, and execution stability.

[0042] The path evaluation model generates a comprehensive evaluation result for each candidate execution path based on its performance across various preset evaluation dimensions. This comprehensive evaluation result characterizes the overall performance of the candidate execution path in satisfying the constraints defined by the operational constraint model, as well as its ability to maintain stable operation during actual execution. A higher value or a higher ranking in the comprehensive evaluation result indicates better overall performance of the candidate execution path after considering all evaluation dimensions.

[0043] After obtaining the comprehensive evaluation results of each candidate execution path in the candidate execution path set, the system sorts the candidate execution paths according to the comprehensive evaluation results and a preset selection strategy. The preset selection strategy includes at least: prioritizing the selection of candidate execution paths that meet all preset hard constraints, and within the range of candidate paths that meet the hard constraints, selecting the best one according to the ranking of the comprehensive evaluation results, and determining it as the target execution path.

[0044] This evaluation method avoids the path instability problem caused by selecting paths based solely on the shortest path, the fewest number of nodes, static priority, or manual weighting in existing technologies, ensuring that the selected path has comprehensive advantages in terms of execution security, resource rationality, and business adaptability.

[0045] S150. Execute the power grid data service according to the target execution path.

[0046] In this step, the corresponding power grid data services are called sequentially according to the service call order, data transmission relationship and execution logic specified in the determined target execution path, so as to complete the complete execution process from data acquisition and processing to the achievement of the final business goal.

[0047] The technical solution of this invention involves obtaining a service-data lineage coupling graph of a power grid data service; parameterizing preset operational constraints according to the service-data lineage coupling graph to obtain an operational constraint parameter set; constructing an operational constraint model based on the operational constraint parameter set; generating a candidate execution path set based on the service-data lineage coupling graph and the operational constraint model; comprehensively evaluating the candidate execution path set based on a path evaluation model; and determining a target execution path from the candidate execution path set based on the comprehensive evaluation result; and executing the power grid data service according to the target execution path. Compared with existing technologies, this invention incorporates service nodes and data object nodes into the coupling graph modeling, enabling service orchestration to identify the lineage association between services and data; through the parameterized expression and modeling of multi-dimensional operational constraints, multiple constraints can be considered simultaneously during the candidate path generation stage; and through the comprehensive evaluation of the path evaluation model, the target path selection has an executable safety margin. Therefore, this solves the technical problems of coarse-grained path generation and incomplete constraint consideration in existing power grid data service orchestration, achieving beneficial effects such as improving service scheduling efficiency and enhancing path execution stability.

[0048] Example 2 Figure 2 This is a flowchart of a power grid data service orchestration method provided in Embodiment 2 of the present invention. Based on the embodiments described above, this embodiment refines the method for determining the candidate execution path set. For example... Figure 2 As shown, the method includes: S210, Service-Data Lineage Coupling Diagram for Obtaining Power Grid Data Services.

[0049] S220. The preset operational constraints are parameterized according to the service-data lineage coupling diagram to obtain the operational constraint parameter set, and an operational constraint model is constructed according to the operational constraint parameter set.

[0050] S230. Starting from the target data object node in the service-data lineage coupling graph, trace back the service node and upstream data object node that can generate the target data object node, and form a candidate dependency closure based on the service node and upstream data object node.

[0051] In this context, the target data object node refers to the node in the coupling graph corresponding to the data result that the business system ultimately needs to obtain. For example, in a power grid operation analysis scenario, this node could represent "an operation status analysis result data table for a certain area"; in an equipment status assessment scenario, this node could represent "an equipment risk level assessment result dataset". This node is the endpoint of the entire path generation, and all candidate execution paths aim to generate this node as their final goal.

[0052] In this embodiment, starting from the target data object node in the service-data lineage coupling graph, the system searches backwards along the input edges and data lineage edges in the graph. Specifically, it first searches for all service nodes that can output the target data object node (i.e., the upstream services corresponding to the endpoints of the output edges of the target data object node); then, it continues to search for the input data object nodes required for these service nodes to execute (i.e., the data objects connected by the input edges of the service nodes); for the found input data object nodes, it continues to trace their origin upwards along the data lineage edges until it reaches the original data source (i.e., the data object that no upstream service can generate); at the same time, it traces the pre- and post-dependencies between services along the service call edges to ensure that the logical order of service execution is completely covered. Through the above layer-by-layer reverse tracing, the system can exhaustively enumerate all relevant elements that may logically generate the target data object.

[0053] During the reverse tracing process, the service nodes found are collectively referred to as "service nodes capable of generating target data object nodes," including services that directly output target data and services that output data upstream at each level. The data object nodes found are collectively referred to as "upstream data object nodes," including intermediate result data, raw data, and basic data accessed from other systems. A candidate dependency closure refers to a closed subgraph formed by all service nodes found during the reverse tracing process, all upstream data object nodes, and their input / output edges, data lineage edges, and service call edges.

[0054] In this embodiment, the candidate dependency closure contains all the candidate services and candidate data required to generate the target data object, ensuring that no possible paths are missed. Since the boundary of the candidate dependency closure ends at the original data source node (i.e., the data node that can be obtained without input from other external services), all data objects within the candidate dependency closure can find a way to generate them within the closure. Since the candidate dependency closure provides all potential transformation links from the original data to the business target, subsequent constraint pruning and path search are all performed within the scope of this candidate dependency closure, which not only ensures the comprehensiveness of the search but also significantly reduces the computational complexity and avoids invalid searches across the entire graph.

[0055] By forming this candidate dependency closure, the system transforms the originally complex full-graph path search problem into a constrained path search problem within a finite closure subgraph, laying the foundation for subsequent steps to efficiently generate multiple candidate execution paths that satisfy the runtime constraints.

[0056] S240. Prune the nodes and edges in the candidate dependency closure that do not meet the running constraints according to the running constraint model.

[0057] Pruning refers to the operation of deleting nodes and edges in candidate dependency closures that do not meet the runtime constraints, based on the runtime constraint model. Pruning can include node pruning and edge pruning.

[0058] In this embodiment, node pruning can specifically be performed on service nodes based on security level constraints, version compatibility constraints, and minimum quality threshold constraints in the runtime constraint model. If the security level of a service node does not meet the access requirements of the data objects involved, or its interface version is incompatible with upstream and downstream services, or its historical runtime data shows that its output data cannot stably reach the preset lower limit of quality compliance probability, then the service node is considered an unavailable node, removed from the candidate dependency closure, and the input and output edges connected to the node are also removed.

[0059] For data object nodes, the determination is made based on the quality constraints and timeliness constraints (hard parts) in the runtime constraint model. If the latest update time of a data object exceeds the upper limit of the time window allowed by the business, or its quality detection indicators (such as missing rate, outlier ratio) fail to meet the preset minimum threshold, then the data object node is considered an unusable node, deleted from the candidate dependency closure, and the edges connected to the node are also deleted.

[0060] Edge pruning can specifically involve determining the direction of data flow between input / output edges (i.e., edges representing the data flow between service nodes and data object nodes) based on field coverage constraints in the runtime constraint model. If the output fields of the service node cannot cover all the input fields required by the target data object node, the input / output relationship between the two cannot be established, and the edge is deleted.

[0061] For substitute edges (i.e., edges between service nodes that represent a substitutable relationship), the determination is made based on the substitution equivalence constraints in the runtime constraint model. The substitution equivalence constraints limit the lower bounds that substitute services must meet in terms of field coverage, consistency of definitions, lineage similarity, and quality confidence. If the substitution equivalence between two service nodes is below a preset threshold, then these two service nodes do not constitute a valid substitutable relationship, and the substitute edge is deleted.

[0062] For service call edges (i.e., edges representing call dependencies between service nodes), the determination is made based on the execution relationship constraints in the runtime constraint model. If the direction or dependency of an edge violates the mandatory execution order specified in the business rules, the call edge is deleted.

[0063] After the node and edge pruning processes described above, only nodes and edges satisfying the hard constraints are retained in the candidate dependency closure. The system performs subsequent constraint path searches in this pruned coupled graph, effectively avoiding invalid computations on paths that cannot satisfy the constraints. Simultaneously, the pruning operation preserves all feasible solutions that satisfy the hard constraints, ensuring that no valid paths are missed due to over-pruning. Through this pruning mechanism, the size of the candidate dependency closure is significantly compressed, providing a reliable data foundation for subsequent steps to efficiently search for multiple candidate execution paths that satisfy the runtime constraints.

[0064] S250. Based on the operational constraint model and the service-data lineage coupling graph, perform constraint path search in the pruned coupling graph to obtain a candidate execution path set consisting of multiple candidate execution paths that satisfy the operational constraints; wherein, each candidate execution path in the candidate execution path set carries a set of reusable nodes, a set of potential switching anchors, and an expected switching cost.

[0065] Each candidate execution path in the candidate execution path set carries a set of reusable nodes, a set of potential switching anchors, and an estimated switching cost.

[0066] The set of reusable nodes refers to the set of nodes in the candidate execution path that have been completed and whose output data still meets the requirements of quality, timeliness, and lineage. The set of potential switching anchors refers to the set of nodes in the candidate execution path that can serve as the starting point for path switching. The expected switching cost refers to the additional time, resource, or quality loss cost expected to be incurred when switching from the current path to an alternative path.

[0067] In this embodiment, constraint path search refers to the process of searching for all reachable paths from the original data object node, through intermediate service nodes and data object nodes, to the target data object node in the pruned coupled graph, provided that all constraints specified by the runtime constraint model are met. Unlike ordinary graph search (such as shortest path search), constraint path search in this step has the following characteristics: First, the legality of a path is determined jointly by multi-dimensional runtime constraints, rather than solely by topological connectivity; second, the same topological link may exhibit different feasibility under different runtime environments due to varying constraint satisfaction; and third, the search objective is not to find an optimal path, but rather to find all feasible paths that satisfy the constraints, forming a candidate set.

[0068] During the constrained path search process, the alternative edge information in the coupled graph is fully utilized. As mentioned earlier, alternative edges connect service nodes with substitutable relationships, and their substitutability is determined by a combination of field coverage, data source lineage similarity, statistical consistency, time window overlap, and historical quality confidence. During the search, alternative service groups formed by service nodes connected by alternative edges are identified, and multiple candidate service nodes that meet the constraint relaxation requirements are retained within each group.

[0069] Specifically, when the search reaches a service node, the system checks other service nodes in the alternative service group to which that node belongs. For each candidate service node in the group, the system calculates its quality slack, timeliness slack, and resource slack in the context of the current search path. Only candidate nodes whose slack meets the preset lower limit are retained as the next possible step in the current path branch. If multiple candidate nodes in the group meet the requirements, these nodes form different path branches, rather than selecting only one and discarding the others. In this way, sufficient alternative solutions can be reserved for possible subsequent path switching during the path generation stage, avoiding insufficient alternative paths due to retaining only a single node.

[0070] When performing a search in the pruned coupled graph, a complete link from the upstream data object to the target data object is constructed one by one, and the satisfaction of various runtime constraints is verified layer by layer during the construction process: (1) Data dependency constraint verification: During the search process, ensure that all input data objects of each service node in the path have been generated in the previous steps, that is, the data dependencies of the path can be satisfied in both time and logic. If an input data object of a certain service node has not been generated in the current path prefix, the path branch is marked as invalid and will not be expanded further.

[0071] (2) Data quality constraint verification: For key data objects involved in the path, determine whether they meet the preset quality threshold based on their quality detection indicators (such as completeness, accuracy, outlier ratio and missing rate). If the quality indicators of a data object do not meet the requirements, the path branch passing through that data object is excluded.

[0072] (3) Timeliness constraint verification: Accumulate the expected response latency and data transmission latency of each service node in the path, and combine them with the freshness of each data object to calculate whether the total execution time of the path meets the requirements of the business completion time window. If the expected total time exceeds the upper limit of the window, the path branch is excluded.

[0073] (4) Verification of resource constraints and interface call quota constraints: Accumulate the estimated values ​​of CPU, memory, bandwidth and other resources consumed by service nodes in the path segment by segment, as well as the number of interface calls, to ensure that the resource consumption does not exceed the upper limit and the number of interface calls does not exceed the quota at any time. If an excess is found during the accumulation process, the corresponding branch is excluded.

[0074] In this embodiment, a depth-first or breadth-first graph traversal strategy is adopted during the search process. All nodes and edges are systematically enumerated until all complete links that can reach the target data object from the initial raw data and satisfy the constraints in all dimensions are exhausted.

[0075] For each complete path that meets the runtime constraints obtained from the search, the system needs to attach the following three types of runtime metadata to the path before adding it to the candidate execution path set: Reusable node set: In the current path, if a service node has already been completed in the preceding execution and its output data object still meets the quality requirements and timeliness window, then the node can be marked as a reusable node. This set is used to determine which upstream results can be directly reused without regeneration during subsequent actual execution.

[0076] Potential switching anchor set: In the current path, if a node, upon completion, demonstrates good stability and reusability in terms of lineage, field coverage, quality, and timeliness, then that node can serve as a potential switching anchor. When a switch is required during path execution, the system can select a starting point from these anchors without having to start from scratch.

[0077] Expected switching cost: This refers to the additional costs that are expected to be incurred when switching from each potential switching anchor point of the current path to an alternative path. This includes the increase in remaining execution time after the switch, the proportion of workload that needs to be recalculated, and the potential loss of quality or additional consumption of resources.

[0078] S260. The candidate execution path set is comprehensively evaluated based on the path evaluation model, and the target execution path is determined from the candidate execution path set according to the comprehensive evaluation results.

[0079] Optionally, the comprehensive evaluation result includes: at least one of the following for each candidate execution path in the candidate execution path set output by the path evaluation model: comprehensive cost value, constraint satisfaction probability, minimum constraint relaxation, and executability confidence. The comprehensive cost value refers to the overall cost value output by the path evaluation model after comprehensively considering factors such as historical success rate, historical latency distribution, data quality compliance probability, resource usage prediction, remaining interface quota, substitution equivalence, path stability, reusable node ratio, and expected switching costs. The constraint satisfaction probability refers to the probability that a candidate execution path satisfies all operational constraints in its current running state. The minimum constraint slackness is the minimum constraint slackness of the candidate execution path on data quality constraints, timeliness constraints, resource constraints, and interface call quota constraints. Constraint slackness represents the safety margin of a candidate execution path from the constraint boundary under constraints such as quality, timeliness, resources, and call quota. The larger the constraint slackness, the less likely the path is to violate constraints in its current running state. Executability confidence refers to the degree of certainty that a candidate execution path can be successfully executed.

[0080] In this embodiment, the target execution path can be determined in the following order: first, the probability of satisfying constraints; then, the minimum constraint relaxation; next, the overall cost; and finally, the executable confidence. This evaluation method avoids the path instability problem caused by prior art that selects paths solely based on the shortest path, fewest nodes, static priority, or manual weighting. Specifically, by introducing minimum constraint relaxation, it avoids selecting paths with high overall scores but where a critical constraint is close to the failure boundary.

[0081] S270. Execute the power grid data service according to the target execution path.

[0082] As an optional embodiment, the process of executing the power grid data service according to the target execution path further includes: Generate a path execution token; The running status of each service node is collected in real time, and the collected running status information is written into the path execution token; When a constraint violation risk is detected in the current path or a constraint violation risk is predicted, a path switching is triggered by a token based on the path.

[0083] Among them, the path execution token refers to a runtime data structure used to record the current execution position, completed node set, generated data objects, data quality inspection results, data validity time window, resource consumption, and reusability status of the target execution path. Constraint violation risk refers to the risk that the current execution path will not meet a certain operational constraint during operation. Predicting the existence of constraint violation risk refers to the risk predicted based on historical fluctuation models that the current path is about to violate timeliness constraints, quality constraints, or resource constraints.

[0084] In this embodiment, various data services in the power grid data service are scheduled according to the target execution path. During the scheduling process, the system generates a path execution token. Real-time status information such as response latency, call results, error codes, resource usage, data quality detection results, and interface quota consumption of each service node is collected and written into the path execution token. Based on the status information, the system detects whether there is a risk of constraint violation in the current path and predicts whether there is a risk of imminent constraint violation (such as timeliness constraints, quality constraints, or resource constraints) based on historical fluctuation models. When a constraint violation risk is detected in the current path, such as service node call failure, response latency exceeding a threshold, output data quality not meeting constraints, insufficient interface quota, or excessive resource usage, or when a constraint violation risk is predicted, such as the remaining execution time exceeding the business completion window, dynamic path switching is triggered.

[0085] Existing exception handling methods mostly involve failure retry, full process rollback, or overall rerun. This embodiment records the complete running status during path execution through path execution tokens and triggers path switching when constraint violation is detected or a risk of constraint violation is predicted. This realizes the transformation from passive exception handling to proactive predictive switching, and can complete path adjustment before actual faults or service timeouts occur, thereby improving the continuity of power grid services.

[0086] Optionally, the trigger path switching includes: Based on the path execution token, determine the set of data object nodes that have been completed and are still valid; Select reusable switching anchor points that meet the reusability conditions from the set of data object nodes; the reusability conditions include: If no available path exists in the candidate execution path set, then an alternative path that is compatible with the reusable switching anchor point and satisfies the constraints on the remaining subgraph is selected from the candidate execution path set. If no available path exists in the candidate execution path set, then the reusable switching anchor point is used as the new starting point to perform incremental path search and replanning of execution paths on the remaining dependency subgraph.

[0087] In this context, a reusable switching anchor point refers to a service node or data object node in the current execution path that has been completed and whose output data still meets the requirements of lineage, fields, quality, and timeliness. When switching paths, the reusable switching anchor point serves as the starting point, and alternative paths are selected or replanned only for the remaining incomplete subgraphs. The remaining subgraph refers to the subgraph formed by the nodes and edges between the reusable switching anchor point and the target data object that have not yet been executed. Incremental path search refers to using the reusable switching anchor point as a new starting point and performing a path search only on the remaining dependency subgraphs, rather than re-searching the entire dependency closure.

[0088] In this embodiment, during path switching, the system first determines the set of completed and still valid data objects based on the path execution token, and selects a reusable switching anchor point that satisfies lineage consistency, field coverage, quality threshold, and timeliness window. If no available path exists in the candidate execution path set, an alternative path that is compatible with the switching anchor point and satisfies the constraints on the remaining subgraph is selected from the pre-generated candidate paths. If no available path exists in the pre-generated candidate paths, the system uses the switching anchor point as a new starting point to perform incremental path search and path replanning on the remaining dependency subgraph.

[0089] When selecting alternative paths, priority is given to constraint satisfaction, number of reused nodes, switching cost, estimated remaining execution time, and path stability. To avoid frequent switching, the system can set a minimum switching interval, a maximum number of switching attempts, and a switching benefit threshold. Switching is only performed when the alternative path provides sufficient constraint improvement or risk reduction compared to the current path.

[0090] In this embodiment, reusable switching anchors are identified based on path execution tokens, and compatible alternative paths are selected from the candidate path set or incremental replanning is performed when no path is available. This achieves path switching or replanning only on the remaining subgraph, which is different from failure retries, entire path rollback or execution from the beginning in the prior art. This greatly reduces the cost of anomaly recovery and improves cross-system service continuity.

[0091] As an optional implementation, after path execution or switching is complete, the actual execution latency, actual resource consumption, service call results, data quality detection results, whether a switch occurred, post-switch path performance, and anomaly recovery time can be written to the historical operation database, and the service node status, alternative edge equivalence, path evaluation model parameters, and constraint relaxation calculation parameters can be updated. Through continuous feedback, the system can dynamically adjust the path selection strategy according to power grid business peaks, interface status changes, data quality fluctuations, and resource environment changes.

[0092] As an optional embodiment, the system executing this method can output the target path, candidate paths, reasons for path selection, constraint slackness, switching anchor point, reused data objects, path differences before and after switching, and anomaly cause location information. This information can be used for operation and maintenance traceability, service governance, data quality governance, and implementation effect verification. Building upon the previous embodiments, this example further enhances the dynamic orchestration and scheduling of power grid data services through mechanisms such as the construction of alternative service groups, predictive constraint violation identification, incremental replanning, and operation feedback-driven model updates. The construction of alternative service groups ensures that substitution relationships are established based on multi-dimensional comprehensive judgment; dynamic switching triggered by predictive constraint violations enables path adjustments to be completed before actual faults occur; and reusable switching anchors and incremental replanning allow path switching to be performed only on the remaining subgraphs, significantly reducing anomaly recovery costs.

[0093] In a specific embodiment, the data service orchestration process for power grid operation analysis is described as follows: In a power grid operation analysis scenario, the business system needs to generate operational status analysis results for a certain region within a specified time window. These results rely on real-time operational data, historical operational data, equipment status data, and load forecasting algorithm services. The system retrieves the lineage relationships of relevant data objects from the data catalog and obtains metadata for real-time operational data services, historical data cleaning services, equipment status fusion services, and load forecasting algorithm services from the service registry center.

[0094] The system constructs a service-data lineage coupling graph. In this graph, both real-time running data service A and real-time running data service B are service nodes capable of generating target real-time running data objects, but they originate from different acquisition links. The system calculates the substitution equivalence between them based on field coverage, field mapping relationships, data source lineage similarity, statistical consistency, timeliness window overlap, and historical quality confidence. If service A has a high historical quality confidence but a long response latency, while service B has a fast response but large quality fluctuations, then the substitution equivalence between them reaches a preset threshold. The system establishes a substitution edge between them, includes them in the same substitution service group, and records the corresponding substitution equivalence and expected switching cost for the substitution edge.

[0095] During the candidate path generation phase, the system starts from the target data object node and traces back to the service nodes and upstream data object nodes that can generate the target data object node, forming candidate dependency closures. The system prunes nodes and edges in the candidate dependency closures that do not meet the runtime constraints according to the runtime constraint model, and performs constraint path search in the pruned coupled graph. During the search, the system sets data quality constraint thresholds, total completion time windows in timeliness constraints, and resource constraint upper limits according to business requirements, calculates the constraint slackness of each candidate path under each dimension of constraints, and takes the minimum value as the minimum constraint slackness. The system selects the path with the lowest overall cost and the minimum constraint slackness as the target execution path, following the order of first satisfying hard constraints, then comparing the minimum constraint slackness, and finally comparing the overall cost value.

[0096] During execution, the system schedules various data services in the power grid data service according to the target execution path and generates a path execution token. If the response latency of real-time running data service A continuously increases, the system predicts that the remaining execution time may exceed the business time window, i.e., there is a risk of constraint violation. Therefore, a path switch is triggered before service A completely fails. Based on the path execution token, the system determines that the data object nodes corresponding to the historical data cleaning results and equipment status fusion results still meet the quality and timeliness requirements. Therefore, a reusable switching anchor point is selected from the set of completed and still valid data object nodes. The system selects an alternative path from the candidate execution path set that is compatible with the reusable switching anchor point and meets the constraints of the remaining subgraph. Only the real-time running data acquisition stage is switched to service B, and the remaining load prediction and situation analysis steps continue to be executed. After the switch, the system writes the actual execution latency, service call results, and data quality detection results into the historical operation database to update the path evaluation model parameters.

[0097] In another specific embodiment, the process of cross-system service orchestration for power grid marketing analysis is given as follows: In the power grid marketing analysis scenario, the business system needs to generate customer electricity consumption behavior analysis results within the marketing business window. These results rely on data services from the metering system, customer information system, payment record data, and analytical application services. Inconsistencies exist between these systems regarding interface call quotas, network latency, and data caliber. The system constructs a service-data lineage coupling graph, identifies multiple substitutable service nodes for the metering data service based on the graph, and calculates substitution equivalence based on field coverage, statistical caliber consistency, timeliness window overlap, and historical quality confidence. Substitutive edges are established between service nodes with substitution equivalence greater than a preset threshold, generating substitutable service groups. The system further establishes an operational constraint model that includes data quality constraints, timeliness constraints, resource constraints, and interface call quota constraints.

[0098] During execution, when the response latency of the metering system data service node continuously increases and the remaining interface call quota is insufficient to support subsequent calls, the system detects a constraint violation in the current path and triggers a path switch. Based on the path execution token, the system determines that customer information data and payment record data have been generated and are still within the valid time window; therefore, the aforementioned data object nodes are used as reusable switching anchors. The system selects an alternative path from the candidate execution path set to call the backup metering data service, only re-acquiring the metering data and continuing to execute subsequent analysis services, without needing to re-call the customer information system and payment record system.

[0099] If there is no available path in the candidate execution path set that is compatible with the reusable switching anchor and satisfies the constraints on the remaining subgraph, then the reusable switching anchor is used as the new starting point to perform incremental path search and replanning of the execution path on the remaining dependent subgraph, generate new candidate paths, and select the path with the lowest expected switching cost for execution.

[0100] In another specific embodiment, in the equipment condition assessment scenario, the system needs to integrate online monitoring data, maintenance records, defect records and environmental data, and call the condition assessment algorithm service to generate the equipment risk level. The data update frequency and quality stability of different data sources vary.

[0101] The system constructs a service-data lineage coupling graph to identify the substitution relationships between online monitoring data service nodes and backup monitoring aggregation service nodes. It calculates substitution equivalence based on field coverage, data source lineage similarity, statistical consistency, timeliness window overlap, and historical quality confidence. When the substitution equivalence exceeds a preset threshold, a substitution edge is established between the two nodes. The system also establishes an operational constraint model that includes data quality and timeliness constraints.

[0102] During execution, when the data loss rate of the online monitoring data service node increases but the call has not yet failed, the system predicts that this trend may lead to subsequent status evaluation results not meeting data quality constraints, i.e., a risk of constraint violation, thus triggering a path switch. The system determines, based on the path execution token, that the maintenance and defect records have been completed and still meet the timeliness constraints. It uses the corresponding data object node as a reusable switch anchor point, selects an alternative path compatible with the reusable switch anchor point from the candidate execution path set, replaces only the online monitoring data branch, replaces the original online monitoring data service with the backup monitoring aggregation service, and continues to execute the status evaluation algorithm service.

[0103] Example 3 Figure 3 This is a schematic diagram of the structure of a power grid data service orchestration system provided in Embodiment 3 of the present invention. Figure 3 As shown, the system includes: Module 310 is used to obtain the service-data lineage coupling graph of power grid data services; The model building module 320 is used to parameterize the preset running constraints according to the service-data lineage coupling diagram, obtain the running constraint parameter set, and build the running constraint model according to the running constraint parameter set. The candidate path determination module 330 is used to generate a set of candidate execution paths based on the service-data lineage coupling graph and the runtime constraint model. The target path determination module 340 is used to comprehensively evaluate the candidate execution path set based on the path evaluation model, and determine the target execution path from the candidate execution path set according to the comprehensive evaluation result; The path execution module 350 is used to execute the power grid data service according to the target execution path.

[0104] Optionally, the service-data lineage coupling graph includes: service nodes and data object nodes; the service nodes and the data object nodes are connected by at least one of data lineage edges, service call edges, substitution edges, and result reuse edges; The service node represents a schedulable data service, and the data object node represents the data input or output by the service node. The data lineage edges connect data object nodes and are used to represent the source-derived relationship between data objects; The service call edge connects the service nodes and is used to represent the call dependency relationship or pre- and post-execution relationship between data services; The alternative edge connects service nodes that have a substitutable relationship, and is used to indicate that the service nodes are substitutable when a preset substitution condition is met. The result reuse edge connects the completed node and the subsequent node, indicating that the completed result can be reused by the subsequent path.

[0105] Optionally, the alternative edges can be constructed in the following ways: The substitution equivalence between every two service nodes is calculated based on substitution evaluation indicators; the substitution evaluation indicators include at least one of the following factors: field coverage, field mapping relationship, data source lineage similarity, statistical consistency, time window overlap, and historical quality confidence. If the substitution equivalence between the two service nodes is greater than a preset threshold, then the substitution edge is established between the two service nodes.

[0106] Optionally, the operational constraints include at least one of the following: Data quality constraints, timeliness constraints, resource constraints, interface call quota constraints, execution relationship constraints, substitution equivalence constraints, and result reuse constraints; The data quality constraint, the timeliness constraint, the resource constraint, and the interface call quota constraint are used to limit the boundary conditions during the path execution process; the execution relationship constraint is used to limit the execution order between service nodes; the substitution equivalence constraint is used to limit the service substitution conditions; and the result reuse constraint is used to limit the result reuse conditions.

[0107] Optionally, the candidate path determination module has the following functions: Starting from the target data object node in the service-data lineage coupling graph, trace back the service node and upstream data object node that can generate the target data object node, and form a candidate dependency closure based on the service node and upstream data object node; Prune nodes and edges in the candidate dependency closure that do not meet the running constraints according to the running constraint model; Based on the operational constraint model and the service-data lineage coupling graph, a constraint path search is performed in the pruned coupling graph to obtain a candidate execution path set consisting of multiple candidate execution paths that satisfy the operational constraints; Each candidate execution path in the candidate execution path set carries a set of reusable nodes, a set of potential switching anchors, and an estimated switching cost.

[0108] Optionally, the comprehensive evaluation result includes: at least one of the following for each candidate execution path in the candidate execution path set output by the path evaluation model: comprehensive cost value, constraint satisfaction probability, minimum constraint relaxation, and executability confidence. The minimum constraint slackness is the minimum value of the constraint slackness of the candidate execution path on data quality constraints, timeliness constraints, resource constraints, and interface call quota constraints.

[0109] Optional, also includes: An execution token generation module is used to generate a path execution token during the execution of the power grid data service according to the target execution path; The status writing module is used to collect the running status of each service node in real time and write the collected running status information into the path execution token. The path switching module is used to trigger path switching based on a token when a constraint violation is detected in the current path or a risk of constraint violation is predicted.

[0110] Optionally, the step of triggering a path switch based on the path using a token includes: Based on the path execution token, determine the set of data object nodes that have been completed and are still valid; Select reusable switching anchor points that meet the reusability conditions from the set of data object nodes; the reusability conditions include: If no available path exists in the candidate execution path set, then an alternative path that is compatible with the reusable switching anchor point and satisfies the constraints on the remaining subgraph is selected from the candidate execution path set. If no available path exists in the candidate execution path set, then the reusable switching anchor point is used as the new starting point to perform incremental path search and replanning of execution paths on the remaining dependency subgraph.

[0111] The power grid data service orchestration system provided in this embodiment of the invention can execute the power grid data service orchestration method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0112] Example 4 Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0113] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0114] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0115] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as power grid data service orchestration methods.

[0116] In some embodiments, the power grid data service orchestration method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the power grid data service orchestration method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the power grid data service orchestration method by any other suitable means (e.g., by means of firmware).

[0117] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0118] In some embodiments, the power grid data service orchestration method can be implemented as a computer program, which is implicitly included in a computer program product. When executed by a processor, the computer program implements the power grid data service orchestration method of the present invention. The computer program product can be understood as a software product that primarily implements its solution through a computer program. The computer program used to implement the method of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program can be executed entirely on a machine, partially on a machine, partially on a remote machine as a standalone software package, or entirely on a remote machine or server.

[0119] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0120] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0121] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0122] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0123] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0124] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for orchestrating power grid data services, characterized in that, include: Service-data lineage coupling diagram for obtaining power grid data services; The preset operational constraints are parameterized according to the service-data lineage coupling diagram to obtain the operational constraint parameter set, and an operational constraint model is constructed based on the operational constraint parameter set. A set of candidate execution paths is generated based on the service-data lineage coupling graph and the operational constraint model; The candidate execution path set is comprehensively evaluated based on the path evaluation model, and the target execution path is determined from the candidate execution path set based on the comprehensive evaluation results. The power grid data service is executed according to the target execution path.

2. The method according to claim 1, characterized in that, The service-data lineage coupling graph includes: service nodes and data object nodes; the service nodes and the data object nodes are connected by at least one of the following: data lineage edge, service call edge, substitution edge, and result reuse edge; The service node represents a schedulable data service, and the data object node represents the data input or output by the service node. The data lineage edges connect data object nodes and are used to represent the source-derived relationship between data objects; The service call edge connects the service nodes and is used to represent the call dependency relationship or pre- and post-execution relationship between data services; The alternative edge connects service nodes that have a substitutable relationship, and is used to indicate that the service nodes are substitutable when a preset substitution condition is met. The result reuse edge connects the completed node and the subsequent node, indicating that the completed result can be reused by the subsequent path.

3. The method according to claim 2, characterized in that, The methods for constructing the alternative edges include: The substitution equivalence between every two service nodes is calculated based on substitution evaluation indicators; the substitution evaluation indicators include at least one of the following factors: field coverage, field mapping relationship, data source lineage similarity, statistical consistency, time window overlap, and historical quality confidence. If the substitution equivalence between the two service nodes is greater than a preset threshold, then the substitution edge is established between the two service nodes.

4. The method according to claim 1, characterized in that, The operational constraints include at least one of the following: Data quality constraints, timeliness constraints, resource constraints, interface call quota constraints, execution relationship constraints, substitution equivalence constraints, and result reuse constraints; The data quality constraint, the timeliness constraint, the resource constraint, and the interface call quota constraint are used to limit the boundary conditions during the path execution process; the execution relationship constraint is used to limit the execution order between service nodes; the substitution equivalence constraint is used to limit the service substitution conditions; and the result reuse constraint is used to limit the result reuse conditions.

5. The method according to claim 1, characterized in that, A set of candidate execution paths is generated based on the service-data lineage coupling graph and the runtime constraint model, including: Starting from the target data object node in the service-data lineage coupling graph, trace back the service node and upstream data object node that can generate the target data object node, and form a candidate dependency closure based on the service node and upstream data object node; Prune nodes and edges in the candidate dependency closure that do not meet the running constraints according to the running constraint model; Based on the operational constraint model and the service-data lineage coupling graph, a constraint path search is performed in the pruned coupling graph to obtain a candidate execution path set consisting of multiple candidate execution paths that satisfy the operational constraints; Each candidate execution path in the candidate execution path set carries a set of reusable nodes, a set of potential switching anchors, and an estimated switching cost.

6. The method according to claim 1, characterized in that, The comprehensive evaluation results include: at least one of the following for each candidate execution path in the candidate execution path set output by the path evaluation model: comprehensive cost value, constraint satisfaction probability, minimum constraint relaxation, and executability confidence. The minimum constraint slackness is the minimum value of the constraint slackness of the candidate execution path on data quality constraints, timeliness constraints, resource constraints, and interface call quota constraints.

7. The method according to claim 1, characterized in that, The process of executing the power grid data service according to the target execution path also includes: Generate a path execution token; The running status of each service node is collected in real time, and the collected running status information is written into the path execution token; When a constraint violation is detected in the current path or a risk of constraint violation is predicted, a path switching is triggered by a token based on the path.

8. The method according to claim 7, characterized in that, The step of triggering a path switch based on the path using a token includes: Based on the path execution token, determine the set of data object nodes that have been completed and are still valid; Select reusable switching anchor points that meet the reusability conditions from the set of data object nodes; the reusability conditions include: If no available path exists in the candidate execution path set, then an alternative path that is compatible with the reusable switching anchor point and satisfies the constraints on the remaining subgraph is selected from the candidate execution path set. If no available path exists in the candidate execution path set, then the reusable switching anchor point is used as the new starting point to perform incremental path search and replanning of execution paths on the remaining dependency subgraph.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the power grid data service orchestration method according to any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the power grid data service orchestration method according to any one of claims 1-8.

Images