Automatic adjustment of data flow execution graph

Abstract

At least some embodiments described herein relate to automatic adjustment of a dataflow execution graph. Such a dataflow execution graph is often used to perform some processing on a data message stream. Performance parameters of the dataflow execution graph are monitored and compared with service level objectives. Based on the comparison, it is automatically determined whether the configuration of the dataflow execution graph should be changed. If a decision is made to make a change, the configuration of the dataflow execution graph is changed. Therefore, the configuration of the dataflow execution graph is changed (or adjusted) depending on compliance with performance with service level objectives without the need for explicit instructions to change the configuration of the dataflow execution graph.

Description

Background Art

[0001] Large cloud and Internet service providers typically generate millions of events per second. To handle such a high throughput of events, events are often accumulated before being processed in batches. To reduce latency and ensure timely event processing, recent stream processing systems avoid batch processing by processing events as streams.

[0002] The volume of events streamed with each event stream may have a high degree of variability (referred to herein as "temporal variability"). For example, an event stream can include a mix of expected events (e.g., processing demand during the day may typically be higher than at night, etc.) and unexpected events (e.g., drastic stock market changes, etc.). In addition, due to the different workload characteristics across event streams (referred to herein as "spatial variability"), each event stream has different resource requirements. In addition, there are inevitable failures and hardware heterogeneity in large systems, which make it difficult to ensure stable performance in processing event streams. In order to deal with these variabilities and uncertainties, users of stream processing systems (usually system administrators) often provide safety factors for resources, leaving many resources idle or underutilized.

[0003] Many existing stream processing systems adopt a streaming data flow computing model. In this model, the computing work is represented as a directed acyclic graph (DAG) of operators, which is also called a "data flow execution graph". Although such operators may be stateless, such operators are mostly stateful, in which they maintain variable local states. Each operator sends and / or receives logical timestamp events along the directed edges of the DAG. After receiving events along (multiple) input edges, if appropriate, the operator updates its local state, possibly generates new events, and sends those new events to downstream operators along (multiple) output edges. Operators without input edges are called "source" operators, or simply "sources". Operators without output edges are called "sink" operators, or simply "receivers". Edges in the DAG have no state, but can have configurable properties. For example, the properties of the edge may be a queue size threshold that triggers back-pressure.

[0004] The subject matter claimed herein is not limited to embodiments that solve any disadvantages, or embodiments that operate only in environments such as those described above. Rather, this background is provided merely to illustrate an exemplary technology area in which some embodiments described herein may be practiced. Summary of the invention

[0005] At least some embodiments described herein relate to automatic adjustment of data flow execution graphs. Such data flow execution graphs are often used to perform some processing (such as in response to queries) on incoming data messages (either as a stream or in batches). According to the principles described herein, performance parameters of the data flow execution graph are monitored and compared with service level objectives. Based on the comparison, it is automatically determined whether the configuration of the data flow execution graph should be changed. If a change is determined, the configuration of the data flow execution graph is changed.

[0006] Thus, the principles herein depend on automatically changing the configuration of a dataflow execution graph in accordance with service level objectives, rather than requiring explicit instructions to change the configuration of the dataflow execution graph. Thus, the configuration can be changed without requiring simultaneous attention from both the user and the administrator while maintaining the expected performance standards. Thus, the configuration can be changed more frequently and accurately, thereby improving the performance of the dataflow execution graph as it encounters changing conditions (such as spatial and temporal variability) and without inconvenience to the user.

[0007] This Summary is provided to introduce a selection of concepts in a simplified form, which are further described in the Detailed Description below. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be drawn by reference to specific embodiments thereof illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0009] Figure 1 An example dataflow execution graph is illustrated in the form of a directed acyclic graph (DAG) having a plurality of operators and edges, and is provided as just one example of an infinite variety of dataflow execution graphs;

[0010] Figure 2 illustrates an environment in which the principles described herein may be employed, including a controller and a corresponding data flow execution graph;

[0011] Figure 3 illustrates a flow chart of a method for automatically adjusting the performance of a dataflow execution graph according to the principles described herein;

[0012] Figure 4 The diagram shows the Figure 3A controller set of methods and which includes a monitoring controller and a reconfiguration controller, and possibly other controllers;

[0013] Figure 5 illustrates an example raw data flow execution graph in an example reconfiguration described herein;

[0014] Figure 6 illustrates a flow chart of a method for reconstructing a dataflow execution graph for processing (multiple) dataflows according to the principles described herein;

[0015] Figure 7 The new data flow execution graph is shown, which represents Figure 5 a modified version of the original dataflow execution graph;

[0016] Fig. 8A The diagram shows a first example intermediate data flow execution graph used in the example, in which the original data flow execution graph is Figure 5 The original data flow execution graph is Figure 7 A new data flow execution graph;

[0017] Figure 8B illustrates a second example intermediate data flow execution graph that is similar to Fig. 8A The same as the figure;

[0018] Figure 8C illustrates a third example intermediate dataflow execution graph that is similar to Figure 8B is the same as the figure of

[0019] Fig. 9 An example computer system is illustrated in which the principles described herein may be employed. DETAILED DESCRIPTION

[0020] As a general introduction, at least some embodiments described herein relate to automatic adjustment of a dataflow execution graph. Such a dataflow execution graph is often used to perform some processing on incoming data messages either as a stream or in batches. As an example, such a dataflow execution graph can represent a standing query or a streaming query. According to the principles described herein, performance parameters of the dataflow execution graph are monitored and compared with service level objectives. Based on the comparison, it is automatically determined whether the configuration of the dataflow execution graph should be changed. If a change is determined, the configuration of the dataflow execution graph is changed. This monitoring and reconfiguration can be performed repeatedly and / or continuously to adjust the dataflow execution graph when the graph encounters a change, thereby achieving the service level objectives.

