Reivindicaciones
1. A parallel data stream processing engine executing continuous queries on a plurality of processing nodes (1) wherein a continuous query comprises a plurality of interconnected operators, each operator of the query being selectable between stateless operator (M, F) and stateful operator (A, J), which comprises: a) means for splitting a continuous query into at least one sub-query, wherein each of said at least one sub-query consists of one stateful operator (A, J) followed by at least a stateless operator (M, F), except an initial sub-query which only contains stateless operators (M, F), b) means for associating each at least one sub-query to at least two nodes (1); wherein the nodes (1) are configured to execute the sub-query; wherein an executed sub-query generates at least one tuple; c) means for labeling the generated tuples with an ordering label comprising a timestamp indicating a relative ordering among tuples and used for ordering tuples to a destination sub-query (3) at the input merger (IM)characterized in that it further comprises d) means for sending and receiving tuples across interconnected sub-queries, a source sub-query (2) and a destination sub-query (3) comprising interconnected operators between them; wherein the means for sending and receiving tuples comprise: - for each node (1) executing a source sub-query (2), a load balancer (LB) configured to send a plurality of generated tuples to the nodes (1) executing a destination sub-query (3); - for each node (1) executing a destination sub-query, an input merger (IM) configured to receive a plurality of generated tuples sent by each load balancer (LB) of the source sub-query; wherein the load balancer (LB) is configured to determine the node (1) to which a tuple is sent based on at least a field comprised in the tuple, the field called a key field; and wherein for each subquery comprising a stateless operator (M, F) or a stateful operator (A, J): - an input merger (IM) at the beginning of each operator (A, M) and a load balancer (LB) at the end of each operator (A, M) is introduced, where the subquery is executed, and wherein each load balancer (LB) is connected to each input merger (IM) respectively to distribute the output tuples from the source subquery (2) to the destination subquery (3), wherein each load balancer is configured to: - send tuples with a same key field to a same node (1) executing the destination sub-query (3), when the operator is a stateful operator (A, J), or - send tuples to the destination sub-query in a round robin fashion, when the operator is a stateless operator (M, F). 2. The engine according to claims 1, wherein the means for splitting queries uses the method for splitting the source query into as many sub-queries as operators included in the original query. 3. The engine according to any of claims 1 to 2, wherein the sending of tuples received with the same key to the node (1) executing a destination sub-query (3) comprises: a) applying to each tuple with key c a hash function obtaining a value h=hash; b) obtaining the partition identifier p of the tuple, making the modulo operation by a constant np, obtaining a value p=h mod np; c) assigning each partition with identifier p to a node (1) executing a destination sub-query (3). 4. The engine according to claim 1, wherein: a) each input merger (IM) forwards tuples as an input merger (IM) receives the tuples from any of the source sub-queries to the destination sub-query (3) is connected to, or; b) each input merger (IM) waits to receive a tuple from each one of the input merger (IM) input streams before forwarding the tuple with smallest timestamp to the destination sub-query (3) is connected to, c) a load balancer (LB) stores the timestamp from the last generated tuple for each destination sub-query (3) and if after a maximum prefixed period of time m, a tuple has not been sent to the destination sub-query (3), the load balancer (LB) sends a dummy tuple with the same timestamp the last tuple sent by the load balancer (LB) had. 5. The engine according to any of claims 2 to 4, wherein it further reconfigures the processing of tuples corresponding to a partition p, by transferring the processing of said tuples from a source node (1) to a destination node (1), comprising: a) means for obtaining the greatest active timestamp in the system, mt; b) means for establishing a future timestamp mtf, by adding temporal shift f to the greatest active timestamp in the system, mt, mtf=mt+f; c) means for sending, during the established time margin f, a reconfiguration command including the timestamp that begins the reconfiguration, mtf, to all source sub-queries involved in the reconfiguration; d) means for storing the timestamp mtf in all load balancers (LB) of the source sub-query (2); e) sending of the tuples corresponding to the reconfigured partition p with timestamp less or equal than mtf by the load balancers of the source sub-query to the node (1) executing the destination sub-query responsible for the partition p before the reconfiguration started; f) means for sending of one tuple by the load balancers (LB) of the source sub-query (2) that indicates the end of reconfiguration to the nodes (1) executing the destination sub-query (3) involved in the state transfer before sending the first tuple from partition p greater than mtf; g) means for sending of the tuples belonging to reconfigured partition p with timestamp greater than mtf by the load balancers of the source sub-query to the node (1) executing the destination sub-query (3) responsible for the partition p after the reconfiguration; h) means for transferring the state of partition p to the destination node (1) after receiving the tuple that indicates the end of reconfiguration from all load balancers (LB) of the source sub-query (2); i) means for applying at the destination node (1) the state of the partition p after receiving the state transfer from partition p. 6. The engine according to claim 5, wherein the configuration of one of the nodes (1) where a sub-query is executed to balance the load comprises: a) means for receiving periodically from all the nodes (1) where the sub-query is being executed, data about CPU and memory utilization at each node (1), and the greatest timestamp among the processed tuples at each node (1), b) means for comparing utilization data across the nodes (1) executing the sub-query; c) means for sending a reconfiguration command to the involved nodes (1) of the source sub-query (2) and destination sub-query (3) if, for a sub-query, the comparison between utilization exceeds a first given upper utilization threshold, the node (1) reconfigures at least a data partition, d) means for adding the selected node (1) to the set of nodes (1) that executes the sub-query so that, the selected node (1) will receive load from other nodes (1) automatically if the average load of the nodes (1) of a sub-query exceeds a given second upper imbalance threshold, the node (1) selects one node (1) from the set of free nodes (1), e) means for sending a reconfiguration command to the selected node (1) so all the selected nodes (1) partitions will be distributed among the rest of the nodes (1) that execute the sub-query if the average load of the nodes (1) of a sub-query can be satisfied with a smaller set of nodes (1) without exceeding the second upper utilization threshold, the node (1) selects one node (1) from the set of nodes (1) where the sub-query is being executed. 7. A parallel data stream processing method executing continuous queries on a plurality of processing nodes (1), wherein a continuous query comprises a plurality of interconnected operators, each operator of the query being selectable between stateless operator (M, F) and stateful operator (A, J), which comprises: a) splitting a continuous query into at least one sub-query, wherein said sub-query consists of one stateful operator (A, J) followed by at least a stateless operator (M, F), except an initial sub-query which only contains stateless operators (M, F), b) associating each at least one sub-query to at least two nodes (1); wherein the nodes (1) are configured to execute the sub-query; wherein an executed sub-query generates at least one tuple; c) labeling the generated tuples with an ordering label comprising a timestamp indicating a relative ordering among tuples and used for ordering tuples to a destination sub-query (3) at the input merger (IM), characterized in that it further comprises d) sending and receiving tuples across interconnected sub-queries, a source sub-query (2) and a destination sub-query (3) comprising interconnected operators between them; wherein the means for sending and receiving tuples comprise: - for each node (1) executing a source sub-query (2), sending a plurality of generated tuples to the nodes (1) executing a destination sub-query (3); - for each node (1) executing a destination sub-query, receiving a plurality of generated tuples sent by each node (1) executing the source sub-query (2); wherein the load balancer (LB) is configured to determine the node (1) to which a tuple is sent based on at least a field comprised in the tuple, the field called a key field; wherein for each subquery comprising a stateless operator (M, F) or a stateful operator (A, J): - an input merger (IM) at the beginning of each operator (A, M) and a load balancer (LB) at the end of each operator (A, M) is introduced, where the subquery is executed, and wherein each load balancer (LB) is connected to each input merger (IM) respectively to distribute the output tuples from the source subquery (2) to the destination subquery (3), wherein each load balancer is configured to: - send tuples with a same key field to a same node (1) executing the destination sub-query (3), when the operator is a stateful operator (A, F), or; - send tuples to the destination sub-query in a round robin fashion, when the operator is a stateless operator (M, F). 8. The method according to claim 7, wherein the means for splitting queries split the source query (2) into as many sub-queries as operators included in the original query. 9. The method according to any of claims 7 to 8, wherein the sending of tuples received with the same key to the node (1) executing a destination sub-query (3) comprises: a) applying to each tuple with key c a hash function obtaining a value h=hash; b) obtaining the partition identifier p of the tuple, making the modulo operation by a constant np, obtaining a value p=h mod np; c) assigning each partition with identifier p to a node (1) executing a destination sub-query (3). 10. The method according to any of claims 7 to 9, wherein: a) each input merger (IM) forwards tuples as an input merger (IM) receives the tuples from any of the source sub-queries (2) to the destination sub-query (3) is connected to, b) each input merger (IM) waits to receive a tuple from each one of the input merger (IM) input streams before forwarding the tuple with smallest timestamp to the destination sub-query (3) is connected to, c) a load balancer (LB) stores the timestamp from the last generated tuple for each destination sub-query (3) and if after a maximum prefixed period of time m, a tuple has not been sent to the destination sub-query (3), the load balancer (LB) sends a dummy tuple with the same timestamp the last tuple sent by the load balancer (LB) had. 11. The method according to any of claims 8 to 10, wherein it further reconfigures the processing of tuples corresponding to a partition p, by transferring the processing of said tuples from a source node (1) to a destination node (1), comprising: a) obtaining the greatest active timestamp in the system, mt; b) establishing a future timestamp mtf, by adding temporal shift f to the greatest active timestamp in the system, mt, mtf=mt+f; c) sending, during the established time margin f, a reconfiguration command including the timestamp that begins the reconfiguration, mtf, to all source sub-queries involved in the reconfiguration; d) storing the timestamp mtf in all load balancers (LB) of the source sub-query (2); e) sending of the tuples corresponding to the reconfigured partition p with timestamp less or equal than mtf by the load balancers of the source sub-query to the node (1) executing the destination sub-query (3) responsible for the partition p before the reconfiguration started; f) sending of one tuple by the load balancers (LB) of the source sub-query (2) that indicates the end of reconfiguration to the nodes (1) executing the destination sub-query (3) involved in the state transfer before sending the first tuple from partition p greater than mtf; g) sending of the tuples belonging to reconfigured partition p with timestamp greater than mtf by the load balancers of the source sub-query to the node (1) executing the destination sub-query (3) responsible for the partition p after the reconfiguration; h) transferring the state of partition p to the destination node (1) after receiving the tuple that indicates the end of reconfiguration from all load balancers (LB) of the source sub-query; i) applying at the destination node (1) the state of the partition p after receiving the state transfer from partition p. 12. The method according to claim 1 1 , wherein the configuration of one of the nodes (1) where a sub-query is executed to balance the load comprises: a) receiving periodically from all the nodes (1) where the sub-query is being executed, data about CPU and memory utilization at each node (1), and the greatest timestamp among the processed tuples at each node (1); b) comparing utilization data across the nodes (1) executing the sub-query; c) if, for a sub-query, the comparison between utilization exceeds a first given upper utilization threshold, the node (1) reconfigures at least a data partition, sending a reconfiguration command to the involved nodes (1) of the source and destination sub-query; d) if the average load of the nodes (1) of a sub-query exceeds a given second upper imbalance threshold, the node (1) selects one node (1) from the set of free nodes (1), adds the selected node (1) to the set of nodes (1) that executes the sub-query so that, the selected node (1) will receive load from other nodes (1) automatically; e) if the average load of the nodes (1) of a sub-query can be satisfied with a smaller set of nodes (1) without exceeding the second upper utilization threshold, the node (1) selects one node (1) from the set of nodes (1) where the sub-query is being executed, and sends a reconfiguration command to the selected node (1) so all the selected nodes (1) partitions will be distributed among the rest of the nodes (1) that execute the sub-query.
