Government affair big data public service platform method
By constructing a cross-departmental permission credential chain and adaptive resource scheduling, the dynamic parsing and resource management issues of the government data service platform were resolved, achieving an efficient and secure government data service process and improving the platform's responsiveness and stability.
Patent Information
- Application Number
- CN202511450612.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-11
- Publication Date
- 2026-02-17
AI Technical Summary
Existing government data service platforms lack dynamic parsing and service chain construction mechanisms, resulting in insufficient response flexibility, lack of dynamic verification in data access control, security risks, and improper resource management that can lead to computing bottlenecks and resource contention, reducing platform efficiency and stability.
By employing technical solutions such as service chain definition, dynamic permission anchoring, data lineage encapsulation, and adaptive resource scheduling, a cross-departmental permission credential chain is constructed to achieve dynamic permission verification and optimized resource scheduling, generate standard data containers, and dynamically execute edge transfer strategies under high concurrency conditions.
It significantly improves the transparency and flexibility of government data service processes, enhances data security and accountability, improves system compatibility and overall execution efficiency, and ensures platform stability.
Smart Images
Figure CN121542022A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application relates to the technical field of big data service platforms, and in particular to a government affair big data public service platform method. BACKGROUND
[0002] With the continuous promotion of digital transformation of government affairs, government departments have accumulated a large amount of government data resources of heterogeneous structures, covering multiple fields such as population, education, medical treatment, transportation, industry and commerce, social security and the like. In order to improve the efficiency of public services and the ability of data governance, government data service platforms for business collaboration and resource sharing are generally deployed by government agencies at all levels, so as to realize the query, aggregation, sharing and calling of government data. However, the cross-system and cross-department flow of government data often involves multiple challenges such as permission control, service chain arrangement, data format conversion and system resource scheduling.
[0003] In the prior art, the government data service platform mainly relies on static configuration of service rules and manual preset of data interface calling process, lacks dynamic analysis of user requests and service chain construction mechanism, and leads to rigid service process and insufficient response flexibility; in terms of data permission management, only static access control list or single-point identity authentication is generally adopted, and dynamic permission verification and traceable mechanism for the whole process of data flow are lacked, which easily leads to data overreach and security risks; at the same time, for the resource management problem of concurrent execution of multiple service nodes, there is a lack of effective load regulation means, and the computing bottleneck or resource preemption phenomenon is easily caused, which reduces the service efficiency and stability of the whole platform. SUMMARY
[0004] The application provides a government affair big data public service platform method, and provides a technical solution capable of fusing dynamic analysis of service chain, verification of permission chain, encapsulation of data blood relationship and adaptive scheduling of resources.
[0005] A government affair big data public service platform method comprises the following steps: S1, service chain definition: a service request analysis module receives a government data service request submitted by a user, and analyzes and generates a government data service chain comprising N ordered service nodes, wherein each service node defines a set of input data identifiers, data processing logic code and a set of output data identifiers; S2, dynamic permission anchoring: a permission anchoring engine constructs a cross-department permission credential chain based on the government data service chain generated in S1, verifies the dynamic data use credentials corresponding to the input data identifiers held by the current operator by traversing each node of the service chain, and embeds a permission traceability label comprising the operator identity and the operation type in the output data identifier, to generate data with the permission traceability label; S3, data lineage encapsulation: the heterogeneous data encapsulation engine encapsulates the data with the permission traceability label generated in S2 into a standard data container including a data ontology layer, a lineage metadata layer, and a service interface layer; S4, service chain self-optimization execution: the resource scheduler monitors resource occupancy in a service node running environment based on the standard data container generated in S3, and when the threshold is exceeded, the low-priority container is stored to an edge computing cache pool, and the optimized service result is output.
[0006] Optionally, the S1 comprises: S11, service request receiving: a service request parsing module receives a user-submitted government data service request; S12, service node parsing: the service request parsing module parses the government data service request to generate a logical topology structure of N ordered service nodes; S13, node parameter definition: the service request parsing module defines an input data identifier set, data processing logic code, and an output data identifier set for each service node; S14, service chain generation: the service request parsing module integrates the N ordered service nodes and their corresponding input data identifier sets, data processing logic codes, and output data identifier sets to generate a complete government data service chain.
[0007] Optionally, the S2 comprises: S21, credential chain construction: a permission anchoring engine constructs a cross-department permission credential chain based on the government data service chain generated in S1; S22, node credential verification: the permission anchoring engine traverses each service node in the government data service chain, and verifies the dynamic data use credential held by the current operator against the input data identifier set of the current service node; S23, traceability label generation: the permission anchoring engine embeds a permission traceability label in the output data identifier of the current service node, the permission traceability label including the identity information of the current operator and the operation type code; S24, permission data output: the permission anchoring engine integrates all output data identifier sets with embedded permission traceability labels to generate data with permission traceability labels.
[0008] Optionally, the S21 comprises: S211, node-level data permission extraction: the permission anchoring engine traverses the government data service chain generated by the service request parsing module, extracts the input data identifier set of each service node in the service chain, and aggregates to form an input data resource list at the chain level for subsequent permission attribution analysis and authorization management; S212, data ownership department identification: the authority anchoring engine performs ownership department identification operation on each item in the extracted input data identifier set based on the government data resource catalog, determines the government department corresponding to each data identifier, and generates a one-to-one mapping relationship table between the data identifier and the ownership department as the basis for the distribution of the credential request; S213, authority credential request generation: the authority anchoring engine constructs the authority credential request of the data resources in the department range for each ownership department according to the mapping relationship table, and the content includes the identity information of the current service request initiator, the list of all data identifiers belonging to the department, and the data use purpose description; S214, cross-department credential collaborative acquisition: the authority anchoring engine distributes the authority credential request to the corresponding government departments, and requests to generate the respective data use credentials by calling the local or blockchain-based authorization mechanism. Each credential includes the authorized data identifier, the identity of the current operator, the authorized operation type, and the digital signature generated by the authorized department, ensuring the authenticity and non-repudiation of the credential; S215, authority credential chain aggregation: the authority anchoring engine collects all the authorized credentials returned by each department and aggregates them uniformly to form a cross-department authority credential chain. The credential chain will serve as the basis for subsequent node-level authority verification and authority traceability label generation throughout the entire service chain execution process.
[0009] Optionally, the S3 comprises: S31, data ontology extraction: the heterogeneous data packaging engine extracts the data ontology layer from the data with the authority traceability label generated in S2; S32, blood relationship metadata construction: the heterogeneous data packaging engine analyzes the authority traceability label in the data with the authority traceability label to generate a blood relationship metadata layer including an operator identity chain, a data operation sequence, and a permission change record; S33, service interface packaging: the heterogeneous data packaging engine generates a service interface layer supporting a standardized data access protocol based on the data ontology layer and the blood relationship metadata layer; S34, container integration output: the heterogeneous data packaging engine performs hierarchical binding on the data ontology layer, the blood relationship metadata layer, and the service interface layer to generate a standard data container.
[0010] Optionally, the S31 comprises: S311, data structure analysis: the heterogeneous data packaging engine analyzes the data with the authority traceability label generated in S2 to identify the data ontology block and the authority traceability label block therein; S312, label stripping operation: the heterogeneous data packaging engine strips the authority traceability label block from the data with the authority traceability label and retains the original data ontology block; S313, body integrity verification: the heterogeneous data packaging engine performs hash check on the original data ontology block, and if the hash value is consistent with the ontology hash value in the permission traceability label block, the data ontology layer is output.
[0011] Optionally, the S32 comprises: S321, label structure analysis: the heterogeneous data packaging engine analyzes the permission traceability label in the data with the permission traceability label, extracts operator identity information, operation type code and associated data identifier; S322, identity chain reconstruction: the heterogeneous data packaging engine concatenates the operator identity information of each service node into an operator identity chain according to the node execution order of the government data service chain; S323, operation sequence generation: the heterogeneous data packaging engine generates a data operation sequence including read-write operation type, operation timestamp and target data identifier according to the mapping relationship between the operation type code and the data identifier; S324, blood relationship metadata packaging: the heterogeneous data packaging engine integrates the operator identity chain, the data operation sequence and the permission change record to build a structured blood relationship metadata layer.
[0012] Optionally, the S4 comprises: S41, container loading: the resource scheduler loads the standard data container generated by S3 to the service node running environment corresponding to the government data service chain; S42, resource monitoring: the resource scheduler monitors the resource occupation rate of each standard data container in the service node running environment in real time; S43, edge storage decision: when the resource scheduler detects that the resource occupation rate of any standard data container exceeds the preset threshold, the standard data container is marked as a low-priority container and stored in the edge computing cache pool.
[0013] Optionally, the S4 further comprises: S44, container execution: the resource scheduler executes the standard data container whose resource occupation rate does not exceed the preset threshold in the service node running environment, and executes the stored low-priority container in the edge computing cache pool; S45, result integration: the resource scheduler collects the container execution results output by the service node running environment and the edge computing cache pool, and integrates to generate the service result after optimization execution.
[0014] The beneficial effects of the present application are: The application, through the service request analysis module in S1, structurally disassembles the user request, constructs a government data service chain composed of ordered service nodes, and clearly defines the input data identifier, data processing logic code and output data identifier of each service node, not only realizes accurate data docking between multiple nodes, but also provides technical support for service chain visual modeling and dynamic path analysis, and significantly improves the transparency and flexibility of government data service process.
[0015] The application, through the permission anchoring engine in S2, can verify the data use permission of each node operator of the service chain one by one based on the cross-department permission certificate chain constructed by the blockchain, and embeds a permission traceability label with the operator identity and operation type in the output data, effectively preventing data abuse and unauthorized access. At the same time, the label mechanism constructs a complete operator identity chain and data operation track, has good auditability and traceability, and improves the data security and responsibility controllable ability.
[0016] The application, through the multi-layer encapsulation of data with permission traceability label in S3, constructs a standard data container containing data ontology layer, bloodline metadata layer and service interface layer, realizes the format unification and interface standardization of data, enhances the system compatibility, and the resource scheduler in S4 dynamically executes the edge storage and main node parallel scheduling strategy based on the real-time monitoring of container resource occupation rate, can actively release the system core resources under high concurrency conditions, and significantly improves the overall service chain execution efficiency and platform running stability. BRIEF DESCRIPTION OF DRAWINGS
[0017] In order to more clearly illustrate the technical solutions in the present application or prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only a part of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.
[0018] Figure 1 The method flowchart of the embodiment of the present application. DETAILED DESCRIPTION
[0019] The present application will be described in detail below in combination with the drawings and specific embodiments. It should be noted here that in order to make the embodiments more detailed, the following embodiments are the best and preferred embodiments, and other alternative ways can also be used by those skilled in the art to implement them; and the drawings are only used to more specifically describe the embodiments, and are not intended to specifically limit the present application.
[0020] It is to be noted that references in the specification to "one embodiment", "an embodiment", "exemplary embodiment", "some embodiments", etc. indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, the descriptions of the various embodiments can be presented with reference to the accompanying drawings, which can be used to illustrate the features, structures, or characteristics of the various embodiments. Furthermore, the descriptions of the various embodiments can be presented with reference to terms that can be used to describe the features, structures, or characteristics of the various embodiments. These terms are to be understood as not necessarily referring to the same underlying feature, structure, or characteristic of the various embodiments.
[0021] In general, the terminology or the terminology used in the specification can be understood at least in part from the context in which it is used. For example, the terminology "one or more" as used herein, depending at least in part upon the context in which it is used, can be used to describe any feature, structure, or characteristic in a singular sense or can be used to describe combinations of features, structures, or characteristics in a plural sense. Additionally, the term "based on" can be understood as not necessarily requiring a set of factors to be exhaustive of factors that can be relevant to a combination of factors that form a basis for the understanding, but instead can allow for further factors to be relevant to the combination of factors that form the basis for the understanding.
[0022] As shown in Figure 1 A government affair big data public service platform method, comprising the following steps: S1, service chain definition: a service request parsing module receives a government data service request submitted by a user, and parses to generate a government data service chain including N ordered service nodes, wherein each service node defines a set of input data identifiers, data processing logic code, and a set of output data identifiers; S2, dynamic permission anchoring: a permission anchoring engine constructs a cross-department permission credential chain based on the government data service chain generated in S1, verifies the dynamic data use credentials corresponding to the input data identifiers held by the current operator by traversing each node of the service chain, and embeds a permission traceability label including the operator's identity and the operation type in the output data identifier, to generate data with a permission traceability label; S3, data blood relationship packaging: a heterogeneous data packaging engine packages government data into a standard data container including a data ontology layer, a blood relationship metadata layer, and a service interface layer according to the data with a permission traceability label generated in S2; S4, self-optimization execution of service chain: a resource scheduler monitors resource occupancy in a service node running environment based on the standard data container generated in S3, and when the threshold is exceeded, stores low-priority containers to an edge computing cache pool, and outputs the service results after optimization execution.
[0023] S1 includes: S11, service request receiving: a service request parsing module receives a government data service request submitted by a user, denoted as: ; wherein, is a unique identity of the user, For the request service type (such as query, statistics, aggregation) For the request content description, including data range and processing requirements S12, service node parsing: the service request parsing module parses the government data service request , generates a logical topology structure of N ordered service nodes, defined as: ; Where, represents the total number of service nodes, represents the last service node, is the service node, is the output of the service node is the input of , forming a strict ordered topology structure S13, node parameter definition: the service request parsing module defines the following parameter set for each service node : ; Where, is the input data identifier set, is the corresponding data processing logic code (such as data cleaning, aggregation, matching, fusion), is the output data identifier set S14, service chain generation: the service request parsing module integrates N ordered service nodes and their corresponding parameter sets to build a government data service chain model: ; Where, represents the data dependency relationship, that is , realizing the chain transmission of service nodes, is the complete government data service chain structure, used to drive the subsequent permission verification and data execution process
[0024] S21, credential chain construction: the permission anchor engine constructs a cross-department permission credential chain based on the government data service chain generated by S1 , denoted as: ; Where: is the permission credential chain set, is the department issued permission credential, including access control information of the corresponding data resources is the total number of government departments involved S21 includes: S211, node-level data permission extraction: traversing the government data service chain , for each service node Extract its input data identifier set , constitute the whole chain input data set: ; This set represents the data resource list required for the whole service chain execution.
[0025] S212, data ownership department identification: based on the government data resource directory, map each data identifier to the management department it belongs to, generate a data ownership mapping table: ; Among them, is a single data identifier, is the government department to which the data belongs, is the complete set of government departments involved; S213, permission certificate request generation: generate data use certificate request items for each ownership department ; ; Among them, is the identity of the service request initiator, is the purpose of data use (obtained by parsing the original service request ); S214, cross-departmental credential collaborative acquisition: initiate a cross-departmental credential collaborative request to the permission authorization nodes of each ownership department, and each department responds to generate authorization credentials based on local or alliance chain policies : ; Among them, is the approved operation type, is the digital signature of the ownership department to ensure the validity and non-repudiation of the credential; S215, permission credential chain aggregation: aggregate all obtained credentials to build a complete cross-departmental permission credential chain.
[0026] S22, node credential verification: the permission anchor engine traverses each service node in the government data service chain , verifies whether the current operator holds the corresponding dynamic data use credential for each node's input data identifier set : ; Among them, is the th item in the input data identifier set, is the credential holder's identity (which should match the operator ), Data identifier for credential control (should be matched with ); S23, Provenance label generation: For the service nodes passed the verification, the authority anchoring engine embeds the authority provenance label in the output data identifier set ; , defined as: ; ; is the digital identity of the current operator (such as a blockchain address or a digital certificate fingerprint), is the operation type code (such as read, process, transfer, etc.) is the label generation timestamp; After embedding, the marked output set is formed: ; S24, Authority data output: The authority anchoring engine integrates all the output data identifier sets with provenance labels to obtain the final authority marked data set: ; ; , where is the set of government data with authority provenance labels, is the total number of service nodes in the government data service chain.
[0027] S31, Data ontology extraction: The heterogeneous data packaging engine extracts the data ontology layer from the data with authority provenance labels generated in S2; S32, Bloodline metadata construction: The heterogeneous data packaging engine parses each provenance label in the data with authority provenance labels to construct the bloodline metadata layer; S33, Service interface packaging: The heterogeneous data packaging engine constructs a set of data interfaces supporting standardized access protocols based on and : ; ; , where is the service call interface for accessing the data ontology and bloodline metadata, supporting RESTful, GraphQL, gRPC, and other protocol standards; S34, Container integration output: The data ontology layer, bloodline metadata layer, and service interface layer are bound according to a unified structure to generate a standard data container: ; ; , where is the standard data container, with the three attributes of unified structure, bloodline traceability, and interface standardization, which is the core packaging unit supporting the subsequent service chain self-optimization execution; S311, data structure parsing: the heterogeneous data packaging engine performs structural parsing on the data with permission traceability labels generated by S2, identifies the data ontology block and the permission traceability label block therein, and represents them as: ; Among them, is the striped permission traceability label data is the data ontology block, representing the original business data, is the permission traceability label block, containing operator identity, operation type, timestamp, hash digest, etc. S312, label stripping operation: the heterogeneous data packaging engine performs label stripping operation to remove from each piece of data, and only retains the original data ontology , constituting the data ontology set: ; S313, ontology integrity verification: the heterogeneous data packaging engine performs hash function calculation on each data ontology block to obtain the ontology hash value: ; Compare the hash value with the ontology hash value recorded in the traceability label block : ; If they are consistent, it is considered that the data ontology has not been tampered with, and the verification is passed. The is formally included in the data ontology layer output set, wherein, is a consistent hash function, such as SHA-256, is the ontology hash digest pre-stored in for integrity verification, is the hash value calculated after the current ontology is extracted Finally, all the data ontologies that pass the verification constitute: ; S32 includes: S321, label structure parsing: the heterogeneous data packaging engine performs structural parsing on each permission traceability label in the data with permission traceability labels, and extracts the following fields therefrom: ; Among them, is the operator identity (such as on-chain address or digital certificate), is the operation type code (such as read, write, process, etc.), is the operation timestamp, is the associated data identifier; This step establishes the initial mapping relationship between the permission label field and the lineage element.
[0028] S322, Identity Chain Reconstruction: Based on the node execution order of the government data service chain. The heterogeneous data encapsulation engine extracts the identity information of each service node operator and reconstructs an ordered operator identity chain: ; Among them: each Indicates service node The operator's identity, Indicates the last service node The operator's identity, This indicates the responsibility transfer path in the execution order of the service chain; S323, Operation Sequence Generation: Heterogeneous Data Encapsulation Engine Based on Parsed Operation Type Code (OPC) timestamp and data identifiers Construct a structured sequence of data operations: ; Each triple represents a record of an operation, and the operation sequence can be used for subsequent analysis of data usage paths, operator behavior chains, and permission tracing logic. S324, Lineage Metadata Encapsulation: The heterogeneous data encapsulation engine encapsulates the operator's identity chain. , operation sequence and permission change record collection Together, we integrate and build a structured lineage metadata layer: ; in: This is a collection of permission change records, documenting data authorization changes at each node, including modification time, change type, and responsible party. This structured lineage metadata layer will serve as an important component of the standard data container. S41, Container Loading: The resource scheduler loads the standard data container generated by S3 into the runtime environment of the service node corresponding to the government data service chain. ; in, For the first A standard data container for each service node For the corresponding service node The operating environment; S42, Resource Monitoring: The resource scheduler monitors the real-time resource usage of all service node runtime environments and records the current resource utilization of each container. ; in, is a standard data container in the service node resource occupancy rate; , edge migration decision: if the resource scheduler detects that the resource occupancy rate of a container exceeds the system set threshold , the container is marked as low priority and edge migration is performed: ; wherein, is the system preset resource occupancy threshold, is the edge computing cache pool for storing low-priority containers to be executed later container execution: for containers that do not exceed the threshold, the resource scheduler continues to execute in the original running environment: ; For low-priority containers that have been migrated to the edge cache pool, they are also executed asynchronously in the edge node: ; wherein, , are the execution results of the containers in the main environment and the edge environment, respectively; S45, result integration: the resource scheduler collects and integrates all container execution results output by the main running environment and the edge computing cache pool to generate the final optimized service result: ; wherein, is the comprehensive execution result set of the service chain under the optimized scheduling mechanism.
[0029] The present application encompasses any substitutions, modifications, equivalent methods and schemes made on the essence and scope of the present application. In order to make the public have a thorough understanding of the present application, specific details are described in the following preferred embodiments of the present application, and the present application can also be fully understood without the description of these details. In addition, in order to avoid unnecessary confusion to the essence of the present application, well-known methods, processes, procedures, elements and circuits, etc. are not described in detail.
[0030] The above is only the preferred embodiment of the present application, and it should be pointed out that for ordinary skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, and these improvements and refinements should be considered as the protection scope of the present application.
Claims
1. A government affair big data public service platform method, characterized in that, Comprising the following steps: S1, service chain definition: the service request parsing module receives the user-submitted government data service request, parses and generates a government data service chain comprising N ordered service nodes, wherein each service node defines a set of input data identifiers, data processing logic code and a set of output data identifiers; S2, dynamic permission anchoring: the permission anchoring engine constructs a cross-department permission credential chain based on the government data service chain generated in S1, verifies the dynamic data use credentials held by the current operator for the input data identifiers of each node in the service chain, and embeds a permission traceability label comprising the operator's identity and operation type in the output data identifier, generating data with a permission traceability label; S3, data bloodline encapsulation: the heterogeneous data encapsulation engine encapsulates the data with a permission traceability label generated in S2 into a standard data container comprising a data ontology layer, a bloodline metadata layer and a service interface layer; S4, self-optimization execution of service chain: the resource scheduler monitors resource occupancy in the service node running environment based on the standard data container generated in S3, and when the threshold is exceeded, stores low-priority containers to the edge computing cache pool, and outputs the optimized execution result. 2.The government affair big data public service platform method of claim 1, wherein, The S1 comprises: S11, service request receiving: the service request parsing module receives the user-submitted government data service request; S12, service node parsing: the service request parsing module parses the government data service request and generates a logical topology structure of N ordered service nodes; S13, node parameter definition: the service request parsing module defines a set of input data identifiers, data processing logic code and a set of output data identifiers for each service node; S14, service chain generation: the service request parsing module integrates the N ordered service nodes, their corresponding input data identifier sets, data processing logic codes and output data identifier sets, and generates a complete government data service chain. 3.The government affair big data public service platform method of claim 2, wherein, The S2 comprises: S21, credential chain construction: the permission anchoring engine constructs a cross-department permission credential chain based on the government data service chain generated in S1; S22, node credential verification: the permission anchoring engine traverses each service node in the government data service chain, and verifies the dynamic data use credentials held by the current operator for the input data identifier set of the current service node; S23, traceability label generation: the permission anchoring engine embeds a permission traceability label in the output data identifier of the current service node, wherein the permission traceability label comprises the identity information and operation type code of the current operator; S24, permission data output: the permission anchoring engine integrates all output data identifier sets embedded with permission traceability labels to generate data with permission traceability labels.
4. The government affair big data public service platform method of claim 3, characterized in that, The S21 comprises: S211, node-level data permission extraction: the permission anchoring engine traverses the government data service chain generated by the service request parsing module, extracts the input data identifier set of each service node in the service chain, and aggregates to form an input data resource list at the chain level; S212, data ownership identification: the authority anchoring engine performs ownership identification on each item in the extracted input data identifier set based on the government data resource catalog, determines the government department corresponding to each data identifier, and generates a one-to-one mapping relationship table between the data identifier and the ownership department; S213, authority credential request generation: the authority anchoring engine constructs an authority credential request for the data resources within each ownership department according to the mapping relationship table, including the identity information of the current service request initiator, the list of all data identifiers belonging to the department, and the data use purpose description; S214, cross-department credential collaborative acquisition: the authority anchoring engine distributes the authority credential request to the corresponding government departments, and requests to generate respective data use credentials by calling local or blockchain-based authorization mechanisms, each credential including authorized data identifiers, current operator identity, authorized operation type, and digital signature generated by the authorized department; S215, authority credential chain aggregation: the authority anchoring engine collects all authorized credentials returned by each department and aggregates them to form a cross-department authority credential chain.
5. The government affair big data public service platform method of claim 4, wherein, The S3 includes: S31, data ontology extraction: the heterogeneous data packaging engine extracts the data ontology layer from the data with the permission traceability label generated in S2; S32, blood relationship metadata construction: the heterogeneous data packaging engine parses the permission traceability label in the data with the permission traceability label, and generates a blood relationship metadata layer including an operator identity chain, a data operation sequence, and a permission change record; S33, service interface packaging: the heterogeneous data packaging engine generates a service interface layer supporting a standardized data access protocol based on the data ontology layer and the blood relationship metadata layer; S34, container integration output: the heterogeneous data packaging engine binds the data ontology layer, the blood relationship metadata layer, and the service interface layer hierarchically to generate a standard data container. 6.The government affair big data public service platform method of claim 5, wherein, The S31 includes: S311, data structure analysis: the heterogeneous data packaging engine analyzes the data with the permission traceability label generated in S2 to identify the data ontology block and the permission traceability label block; S312, label stripping operation: the heterogeneous data packaging engine strips the permission traceability label block from the data with the permission traceability label and retains the original data ontology block; S313, ontology integrity verification: the heterogeneous data packaging engine performs a hash check on the original data ontology block, and outputs the data ontology layer when the hash value is consistent with the ontology hash value in the permission traceability label block.
7. The government affair big data public service platform method of claim 6, wherein, The S32 includes: S321, label structure analysis: the heterogeneous data packaging engine analyzes the permission traceability label in the data with the permission traceability label to extract operator identity information, operation type code, and associated data identifiers; S322, identity chain reconstruction: the heterogeneous data packaging engine concatenates the operator identity information of each service node into an operator identity chain according to the execution order of the nodes in the government data service chain; S323, operation sequence generation: the heterogeneous data packaging engine generates a data operation sequence including read-write operation type, operation timestamp and target data identifier according to the mapping relationship between operation type code and data identifier; S324, bloodline metadata packaging: the heterogeneous data packaging engine integrates the operator identity chain, data operation sequence and permission change record to build a structured bloodline metadata layer. 8.The government affair big data public service platform method of claim 7, wherein, The S4 comprises: S41, container loading: the resource scheduler loads the standard data container generated in S3 to the service node running environment corresponding to the government data service chain; S42, resource monitoring: the resource scheduler monitors the resource occupancy rate of each standard data container in the service node running environment in real time; S43, edge storage decision: when the resource scheduler detects that the resource occupancy rate of any standard data container exceeds the preset threshold, the standard data container is marked as a low-priority container and stored to the edge computing cache pool. 9.The government affair big data public service platform method of claim 8, wherein, The S4 further comprises: S44, container execution: the resource scheduler executes the standard data container whose resource occupancy rate does not exceed the preset threshold in the service node running environment, and executes the stored low-priority container in the edge computing cache pool; S45, result integration: the resource scheduler collects the container execution results output by the service node running environment and the edge computing cache pool, and integrates to generate the service result after optimization execution.