[0021] First, before describing the concept of performance tuning of dataflow execution graphs in more detail, we will refer to Figure 1 Describe the concept of a dataflow execution graph. In the dataflow computation model, computational work is represented as a directed acyclic graph (DAG) of operators. Such a graph is also called a dataflow execution graph. Figure 1 A very simple example of a data flow execution graph 100 is illustrated, which includes operators 101 to 104. Each operator may be an executable component, such as the one described below with reference to Fig. 9 Executable components 906 of computing system 900 are depicted.

[0022] Although dataflow execution graph operators can be stateless, such operators are often stateful in that they maintain mutable local states. Each operator sends and / or receives logically time-stamped data messages along the directed edges of the dataflow execution graph. In the example dataflow execution graph 100, there are four directed edges 111 to 114.

[0023] After receiving a data message along an input edge, the operator performs its function, updates its local state if appropriate, possibly generates new data messages, and sends those new data messages to downstream operators along (multiple) output edges. Operators without input edges are called "source" operators, or simply "sources". These source operators receive the original input data messages received by the dataflow execution graph (either as a data stream, or in batches). In the example dataflow execution graph 100, source operator 101 appropriately receives input data messages (represented by arrow 121), performs functions, generates (multiple) resulting data messages, and sends those resulting data messages along directed edges 111 and 112. Source operator 102 appropriately receives input data messages (represented by arrow 122), performs its functions, generates (multiple) resulting data messages, and sends those resulting data messages along directed edges 113 and 114.

[0024] Operators without output edges are called "receiver" operators, or simply "receivers". One or more of these receiver operators generate output results of the dataflow execution graph. In the example dataflow execution graph 100, receiver operator 103 receives data messages along directed edges 111 and 113, performs its function, and generates resulting output data (represented by arrow 123). Receiver operator 104 receives data messages along directed edges 112 and 114, performs its function, and generates resulting output data (represented by arrow 124).

[0025] Edges in a dataflow execution graph often have no state, but can have properties. For example, a property of an edge could be a queue backlog size threshold that triggers backpressure. Edges can also have useful state. For example, an edge might include state in the form of data being sent (i.e., data that is "in-flight" between operators). The state of an edge might also be checkpointed during checkpointing to avoid replaying in-flight data.

[0026] The dataflow execution graph may include any number of operators and any number of edges in any configuration. A dataflow execution graph may be as simple as a single operator without any edges. On the other hand, a dataflow execution graph may be extremely complex, including a vast number of operators and edges between them. Therefore, the example dataflow execution graph 100 is actually only a simple example dataflow execution graph of an infinite number of possible dataflow execution graphs. The dataflow execution graph may be operated on a single computing system, such as the following reference Fig. 9 The computing system 900 described may alternatively be distributed across multiple computing systems. As an example, the dataflow execution graph may operate in a cloud computing environment.

[0027] Now referenced Figure 1 An introduction to a dataflow execution graph is provided, and more details on how to use the principles described herein to adjust the dataflow execution graph will be described with reference to the subsequent figures. For example, Figure 2 Illustrated is an environment 200 in which the principles described herein may be employed.

[0028] Environment 200 includes controller 210 and data flow execution graph 220. Data messages 211 are supplied to data flow execution graph 220 (either as a stream or in batches). Data flow execution graph 220 performs computation work on input data messages 211 and generates output results 221. As an example, the computation work may be a streaming query or a standing query. Controller 210 may be an executable component, such as the following reference Fig. 9 Executable components 906 described. The dataflow execution graph 220 and the controller 210 can be on the same computing system, or on different computing systems. In one embodiment, the controller 210 is specifically assigned to the dataflow execution graph 220 and not to others. Therefore, the risk of controller 210 failure is limited to only a single dataflow execution graph.

[0029] Figure 3 FIG. 1 is a flowchart of a method 300 for automatically adjusting the performance of a data flow execution graph according to the principles described herein. The method 300 may be performed in Figure 2 Therefore, frequent reference will be made to Figure 2 The environment 200 is described Figure 3 Method 300.

[0030] Method 300 includes monitoring performance parameters of a data flow execution graph (act 301). For example, Figure 2 The controller 210 can monitor Figure 2 The performance of the dataflow execution graph 220. The dataflow execution graph can have any number of performance parameters. The monitoring action (action 301) can monitor a single one of the performance parameters, or can monitor multiple performance parameters. An example of a performance parameter is latency - or the amount of time taken for a data message provided to the dataflow execution graph, which will be reflected in the results generated by the dataflow execution graph. Another example of a performance parameter is the throughput of event processing by the dataflow execution graph. For example, throughput can be measured by the number of input data messages processed by the dataflow execution graph for a particular unit of time (i.e., the rate at which data messages are processed). The unit of time might perhaps be a rolling or sliding window, or it might be a flipping or jumping window.

[0031] In one embodiment, method 300 is performed by a single controller, such as Figure 2 However, in other embodiments, multiple controllers may be used to perform Figure 3 Method 300. In this sense, Figure 2 The controller 210 may be represented as a collection of multiple controllers. For example, the monitoring action 301 may be performed by a separate controller. Figure 4 The diagram can be used to execute Figure 3 The controller set 400 of the method 300 of the present invention is shown. The monitoring controller 401 can perform monitoring of one or more performance parameters of the dataflow execution graph. Although only one monitoring controller 401 is shown, there can be other monitoring controllers for monitoring other performance parameters. In one embodiment, the monitoring controller 401 is only assigned to the dataflow execution graph 220, so the risk of failure of the monitoring controller 401 is limited to only the dataflow execution graph 220.

