Distributed query method, device and equipment for dense mode log data and storage medium

Abstract

The application discloses a method and device for distributed query of encrypted log data, equipment and a storage medium, the method comprising: performing semantic analysis when receiving a query request of a user, and matching an encrypted calculation type according to an analysis result; determining a plurality of query operations and a data dependency relationship therebetween according to the query request, and converting the encrypted calculation type into an encrypted calculation operation, thereby reducing the calculation and transmission overhead caused by decryption; determining the storage node positions of the encrypted calculation operation log data, and determining target calculation nodes according to the storage node positions and the data dependency relationship; respectively issuing task instructions generated based on the encrypted calculation operations to the target calculation nodes; and when receiving the task execution results returned by the target calculation nodes, aggregating the task execution results to obtain a current query result, thereby reducing network delay and improving parallelism under the premise of ensuring data availability and invisibility, and being conducive to improving query response efficiency.

Description

Technical Field

[0001] This application relates to the field of dense computing technology, and in particular to a method, apparatus, device and storage medium for distributed querying of dense log data. Background Technology

[0002] With the acceleration of digital transformation, the log data generated by information systems across industries is growing exponentially. This data has become a core asset supporting real-time monitoring, security auditing, and intelligent decision-making. At the same time, increasingly stringent data security regulations require strong protection for log data containing sensitive information. Therefore, how to ensure data confidentiality while meeting the business needs for rapid retrieval and in-depth analysis of massive logs has become a key technical challenge for the industry.

[0003] Traditional solutions involve statically encrypting log data and storing it centrally. Therefore, during query analysis, the system server must first retrieve all the statically encrypted data from the database and decrypt it to restore the plaintext log data before executing the requested query logic. This "complete decryption first, then computation and analysis" paradigm makes decryption an inherent bottleneck in the query process. Especially when processing large-scale logs or complex analysis tasks, the substantial decryption overhead and the data preparation process before plaintext computation introduce significant latency, severely limiting query response efficiency and making it difficult to meet the time-sensitive requirements of application scenarios such as operations and maintenance, and risk control. Summary of the Invention

[0004] The main objective of this application is to provide a distributed query method, apparatus, device, and storage medium for encrypted log data, aiming to solve the technical problem that the existing method of decryption before computation affects the query response efficiency when processing large-scale log data due to the large decryption overhead.

[0005] To achieve the above objectives, this application proposes a distributed query method for dense log data. The method is applied to query nodes in a distributed system, which also includes several storage nodes and several computing nodes. The method includes: Upon receiving a user's query request, the query request is semantically parsed, and the encrypted computation type is matched based on the parsing result. The encrypted computation type is a homomorphic encryption algorithm, a secure multi-party computation protocol, or a zero-knowledge proof scheme. Based on the query request, determine the corresponding query operations and the data dependencies between each query operation, and convert each query operation into a dense state calculation operation according to the dense state calculation type; Determine the location of the storage node for the log data corresponding to each of the dense-state computation operations, and determine the target computation node corresponding to each of the dense-state computation operations in each of the computation nodes based on the location of each storage node and the data dependencies. The task instructions generated based on each of the dense state computation operations are respectively sent to each of the target computing nodes, so that each of the target computing nodes responds to the task instructions and executes the corresponding dense state computation operation to obtain the task execution result; Upon receiving the task execution results returned by each of the target computing nodes, the current query result is obtained by aggregating the task execution results.

[0006] In one embodiment, the step of performing semantic parsing on the query request upon receiving a user's query request, and matching the encrypted computation type based on the parsing result, wherein the encrypted computation type is a homomorphic encryption algorithm, a secure multi-party computation protocol, or a zero-knowledge proof scheme, includes: Upon receiving a user's query request, an abstract syntax tree is generated based on the query request, and the abstract syntax tree is traversed to determine the semantic type of the current request; In the preset encrypted computing adaptation library, the corresponding encrypted computing type is obtained according to the current request semantic type. The preset encrypted computing adaptation library maintains the association relationship between different request semantic types and different encrypted computing types. The request semantic types include: aggregate query, conditional filtering, cross-organizational collaborative analysis, and compliance audit.

[0007] In one embodiment, the step of determining a plurality of corresponding query operations and the data dependencies between the query operations based on the query request, and converting each query operation into a dense computation operation according to the dense computation type, includes: The abstract syntax tree is optimized according to a preset optimization strategy; Based on the optimized abstract syntax tree, determine the several query operations corresponding to the query request and the data dependencies between the query operations. In the preset dense-state calculation adaptation library, each query operation is converted into a dense-state calculation operation according to the dense-state operation rules corresponding to the dense-state calculation type; The preset dense state calculation adaptation library also maintains dense state operation conversion rules corresponding to each of the dense state calculation types.

[0008] The step of determining the storage node location of the log data corresponding to each of the dense-state computation operations, and determining the target computation node corresponding to each of the dense-state computation operations in each of the computation nodes based on the storage node location and the data dependencies, includes: Based on the query request, determine the request-related log data, and based on the secret state calculation type and the request-related log data, determine the storage node location of the log data corresponding to each secret state calculation operation; Determine the location distance information between the storage node and each computing node based on the location of the storage node; Based on the location distance information and the data dependencies, the target computing node corresponding to each dense state computing operation is determined in each computing node.

[0009] In one embodiment, the step of determining the target computing node corresponding to each dense-state computation operation in each computing node based on the location distance information and each of the data dependencies includes: Based on the location distance information, candidate computing nodes are determined among the computing nodes; Based on the data dependencies, the dense state computation operations are grouped to obtain several parallel dense state computation task groups; The node resource status of each candidate computing node is obtained, and each parallel dense computing task group is assigned to each candidate computing node according to the node resource status and the location distance information, so as to determine the target computing node corresponding to each dense computing operation.

