# Industry 4.0 towards Forestry 4.0: Fire Detection Use Case +
## 5 Methodology
### The Importance of Dynamic Window Sizing over IoT-Based Stream Rate Change  
As IoT streaming data is potentially never-ending, analyzing such data can be never-ending as well. Therefore, the stream windowing concept is re-emerging and being used in IoT-based data stream processing [4]. All stream queries are executed as multiple executions of the same query over data within a single window. Hence, the repeated  
Figure 7: Research methodology description. execution of queries on changing data within the window is the major resource-intensive task. Performing analytics (i.e., aggregation) over streaming data makes it further resource-complicated, bringing the windowing function into further limelight. Hence, any stream processing system's performance depends on the configuration of windows, including their type and size. A larger window size is used to facilitate streaming query engines for optimal processing of data with high velocity to deal with higher stream rate. However, the larger window size increases the latency between the input arrival time and output generation in lower stream rate. Furthermore, a few external factors can also impede a query engine's performance, such as application requirements, resource configurations, number and type of queries, etc. Therefore, it is of utmost necessity to maintain an optimal windows size at the query deployment time and during the executions of queries over the time. As the query static window configuration may cause unreasonable high latency in case of low stream rate or a resource contention problem and/or violate workload requirements in case of high stream rate. However, due to multiple external and dynamic factors it is not possible to guarantee an optimal window size and type which could be valid throughout the life-cycle of a streaming query. Ideally, the stream query processor must cater to external factors such as stream rate and resource availability to continuously monitor the performance and recommend the alternative optimal solution as soon as it is available. Consequently, if the stream processing platform is windowing that data for processing, the windows no longer represent the data that actually tremendously arrived. In particular, alignment of stream rates with window-based analytics is difficult, especially in cases where these analytics are required for sending preventable emergency alerts to avoid downtime and costly unplanned maintenance. Indeed, not only the windowing configuration affects the stream processing system performance, but also fluctuations of the incoming streaming data rate [20]. Consequently, in this work, we will study the data drift in IoT typically faced by industrial data analytics, and discuss Apache Flink stream processing windows. Flink stream query processing is insufficient to execute the same continuous query on variable stream data (i.e., high-rate and low-rate). Significantly, choosing the proper window size in terms of milliseconds, seconds, or minutes according to stream rates is beneficial to avoid data drift problems to meet analytics requirements such as latency constraints. We study different stream rate scenarios with regards to window size such as (1) assigning small window sizes for high stream rates to materialize enough tuples (sequences of values) to be joined and (2) assigning large window sizes for low stream rates that could buffer enough tuples for insightful joins. Then, we provide a flexible model to propose the ideal window type and size depending on stream rates and application requirements. In this paper, we performed an empirical study to showcase how constant window size and type impede query engine performance whenever stream rate varies. We evaluated the impact over the Flink query engine's performance with changing stream rate while keeping the window size and type constant.