Lazy execution method for improving application efficiency in distributed environment

Abstract

The invention discloses a lazy execution method for improving application efficiency in a distributed environment. The invention provides a method for automatically optimizing network calling by a lazy execution method, which can effectively and automatically optimize a program into a program A which packages lazy execution codes and instructions and then transmits the codes and the instructions to the node B, and the node B executes once in batches and returns a batch result to the node A, so that the network calling efficiency of the node B is greatly improved. And the node A runs the program again to obtain a result. Compared with the prior art, the method has the advantages that network interaction is carried out for one time, and an automatic optimization process of a distributed program is realized.

Description

Technical Field

[0001] The present invention relates to a lazy execution program execution method for automatically improving the call efficiency of a program in a distributed environment in the distributed environment, belonging to the field of computer science. Background Art

[0002] In the current big data era, the programming design technology of the distributed architecture has been widely applied. In the data distribution in the distributed environment, there are usually two categories: horizontal sharding (also called horizontal partitioning) and vertical sharding (also called vertical partitioning). In the case of horizontal sharding, the distributed program usually uses the Mapreduce method to execute the data calculation method in each horizontal sharding node, and then merges the result sets to obtain the final result. The horizontal sharding method has some disadvantages: for example, when there are too many Worker nodes, there is a network bottleneck in the communication with the master node, etc. And the vertical sharding also has significant disadvantages: such as the inability to join business tables, and the problems of complex cross-sharding access and low efficiency. However, when the data volume further increases, it is necessary to combine horizontal sharding and vertical sharding and use them together, and then these problems must be faced and solved (or alleviated).

[0003] In the traditional single-node service architecture, the data of multiple different types of objects are usually mixed in a single node (for example, there are a data objects and b data objects, and each of the a data objects and b data objects has its corresponding fields, represented in the form of a.field and b.field). After the application developer loads the data into the storage system (or database storage system or memory, etc.), it is relatively simple to develop an application algorithm program that simultaneously accesses the a and b data objects, such as Figure 1 As shown, its code is also relatively simple, as shown in the following pseudo-code (Demo1):

[0004] vara[] = geta();

[0005] (obtained a set of a data objects)

[0006] for (loop over a[]){

[0007] Loop for each element in the a[] set

[0008] b = getb(a[i].prop1);

[0009] Obtained the corresponding b data object according to the prop1 attribute value of the i-th a object in the a data object set

[0010] result = result + a[i].value1 + b.value1;

[0011] The result value is equal to the cumulative value of the sum of a[i].value1 + b.value1

[0012] }

[0013] The above code realizes querying the b object according to the prop1 attribute of the a data object, and then accumulating the value1 values of the a object and the value1 values of the b object.

[0014] However, in a distributed environment, the situation is not so simple. Now, assume that in a vertically sharded distributed environment, node A has the a data object, node B has the b data object, and each of the a data object and the b data object has its corresponding fields, represented in the form of a.field and b.field, that is, the a data object and the b data object are not on the same vertically sharded node. If the program of Demo1 is run on node A, the getb method needs to be changed to the remote call (RPC) mode, assumed to be: getb_remote, then the program can run. However, when the loop of a[] is very large, the call will cause serious network congestion. Assume that the size of the a[] set is one hundred million, then getb_remote will be remotely called one hundred million times.

[0015] When the above situation occurs, the usual method is to modify the program again, and try to change the getb_remote method to the batch call mode as much as possible, or use a specific map reduce method to first complete the counting of b.value1 in the b node, and then merge its results to the a node and accumulate them to the result to complete the calculation. However, in some cases, the cost of modifying each program is very high, and it is necessary to re-verify and test, resulting in a relatively high cost, or because the program is dynamically generated (such as generated by a large language model), there is little possibility of modification. Summary of the Invention

[0016] The object of the present invention is to provide a distributed lazy execution method that can automatically optimize the program and execute only by developers writing conventional cross-node access code in the case of vertical sharding, thereby optimizing the network performance of cross-node calls.

[0017] In order to achieve the above object, the technical solution of the present invention discloses a lazy execution method for improving the call efficiency in a distributed environment, which is characterized by including the following steps:

[0018] Step 1: Compile the code and then execute it;

[0019] Step 2: During the running period, according to the node sharding information, execute the code related to the data object that can be processed by the current node sharding;

[0020] For the code related to data object that is not in the current node shard and cannot be processed temporarily, let the code return an UNBOUND value, and record the statement where the execution fails and the relevant parameter information;