[0010] In one embodiment, the step of issuing task instructions generated based on each of the dense-state computation operations to each of the target computing nodes, so that each target computing node executes the corresponding dense-state computation operation in response to the task instructions and obtains the task execution result, includes: Based on the parallel dense state computation task group to which each of the aforementioned dense state computation operations belongs, corresponding task instructions are generated; Each of the task instructions is sent to the target computing nodes, so that when each target computing node receives the corresponding task instruction, it executes each of the dense computing operations in the parallel dense computing task group, obtains several local operation results, aggregates the local operation results, obtains the task execution results corresponding to each target computing node, and returns them to the query node.

[0011] In one embodiment, the step of aggregating the task execution results to obtain the current query result upon receiving the task execution results returned by each of the target computing nodes includes: Upon receiving the task execution results returned by each of the target computing nodes, the validity of each task execution result is verified. The verified task execution results are aggregated to obtain the current aggregated result; Perform post-processing operations on the current aggregation result to obtain the current query result and display it to the user; The post-processing operations include: decryption, format conversion, or privacy protection processing.

[0012] Furthermore, to achieve the above objectives, this application also proposes a distributed query device for encrypted log data, the device comprising: The query parsing module is used to perform semantic parsing on the query request when it receives a user's query request, and match the encrypted computation type according to the parsing result. The encrypted computation type is a homomorphic encryption algorithm, a secure multi-party computation protocol, or a zero-knowledge proof scheme. The dense computation adaptation module is used to determine a number of corresponding query operations and the data dependencies between each query operation according to the query request, and to convert each query operation into a dense computation operation according to the dense computation type. The task scheduling module is used to determine the storage node location of the log data corresponding to each of the dense state computation operations, and to determine the target computing node corresponding to each of the dense state computation operations in each computing node according to the storage node location and the data dependency relationship. The task scheduling module is further configured to send task instructions generated based on each of the dense state computation operations to each of the target computing nodes, so that each of the target computing nodes responds to the task instructions to execute the corresponding dense state computation operation and obtain the task execution result; The result processing module is used to aggregate the task execution results returned by each of the target computing nodes to obtain the current query result.

[0013] Furthermore, to achieve the above objectives, this application also proposes a distributed query device for encrypted log data. The device includes a memory, a processor, and a distributed query program for encrypted log data stored in the memory and executable on the processor. When the distributed query program for encrypted log data is executed by the processor, it implements the distributed query method for encrypted log data as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium storing a distributed query program for encrypted log data, which, when executed by a processor, implements the distributed query method for encrypted log data as described above.

[0015] This application discloses a distributed query method for encrypted log data, applied to query nodes in a distributed system. The distributed system also includes several storage nodes and several computing nodes. The method includes: upon receiving a user's query request, performing semantic parsing on the query request and matching the encrypted computation type based on the parsing result. The encrypted computation type is a homomorphic encryption algorithm, a secure multi-party computation protocol, or a zero-knowledge proof scheme. Based on the query request, determine several corresponding query operations and the data dependencies between each query operation, and convert each query operation into an encrypted computation operation according to the encrypted computation type. Determine the storage node location of the log data corresponding to each encrypted computation operation, and determine the target computing node corresponding to each encrypted computation operation in each computing node based on the storage node location and the data dependencies. Distribute task instructions generated based on each encrypted computation operation to each target computing node, so that each target computing node responds to the task instructions and executes the corresponding encrypted computation operation to obtain the task execution result. Upon receiving the task execution results returned by each target computing node, aggregate the task execution results to obtain the current query result.

[0016] Because this application can complete semantic parsing and encrypted computation type matching locally at the query node, it can directly generate encrypted operations corresponding to homomorphic encryption, secure multi-party computation, or zero-knowledge proofs without pre-decrypting log data. This avoids the step of pre-decrypting the entire encrypted data, reducing the computation and transmission overhead caused by decryption. Furthermore, by jointly determining the target computing node through dependencies and storage location, it can reduce network latency and increase parallelism while ensuring data availability without visibility, ultimately shortening the response time of the entire query request and improving query response efficiency. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the distributed query method for encrypted log data in this application; Figure 2 This application provides a content architecture diagram for the pre-defined dense-state computation adaptation library; Figure 3 This is a flowchart illustrating the second embodiment of the distributed query method for encrypted log data in this application; Figure 4 This is a flowchart illustrating the third embodiment of the distributed query method for encrypted log data in this application; Figure 5 This is a schematic diagram illustrating the entire process of the distributed query method for encrypted log data in this application. Figure 6 This is a schematic diagram of the module structure of the distributed query device for encrypted log data in this application; Figure 7 This is a schematic diagram of the distributed query device for encrypted log data in this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] This application provides a distributed query method for dense log data, referencing... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the distributed query method for encrypted log data in this application. In this embodiment, the method includes steps S10 to S50: Step S10: Upon receiving a user's query request, perform semantic parsing on the query request and match the encrypted computation type based on the parsing result. The encrypted computation type is a homomorphic encryption algorithm, a secure multi-party computation protocol, or a zero-knowledge proof scheme.

[0024] It should be noted that the executing entity in this embodiment can be a computing electronic device with data processing, network communication, program execution, and interactive control functions, such as a desktop computer, mainframe computer, or server. It can also be other node devices that implement task scheduling and interactive query functions in a distributed system. This embodiment and the following embodiments can be described using a distributed query device for encrypted log data as an example. This encrypted log data distributed query device can be considered as a query node in a distributed system.

[0025] A distributed system can consist of several node devices, which can be divided into query nodes, storage nodes, and compute nodes based on their functions. Query nodes are responsible for receiving requests, parsing and optimizing them, scheduling tasks, and aggregating results. Storage nodes persistently store multi-replica, layered encrypted log data (e.g., layer one uses homomorphic encryption, layer two uses a secure multi-party computation protocol, and layer three uses a zero-knowledge proof scheme). Computation nodes are devices in the distributed system responsible for receiving instructions from query nodes and executing specific encrypted computation operations.

[0026] It should be understood that a query request can be an SQL or SQL-like string entered or triggered by the user in the interactive interface of the query node. When the query node receives an SQL statement, it performs lexical and syntactic analysis on it to generate an Abstract Syntax Tree (AST). The AST reflects the syntactic composition of the query request, that is, it transforms the unstructured query language into a structured object that is easy for the computer to analyze and manipulate in a programmatic way.