[0032] Return to Figure 3 Method 300, method 300 includes comparing the monitored performance parameters with the service level objectives (action 302). Based on the comparison, method 300 automatically determines whether the configuration of the data flow execution graph should be changed (decision block 303). If, based on the comparison, the data flow execution graph should not be changed ("no" in decision block 303), the service level objectives are appropriately met by the data flow execution graph. Therefore, no changes are made to the configuration, and monitoring continues (action 301). When the comparison results in no changes being made to the configuration, the loop represented by action 301, action 302 and decision block 303 returning to action 301 can be executed continuously or repeatedly.

[0033] On the other hand, if a decision is determined that results in a configuration that should be changed ("yes" in decision block 303), then unless changes are made to the configuration, there is a chance that the service level objectives may not be met. In this case ("yes" in decision block 303), the configuration of the dataflow execution graph is changed (action 304), and the process returns to continue monitoring the performance parameter(s) (action 301). The loop represented by action 301, action 302, decision block 303, and action 304 back to action 301 may be executed continuously or repeatedly to continuously or repeatedly change the configuration of the dataflow execution graph. Thus, the dataflow execution graph is frequently changed (or adjusted) for good performance that falls within the service level objectives.

[0034] The configuration change (act 304) may also be performed by a separate controller. Figure 4 , reconfiguration controller 402 can be used to perform changes to the configuration of data flow execution diagram 220. Although only one reconfiguration controller is illustrated, there are other reconfiguration controllers that can be used to monitor other performance parameters. For example, some reconfiguration controllers can be customized to effectively perform certain types of reconfigurations. In one embodiment, reconfiguration controller 402 is assigned only to data flow execution diagram 220, so that the risk of failure of reconfiguration controller 402 is limited to only data flow execution diagram 220. In one embodiment, monitoring controller 401 and / or reconfiguration controller 402 also perform comparison (action 302) and / or determination (decision block 303). Ellipsis 403 indicates that there may be multiple monitoring or reconfiguration controllers, or other types of controllers in controller set 400.

[0035] Although the principles described herein are not limited to any particular type of change to the configuration of a dataflow execution graph, by way of example only, three different types of configuration changes will now be described. Configuration changes that will be discussed in further detail include: 1) changes to operational parameters of the dataflow execution graph itself, 2) changes to states or parameters of components (operators or edges) of the dataflow execution graph; and 3) changes to the structure of the dataflow execution graph. These example change types will now be described in this order.

[0036] The first type of configuration change described is a change to the operating parameters of the execution graph itself. As an example, in a case where a dataflow execution graph processes incoming data messages in batches, the operating parameters may include the size of the batch (in terms of the number of data messages). Batches provide a trade-off between throughput and latency. Batches have the benefit of reducing the operating cost of each message. However, batches do have an impact on the overall latency of processing input data messages. If the batch size is too small, the number of batches increases, and this may increase latency due to the time it takes to formulate the batches. On the other hand, if the batch size is large, although the number of batches is reduced, the number of data messages per batch increases. Therefore, there is a delay associated with waiting for data messages to arrive so that the batch can be created in the first place. Somewhere between these two extremes is the size of the batch where latency is minimized. In complex systems, identifying the size of this batch is not a simple task, and the ideal batch size will change over time.

[0037] For example, suppose the service level target is a throughput of 60 million data messages per second, with a latency upper bound of 500 milliseconds. Now, suppose that every 30 seconds the controller collects latency samples, updates the moving average of the processing latency, and performs a reconfiguration of the dataflow execution graph configuration if necessary.

[0038] Initially (at time equal to zero seconds), assume that a conservative batch size of 40,000 messages per batch is chosen while measuring latency and throughput. Now assume that the throughput rate at this batch size is monitored at 50 million data messages per second. This is less than the service level objective of 60 million data messages per second. Therefore, 60 million data messages per second will overwhelm the system triggering significant back pressure within the data flow execution graph. Because of this back pressure, latency will be higher, for example, about one second.

[0039] Then, starting at the 30-second mark, to address these deficiencies in the service level objectives, the controller doubles the batch size operating parameters to 80,000 messages per batch. Assume that this results in a more stable throughput of 60 million messages per second, and gives a stable latency of approximately 500 milliseconds. At the 60-second mark, assume that the controller attempts to double the batch size again to 160,000 messages per batch. However, the controller finds that this increases latency above the service level objectives with little improvement in throughput. Therefore, at the 90-second mark, the controller returns to a batch size of 80,000 messages per batch. Thus, the controller selects appropriate parameter values ​​for the data flow execution graph without requiring any information other than the service level objectives and the actual monitored performance of the data flow execution graph.

[0040] The second type of configuration change is a change in the state or parameter value of a component of the dataflow execution graph, such as an operator or an edge. For example, the queue size of an edge can be adjusted so that backpressure is applied less frequently by the edge. As another example, an operator can have its priority level changed so that the operator has more access to the processing loop.

[0041] The third type of configuration change is a change to the actual structure of the dataflow execution graph itself. This structural change may include adding or removing operators, or adding or removing edges, or a combination or multiple of the above.