[0021] Step 3: After executing all the programs, collect the access information of all data that has not obtained instance objects in the program;

[0022] Step 4: Judge the program running result. If there is an UNBOUND value among them, then after packing the statement where the execution fails and the relevant parameter information, send it to the corresponding node shard for execution. Otherwise, the program flow ends;

[0023] Step 5: Pack the statements that cannot be executed, the relevant parameter information, and the information of the accessed object fields, and send them to the next node shard;

[0024] Step 6: Expand the lazy execution code in the new node shard for execution, and cache all the calculation results;

[0025] Step 7: Pack the cached calculation results and the information of the accessed object fields and send them back to the original node shard;

[0026] Step 8: In the original node shard, after receiving the sent-back data, execute the program again, and return to Step 4.

[0027] Preferably, in Step 1, AOT compilation is performed on the code.

[0028] Preferably, the distributed environment is a vertical distributed environment, and different object data is in different shards.

[0029] The present invention proposes a method for automatically optimizing its network calls by means of lazy execution, which can effectively optimize the original hundreds of millions of calls from Node A to Node B by the program automatically optimizing the lazy execution code and instructions of Program A and passing them to Node B. Node B executes them in batches once and returns the batch results to Node A. Node A runs the program again to obtain the results. Compared with the existing technical solutions, the network interaction of the present invention has only one round trip in total, realizing the automatic optimization process of a distributed program. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 Schematically shows that data objects a and b are both in Node A;

[0031] Figure 2 Schematically shows that data objects a and b are respectively on Nodes A and B;

[0032] Figure 3 is a flowchart of the present invention. DETAILED DESCRIPTION

[0033] The present invention will be further described below in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and not to limit the scope of the present invention. In addition, it should be understood that after reading the content taught by the present invention, those skilled in the art can make various changes or modifications to the present invention, and these equivalent forms also fall within the scope defined by the appended claims of this application.

[0034] Suppose in a vertical distributed environment, different object data are in different shards. Taking Demo1 as an example, in a vertically segmented distributed environment, node A has the data of object a, and node B has the data of object b. The data of object a and object b each have their corresponding fields, represented in the form of a.field and b.field, as Figure 2 shown.

[0035] Still taking the following pseudocode as an example:

[0036] vara[] = geta();

[0037] for (loop on a[]) {

[0038] b = getb(a[i].prop1);

[0039] result = result + a[i].value1 + b.value1;

[0040] }

[0041] Step 1: A new distributed programming language is implemented. The main purpose of implementing this programming language is to control the optimization steps during the Ahead-of-Time (AOT) compilation of the programming language. Making efforts on the optimization steps, as for the programming language itself, it has no direct relation to the present invention and will not be elaborated at length.

[0042] Step 2: The new programming language first performs AOT compilation on the above code and then executes it. During the running period, it can execute the code related to the data objects that the current node can process according to the node shard information. For the cases that cannot be processed temporarily (the data is not in this shard), let the relevant code return an UNBOUND value and record the relevant statement and parameter information.

[0043] In this example: The program can, according to the information that "node A has the data object a and node B has the data object b" and the information of the current node (here it is assumed to execute on node A), retain the parameter information of the getb function when executing the getb function and let getb return a special UNBOUND value.

[0044] vara[] = geta();

[0045] for (loop over a[]){

[0046] / * When the A node executes, since there is no data of b in the A node, a valid b data object cannot be returned. Therefore, the value of b is set to UNBOUND. At the same time, the set of values of the parameters of each getb function (i.e., a[i].prop1) is saved. * /

[0047] b = getb(a[i].prop1);

[0048] result = result + a[i].value1 + b.value1;

[0049] }

[0050] During the execution of this step, since there is no b object data on the A node, the value of b is returned as UNBOUND.

[0051] After the execution of this step, a set of parameters of the getb function (i.e., the set of values of a[i].prop1) can be obtained. Here, this set is named a'[]. Also, the statement "getb(a[i].prop1)" that failed to execute correctly is saved.

[0052] Step 3: After executing the entire program, collect the access information of all data of the objects that have not yet obtained instances (UNBOUND) in the program. In this example, according to the rule that "the calculation result of the value of UNBOUND and any value is also UNBOUND", it is obtained that b.value1 is also UNBOUND, and further the result of result = result + a[i].value1 + UNBOUND is also UNBOUND. According to this step, we also obtain an information: that is, the b.value1 field will be accessed (to simplify the Demo, here it is assumed that only b.value1 has been accessed in the getb function).