[0027] Next, the query node can traverse each node in the AST (the node where the query operation is performed), and combine the metadata involved in each node (such as the encryption attributes of tables and columns, and the organization to which they belong) to classify the query request into a pre-defined applicable scenario, i.e., different pre-defined request semantic types, including: Aggregate queries: The AST contains aggregate functions or clause nodes such as COUNT, SUM, AVG, and GROUP BY. Suitable for scenarios involving statistical summarization of data.

[0028] Conditional filtering: The core of AST is the WHERE and HAVING clauses, which contain a large number of comparison operations (=, >, <, IN). The intention is to filter records from the dataset that meet certain conditions.

[0029] Cross-organizational collaborative analysis: The data sources involved in the FROM or JOIN clause of the AST belong to different data owners (organizations) based on metadata, or the query itself uses extended keywords such as SECUREJOIN. This is suitable for scenarios where data from multiple independent entities are combined for computation, and the parties do not wish to share the original data.

[0030] Compliance audit: Query requests use extended syntax such as GENERATE PROOF THAT or VERIFY PROOF, or their ultimate goal is to output a Boolean assertion (yes / no) rather than a specific dataset. Suitable for scenarios that verify whether a claim about data is true and generate verifiable evidence.

[0031] It should be noted that the SQL statement of a query request may contain multiple semantic elements (such as both aggregation elements and conditional filtering elements). In this case, the query node will determine the semantic type of the current request based on the dominant intent or the most complex privacy requirements.

[0032] Understandably, the pre-defined cryptographic computation adaptation library can be a configurable or rule-based knowledge base, which can maintain the preferred cryptographic computation types for different applicable scenarios (request semantic types), including: homomorphic encryption algorithms (HE), secure multi-party computation protocols (MPC), or zero-knowledge proof schemes (ZKP). See here for reference. Figure 2 The dense state calculation types maintained in the preset dense state calculation adaptation library are described. Figure 2 This is a content architecture diagram of the pre-defined dense state calculation adaptation library for this application.

[0033] Depend on Figure 2 It can be seen that, in Figure 2 The pre-defined encrypted computation adaptation library may include: a homomorphic encryption processing unit, a secure multi-party computation unit, and a zero-knowledge proof unit.

[0034] Homomorphic encryption algorithms support direct computational operations on encrypted data, enabling basic operations such as addition, multiplication, and comparison. Specifically, they can employ various homomorphic encryption algorithms, including floating-point arithmetic (e.g., CKKS algorithm), integer arithmetic (e.g., BGV algorithm), modular arithmetic (e.g., BFV algorithm), and Boolean circuit evaluation (e.g., TFHE algorithm), automatically selecting the most suitable algorithm based on the operation type and data characteristics.

[0035] Secure multi-party computation protocols enable multiple parties to perform joint computations without disclosing their individual data, making them suitable for cross-organizational collaborative analysis scenarios. Specifically, they can include protocols based on secret sharing, protocols based on obfuscated circuits, and protocols based on unintended transmission.

[0036] Zero-knowledge proof schemes can prove the truth of specific assertions without revealing the original data, making them suitable for compliance audits and threshold alert scenarios. Specifically, they can include: concise non-interactive zero-knowledge proof schemes (zk-SNARKs), concise transparent zero-knowledge proof schemes (zk-STARKs), and bulletproofs.

[0037] Also by Figure 2It can be seen that when the current request semantic type (current scenario) is aggregate query and conditional filtering, homomorphic encryption algorithm can be matched; when the current request semantic type (current scenario) is cross-organizational collaborative analysis, secure multi-party computation protocol can be matched; when the current request semantic type (current scenario) is compliance audit (or threshold alarm), zero-knowledge proof scheme can be matched.

[0038] Specifically, when a query node receives a user's query request, it can generate an abstract syntax tree based on the query request, traverse the abstract syntax tree, determine the semantic type of the current request, and then obtain the corresponding encrypted computation type from the preset encrypted computation adaptation library based on the semantic type of the current request.

[0039] Step S20: Determine the corresponding query operations and the data dependencies between the query operations according to the query request, and convert each query operation into a dense state calculation operation according to the dense state calculation type.

[0040] It should be noted that, in conjunction with the AST mentioned above, the query node can break down a complete SQL statement into more basic query operations, such as scanning, filtering, joining, and aggregation, and determine the data dependencies between these query operations.

[0041] Next, based on the previously determined dense-state computation type, the above query operation can be translated into a specific, executable dense-state computation operation.

[0042] It should also be noted that, since the aforementioned AST directly reflects the user's query logic, it may not be the most efficient or most suitable form for dense computation. Therefore, the AST can be optimized to generate an execution plan suitable for dense computation so that subsequent dense computation operations can be transformed. Step S20 specifically includes: Steps S201~S203: Step S201: Optimize the abstract syntax tree according to the preset optimization strategy.

[0043] It should be understood that the preset optimization strategies can include general database optimizations, such as predicate pushdown, projection pushdown, partition pruning, and join order optimization, as well as optimizations specific to dense computation, such as dense operation cost evaluation, computational complexity optimization, and ciphertext refresh point determination.

[0044] Predicate pushdown can be a strategy to execute filtering conditions such as WHERE clauses earlier, reducing the amount of data processed later. For example, the filter condition timestamp>'2024-01-01' can be executed when scanning the data table, instead of waiting until all data is loaded. In encrypted mode, this optimization is significant if the filtered field is plaintext; if it is encrypted, the cost of encrypted comparisons after pushdown should be carefully evaluated.

[0045] Projection pushdown allows you to select only the columns needed for the final query as early as possible, discarding unnecessary columns. Considering the significant growth of encrypted data, reducing the number of encrypted columns to be processed in advance through projection pushdown can greatly save network and computing resources.