[0042] Such a structural reconfiguration can be a difficult task. Conventionally, in order to perform such a reconstruction, the entire dataflow execution graph must block incoming data messages, while the state of the original dataflow execution graph is checkpointed, a new dataflow execution graph is instantiated, and the checkpointed state is mapped into the new dataflow execution graph. Only then are incoming data messages blocked. This is a significant blocking operation, which itself introduces significant latency. Therefore, this type of reconfiguration cannot be performed too frequently.

[0043] However, by using an intermediate dataflow execution graph, applying backpressure at the level of the entire dataflow execution graph can be avoided. Instead, backpressure can be applied only at the operator level, significantly reducing the impact of blocking, and significantly reducing the latency impact associated with reconstructing the dataflow execution graph. Therefore, reconstruction of the dataflow execution graph can be performed more frequently. Therefore, the use of an intermediate execution graph to reconstruct the dataflow execution graph will now be described.

[0044] In this new reconstruction mechanism, controller messages are supplied to the dataflow execution graph together with data messages. Specifically, control messages can be input to each source operator of the dataflow execution graph 220. The difference between control messages and data messages is that control messages are constructed to be executable by the dataflow execution graph 220 to actually change the configuration of the dataflow execution graph 220. On the other hand, data messages do not change the configuration of the dataflow execution graph 220, but are simply processed by the dataflow execution graph 220. As an example, a control message may also contain a small executable program that can be executed by each operator that encounters the control message. This executable program can be an unnamed / anonymous function that is executed as part of a new dataflow execution graph.

[0045] In the example, Figure 5 The data flow execution graph 500 will be used as the original or "old" data flow execution graph in the example configuration to be described below. It should be noted that Figure 5 The data flow execution diagram 500 is similar to Figure 1 An example data flow execution diagram 100, wherein Figure 5 Operators 501 to 504 of Figure 1 101 to 104 are the same. However, operators 503 and 504 are shown as diamonds to symbolize that these operators 503 and 504 have states, while operators 501 and 502 do not have states, as symbolized by circles. Figure 5 In the data flow execution graph 500, the relationship between edge 511 to edge 514 and operator 501 to operator 504 is the same as Figure 1 The relationship between edge 111 to edge 114 of data flow execution graph 100 is the same as the relationship between operator 101 to operator 104 .

[0046] Dataflow execution graph 500 will also be designated herein as the “example original dataflow execution graph” herein. Figure 6 A flow chart of a method 600 for modifying a data flow execution graph for processing a data flow is shown. Figure 2 The controller 210 in the environment 200 is executed, so reference will be made to Figure 2 The environment 200 is described Figure 6 Method 600. Moreover, since Figure 5 The example original data flow execution graph 500 will be used as the example data flow execution graph to be modified, and thus will also be frequently referenced. Figure 5 .

[0047] Method 600 determines a new data flow execution graph to which an old data flow execution graph is to be changed (act 601). As an example, assume that Figure 5 The example original data flow execution graph 500 is to be modified as Figure 7 700. It should be noted that adding stateful operator 705, and edge 715 and edge 716 to the original dataflow execution graph 500 forms the new dataflow execution graph 700. For example, if operator 501 and operator 502 are map operators, and operator 503 and operator 504 are reducer operators in a map-reduce model, then this modification may be performed, in which case it is decided to expand (i.e., increase) the number of reducer operators by one.

[0048] Figure 7 The operators 501', 502', 503' and 504' of the example new data flow execution graph 700 are respectively Figure 5 The operators 501, 502, 503, and 504 of the example raw data flow execution graph 500 are the same. Therefore, operators 501 and 501' are common, operators 502 and 502' are common, operators 503 and 503' are common, and operators 504 and 504' are common. However, in Figure 7The newly added primary suffix in indicates that an operator can have its functionality, parameter(s), and / or state changed as a result of the reconfiguration and still be considered a common operator between the original dataflow execution graph and the new dataflow execution graph. Similarly, Figure 7 The edges 511', 512', 513' and 514' of the example new data flow execution graph 700 are respectively Figure 5 The edges 511, 512, 513, and 514 of the original dataflow execution graph 500 are the same (or common). In addition, the newly added primary suffix indicates that the edge has its (multiple) parameters or states changed during the reconfiguration and is still considered a common edge between the original dataflow execution graph and the new dataflow execution graph.

[0049] The method 600 also includes generating an intermediate data flow execution graph based on both the original data flow execution graph to be modified and the new data flow execution graph to be the result of the modification (act 602). More information about the intermediate data flow execution graph will be referred to the example original data flow execution graph 500, the example new data flow execution graph 700, and the associated FIG. 8A to FIG. 8C Example intermediate data flow execution diagrams 800A, 800B, and 800C are described.

[0050] Now it can be said that the intermediate dataflow execution graph includes at least the common operators of both the original dataflow execution graph and the new dataflow execution graph, and includes the common edges of both the original dataflow execution graph and the new dataflow execution graph. For example, for the example original dataflow execution graph 500 and the example new dataflow execution graph 700, there are common operators 501 to 504 in both the example original dataflow execution graph 500 and the example new dataflow execution graph 700. In addition, there are common edges 511 to 514 in both the example original dataflow execution graph 500 and the example new dataflow execution graph 700.

[0051] Method 500 also includes generating one or more control messages that are not part of the data flow (act 603). These control messages are constructed so that when executed by operators within the intermediate data flow execution graph, the intermediate data flow execution graph will take the form of a new data flow execution graph. As an example, in Figure 2 In the environment 200, the controller 210 generates control messages. The control messages represent: the topology of the new dataflow execution graph, and possible new or modified functions performed by specific operators, new or modified parameters or parameter values ​​maintained by operators or edges, and how the state is distributed among multiple stateful operators.