[0053] Step 4: Judge the program running result. If there is a UNBOUND value, then pack the statement that fails to execute and the related variables and send them to the corresponding node for execution; otherwise, if a normal result value is obtained, the program flow ends.

[0054] Step 5: Package the statements that failed to execute, the parameters involved in the statements, and the information about the accessed object fields, and send them to the next execution node. In the above case, the value UNBOUND appears in the program, and the statement that appears is getb(a[i].prop1). At this time, based on the static analysis of the implementation inside the getb statement, the programming language obtains that there must be a query for data b inside the getb statement, and data b belongs to Node B. Then, the following three items are sent to Node B for execution: 1) The statement getb(a[i].prop1) (including the executable bytecode of getb in memory); 2) The information that the.value1 field of the b object will be accessed; 3) The parameter information packaged by a’[]; The present invention calls this execution step the “lazy execution” of the code.

[0055] Step 6: Expand the lazy execution code on the new computing node, execute it, and cache all the calculation results. In this example, the same distributed program instance is deployed on Node B. After receiving the statement information sent in Step 5, the pseudo-code in memory is as follows:

[0056] a’[] = {actual parameter 1, actual parameter 2, actual parameter 3...}

[0057] for (loop over a’[]){

[0058] b[i] = getb(a’[i]);

[0059] }

[0060] It can be seen that this step actually executes the program that could not be executed in the second step again on Node B. In the above code, a’[] is all the parameters of getb packaged before, and b[i] is the set of all b data objects that getb may return.

[0061] Step 7: Package the cached calculation results, combine them with the information about the accessed object fields, and send these data back to the original node in a packaged form. In this example, according to the previous information, only the b.value1 field in the b data object will be accessed. After the program on Node B finishes execution, a set of b objects and b.value1[] will be obtained, and these data are packaged and sent back to Node A.

[0062] Step 8: In the original node, after receiving the data sent back by the calling node, execute the program again:

[0063] vara[] = geta();

[0064] for (loop over a[]){

[0065] b = getb(a[i].prop1);

[0066] result = result + a[i].value1 + b.value1;

[0067] }

[0068] In this example, when the A node is re-executed, according to the information sent back by the B node within the program, a function-level hash cache is made for getb(a[i].prop1). That is, when calling getb, the content of the getb function will not actually be executed. Instead, based on its parameters, the b object in the cache is directly returned. The reason is that the statement getb(a[i].prop1) has been batch-executed at the B node and does not need to be executed again.

[0069] And when the A node program is executed again this time, the statement getb(a[i].prop1) can obtain a correct b object from the cache, no longer the previous UNBOUND object, and the value of value1 of this b object can also be accessed normally. Therefore, the statement result = result + a[i].value1 + b.value1; will also be correctly executed and a correct result will be obtained.

[0070] Step 9: If another UNBOUND object is still obtained during the subsequent process of the program, this program will automatically execute according to Step 4, pack the variables and then pass them to the vertical shard node where the next data is located.

Claims

1. A lazy execution method for improving the call efficiency in a distributed environment, characterized in that, It includes the following steps: Step 1: Compile the code and then execute it; Step 2: During the running period, according to the node sharding information, execute the code related to the data objects that can be processed by the current node shard; For the code related to the data objects that are not in the current node shard and cannot be processed temporarily, let the code return an UNBOUND value, and record the statements and relevant parameter information of the execution failure; Step 3: After executing the entire program, collect the access information of all data that has not obtained instance objects in the program; Step 4: Judge the running result of the program. If there is an UNBOUND value among them, then pack the statements and relevant parameter information of the execution failure and send them to the corresponding node shard for execution. Otherwise, the program flow ends; Step 5: Pack the statements that cannot be executed, relevant parameter information, and the information of the accessed object fields, and send them to the next node shard; Step 6: Expand the lazy execution code in the new node shard for execution, and cache all calculation results; Step 7: Pack the cached calculation results and the information of the access to the data object fields and send them back to the original node shard; Step 8: In the original node shard, after receiving the sent-back data, execute the program again and return to Step 4; 2. The lazy execution method for improving the call efficiency in a distributed environment according to claim 1, wherein, In Step 1, perform AOT compilation on the code; 3. The lazy execution method for improving the call efficiency in a distributed environment according to claim 1, characterized in that, The distributed environment is a vertical distributed environment, and different object data is in different shards.

Images