[0046] Partition pruning allows you to skip irrelevant partitions if data is partitioned by a specific key (such as date) and the query conditions involve that key. Additionally, you can require the partition key to be plaintext or queryable.

[0047] Join order optimization can be used to select the join order that produces the fewest intermediate results for multi-table joins. Considering that the cost model can differ in dense mode, we can mainly evaluate the dense computation (such as secure comparison) and communication overhead caused by join operations, rather than traditional I / O and CPU time.

[0048] The cost evaluation of dense operations can help build models and assess the relative overhead of different dense operations (such as one homomorphic multiplication versus ten homomorphic additions), thereby guiding the optimizer to choose the lower-cost execution path.

[0049] Computational complexity optimization can be achieved by reorganizing computational expressions. For example, a*x + b*y (which requires two homomorphic multiplications and one addition) can be optimized into a scalar multiplication of x and y.

[0050] With the ciphertext refresh point determined, homomorphic encryption can be used. However, considering that ciphertext noise increases with multiplication and rotation operations, a bootstrap operation can be intelligently inserted to refresh the ciphertext, ensuring that noise does not exceed the limit before final decryption, while minimizing the number of refreshes.

[0051] Step S202: Determine several query operations corresponding to the query request and the data dependencies between the query operations based on the optimized abstract syntax tree.

[0052] It should be understood that when obtaining the optimized AST based on the aforementioned steps, it can then be broken down into some more basic query operations, such as: Scan_EncryptedTable_A (scanning encrypted table A), Filter_On_PlainTimestamp (filtering on the plaintext timestamp field), Homomorphic_GroupBy_EncryptedIP (performing homomorphic grouping on the encrypted IP field), Secure_Join_With_TableB (performing a secure join with table B), and ZeroKnowledge_GenerateProof (generating zero-knowledge proofs).

[0053] Analyzing the input-output relationships between the above query operations allows us to form a directed acyclic graph, or data dependency graph, which serves as the fundamental basis for subsequent distributed task scheduling. For example, if operation C (Secure_Join) requires the outputs of operations A (Scan_EncryptedTable_A) and B (Scan_EncryptedTable_B) as input, then A and B must be executed before C, and A and B can be executed in parallel.

[0054] Step S203: In the preset dense state calculation adaptation library, convert each query operation into a dense state calculation operation according to the dense state operation rules corresponding to the dense state calculation type.

[0055] It should be understood that the pre-defined encrypted computation adaptation library not only stores the mapping relationship between request semantic types and encrypted computation types, but also stores the conversion rules between query operations and specific encrypted computation operations under different encrypted computation types.

[0056] For example, if the encrypted computation type is a homomorphic encryption algorithm and the query operation is aggregation (COUNT), then COUNT can be converted into an initial ciphertext (encrypted 0), and then a homomorphic addition is performed on each record that meets the condition. If the encrypted computation type is secure multi-party computation and the query operation is a join operation, aggregation operation, or threshold comparison, then the query operation can be converted into a secure set intersection operation, a secure summation protocol, or a secure comparison protocol. If the encrypted computation type is zero-knowledge proof and the query operation is verification (WHEREcondition), then the entire WHEREcondition can be converted into an arithmetic circuit or constraint system as input for generating the zero-knowledge proof.

[0057] Specifically, the query node can traverse each query operation obtained in the previous step, and use the dense computation type (HE / MPC / ZKP) and the type of the operation (such as GroupBy, Join, Compare) as keys to query the preset dense computation adaptation library, and then perform the conversion based on the corresponding conversion rules, so that each query operation is converted into one or more specific, executable dense computation operations.

[0058] Step S30: Determine the location of the storage node for the log data corresponding to each of the dense-state computation operations, and determine the target computation node corresponding to each of the dense-state computation operations in each of the computation nodes according to the location of each storage node and the data dependency relationship.

[0059] It should be understood that the query node can determine which storage nodes the original encrypted data required to perform each encrypted computation operation is stored on based on the content identifier (CID) of the metadata involved in the query request, that is, determine the location of the storage nodes for each log data.

[0060] Next, based on the location of storage nodes and data dependencies, corresponding target computing nodes can be assigned to different dense computing operations in each computing order in the system.

[0061] Specifically, when allocating data, encrypted computation operations can be preferentially assigned to nodes that store the required data or nodes that are close to the storage node in the network, in order to reduce the overhead of encrypted data transmission. For encrypted computation operations with dependencies, they can be assigned to computing nodes that can communicate efficiently or directly assigned to the same target computing node.

[0062] Step S40: The task instructions generated based on each of the dense state computation operations are sent to each of the target computing nodes, so that each of the target computing nodes responds to the task instructions to execute the corresponding dense state computation operation and obtain the task execution result.

[0063] It should be understood that the query node can encapsulate corresponding task instructions based on the secret computation operation. These task instructions may include the secret computation operation to be performed, the CID or address of the input data, and relevant parameters. Then, each task instruction is sent to the corresponding assigned target computing node.

[0064] After receiving the instruction, each computing node can retrieve the associated encrypted log data from the specified storage node, perform the corresponding encrypted computation operation locally on the node, and then return the task execution result to the query node after completing the local computation.

[0065] Step S50: Upon receiving the task execution results returned by each of the target computing nodes, aggregate the task execution results to obtain the current query result.

[0066] In the specific implementation, when the query node receives the task execution results returned by each computing node, it can perform secure processing on these task execution results before returning them to authorized users, thereby ensuring that only authorized users can access the query results and further protecting the privacy of log data.

[0067] Security processing may include result decryption (if necessary), format conversion, and privacy protection processing (such as differential privacy).

[0068] This embodiment can complete semantic parsing and encrypted computation type matching locally at the query node. It can directly generate encrypted operations corresponding to homomorphic encryption, secure multi-party computation, or zero-knowledge proofs without pre-decrypting log data, thus avoiding the step of pre-decrypting the entire encrypted data and reducing the computational and transmission overhead of decryption. Furthermore, by jointly determining the target computing node through dependencies and storage location, it can reduce network latency and increase parallelism while ensuring data availability without visibility, ultimately shortening the response time of the entire query request and improving query response efficiency.