[0052] The data stream(s) are then streamed to the intermediate data flow execution graph along with the control message(s) (action 604). It should be noted that such streaming of the data stream(s) is not delayed until the new data flow execution graph has been established. As an example, in Figure 2 In the environment 200 of FIG. 2 , data messages 211 and control messages are supplied to the dataflow execution graph 220, which is now the intermediate dataflow execution graph during the reconfiguration. Due to the way the control message(s) are constructed, as each operator completes the execution of the control message(s), the intermediate dataflow execution graph will take the form of a new dataflow execution graph.

[0053] Specifically, for each operator of the intermediate data flow execution graph that is not part of the new data flow execution graph, after the operator executes at least one (and preferably all) of the (multiple) control messages, the operator is closed so that after closing, the operator stops being able to continue processing data messages of the data flow. In this way, the operator receives a control message on one of its input edges, and the operator closes the input channel so that it does not receive data messages on this input edge. After all control messages are received on all input edges of the operator, the operator will no longer receive data messages. For each operator of the intermediate data flow execution graph that is not part of the original data flow execution graph, after the operator processes at least one (and preferably all) of the (multiple) control messages, the operator starts processing data messages of the data flow.

[0054] When the receiver operators within the intermediate dataflow execution graph complete execution of the control message, the operators each report completion to the controller 210. When the controller 210 confirms that all receiver operators in the dataflow execution graph have executed the control message (act 605), the controller 210 is able to know that the intermediate dataflow execution graph has now taken the form of a new dataflow execution graph, and the dataflow(s) are supplied to and processed by the new dataflow execution graph.

[0055] Fig. 8A An example intermediate data flow execution graph 800A is included, which is based on the example original data flow execution graph 500 and the example new data flow execution graph 700. Specifically, the intermediate data flow execution graph 800A includes all operators of both the original data flow execution graph 500 and the new data flow execution graph 700. That is, the intermediate data flow execution graph 800A includes operators 501 to 504, 501' to 504' and 705 for both stateless operators and stateful operators. The intermediate data flow execution graph 800A also includes the edges of both the original data flow execution graph 500 and the new data flow execution graph 700. That is, the intermediate data flow execution graph 800A includes edges 511 to 514, 511' to 514', 715 and 716. Such edges are represented by solid arrows.

[0056] The intermediate dataflow execution graph 800A also includes additional edges represented by dashed arrows. Such edges include edges that capture state dependencies between the stateful operator(s) of the original dataflow execution graph and the stateful operator(s) of the new dataflow execution graph. For example, assume that as part of a reconfiguration, some state will be transferred from operator 503 to new operator 705. Thus, there is a new edge 801 representing this dependency. Furthermore, assume that as part of a reconfiguration, some state will be transferred from operator 504 to new operator 705. Thus, there is a new edge 802 representing this state dependency.

[0057] The intermediate dataflow execution graph 800A also includes new edges between each common operator of the original dataflow execution graph 500 and the new dataflow execution graph 700. For example, there is a new edge 811 from operator 501 to operator 501', a new edge 812 from operator 502 to operator 502', a new edge 813 from operator 503 to operator 503', and a new edge 814 from operator 504 to operator 504'. Therefore, the intermediate dataflow execution graph 800A includes nine operators 501 to 504, 501' to 504', and 705; and sixteen edges 511 to 514, 511' to 514', 715, 716, 801, 802, and 811 to 814.

[0058] Eventually, once all operators have finished processing control messages, the intermediate dataflow execution graph 800A will collapse into the new dataflow execution graph 700. Recall that for each operator of the intermediate dataflow execution graph 800A that is not part of the new dataflow execution graph 700 (which includes all operators in the original operators 501, 502, 503, and 504), the operator will shut down after executing the control messages received on all of its input edges. Similarly, for each operator of the intermediate dataflow execution graph 800A that is not part of the original dataflow execution graph 500 (including all operators in operators 501', 502', 503', and 504'), the operator will begin processing data messages after executing the control messages received on each of its input edges.

[0059] The control message is first provided to operators 501 and 502, which respond by each stopping the data message on the input channel. After operator 501 processes the control message, the control message is passed to corresponding operators 503, 504 and 501' along directed edges 511, 512 and 811, and operator 501 will be closed thereafter, thereby also eliminating directed edges 511, 512 and 811. After operator 502 processes the control message, the control message is passed to corresponding operators 503, 504 and 502' along directed edges 513, 514 and 812, and operator 502 will be closed thereafter, thereby also eliminating directed edges 513, 514 and 812.

[0060] After operator 501' processes the control message, the control message is passed along directed edges 511', 715 and 512' to the corresponding operators 503', 705 and 504', and thereafter operator 501' begins processing the incoming data message. Similarly, after operator 502' processes the control message, the control message is passed along directed edges 513', 716 and 514' to the corresponding operators 503', 705 and 504', and thereafter operator 502' begins processing the incoming data message. At this point, shortly after the intermediate data flow execution graph stops accepting input data messages (when operators 501 and 502 receive control messages), the intermediate data flow execution graph again accepts input data messages.

[0061] As part of processing the control message, operator 503 will perform some transformations on its own state as directed by the control message, and will provide the transformed state to operator 705 along directed edge 801. After operator 503 processes the control message, the control message is passed along directed edges 813 and 801 to the corresponding operators 503' and 705, and thereafter operator 503 will shut down, thereby also eliminating directed edges 813 and 801. As part of processing the control message, operator 504 will perform some transformations on its own state as directed by the control message, and will provide the transformed state to operator 705 along directed edge 802. After operator 504 processes the control message, the control message is passed along directed edges 802 and 814 to the corresponding operators 705 and 504', and thereafter operator 504 will shut down, thereby also eliminating directed edges 802 and 814.

