## 2 Related Work  
In this paragraph, we describe some of the most important dynamic strategies found in the literature. Before this, we make a short reference to the static big data scheduling strategies. The static strategies work offline and try to assign the tasks to the most suitable nodes in order to minimize the communication latencies between tasks that need to co-operate during the execution of an application. A number of static strategies are topology-aware, such as those listed in [8; 9; 10], while others are based on resource handling (resource-aware), such as those in [11; 12] or [13]. Finally, other recent works employ the idea of linear programming; for example, this is evident in [14; 15; 16; 17]. In this paragraph, we focus on dynamic big-data scheduling strategies. The dynamic strategies monitor performance parameters during runtime and update tasks' placement. Decisions are made online. However, issues such as re-balancing can be proven to be highly time-consuming; e.g., \(\approx\)200 s in Storm [11] (recent works have tried to develop techniques for rapid re-balancing [18; 19]). Moreover, several existing works employ the CPU without considering memory constraints [18; 20], and this can lead to memory overflow. A dynamic scheme should be able to handle system changes (number of tasks or nodes) that occur after monitoring and during runtime. Additionally, it should be able to adopt data parallelism and scale out the number of parallel instances for an operator that is overloaded [11]. Many dynamic works employ task migrations, which are required to reduce resource utilization imbalances between nodes. This is a costly procedure, and it is not employed in our work. Below, we briefly describe some of the most important works presented in the literature. [PERSON] et al. [8] developed a dynamic online scheduler that produced assignments that reduced the inter-node and inter-slot traffic on the basis of the communication patterns among executors observed at runtime. The goal of an online scheduler is to allocate executors to nodes in order to impose limitations on the number of workers each topology has to run on, the number of slots available for each worker node and the computational power available on each node. There are two phases in this implementation: in the first phase, the pairs of communicating executors of each topology are put in descending order based on the rate of exchanged tuples. For each of these pairs, if both the executors have not been assigned yet, they are assigned to the least loaded worker. Otherwise, to choose the best worker, a set is generated by putting the least loaded worker together with the workers where either executor of the pair is assigned and the assignment decision is based on the criterion of the lowest inter-worker traffic. The latency of processing an event is below 20-30% and the inter-node traffic below 20% with respect to the default Storm scheduler in both tested topologies. [PERSON] et al. [18] designed and implemented the DRS (dynamic resource scheduler). Their algorithm takes into account the number of operators in an application and the maximum number of available processors that can be allocated to them and tries to find an optimal assignment of processors that results in the minimum expected total sojourn time. They estimated the total sojourn time of an input by modeling the system as an open queuing network (QQN). The performance model is built based on a combination of one of [PERSON]'s models and the Jackson network. The system monitors the actual total sojourn time and checks if the performance falls or whether the system can fulfill the constraint with fewer resources, rescheduling if necessary. It repeatedly adds one processor to the operator with the maximum marginal benefit, until the estimated total sojourn time is no larger than a real-time constraint parameter.