[0069] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the distributed query method for encrypted log data in this application.

[0070] In this embodiment, to specifically illustrate how the allocation of the target computing node is implemented, step S30 specifically includes: steps S301~S303: Step S301: Determine the request-related log data based on the query request, and determine the storage node location of the log data corresponding to each of the dense calculation operations based on the dense calculation type and the request-related log data.

[0071] It should be understood that the metadata involved in each query request can be determined, namely the requested associated log data, including the specific log data blocks or data fragments to be read.

[0072] Furthermore, considering that the metadata required for different types of cryptographic computation can be log data encrypted using different methods, the same metadata can be pre-stored as different datasets according to different types of cryptographic computation for subsequent cryptographic computation operations. These different datasets can include: homomorphically encrypted data, secure multi-party computation data, and zero-knowledge proof-related data. Their data storage formats and locations may differ, as may their location methods.

[0073] Homomorphic encrypted (HE) data can typically be stored centrally or distributed as complete homomorphic ciphertext. Querying nodes can use the data's content identifier (CID) or metadata index to query a distributed storage system (such as IPFS) to determine the physical or network location of the storage node storing these ciphertext blocks.

[0074] Secure multi-party computation (MPC) data can be secretly shared, divided into multiple shares, and distributed across the storage nodes of multiple participating parties. In this case, the storage node locations can be a set of locations containing all nodes holding the relevant data shares.

[0075] Zero-knowledge proof (ZKP) related data can be preprocessed results, commitments, or public parameters used to generate proofs, and they also need to be located to specific storage nodes through their identifiers.

[0076] In the specific implementation, the query node can first determine the metadata required for each dense state computation operation, and then locate the specific storage node of the corresponding dataset storage according to the dense state computation type.

[0077] Step S302: Determine the location distance information between the storage node and each computing node based on the location of the storage node.

[0078] It's important to note that both storage nodes and compute nodes operate within a distributed system. Therefore, query nodes can determine the location distance between each storage node and each compute node. This location distance can be used to measure data transfer costs. It can be a physical / network topology distance, such as network hop count or round-trip time (RTT); it can also be bandwidth and link costs, such as available bandwidth between nodes or whether it crosses expensive or restricted network domains; or it can be a logical / policy distance: whether they are within the same security domain, data center, or cloud service provider. Furthermore, in zero-knowledge proof-based encrypted computing schemes, this location distance can also include the trust distance or compliance boundary distance between participating nodes.

[0079] Step S303: Based on the location distance information and the data dependencies, determine the target computing node corresponding to each dense state computing operation in each computing node.

[0080] It should be understood that the process of assigning dense-state computation operations to target computation nodes can be constructed as a multi-objective optimization problem, and the optimization objective of this multi-objective optimization problem can be set based on location distance information and various data dependencies. Solving this multi-objective optimization problem can determine the target computation node corresponding to each dense-state computation operation.

[0081] Furthermore, to illustrate in detail how to schedule dense-state computation operations to different target computation nodes, step S303 specifically includes: steps S3031~S3033: Step S3031: Determine candidate computing nodes among the computing nodes based on the location distance information.

[0082] It should be noted that, firstly, based on the principle of proximity, candidate computing nodes can be obtained by filtering different dense-state computing operations in each computing node according to the location distance between the corresponding request-related log data and each computing node.

[0083] The proximity principle can be defined as follows: computation nodes whose location distance from the storage node of the log data corresponding to a certain dense computation operation is less than a preset threshold are selected as candidate computation nodes for that dense computation operation.

[0084] Step S3032: Group each of the dense state computation operations according to the data dependencies to obtain several parallel dense state computation task groups.

[0085] It should be understood that the query node can first analyze the aforementioned data dependency graph, and divide the dense computation operations that do not have direct dependencies in the graph into the same parallel dense computation task group (parallel group). This ensures that dense computation operations in the same parallel group can be executed simultaneously, which is beneficial for the simultaneous scheduling and execution of computations within the group. Data dependencies can be reflected in different parallel groups.

[0086] For example, if the dense state computation operation includes: Scan_A, Scan_B, Filter_A, Filter_B, Join_A_B, Aggregate; and the data dependencies between them are: Join_A_B depends on the results of Filter_A and Filter_B; Aggregate depends on the result of Join_A_B; Filter_A depends on Scan_A; Filter_B depends on Scan_B.

[0087] The parallel groups obtained based on data dependencies can include: Group 1 (parallel): Scan_A and Scan_B (no dependencies, can be parallelized); Group 2 (parallel): Filter_A and Filter_B (depend on different tasks in Group 1, but there is no dependency between them, can be parallelized); Group 3: Join_A_B (depends on all tasks in Group 2); and Group 4: Aggregate (depends on Group 3).

[0088] Therefore, based on the several parallel dense computation task groups obtained from the partitioning, we can determine the dense computation operations that can be scheduled and executed simultaneously, as well as the dense computation operations that need to be scheduled and executed sequentially.

[0089] Step S3033: Obtain the node resource status of each candidate computing node, and allocate each parallel dense computing task group to each candidate computing node according to the node resource status and the location distance information, so as to determine the target computing node corresponding to each dense computing operation.

[0090] It should be understood that the query node can obtain the node resource status of each of the above candidate computing nodes, including: node load information such as CPU / memory / GPU utilization, network I / O, and queue length of the candidate nodes, as well as node computing capability information such as whether it is equipped with specific hardware acceleration capabilities required for the encrypted computing type, such as homomorphic encryption accelerator cards or support for specific instruction sets.

[0091] Next, the query node can select a scheduling strategy that takes into account factors such as the node load information, node computing power information, and the aforementioned location distance information, and allocate different dense-state computing operations to different candidate computing nodes, thereby determining the target computing node corresponding to each dense-state computing operation.

[0092] It should be noted that the above scheduling strategy can be implemented based on intra-group task affinity scheduling rules, component dependency optimization rules, resource load balancing rules, and hardware capability matching rules to achieve the allocation process.