[0062] After operators 503', 705 and 504' each process the control message, the corresponding operator then begins processing the incoming data message and reports the completion of the processing of the control message to controller 210. At this point, the intermediate dataflow execution graph 800A has taken the form of the new dataflow execution graph 700, and the dataflow is being executed on the new dataflow execution graph 700.

[0063] While some amount of back pressure may result in this scenario, the amount of back pressure is much less than in a freeze-the-world scenario, where the original dataflow execution graph is completely stopped, the state of the original dataflow execution graph is checkpointed, a new dataflow execution graph is generated, the checkpointed state is passed to the appropriate operators in the new dataflow execution graph, and only then is the new dataflow execution graph started.

[0064] One optimization is based on the recognition that when a control message does not change the state of an operator (eg, as in this example, for operators 501, 501', 502 and 502', since they are stateless), the corresponding common operators can be collapsed into one operator, eliminating the corresponding links between them. Figure 8B illustrates an example intermediate data flow execution diagram 800B, which is similar to Fig. 8A Data flow execution graph 800A. Specifically, operators 501 and 501' are contracted to operator 501', and the corresponding edge 811 disappears. Moreover, operators 502 and 502' are contracted to operator 502', and the corresponding edge 812 disappears. Therefore, in the intermediate data flow execution graph 800B, there are now only seven operators 501', 502', 503, 504, 503', 504' and 705. In the intermediate data flow execution graph 800B, there are fourteen edges 511 to 514, 511' to 514', 715, 716, 801, 802, 813 and 814.

[0065] If the data flow execution graph is an acyclic graph, another optimization can be formed. In this case, common operators 503 and 503' can be contracted to operator 503' (eliminating edge 511, 513 and 813), and common operators 504 and 504' can be contracted to operator 504' (eliminating edge 512, 514 and 814), and the invariance of the acyclic graph can not be destroyed. In addition, such acyclic invariance can be maintained as a segmentation scheme by using a hash algorithm for expansion and contraction. This contraction makes only five operators 501' to 504' and 705 remaining in the intermediate data flow execution graph 800C. In the intermediate data flow execution graph 800C, there are also eight edges 511' to 514', 801, 802, and 715 and 716.

[0066] Thus, the principles described herein provide a mechanism for adjusting a dataflow execution graph to comply with service level objectives. Thus, rather than requiring explicit instructions to change the configuration of a dataflow execution graph, the principles herein depend on compliance with performance having a service level objective to automatically change the configuration of the dataflow execution graph. Thus, while maintaining expected performance standards, the configuration can be changed without requiring simultaneous attention from a user or administrator. Thus, as the dataflow execution graph encounters changing conditions, the configuration can be changed more frequently and accurately, thereby improving the performance of the dataflow execution graph and without inconvenience to the user.

[0067] Since the principles described herein operate in the context of a computing system, the computing system will be referred to as Fig. 9Described. Computing systems now take more and more forms. For example, a computing system may be a handheld device, an apparatus, a laptop computer, a desktop computer, a mainframe computer, a distributed computing system, a data center, or even a device that is not conventionally considered to be a computing system, such as a wearable device (e.g., glasses, watches, bracelets, etc.). In this description and in the claims, the term "computing system" is broadly defined to include any device or system (or combination thereof) having at least one physical and tangible processor and a physical and tangible memory, the memory being able to have computer executable instructions thereon, which can be executed by the processor. The memory may take any form and may depend on the nature and form of the computing system. The computing system may be distributed in a network environment and may include multiple constituent computing systems.

[0068] like Fig. 9 As shown, in its most basic configuration, computing system 900 generally includes at least one hardware processing unit 902 and memory 904. Memory 904 can be physical system memory, which can be volatile, non-volatile, or some combination of the two. The term "memory" can also be used herein to refer to non-volatile mass storage, such as physical storage media. If the computing system is distributed, then the processing, memory and / or storage capabilities can also be distributed.

[0069] The computing system 900 has a number of structures thereon that are often referred to as "executable components." For example, the memory 904 of the computing system 900 is illustrated as including an executable component 906. The term "executable component" is a name for a structure that is generally understood by those of ordinary skill in the computing arts to be a structure that can be software, hardware, or a combination thereof. For example, when implemented in software, those skilled in the art understand that the structure of the executable component can include a software object, a routine, a method that can be executed on the computing system, whether the executable component is present in the computing system's stack or whether the executable component is present on a computer-readable storage medium.

[0070] In this case, it will be understood by those skilled in the art that the structure of the executable component is present on a computer-readable medium so that when interpreted by one or more processors of the computing system (e.g., by a processor thread), the computing system is caused to perform a function. Such a structure can be directly computer-readable by the processor (as in the case where the executable component is binary). Alternatively, the structure can be constructed to be interpretable and / or compiled (whether in a single stage or in multiple stages) to generate such a binary that is directly interpretable by the processor. When the term "executable component" is used, such an understanding of the example structure of the executable component is fully within the understanding of those skilled in the art of computing.

[0071] The term "executable component" may also be well understood by those of ordinary skill to be included in a proprietary or nearly proprietary structure implemented in hardware, such as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other special circuit. Therefore, the term "executable component" is a term for a structure generally known to those of ordinary skill in the field of computing, whether implemented in software, hardware, or combination. In this description, the term "component" or "apex" may also be used. As used in this description and in this case, this term (whether the term is modified by one or more modifiers) is also intended to be synonymous with the term "executable component", or is a special type of such "executable component", and therefore also has a structure generally known to those of ordinary skill in the field of computing.

