3.5 NexusDS Components Architecture
3.5.4 Operator Execution Service
After the distribution of the NEGM SP graph fragments to the respective Operator Execution Service (OES), each Operator Execution Service instance instantiates the operators contained in the NEGM SP graph fragment and starts execution. The architecture of the Operator Execution Service is shown in Figure 3.8. Its main components are the Operator Execution Environment (OEE), providing an environment for operator execution and its supporting units Statistics Col-lector Client (SCC) to collect runtime statistics, Operator Scheduler (OpS) to do a re-scheduling of locally running operators, Operator Repository Client (ORC) handling locally missing oper-ators, and finally Execution Manager Client (EMC) to receive the NEGM SP graph fragment and signal overload situations. The basic working method of the Operator Execution Service consists of four phases: Aninitialization phase, anexecution phase, a lightweight adaptation phase, a heavyweight adaptationphase, and a termination phase. In the following, the single phases of the Operator Execution Service are described in more detail.
Initialization: The EMC receives an NEGM SP graph fragment 1m, which defines how this Operator Execution Service instance is going to process data. Thefirst step consists of storing the NEGM SP graph fragment and its associated NPGM ID into a localNEGM Fragmentcache to keep track of all fragments currently being executed on this Operator Execution Service instance. Then, the Operator Execution Service must check whether all operators needed to execute the NEGM SP graph fragment are locally available. The localoperator cache must be checked by querying the ORC 2m. If the operator is locally missing, the Operator Repository Client contacts the Operator Repository Service (ORS) asking for the executable code of the missing operator. If the operator is known and the computing node the OES instance is being executed on is allowed to access the executable code, the operator package is downloaded by the ORC and stored in the local operator cache for later reuse. Once all operators are locally available, an instance of all relevant operators is created. The operator instances are
Figure 3.8:Architecture of the Operator Execution Service (OES)
parametrized and interconnected according to the NEGM SP graph fragment definition, and finally executed within the Operator Execution Environment 3m.
Execution: The Operator Execution Service at this point waits for incoming data to be pro-cessed. Incoming data is handled by theStream Input Managerand is routed to corresponding operator inputs. The operators of the NEGM SP graph fragment process incoming data and generate output 4mwhich is sent to theStream Output Manager. The Stream Output manager forwards the processed data to subsequent Operator Execution Service instances on remote participating nodes for further processing. During operator execution, statistics are collected by the Statistics Collector Client. Runtime statistics contain information such as bandwidth consumption and available bandwidth, memory-footprint of the single operators or processed items per time unit. The statistics are collected depending on the actual parametrization of the operator, since the parameter configuration usually has a great influence on the runtime
3.5 NexusDS Components Architecture 101 behavior. The statistics are stored on the participating node running the Operator Execution Service instance and are also transmitted to the Monitoring Service making the statistics avail-able to other NexusDS components 5m. Beside the statistics, the respective operator and node information are also transmitted in order to uniquely identify a runtime statistics record. This is important since the runtime behavior of operators heavily depends on three factors: The operator implementation itself, the parametrization of the operator, and the node it is executed on. These runtime statistics are used besides others by the Operator Scheduler to schedule operator execution. Changing conditions can make it necessary to adapt NEGM SP graph fragments at runtime. For that two options are available: Either a lightweight adaptation or heavyweight adaptation.
Lightweight Adaptation: Lightweight adaptation refers to actions that are limited by com-putation node borders and are only locally applicable. In contrast to this, the heavyweight adaptationrefers to actions that exceed computation node borders and involve other services (described below). During operator execution it may be necessary to change the execution order within the processing pipeline [17, 32, 142]. The Operator Scheduler organizes the order in which operators are executed within the Operator Execution Service by using the collected runtime statistics of the Statistics Collector Client 6m. The lightweight adaptation process is performed until the local adaptation potential for an Operator Scheduler instance is exhausted.
This occurs if the arrival rate of data elements is higher than the Operator Execution Service (and accordingly the operators) can handle or by a computation node failure. In this case, the Operator Scheduler has two options. The first option is to change the operator scheduling strategy 7m. For this purpose Sutherland et al. [130] proposed a flexible operator scheduling framework that adjusts the currently active scheduling strategy to maximize a given QoS. The second option is to ask preceding Operator Execution Services (by contacting their respective Operator Scheduler) to slow down processing speed. This can be achieved by either chang-ing the schedulchang-ing strategy or implementchang-ing a chain-scheduling strategy 8m. Alternatively, modifying the operator parameters is conceivable, which however is error-prone and complex.
Furthermore, for this the Operator Scheduler needs to know about the semantics of each op-erator and each of its parameters, which is difficult to implement with the flexible operator framework supported by NexusDS.
Heavyweight Adaptation: When lightweight adaptation is not applicable or even fails, the consequence is aheavyweight adaptation. Heavyweight adaptation is initiated by the Operator Scheduler when scheduling is not enough to avoid critical situations such as buffer overflows.
If no suitable precautions are taken, incomplete output data or even worse node failures may be the result. This requires techniques as described in [5, 19, 131]. To initiate heavyweight adapta-tion, the Operator Scheduler signals the Execution Manager Client that the current NEGM SP graph fragment execution must be modified 9m. The Execution Manager Client itself contacts the Execution Manager Server of the Core Graph Service (see Figure 3.7) to initiate the heavy-weight adaptation process 10msignaling that the NEGM SP graph must be restructured. The Core Graph Service performs the NEGM SP graph modification process as described in
Sec-Figure 3.9:Components contained in the Access Control Service (ACS)
tion 3.5.3. The modified NEGM SP graph fragments are then received back and the Operator Execution Service performs necessary steps for modified SP graph execution.
Termination: The execution of the NEGM SP graph fragments ends when the lifetime of the associated NPGM SP graph expires or when the inquiring client actively terminates the running NPGM SP graph using the received NPGM ID at SP graph deployment time. The client sends this NPGM ID to the Core Graph Service which in turn initiates thetermination phase, propagating a termination signal to the involved Operator Execution Service instances.