[0093] The task affinity scheduling rule within a group can be as follows: For multiple dense computation operations within a parallel group, the query node can assign them to a set of candidate computation nodes that are physically or network close. Simultaneously, it checks the candidate node sets for each task, looking for intersections or the closest node combinations. This helps to balance the completion time of this parallel phase.

[0094] The inter-group dependency optimization rule can be as follows: For two parallel groups with a dependency relationship (such as predecessor group A and successor group B), when the query node assigns tasks to successor group B, it can give priority to candidate computing nodes that are closer to the target computing node of the predecessor group, so as to minimize the network transmission overhead of intermediate data.

[0095] The resource load balancing rule can be: under the premise of satisfying the above intra-group task affinity scheduling rule and inter-group dependency optimization rule, the query node can evenly distribute dense computing operations to computing nodes with lower loads to avoid excessive resource consumption of a single computing node.

[0096] The hardware capability matching rule can be: for dense computing operations marked with special hardware requirements (such as "requires HE acceleration"), they should be selected from candidate computing nodes that have that capability.

[0097] In the specific implementation, the query node can ultimately determine the target computing node for each dense computation operation, thus forming a specific dense computation operation-node mapping table, ensuring efficient communication between dependent dense computation operations, and enabling independent dense computation operations to make full use of parallel resources.

[0098] This embodiment filters candidate computing nodes for each encrypted computation operation based on distance information from data storage locations, and divides the operations into parallelizable task groups according to data dependencies between tasks. Then, it performs comprehensive scheduling and allocation based on the real-time resource status of the candidate nodes. This effectively reduces the transmission distance and network overhead of encrypted data between nodes. Furthermore, through dependency-aware grouping and resource-aware allocation, it achieves a balanced distribution of computational load and collaborative execution between dependent tasks, significantly improving the overall execution efficiency of query requests and the utilization rate of node resources in the distributed system.

[0099] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the distributed query method for encrypted log data in this application.

[0100] In this embodiment, to specifically illustrate how each computing node performs different dense-state computation operations, step S40 specifically includes: steps S401~S402: Step S401: Generate corresponding task instructions based on the parallel dense state computation task groups to which each of the dense state computation operations belongs.

[0101] It should be noted that after the aforementioned scheduling decision is completed, the query node can generate one or more executable task instruction packages for each parallel dense-state computation task group. Each task instruction in the task instruction package may include: Operation definition: can be a specific description of all dense-state computation operations within this parallel group (such as parameters of homomorphic addition, steps of the MPC protocol, and inputs of the ZKP circuit).

[0102] Data references: can include the location information of the required input data (such as CID), which guides the compute nodes to retrieve encrypted log data from the specified storage nodes.

[0103] Dependencies and context: including the execution sequence number of the parallel group, the required predecessor group result identifier (if it exists), and the security context (such as session key, protocol parameters).

[0104] It should also be noted that the query node generates and issues task instructions in parallel groups, thereby reducing the number of instructions for network communication and facilitating local optimization scheduling and resource management of dense computing operations within the group by each computing node.

[0105] Step S402: Send each of the task instructions to each of the target computing nodes, so that when each of the target computing nodes receives the corresponding task instruction, it executes each of the dense computing operations in the parallel dense computing task group, obtains several local operation results, aggregates each of the local operation results, obtains the task execution result corresponding to each of the target computing nodes, and returns it to the query node.

[0106] It should be understood that the query node can send the encapsulated task instructions to the corresponding target computing node through the communication network in the distributed system.

[0107] When a target computing node receives a task instruction, it can parse the instruction and first retrieve the required encrypted data block from local storage or a specified storage node based on the data reference in the instruction. Then, according to the specific description of the encrypted computation operation defined in the instruction, it performs the encrypted computation operation locally, including: calling a homomorphic encryption library to perform ciphertext operations, participating in network interactions of the MPC protocol, or running a ZKP proof generator, etc. Considering that multiple related encrypted computation operations can be executed within a single target computing node, a local secure aggregation can be performed on the several local operation results (which may still be ciphertext or intermediate states) to obtain the task execution result corresponding to the target computing node. Finally, the target computing node can return the task execution result to the query node.

[0108] Understandably, since the result of this task is an intermediate result of local aggregation, rather than the original data or every operation record, it reduces communication volume while protecting more granular privacy.

[0109] Furthermore, to ensure the accuracy of the final query results, the query node needs to verify the results before aggregating the task execution results. Therefore, step S50 also includes: steps S501~S503: Step S501: Upon receiving the task execution results returned by each of the target computing nodes, verify the validity of each task execution result.