[0072] In the description that follows, embodiments will be described with reference to actions performed by one or more computing systems. If such actions are implemented in software, one or more processors (of the relevant computing system performing the actions) direct the operation of the computing system in response to the executed computer-executable instructions having constituent executable components. For example, such computer-executable instructions may be embodied on one or more computer-readable media forming a computer program product. Examples of such operations involve manipulation of data.

[0073] Computer-executable instructions (and manipulated data) may be stored in memory 904 of computing system 900. Computing system 900 may also contain communication channels 908 that allow computing system 900 to communicate with other computing systems over network 910, for example.

[0074] Although not all computing systems require a user interface, in some embodiments, the computing system 900 includes a user interface 912 for interacting with a user. The user interface 912 may include an output mechanism 912A and an input mechanism 912B. The principles described herein are not limited to the precise output mechanism 912A or input mechanism 912B, as this will depend on the nature of the device. However, the output mechanism 912A may include, for example, a speaker, a display, a tactile output, a hologram, virtual reality, etc. Examples of the input mechanism 912B may include, for example, a microphone, a touch screen, a hologram, virtual reality, a camera, a keyboard, a mouse for other pointing input, any type of sensor, etc.

[0075] The embodiments described herein may include or utilize a dedicated or general-purpose computing system including computer hardware, such as, for example, one or more processors and system memory, as discussed in more detail below. The embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computing system. The computer-readable medium that stores computer-executable instructions is a physical storage medium. The computer-readable medium that carries computer-executable instructions is a transmission medium. Therefore, by way of example, and not limitation, an embodiment may include at least two distinct types of computer-readable media: a storage medium and a transmission medium.

[0076] Computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or other physical and tangible storage media that can be used to store desired program code means in the form of computer-executable instructions or data structures, and which can be accessed by a general-purpose or special-purpose computing system.

[0077] A "network" is defined as one or more data links that enable electronic data to be transported between computing systems and / or components and / or other electronic devices. When information is transmitted or provided to a computing system over a network or another communication connection (either hardwired, wireless, or a combination of hardwired or wireless), the computing system appropriately treats the connection as a transmission medium. Transmission media can include networks and / or data links, which can be used to carry desired program code in the form of computer-executable instructions or data structures, and which can be accessed by general-purpose or special-purpose computing systems. Combinations of the above may also be included within the scope of computer-readable media.

[0078] In addition, upon reaching various computing system components, program code means in the form of computer executable instructions or data structures may be automatically transferred from the transmission medium to the storage medium (or vice versa). For example, computer executable instructions or data structures received over a network or data link may be buffered in RAM within a network interface component (e.g., a "NIC"), and then ultimately transferred to the computing system RAM and / or a less volatile storage medium at the computing system. Thus, it should be understood that readable media may be included in computing system components that also (or even primarily) utilize transmission media.

[0079] Computer executable instructions include, for example, instructions and data, which, when executed on a processor, cause a general-purpose computing system, a special-purpose computing system, or a special-purpose processing device to perform a certain function or group of functions. Alternatively or additionally, the computer executable instructions can configure a computing system to perform a certain function or group of functions. Computer executable instructions can be, for example, binary or even instructions that undergo some translation (such as compilation) before being directly executed by the processor, such as intermediate format instructions (such as assembly language, or even source code).

[0080] Those skilled in the art will appreciate that the invention can be practiced in a network computing environment with various types of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network personal computers, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, data centers, wearable devices (such as glasses or watches), etc. The invention can also be practiced in a distributed system environment, in which both local and remote computing systems that are linked (or by a hardwired data link, a wireless data link, or a combination of hardwired and wireless data links) through a network perform tasks. In a distributed system environment, program components can be located in both local and remote storage devices.

[0081] Those skilled in the art will also appreciate that the invention can be practiced in a cloud computing environment supported by one or more data centers or portions thereof. The cloud computing environment can be distributed, although this is not required. When distributed, the cloud computing environment can be distributed internationally within an organization and / or have components held across multiple organizations.

[0082] In this description and in the claims that follow, "cloud computing" is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of "cloud computing" is not limited to any of several other advantages that may be obtained from such a model when properly deployed.

[0083] For example, cloud computing is currently being adopted in the market to provide universal and convenient on-demand access to a shared pool of configurable computing resources. In addition, the shared pool of configurable computing resources can be quickly provisioned via virtualization, released with low management or service provider interaction, and then scaled accordingly.

[0084] The cloud computing model can consist of various characteristics, such as on-demand, self-service, broad network access, resource pooling, rapid elasticity, measured services, etc. The cloud computing model can also take the form of various application service models, such as, for example, software as a service ("SaaS"), platform as a service ("PaaS"), and infrastructure as a service ("IaaS"). The cloud computing model can also be deployed using different deployment models, such as private cloud, community cloud, public cloud, hybrid cloud, etc. In this description and in the claims, a "cloud computing environment" is an environment in which cloud computing is employed.

[0085] Thus, the principles described herein provide a mechanism for adjusting a dataflow execution graph to comply with service level objectives. Thus, the principles described herein automatically change the configuration of a dataflow execution graph depending on compliance with performance having service level objectives, rather than explicit instructions to change the configuration of the dataflow execution graph. Thus, while maintaining expected performance standards, the configuration can be changed without requiring simultaneous attention from a user or administrator. Thus, as the dataflow execution graph encounters changing conditions, the configuration can be changed more frequently and accurately, thereby improving the performance of the dataflow execution graph and without inconvenience to the user.