[0110] It should be noted that, to ensure the robustness and security of the system, the query node can verify the execution result of each received task before aggregation. This validity verification can include: integrity verification, used to check for data tampering during transmission (such as using Message Authentication Codes (MACs); correctness checks, such as verifying the validity of sub-proofs for zero-knowledge proofs; and verifying the legitimacy of shares for secure multi-party computation.

[0111] Step S502: Aggregate the verified task execution results to obtain the current aggregation result.

[0112] It should be understood that the query node can aggregate the verified task execution results based on a preset secure aggregation protocol to obtain the current aggregation result, and this aggregation process can also be performed in a secret state.

[0113] The secure aggregation protocol can be configured for different types of cryptographic computation: for homomorphic encryption results, the aggregation operation can be homomorphically adding multiple local encrypted counts; for zero-knowledge proof schemes, the aggregation operation can be securely reconstructing the final result according to the protocol; for secure multi-party computation protocols, the aggregation operation can be merging sub-proofs or verifying multiple independent proofs.

[0114] Step S503: Perform post-processing operations on the current aggregation result to obtain the current query result and display it to the user.

[0115] It should be noted that this post-processing operation may include result decryption (if necessary), format conversion, and privacy protection processing (such as differential privacy). Through post-processing, the current aggregation results within the system can be securely returned and displayed to the user who initiated the query.

[0116] In the specific implementation, if the current aggregation result is still encrypted (such as a homomorphically encrypted aggregation value) and the user has the right to view it, then the corresponding key is used for decryption. At the same time, in order to prevent the inference of individual information from the aggregation result, differential privacy techniques such as adding controllable noise can be applied to the decrypted current aggregation result. Finally, the current aggregation result with added noise can be converted into a user-friendly display format (such as JSON or chart data) and then displayed to the user on the interactive interface of the query node.

[0117] This embodiment generates instructions for encrypted computation operations into parallel task groups and distributes them to the target computing nodes for execution and local aggregation. Subsequently, the query node performs validity verification, secure aggregation, and configurable post-processing on the returned results. This achieves efficient parallel execution and load distribution of computation tasks, ensures the integrity and security of results during transmission and aggregation, and meets specific privacy disclosure requirements and display specifications when outputting the final query results through flexible post-processing. Thus, it improves the processing efficiency and reliability of query requests while ensuring data privacy throughout the entire process.

[0118] Furthermore, this can be referenced here. Figure 5 This paper describes the entire process of the distributed query method for encrypted log data in this application. Figure 5 This is a schematic diagram of the entire process of the distributed query method for encrypted log data in this application.

[0119] Depend on Figure 5 As can be seen, the entire process can be divided into steps 1 to 8.

[0120] Step 1: Receive query requests. The query node can receive SQL or SQL-like query requests submitted by users, and perform preliminary verification and permission checks; Step 2: Query Parsing. The query node can parse the aforementioned query request into an Abstract Syntax Tree (AST) for syntax verification and semantic analysis to determine the matching dense state computation type.

[0121] Step 3: Query Optimization. The query node can optimize the AST to obtain the optimized AST and determine the dense computation execution plan. The plan includes several query operations corresponding to the query request and the data dependencies between each query operation (task dependency graph).

[0122] Step 4: Encrypted computation adaptation. The query node can convert each query operation into a specific encrypted computation operation based on the previously matched encrypted computation type (homomorphic encryption algorithm, secure multi-party computation protocol, or zero-knowledge proof scheme).

[0123] Step 5: Distributed Task Generation. Based on the aforementioned data dependencies (task dependency graph), the query node can distribute the aforementioned dense computation operations to different target computing nodes in the system for execution.

[0124] Step 6: Task Scheduling and Execution. The query node can generate task instructions for each dense-state computation operation based on the allocation status and send them to the respective target computation nodes, such as... Figure 5 The nodes shown are 1, 2, and N.

[0125] Step 7: Result Aggregation. The query node can receive the task execution results returned from each target computing node, and aggregate the results to obtain the secure distributed computing results.

[0126] Step 8: Result Processing. To ensure that the results returned to the user satisfy the query requirements while protecting data privacy, the aforementioned secure distributed computing results can be subjected to security processing (decryption, format conversion, and privacy processing) to finally obtain the current query result.

[0127] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the distributed query method for encrypted log data in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0128] This application also provides a distributed query device for encrypted log data; please refer to [reference needed]. Figure 6 , Figure 6 This is a schematic diagram of the module structure of the distributed query device for encrypted log data in this application. The device includes: The query parsing module 601 is used to perform semantic parsing on the query request when it receives a user's query request, and match the encrypted computation type according to the parsing result. The encrypted computation type is a homomorphic encryption algorithm, a secure multi-party computation protocol, or a zero-knowledge proof scheme. The dense computation adaptation module 602 is used to determine a number of corresponding query operations and the data dependencies between each query operation according to the query request, and to convert each query operation into a dense computation operation according to the dense computation type. The task scheduling module 603 is used to determine the storage node location of the log data corresponding to each of the dense state computation operations, and to determine the target computing node corresponding to each of the dense state computation operations in each computing node according to the storage node location and the data dependency relationship. The task scheduling module 603 is further configured to send task instructions generated based on each of the dense state computation operations to each of the target computing nodes, so that each of the target computing nodes responds to the task instructions to execute the corresponding dense state computation operation and obtain the task execution result; The result processing module 604 is used to aggregate the task execution results returned by each of the target computing nodes to obtain the current query result.

[0129] This embodiment can complete semantic parsing and encrypted computation type matching locally at the query node. It can directly generate encrypted operations corresponding to homomorphic encryption, secure multi-party computation, or zero-knowledge proofs without pre-decrypting log data, thus avoiding the step of pre-decrypting the entire encrypted data and reducing the computational and transmission overhead of decryption. Furthermore, by jointly determining the target computing node through dependencies and storage location, it can reduce network latency and increase parallelism while ensuring data availability without visibility, ultimately shortening the response time of the entire query request and improving query response efficiency.

[0130] This application also provides a distributed query device for encrypted log data, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the distributed query method for encrypted log data in the first embodiment described above.

[0131] The following is for reference. Figure 7 , Figure 7This is a schematic diagram of the distributed query device for encrypted log data in this application. The distributed query device for encrypted log data in this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, personal digital assistants (PDAs), tablet computers (PADs), portable media players (PMPs), and fixed terminals such as digital TVs and desktop computers. Figure 7 The distributed query device for dense log data shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0132] like Figure 7 As shown, the distributed query device for encrypted log data may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the distributed query device for encrypted log data. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the distributed query device for encrypted log data to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a distributed query device for encrypted log data with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0133] The distributed query device for dense log data provided in this application, employing the distributed query method for dense log data in the above embodiments, can solve the technical problem of distributed query for dense log data. Compared with the prior art, the beneficial effects of the distributed query device for dense log data provided in this application are the same as those of the distributed query method for dense log data provided in the above embodiments, and other technical features in this distributed query device for dense log data are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0134] This application also provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the distributed query method for encrypted log data in the above embodiments.

[0135] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0136] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described distributed query method for encrypted log data, thereby solving the technical problems of the distributed query method for encrypted log data. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the distributed query method for encrypted log data provided in the above embodiments, and will not be repeated here.

[0137] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other elements in the process, method, article, or system that includes that element.

[0138] The above embodiment numbers are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. They are only some embodiments of this application and do not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A distributed query method for dense log data, characterized in that, The method is applied to a query node in a distributed system, which also includes several storage nodes and several computing nodes. The method includes: Upon receiving a user's query request, the query request is semantically parsed, and the encrypted computation type is matched based on the parsing result. The encrypted computation type is a homomorphic encryption algorithm, a secure multi-party computation protocol, or a zero-knowledge proof scheme. Based on the query request, determine the corresponding query operations and the data dependencies between each query operation, and convert each query operation into a dense state calculation operation according to the dense state calculation type; Determine the location of the storage node for the log data corresponding to each of the dense-state computation operations, and determine the target computation node corresponding to each of the dense-state computation operations in each of the computation nodes based on the location of each storage node and the data dependencies. The task instructions generated based on each of the dense state computation operations are respectively sent to each of the target computing nodes, so that each of the target computing nodes responds to the task instructions and executes the corresponding dense state computation operation to obtain the task execution result; Upon receiving the task execution results returned by each of the target computing nodes, the current query result is obtained by aggregating the task execution results.

2. The method as described in claim 1, characterized in that, The step of performing semantic parsing on the query request upon receiving a user's query request, and matching the encrypted computation type based on the parsing result, wherein the encrypted computation type is a homomorphic encryption algorithm, a secure multi-party computation protocol, or a zero-knowledge proof scheme, includes: Upon receiving a user's query request, an abstract syntax tree is generated based on the query request, and the abstract syntax tree is traversed to determine the semantic type of the current request; In the preset encrypted computing adaptation library, the corresponding encrypted computing type is obtained according to the current request semantic type. The preset encrypted computing adaptation library maintains the association relationship between different request semantic types and different encrypted computing types. The request semantic types include: aggregate query, conditional filtering, cross-organizational collaborative analysis, and compliance audit.

3. The method as described in claim 2, characterized in that, The step of determining the corresponding query operations and the data dependencies between the query operations based on the query request, and converting each query operation into a dense computation operation according to the dense computation type, includes: The abstract syntax tree is optimized according to a preset optimization strategy; Based on the optimized abstract syntax tree, determine the several query operations corresponding to the query request and the data dependencies between the query operations. In the preset dense-state calculation adaptation library, each query operation is converted into a dense-state calculation operation according to the dense-state operation rules corresponding to the dense-state calculation type; The preset dense state calculation adaptation library also maintains dense state operation conversion rules corresponding to each of the dense state calculation types.

4. The method as described in claim 1, characterized in that, The step of determining the storage node location of the log data corresponding to each of the dense-state computation operations, and determining the target computation node corresponding to each of the dense-state computation operations in each of the computation nodes based on the storage node location and the data dependencies, includes: Based on the query request, determine the request-related log data, and based on the dense state calculation type and the request-related log data, determine the storage node location of the log data corresponding to each dense state calculation operation; Determine the location distance information between the storage node and each computing node based on the location of the storage node; Based on the location distance information and the data dependencies, the target computing node corresponding to each dense state computing operation is determined in each computing node.

5. The method as described in claim 4, characterized in that, The step of determining the target computing node corresponding to each dense-state computing operation in each computing node based on the location distance information and the data dependencies includes: Based on the location distance information, candidate computing nodes are determined among the computing nodes; Based on the data dependencies, the dense state computation operations are grouped to obtain several parallel dense state computation task groups; The node resource status of each candidate computing node is obtained, and each parallel dense computing task group is assigned to each candidate computing node according to the node resource status and the location distance information, so as to determine the target computing node corresponding to each dense computing operation.

6. The method as described in claim 5, characterized in that, The step of sending task instructions generated based on each of the dense-state computation operations to each of the target computing nodes, so that each target computing node responds to the task instructions by executing the corresponding dense-state computation operation and obtaining the task execution result, includes: Based on the parallel dense state computation task group to which each of the aforementioned dense state computation operations belongs, corresponding task instructions are generated; Each task instruction is sent to each target computing node, so that when each target computing node receives the corresponding task instruction, it executes each dense computing operation in the parallel dense computing task group, obtains several local operation results, aggregates each local operation result, obtains the task execution result corresponding to each target computing node, and returns it to the query node.

7. The method as described in claim 1, characterized in that, The step of aggregating the task execution results to obtain the current query result upon receiving the task execution results returned by each of the target computing nodes includes: Upon receiving the task execution results returned by each of the target computing nodes, the validity of each task execution result is verified. The verified task execution results are aggregated to obtain the current aggregated result; Perform post-processing operations on the current aggregation result to obtain the current query result and display it to the user; The post-processing operations include: decryption, format conversion, or privacy protection processing.

8. A distributed query device for dense log data, characterized in that, The device includes: The query parsing module is used to perform semantic parsing on the query request when it receives a user's query request, and match the encrypted computation type according to the parsing result. The encrypted computation type is a homomorphic encryption algorithm, a secure multi-party computation protocol, or a zero-knowledge proof scheme. The dense computation adaptation module is used to determine a number of corresponding query operations and the data dependencies between each query operation according to the query request, and to convert each query operation into a dense computation operation according to the dense computation type. The task scheduling module is used to determine the storage node location of the log data corresponding to each of the dense state computation operations, and to determine the target computing node corresponding to each of the dense state computation operations in each computing node according to the storage node location and the data dependency relationship. The task scheduling module is further configured to send task instructions generated based on each of the dense state computation operations to each of the target computing nodes, so that each of the target computing nodes responds to the task instructions to execute the corresponding dense state computation operation and obtain the task execution result; The result processing module is used to aggregate the task execution results returned by each of the target computing nodes to obtain the current query result.

9. A distributed query device for dense log data, characterized in that, The device includes: a memory, a processor, and a secret log data distributed query program stored in the memory and executable on the processor, wherein the secret log data distributed query program, when executed by the processor, implements the secret log data distributed query method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a distributed query program for encrypted log data, which, when executed by a processor, implements the distributed query method for encrypted log data as described in any one of claims 1 to 7.

Images