[0086] Without departing from the spirit or essential characteristics of the present invention, the present invention may be implemented in other specific forms. The described embodiments are considered to be illustrative and not restrictive in all respects. Therefore, the scope of the invention is indicated by the appended claims rather than by the preceding description. All changes falling within the equivalent meaning and scope of the claims will be included within their scope.

Claims

1. A computing system for automatically adjusting the performance of a data flow execution graph, comprising: one or more processors; as well as One or more computer-readable media having computer-executable instructions stored thereon, the computer-executable instructions being configured to, when executed by the one or more processors, cause the computing system to perform a method for automatically adjusting performance of a dataflow execution graph, the method comprising: Monitoring a performance parameter of the dataflow execution graph, the dataflow execution graph comprising a plurality of operators, each operator being configured to send or receive messages along one or more edges of the dataflow execution graph; comparing the monitored performance parameters with service level objectives; Based on the comparison, automatically determining whether a configuration of the dataflow execution graph should be changed; and If a decision is automatically determined that the configuration should be changed, the configuration of the dataflow execution graph is changed, and the changed configuration includes at least one of the following: the addition of an operator or edge in the dataflow execution graph, the removal of an operator or edge, the changed state of an operator or edge, or the changed parameter value of an operator or edge.

2. The computing system of claim 1 , wherein changing the configuration of the dataflow execution graph is performed using an intermediate dataflow execution graph that does not require the dataflow execution graph as a whole to be blocked during the changing of the configuration of the dataflow execution graph. 3 . The computing system of claim 1 , the configuration comprising operating parameters including a batch size of events that are supplied into the dataflow execution graph. 4 . The computing system of claim 1 , wherein the performance parameter monitored comprises a latency of processing an event by the dataflow execution graph.

5. The computing system of claim 4, the configuration comprising a batch size of events supplied to the dataflow execution graph, such that if the automatic determination results in a determination that the configuration should be changed, the batch size is altered.

6. The computing system of claim 1, wherein the performance parameter monitored comprises a rate at which events are processed by the dataflow execution graph.

7. The computing system of claim 1, the method being repeated such that the configuration is repeatedly altered.

8. The computing system of claim 1, the method being performed by a set of data flow controllers of one or more data flow controllers dedicated to the data flow execution graph.

9. The computing system of claim 8, the set of data flow controllers comprising a monitoring data flow controller that performs the monitoring of the performance parameter of the data flow execution graph.

10. The computing system of claim 9, the set of dataflow controllers comprising a reconfiguration dataflow controller that performs the change to the configuration of the dataflow execution graph if the automatic determination results in a determination that the configuration should be changed.

11. A method for automatically adjusting performance of a dataflow execution graph, the method comprising: Monitoring a performance parameter of the dataflow execution graph, the dataflow execution graph comprising a plurality of operators, each operator being configured to send or receive messages along one or more edges of the dataflow execution graph; comparing the monitored performance parameters with service level objectives; Based on the comparison, automatically determining whether a configuration of the dataflow execution graph should be changed; as well as If the automatic determination results in a determination that the configuration should be changed, the configuration of the dataflow execution graph is changed, and the changed configuration includes at least one of the following: the addition of an operator or edge in the dataflow execution graph, the removal of an operator or edge, the changed state of an operator or edge, or the changed parameter value of an operator or edge.

12. The method of claim 11, wherein changing the configuration of the dataflow execution graph is performed using an intermediate dataflow execution graph that does not require the dataflow execution graph as a whole to execute blocking during changing the configuration of the dataflow execution graph.

13. The method of claim 11, the configuration comprising operational parameters including a batch size of events supplied into the dataflow execution graph.

14. The method of claim 13, if the automatic determination results in a determination that the configuration should be changed, the batch size is altered.

15. The method of claim 11, wherein the monitored performance parameter comprises at least one of: a delay in processing an event by the data flow execution graph or a rate at which events are processed by the data flow execution graph.

16. A computer readable storage medium having computer executable instructions thereon, the computer executable instructions being configured to, when executed by one or more processors, cause a computing system to perform a method for automatically adjusting performance of a dataflow execution graph, the method comprising: Monitoring a performance parameter of the dataflow execution graph, the dataflow execution graph comprising a plurality of operators, each operator being configured to send or receive messages along one or more edges of the dataflow execution graph; comparing the monitored performance parameters with service level objectives; Based on the comparison, automatically determining whether a configuration of the dataflow execution graph should be changed; as well as If the automatic determination results in a determination that the configuration should be changed, the configuration of the dataflow execution graph is changed, and the changed configuration includes at least one of the following: the addition of an operator or edge in the dataflow execution graph, the removal of an operator or edge, the changed state of an operator or edge, or the changed parameter value of an operator or edge.

17. The computer-readable storage medium of claim 16, wherein changing the configuration of the dataflow execution graph is performed using an intermediate dataflow execution graph that does not require the dataflow execution graph as a whole to execute blocking during changing the configuration of the dataflow execution graph.

18. The computer-readable storage medium of claim 16, the configuration comprising operating parameters including a batch size of events that are supplied into the dataflow execution graph.

19. The computer-readable storage medium of claim 18, if the automatically determining results in the determination that the configuration should be changed, the batch size is altered.

20. The computer-readable storage medium of claim 16, wherein the performance parameter monitored comprises at least one of: a latency in processing an event by the data flow execution graph or a rate at which events are processed by the data flow execution graph.

Images