Measuring data‑centre workfows complexity through process mining: the Google cluster case

Measuring data‑centre workflows complexity throughprocess mining: theGoogle cluster case DamiánFernández‑Cerero1 · ÁngelJesúsVarela‑Vaca1· AlejandroFernández‑Montes1· MaríaTeresaGómez‑López1· José Antonio Alvárez‑Bermejo2 Abstract Data centres have become the backbone of large Cloud services and applica-tions, providing virtually unlimited elastic and scalable computational and storage resources. The search for the efficiency and optimisation of resources is one of the current key aspects for large Cloud Service Providers and is becoming more and more challenging, since new computing paradigms such as Internet of Things, Cyber-Physical Systems and Edge Computing are spreading. One of the key aspects to achieve efficiency in data centres consists of the discovery and proper analysis of the data-centre behaviour. In this paper, we present a model to automatically retrieve execution workflows of existing datacentre logs by employing process mining tech-niques. The discovered processes are characterised and analysed according to the understandability and complexity in terms of execution efficiency of data-centre jobs. We finally validate and demonstrate the usability of the proposal by applying the model in a real scenario, that is, the Google Cluster traces. Keywords Cloud computing· Business process management· Scheduling· Process mining· Process discovery· High performance computing *Damián Fernández-Cerero [email protected] Ángel Jesús Varela-Vaca ajv[email protected] Alejandro Fernández-Montes [email protected] María Teresa Gómez-López ma[email protected] José Antonio Alvárez-Bermejo [email protected] 1 Department ofComputer Languages andSystems, University ofSeville, 41012Seville, Seville, Spain 2 Department ofComputer Science, University ofAlmería, 04120Almería, Spain 1 3 1 Introduction Data centres are the backbone of large Cloud services and applications, providing virtually unlimited elastic and scalable computational and storage resources. Such environments are constantly evolving, from traditional monolithic systems tightly coupled to the MapReduce workload under execution [10], to highly flexible infrastructures which employ virtualisation and containerisation [13] to improve resource efficiency in Cloud-Computing scenarios. Modern resource-managing and workload-scheduling models enable data-cen- tre operators to share computing resources among heterogeneous applications and frameworks, such as MapReduce applications, frameworks for real-time analytics and on-demand Virtual Machines for Platform as a Service (PaaS) business models. This search for the efficiency and optimisation of resources is one of the current key aspects for large Cloud Service Providers. Several strategies have been proposed to achieve this goal, including: (i)resource orchestration and managing models [21, 24, 26, 37, 48, 53]; (ii) scheduling algorithms and consolidation models [5, 15, 16, 18, 29]; and (iii) workload migration models [41, 58, 59]. The improvement in resource efficiency in data centres is becoming more and more challenging because centralised data centres present numerous limitations when new computing paradigms, such as Internet of Things [23], Edge Computing [50], cyber-physical systems [3] and Fog Computing [4], are under consideration. The aforementioned models have something in common: to optimise their execution, it is necessary a deep knowledge about the system behaviour, actors and workloads involved. Such knowledge has been traditionally gathered through the human experience of data-centre operators and detailed log extraction and analysis [43], such as those presented in Fig.1. Human-based analysis may lack objectivity and be error-prone. Fig. 1 Detailed log analysis examples [7, 43]. It can be noticed that these analyses are complex and hard to apply directly to a decision-making system In our approach, we propose to take a set of existing data-centre logs and to automatically retrieve execution workflows in order to infer how the data-centre operation evolves. The adoption of the proposed model based on a real-time process mining engine employing new process metrics which may unveil useful information about the complexity and behaviour of the workload could be directly applied to develop new scheduling, workload consolidation, container migration and resource and energy efficiency algorithms. Compared to raw log analysis, process mining models provide richer information which may be though to discover through human analysis, enabling more accurate decisions. In addition, such decisions require low computational resources, allowing fast operations in critical infrastructures, such as data centres. A data-centre log represents a set of executions (i.e. jobs and tasks) performed in the past sorted by time. Process mining [55] is a well-recognised discipline which utilises various techniques to infer processes from execution traces [2]. The application of process mining in data-centre contexts facilitates the extraction of the evolution of the data-cen- tre operation and resource planning. Nonetheless, the results provided by process mining techniques (i.e. workflows) are not always easy to understand, and even to interpret depending on the case. Discovered processes might be unleashed into “spaghetti-like” models or “lasagna-like” processes [54, 57] derived from the diversity of the possible order execution of the tasks and its variety. Spaghetti-like processes, which are related to unstructured processes, tend to appear in contexts where the tasks executed in each moment can vary according to the complex decision behind, as occurs in a data-centre scenarios. Lasagna processes represent more structured processes. Figure2 shows the result of the direct application of process mining techniques to a piece of the Google data-centre log [45]. We can observe certain well-structured zones of the process (cf., right hand); nonetheless, the vast majority of processes present a spaghetti-like scheme. Therefore, the understandability and complexity of the process make the analysis almost unbearable for human beings. Usually, processes are influenced by certain factors, including: i) time events and ii) social events, such as the Super Bowl. It is crucial to understand and identify these factors for an optimal interpretation of the results of the mined processes. Therefore, depending on the perspective, the characterisation and analysis of the mined process can help to determine improvements such as detecting bottlenecks and misused resources. Nevertheless, the simplification of lasagna and spaghetti processes is an open problem in the process mining domain [8, 51]. In this first approach, we pursue the transformation of data-centre execution logs into event log traces to characterise the process and to determine the understandability and complexity of data-centre jobs in terms of execution efficiency. Derived from this context and the problems to be addressed, the aims of the paper are: Fig. 2 Spaghetti process. This kind of process provides little usefulness to decision making –OBJ1 Define a framework which may establish the cornerstone in the application of process mining in the field of data centres and Cloud and Edge Computing. –OBJ2 Study the usefulness and the applicability of process mining in the enhancement of data-centre performance by analysing the processes generated from data-centre execution logs. –OBJ3 Analyse the behaviour and homogeneity of the extracted processes by means of statistical tests. –OBJ4 Validate the usability of the proposal by applying our approach to a real scenario, that is, the Google Cluster traces presented in [45]. The rest of the paper is organised as follows: The related work is discussed in Sect.2. Section3 briefly presents the proposed framework. In Sect.4, we discuss the raw input data utilised for the use cases. The Log Extractor and XES Generation cases and tools are presented in Sect.5. In Sect.6, we briefly illustrate the process mining and discovery models and how they are employed in this work. The results obtained in our evaluation are presented and analysed in Sect.7. Finally, the paper is summarised, and the conclusions and future work are presented in Sect.8. 2 Related work Data-centre logs have been the source of information to gather knowledge on many aspects of data-centre operation, such as the behaviour of the scheduling and resource orchestration frameworks, workload classification and characterisation, detection of vulnerabilities, performance issues and anomalies. Many authors [11, 12, 28, 35, 49] have focused on the analysis of Google datacentre traces in order to properly characterise the workloads present in Cloud-Com- puting environments. In [28], Liu etal. study: (a) the management of machines, performing a deep analysis on the frequency and pattern of machine maintenance and (b) the cluster resource utilisation by performing an analysis on the life cycle of jobs and tasks. In [49], Sebastio etal. study the machine dynamic life cycle distributions to propose a data-driven model to enable the estimation of the expected number of available machines at any instant of time. Di etal. [11] analyse the resource utilisation per application and classify applications via a K-means clustering algorithm to show the underlying Pareto principle. Mishra etal. [35] propose a fine-grained algorithm to classify the workload present in the traces and its application to the Google Cloud Backend. In [12], Di etal. perform a detailed statistical analysis on job submission, resource request and machine utilisation patterns in order to compare Cloud-Computing workloads to those present in grid computing. In addition, other authors [1, 14, 44] analyse Google traces with different objectives. In [14], El-Sayed et al. analyse traces to precisely predict patterns of job termination and failures and provide strategies to mitigate such failures through task-cloning policies. Abdul-Raman et al. [1] analyse the topology and resource request patterns of the workload to model the user behaviour through sessions. In [44], Reiss et al. analyse the traces to show that heterogeneity is present at all levels, which imposes challenges in the development of effective cloud-based resource schedulers. Moreover, authors have been working with data-centre traces from various providers in order to apply scheduling optimisation strategies to improve performance and energy efficiency [17]. Process mining has been applied in several fields to properly discover the processes followed by users or systems, by analysing event logs [25]. Depending on the field, different perspectives could be used to discover the processes, such as the activities executed, people involved, resources used and location where the actions occur. The versatility of process mining techniques has brought about their application to several scenarios [9], being health care [30, 40, 46] and IT [31, 38, 47] the most active areas. To the best of our knowledge, process mining has not been used before in data-centre contexts, whose characteristics make necessary certain types of specific adaptations. Process discovery groups a set of algorithms that facilitate the creation of a workflow process model that represents the traces observed [32]. Typically, the process discovery has been based on the tasks analysis, but during last years, other resources as the persons who execute them or even its location have been included [42]. Process mining is a relevant topic very well received by the enterprises, bringing about the evolution of the research solution tools (e.g. ProM [56]) towards commercial solutions (e.g. Disco™and Celonis™); however, how to create the logs to be used in the tools is still a challenge. 3 Evaluation approach Our approach aims to characterise the workflows of data centres from their raw execution logs. We propose the framework depicted in Fig. 3 to achieve this objective. The definition of the framework facilitates the applications of a methodology that includes each step to discover business processes from data-centre behaviour, including the actors and the workloads involved. Derived from the complexity of these systems, it is necessary to provide a mechanism to adjust the process discovery for a better analysis. Fig. 3 Framework overview. This framework extracts and adjusts information from raw data-centre logs to build rich process models, which indicators and metrics may be used to make data-centre operation decisions First of all, the framework begins from a data-centre raw execution log (cf., Execution Raw Log in Fig.3). We defined the most relevant terms used in process mining area to define Log, Event Log, Event and Trace. Definition 1 (Execution Raw Log) Let RL be a raw log which consists of a multiset of records, {r1,r2,…,rm}, in which ri is a tuple of attributes ⟨a1∶t1 , a2∶t2 ,..., an∶tn⟩ where an attribute is identified by a name ( ai ) and described by a data type ( ti ). An event log for a process mining purposes is formed of multiset of traces: Definition 2 (Event Log) Let L be an event log L=[𝜏1,…,𝜏m] as a multiset of traces 𝜏i . A trace is composed of a tuple with an identifier and a sequence of events that occurred at a particular time t: Definition 3 (Trace) Let 𝜏 be a trace 𝜏=⟨case _ id, E⟩ which consists of a case_id that identifies the case, and a sequence of events E={𝜀1 , … , 𝜀n}, 𝜀i occurring at a time index i relative to the other events in E . An event occurrence is a triple with an identifier of an activity that occurred at a particular time stamp which may have additional information: Definition 4 (Event occurrence) Let 𝜀 be an event occurrence 𝜀=⟨activity _ id, time stamps, others⟩ which is specified by the identity of an activity which produces it and the related time stamps. 𝜀 may store more information, such as states, labels and resources. Data-centre logs are usually huge in size, which makes them hard to process in many cases. Due to this, in this work, we perform two analyses which vary in the size of the logs: the first one takes the whole log file as input, whilst in the second analysis, we perform a random sampling to reduce the complexity of the log files. In addition, this second analysis enables us to have enough samples to perform partitionability and statistical tests to check the homogeneity of the internal processes over time. Therefore, the definition of transformations (cf., Log Extractor in Fig.3) aims to extract an event log from data-centre raw execution logs. Depending on the purpose of the analysis, the extraction should define which pieces of data in the raw log should be considered as case_id, activity_id, and event, respectively. The log extraction consists of the specification of a sequence of sentences, that are, recipes, on how to extract certain information from a raw log and how to align it to the definitions of case_id, activity_id and event occurrences. Once the event logs have been obtained, these logs are introduced in a process discovery tool (cf., Process Mining–Process Discovery in Fig.3) which retrieves the workflows. Subsequently, these workflows are analysed (cf., Process Analysis in Fig.3), and as the result of such analysis, the process discovery model and/or log extraction may be adjusted (cf., Adjust discovery and Adjust extraction in Fig.3). On one hand, the aforementioned adjustments may include deletion of irrelevant cases or activities. On the other hand, the discovered workflows can be enriched (cf., Enrich models in Fig.3) with extra information to carry out other type of analysis. 4 Experiment data: execution raw log In this work, we used the data-centre raw execution log presented in [45], in order to illustrate our approach in a real scenario. These raw logs represent 29 days of operation time in a Google cluster composed of approximately 12,500 servers. The trace includes hundreds of thousands of jobs, which are submitted by final users. In this context, a final user may be a data-centre operator, a final client or even an auto-scal- ing software. Each job is composed of one to tens of thousands of tasks, which are the minimum workload unit to be deployed on an available server. These tasks are not gang scheduled [36], but are often processed in parallel. The information is provided in the form of timed events which may be grouped in the following categories: –Machine events, such as a fail or addition of machines, and the attributes related to those machines. Figure4 shows an example of machine events. –Job events, which represent the workload processing in the cluster. A job, which is composed of tasks, may be submitted, scheduled, evicted, or killed, for instance. Figure5 shows an example of job events. –Task events, which represent the minimum atomic workload to be executed by a server and their requirements, such as CPU, RAM and architecture. Both jobs and tasks have the same life cycle. Figure6 shows an example of tasks events. Fig. 4 Machine events log raw data example. This log consists on the following parameters: time, machine ID, event type, platform ID, machine CPU and memory The raw 29-day log of 42GB is divided into hundreds of comma-separated value files, of 50 MB each. Task and job events trace files represent the vast majority of files. In this work, we consider five random files among those task events to study the behaviour and background processes of the data-centre operation and scheduling. Furthermore, we gather four random samples of each log file to analyse the heterogeneity for several general, quality and partitionability metrics among samples. 5 Log extractor: XES generator In general, we consider a data-centre raw execution log as input, and as output, a set of traces such as those shown in Fig.7. The raw log files described in the previous section may be presented in a unstructured (NoSQL) or structured (SQL) fashion. Most of the current process mining tools accept XES [22] and MXML Fig. 5 Job events log raw data example. This log contains the following information: time, missing information (if present), job ID, event type, user ID, scheduling class, job name and logical job name Fig. 6 Task events log raw data example. This log is composed of the following attributes: time, missing information (if present), job ID, event type, task index, machine ID where the task event occurred, event type (in this work we only consider events representing task submission), user ID, scheduling class, priority, CPU, memory, and disk required, and whether the even happened in different machines formats. We are able to define a set of recipes by using the ELE transformation language [52], to convert raw execution logs onto XES formatted files. In Fig.7, two different extractions are depicted as the result of the obtention of various event logs (i.e., XES) for two different analysis purposes. In Example5.1, we provide a piece of code to illustrate the resulting log extraction, containing the information relative to machine_id, job_id and start_ date in XES format. Example 5.1: Generated eventlog in XES format <log xes.version="1.0" xes.features="nested-attributes" openxes.version="1.0RC7"> <trace> <string key="concept:name" value="1436548633"/> <event> <string key="concept:name" value="6318248632"/> <date key="time:timestamp" value="2019-05-27T09:56:52.186+02:000"/> </event> [...] </trace> [...] </log> All the resources, thus, raw logs (i.e., json format), the XES files and the processes discovered that are employed in this work are freely available at http:// www.idea.us.es/thejo urnal ofsup ercom putin g/. Execution Raw Logs Extraction recipe Event Log (XES) Event Log (XES) Fig. 7 Log extraction overview. The XES files are constructed from the execution raw logs following the recipes that are described in the following sections Regarding the quality metrics, in the literature, several metrics are used to measure how “good” a design of a business process model is [6, 34, 39]. The next set of metrics is adapted to measure the understandability and the complexity, which, in turn, allows the objective comparison of the discovered processes: –Density ( 𝜟 ): the ratio of transitions divided by the maximum number of possible transitions. The lower the value of density, the higher the understandability and the lower the complexity. All the metrics are computed based on the control-flow graph G=(V,E), where V and E represent the vertices (activities) and arcs (transitions), respectively. Therefore, we can denote the density formally as follows: –Cyclomatic number (CC): the number of paths needed to visit all activities. The cyclomatic can be seen as a complexity metric; thus, the lower the value of CC, the lower the level of complexity. CC can be defined as: –Coefficient of connectivity (CNC): the ratio of transitions to activities. The greater the value of CNC, the greater the complexity of configuration workflows. Notwithstanding, models with the same CNC value might differ in complexity regarding this parameter [34]. CNC can be written as: . –Control-flow complexity (CFC) enables the measurement of the complexity in terms of the potential transitions after a split, depending on its type. The higher the value of the CFC, the higher the overall structural complexity of a workflow. CFC may be denoted as follows: where |cxor ∙| and |cor ∙| represent the output transitions of a XOR gateway and OR gateway, respectively. –Sequentiality ( 𝜩 ) denotes the ratio computed by dividing the number of arcs between nodes without connectors by the total number of arcs. The lower the value of sequentiality, the higher the structural complexity of a workflow is expected. It may be formally described as: where V×V represent the set of transitions of two activities. (1) 𝛥 (G)= |E| |V| ⋅ (|V|−1) (2) CC(G)=|E|−|V|+1 (3) CNC (G)= |E| |V| (4) CFC (G)= ∑ c∈S and 1+ ∑ c∈S xor | cxor ∙ | + ∑ c∈S or 2|cor ∙|− 1 (5) 𝛯 (G)= |E∩(V×V)| |E| We present the results for tiny sample in Table5, as shown in Fig.8, in order to illustrate the calculation of the quality and general metrics. The skewness and partitionability analysis may help to provide extra data on the behaviour in terms of variability and similarity. The following statistical parameters are proposed to evaluate the understandability and complexity of the models for the general and quality metrics presented in both cases: – Mean ( 𝜇 ), Median ( 𝜇 ), and Standard Deviation 𝜎 = � 1 n− 1 ∑ n i=1(xi−𝜇) 2 . – Fisher skewness coefficient ( 𝛾1 ), which measures the skewness of the distribution of a variable according to its mean: 𝛾 1= 𝜇 3 𝜇 3∕2 2 = 𝜇3 𝜎 3 . –F, Fcritic and p value related to the one-way ANOVA tests [20]; we performed to test whether the samples are statistically homogeneous over time or not. In the next subsections, the resulting metrics for each case are analysed and compared. 7.1 Results forthecase simple In general, this type of process may help to understand which are the most representative users in terms of the number of jobs submitted. A random sample is shown in Fig.9 for illustration purposes. This process is obviously simpler and more understandable when compared with the spaghetti-like ones (cf., Fig.2). Regarding the control-flow structure, the process is composed of two gateways (i.e., XOR-split and XOR-join). Multiple paths, each one representing the sequence of jobs executed by a user, can be observed. Although the process is composed of multiple paths, just one can be executed each time due to the XOR gateway. Looking at in depth, we can highlight that there are very significant users with a large number of jobs, whilst others only submitted one or two jobs. All the remaining discovered processes of the case have a similar structure. Regarding the metrics, the results shown in Table6 represent the general, quality, skewness and partitionability metrics obtained for the analysis of the Case Simple with log-file sampling. It should be borne in mind that one metric is homogeneous among samples when the F ratio is lesser than Fcritic . Therefore, the results obtained for all metrics are statistically not homogeneous, which implies that the behaviour of inherent processes varies significantly over time. It can be noticed that the values for sequentiality 𝛯 are 1 and 2 orders of magnitude Table 5 General and quality metrics Sample Traces Events Act. Trans. Gate. 𝛥 CC CNC CFC 𝛯 Tiny 4 4 3 8 2 1.33 6 2.67 3 0.125 superior to those of the Case A and B, respectively. Notwithstanding, the density levels ( 𝛥 ) are comparable to those of the Case A. On one hand, both the number of events and the number of traces between samples present huge differences: the values range from 54 to 422 and from 27 to 98, respectively. Nonetheless, the standard variation of the number of events and transactions represents the ∼ 57% of the mean, and the standard variation of the number of traces reduces to ∼ 43% of its mean. On the other hand, the number of gateways keeps stable due to the simplicity of the case of study. The low number of transitions and gateways highlights the extremely low complexity of the models due to the multiple options of execution paths introduced. As a general conclusion, we can confirm the low complexity and high understandability of the processes discovered in all the samples due to the low number of activities, transitions and gateways. The ANOVA tests performed showed that the behaviour of the processes in terms of almost all metrics is heterogeneous between log files, which may indicate that the complexity of the process is time dependent. This conclusion may help us to build a set of time-related metrics that could support decision making, especially in scheduling, migration, consolidation and efficiency tasks. Fig. 9 Process discovered for sample 487-4. This process clearly presents the simplicity and the sequentiality of the Case Simple 7.2 Results forCase A As aforementioned, this case can help to understand how machines are used according to the jobs deployed on them. Figure10 shows the discovered process for the case from two perspectives: (a) without sampling and (b) with sampling. On one hand, the process obtained without sampling (cf., sub-figure a) is huge, very complex and non-understandable since we cannot easily analyse the structure. On the other hand, the sampled process (cf., sub-figure b) is less complex and much more understandable. Some conclusions can be drawn from it: some paths are composed of only one activity and others have a more complex path structure. The path with one activity may be the consequence of that particular Table 6 General, quality, skewness, partitionability and variance analysis results obtained for the Case Simple Id-Sample Traces Events Act. Trans. Gate. 𝛥( 10 −3) CC CNC CFC 𝛯( 𝟏0 −1) 150-1 69 300 300 371 2 4.14 72 1.24 70 6.23 150-2 98 291 291 391 2 4.63 101 1.34 99 4.94 150-3 94 422 422 518 2 2.92 97 1.23 95 6.33 150-4 81 364 364 447 2 3.38 84 1.23 82 6.33 276-1 79 219 219 300 2 6.28 82 1.37 80 4.67 276-2 40 121 121 163 2 11.23 43 1.35 41 4.97 276-3 69 202 202 273 2 6.72 72 1.35 70 4.87 276-4 69 233 233 304 2 5.62 72 1.30 70 5.39 311-1 61 123 123 186 2 12.40 64 1.51 62 3.33 311-2 75 159 159 236 2 9.39 78 1.48 76 3.56 311-3 60 140 140 202 2 10.38 63 1.44 61 3.96 311-4 59 279 279 340 2 4.38 62 1.22 60 6.47 401-1 34 68 68 104 2 22.83 37 1.53 35 3.27 401-2 30 60 60 92 2 25.99 33 1.53 31 3.26 401-3 27 54 54 83 2 29.00 30 1.54 28 3.25 401-4 53 86 86 141 2 19.29 56 1.64 54 2.34 487-1 37 110 110 149 2 12.43 40 1.35 38 4.90 487-2 30 71 71 103 2 20.72 33 1.45 31 3.98 487-3 58 138 138 198 2 10.47 61 1.43 59 4.04 487-4 50 186 186 238 2 6.92 53 1.28 51 5.71 𝜇 62.40 176.08 176.08 240.44 2.00 11.59 65.36 1.42 63.36 4.34 𝜇 60 157 157 225 2 9.51 63 1.43 61 4.04 𝜎 27.11 100.56 100.56 121.81 0.00 7.47 26.97 0.12 26.97 1.51 𝛾1 1.44 0.84 0.84 0.70 N/A 0.91 1.41 −0.13 1.41 0.37 F9.34 15.53 15.53 17.05 N/A 17.49 9.34 7.91 9.34 6.37 Fcritic 3.06 3.06 3.06 3.06 N/A 3.06 3.06 3.06 3.06 3.06 p0.00 0.00 0.00 0.00 N/A 0.00 0.00 0.00 0.00 0.00 machine executing only one job. We can conclude that the analysis with sampling is much more useful than that without sampling. Tables7 and 8 present the general, quality, skewness and partitionability results provided by the analysis without and with log-file sampling for Case A, respectively. Regarding general metrics in Table7, although there is a big difference in the number of events between samples ranging from 59,646 and 21,510 events, the number of mapped activities keeps more homogeneous, thus, 1820 at maximum in the worst case and half of that in the best case. All the samples present the similar behaviour with regard to transitions and gateways. However, transitions represent the paths between activities within the model and gateways represent (a) (b) Fig. 10 Processes discovered by Case A. It can be noticed that the sampling reduced the complexity of the process, which enables a richer and more useful processing Table 7 General, quality, skewness and partitionability results obtained for the Case A without log-file sampling Id Traces Events Act. Trans. Gate. 𝛥( 10 −3) CC CNC CFC 𝛯( 10 −2) 150 8437 21510 1428 2271 93 1.11 844 1.59 1342 7.29 276 11678 74498 1601 3159 45 1.23 1559 1.97 1557 3.01 311 11126 65326 1597 3132 45 1.23 1536 1.96 1534 4.00 402 11708 79850 1820 3592 38 1.09 1773 1.97 1771 2.70 478 11660 59646 958 1807 40 1.97 850 1.89 848 8.47 𝜇 10921.80 60166 1480 2792 52.2 1.33 1312 1.88 1410.40 5.05 𝜇 11660 62746 1597 3132 45 1.23 1536 1.96 1534 3.80 𝜎 1409.86 22989.39 323.70 730.06 23.01 3.66 434.79 0.16 349.20 2.64 𝛾1 − 2.08 − 1.61 − 1.24 − 0.53 2.14 2053 − 0.39 − 1.99 − 1.24 0.61 control-flow elements that enable the convergence and divergence of paths. A high number of transitions and gateways may increase considerably the complexity of the models due to the multiple options of execution paths introduced. In summary, we can confirm the high complexity and low understandability of the processes discovered in all the log files without log-file sampling due to the high number of activities, transitions and gateways. The best log file by considering activities, transitions and gateways is 478. However, observing the mean ( 𝜇 ) and median ( 𝜇 ) according to activities, the more representative log files are 150 and 311, whilst 150 and 311 are the most representative in terms of transitions, and with regard to gateways, 276, and 311. Therefore, we can conclude that the models of the log file 150 and 311 can be Table 8 General, quality, skewness, partitionability and variance analysis results obtained for the Case A It can be noticed that all metrics except sequentiality ( 𝛯 ) are statistically heterogeneous Id Traces Events Act. Trans. Gate. 𝛥( 10 −3) CC CNC CFC 𝛯( 10 −2) 150-1 3526 4513 300 621 40 6.92 322 2.07 320 4.99 150-2 3533 4542 291 593 28 7.03 303 2.04 301 6.07 150-3 3166 4291 422 832 45 4.68 411 1.97 409 10.46 150-4 3276 4399 364 723 36 5.47 360 1.99 358 8.99 276-1 3813 4778 219 470 35 9.84 252 2.15 250 5.74 276-2 3880 4855 121 255 16 17.56 135 2.11 133 3.92 276-3 3956 4823 202 406 17 10.00 205 2.01 203 5.42 276-4 4156 4933 233 469 24 8.68 237 2.01 235 8.74 311-1 3948 4886 123 267 21 17.79 145 2.17 143 3.37 311-2 3286 4202 159 337 24 13.41 179 2.12 177 3.86 311-3 3827 4761 140 300 22 15.42 161 2.14 159 3.00 311-4 3761 4825 279 580 46 7.48 302 2.08 300 10.00 402-1 2253 3749 68 153 14 33.58 86 2.25 84 1.31 402-2 2325 3627 60 136 14 38.42 77 2.27 75 2.94 402-3 1929 3265 54 118 10 41.23 65 2.19 63 1.69 402-4 3579 4502 86 184 11 25.17 99 2.14 97 1.63 487-1 4119 4785 110 221 11 18.43 112 2.01 110 10.86 487-2 3665 4216 71 152 10 30.58 82 2.14 80 2.63 487-3 3819 4781 138 290 19 15.34 153 2.10 151 5.17 487-4 3938 4885 186 367 18 10.67 182 1.97 180 7.90 𝜇 3487.75 4480.90 181.30 373.70 23.05 16.91 193.40 2.10 191.40 5.08 𝜇 3665 4542 157 324 18 13.41 193.40 2.10 191.40 4.99 𝜎 631.48 469.92 105.81 207.95 11.61 111.31 102.39 0.09 102.39 8.61 𝛾1 − 1.45 − 1.35 0.78 0.71 0.80 1.03 0.64 0.26 0.64 0.46 F9.71 7.18 15.53 16.17 7.07 14.93 16.59 6.37 16.59 1.40 Fcritic 3.06 3.06 3.06 3.06 3.06 3.06 3.06 3.06 3.06 2.77 p0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.27 taken as representative for the Case A since they can be considered as the most understandable and less complex in terms of general metrics. By analysing 𝛾1 , the coefficient shows a negative skew with regard to activities and transitions but positive regarding gateways. Thus, the models present an asymmetrical distribution when negative or positive coefficient are reached. Although the number of transitions is negative, it is relatively close to zero; thus, it almost achieves a symmetrical distribution. This coefficient has helped us to identify that the complexity and understandability of the models present non-homogeneous trends in terms of symmetry distribution according to the general metrics. Regarding the quality metrics, the reference models are 402, 150 and 478. The log file 402 is the best case for density, whilst 150 excels for CC and CNC, and 478 for CFC. Thus, these are the models that obtained the best score in terms of complexity and understandability regarding quality metrics. Comparing the results with general metrics, the log file 311 has the second highest rate of density and CFC, and the worst CNC. However, the log file 150 has been also selected as the model reference. Although other samples may be considered as relevant, the log file 311 represents better the values for general metrics, and 402 and 478 represent the log files according to quality metrics. We may conclude that the log file 150 is the most representative in terms of general and quality metrics. Hence, it can be considered the most understandable and less complex model, taking into account the difficulty of treating processes like these. Comparing the above results with those provided by the analysis with log-file sampling (cf., Table8), the number of traces, events, activities, gateways and transitions is drastically reduced since the sample covers only a part of the whole log file. Nevertheless, the reduction in the number of elements may help to reduce the complexity and to improve the understandability of the case as remarked at the beginning of the section. We can see how the density in all the samples is higher due to the ratio of activities versus transitions is lower than that provided by the analysis without sampling. It should be noticed that even though a higher density usually implies a worst complexity, in this case, these trends are not present. In terms of CC, CNC, CFC and 𝛯 , we can conclude that in some cases, the log-file sampling increases the complexity. For instance, the values of CNC resulting of the analysis with sampling are higher than those provided by the analysis without sampling. Nevertheless, the lower values of CC, CFC and the higher value of 𝛯 indicate that the process models obtained with the analysis with sampling are less complex and more understandable than those provided by the analysis without sampling. As a summary of the Case A, we may conclude that the analysis of the datacentre workflows employing log-file sampling present a simpler behaviour than that without sampling. 7.3 Results forCase B As previously mentioned, this case may help to understand how tasks are executed depending on the chosen machines. We want to remark that the discovered process without sampling is impossible to depict due to the limitations of the modellers when importing, representing, and exporting these models. Nonetheless, Fig.11 shows the discovered process obtained with the analysis with log-file sampling. In the process, the paths represent the machines where the tasks are executed. On one hand, in this particular case, there are paths with only one activity, which means that those particular tasks are only executed in one machine. On the other hand, there are paths where multiple machines are used to execute the tasks. The results shown in Tables9 and 10 represent the general, quality, skewness and partitionability metrics obtained with the analysis without and with log-file sampling, respectively, in Case B. Due to the complexity of the analysis without sampling, for log file 402, the 𝛯 metric is not provided, since we were unable to compute it due to limitations of the tools employed. Such non-present values are denoted by a dash symbol in Table9. Regarding general metrics, there exist a huge number of traces and events with differences, multiplying by five the number of events in the worst cases. Notwithstanding, the number of mapped activities keeps reasonably stable between 8433 and 11,702. In this case, it is necessary to emphasise the huge number of transitions and gateways. Such a trend demonstrates the enormous complexity related to the number of optional paths in the model. Similarly to the previous case, we confirm the high complexity and low understandability of the processes discovered in all the log files due to the high number of activities, transitions and gateways. The best results are provided by log files 150 and 276 for activities; 276 for transitions; and 402 for gateways. The mean ( 𝜇 ) and median ( 𝜇 ) indicate that the most representative log files are 311, 402 and 276, according to activities, transitions and gateways, respectively. Therefore, we can conclude that the models of the log files 276 and 402 can be taken as representative for the Case B, since they can be considered as the most understandable and less complex in terms of general metrics. The models discovered in Case A seem less complex than those of Case B. However, the ratio between activities and transitions is similar in both cases. Furthermore, in Case B, the number of gateways in the models is enormous compared with that of Case A. In the same way, the selection of reference models in both cases according to general metrics is the result of different analyses. For this reason, the resulting reference models differ from those obtained for Case A. Fig. 11 Process discovered for the first sample of 487 in Case B. It can be noticed the higher complexity of this case Table 9 General, quality, skewness and partitionability results obtained for the Case B without log-file sampling File Traces Events Act. Trans. Gate. 𝛥( 10 −4) CC CNC CFC 𝛯( 10 −3) 150 18929 25034 8433 10225 1410 1.44 1793 1.21 8587 2.74 276 70106 80265 8433 10199 1433 1.43 1767 1.21 8586 0.33 311 62184 71070 11116 13683 2072 1.11 2568 1.23 11541 1.08 402 69217 126677 11702 13251 1207 0.97 1550 1.13 11947 – 478 61072 68324 11659 14487 2282 1.07 2829 1.24 12143 0.74 𝜇 56301.60 74274 10269 12369 1680.80 1.20 2101.40 1.21 10561 0.97 𝜇 62184 72672 11116 13251 1433 1.11 1793 1.21 11541 0.91 𝜎 21280.51 36236.07 1691.50 2018.42 467.36 0.22 560.82 0.04 1815.31 1.06 𝛾1 − 2.04 0.21 − 0.53 − 0.39 0.55 3594 0.60 − 1.69 − 0.55 1501.32 By analysing 𝛾1 , the coefficient shows a negative skew with regard to activities and transitions but positive regarding gateways. Although the skewness values are negative and positive in all cases, the values are moderately close to zero in five of eight metrics. Such values highlight a trend to a symmetrical distribution. Moreover, the samples belonging to Case B have a more symmetrical distribution than those of Case A, since the skewness coefficient is closer to zero in most of the metrics. Regarding the quality metrics, the log files 402 and 276 may be taken as the reference models. The log file 402 provides the best results for the density ( 𝛥 ) parameter, CC and CNC, whilst the log file 276 provides the best results for CFC. Table 10 General, quality, skewness, partitionability and variance analysis results obtained for the Case B It can be noticed that in this case, both the results in terms of density ( 𝛥 ) and sequentiality ( 𝛯 ) are one order of magnitude inferior to those of the Case A. In this case, even the sequentiality is not homogeneous among samples Id-Sample Traces Events Act. Trans. Gate. 𝛥( 10 −4) CC CNC CFC 𝛯( 10 −3) 150-1 4133 4960 3526 7094 67 5.71 3569 2.01 3576 5.07 150-2 4031 4970 3533 7198 122 5.77 3666 2.04 3664 3.61 150-3 3375 4928 3166 6427 106 6.41 3262 2.03 3260 5.76 150-4 3711 4926 3276 6643 89 6.19 3368 2.03 3366 1.96 276-1 4519 4990 3813 7685 82 5.29 3873 2.02 3871 5.07 276-2 4608 4990 3880 7787 43 5.17 3908 2.01 3906 3.08 276-3 4275 4991 3956 8018 136 5.12 4063 2.03 4061 10.23 276-4 4506 4999 4156 8413 151 4.87 4258 2.02 4256 10.10 311-1 4887 4982 3948 7961 43 5.11 4014 2.02 4012 3.01 311-2 4850 4979 3286 6653 54 6.16 3368 2.02 3366 1.95 311-3 4696 4971 3827 7675 19 5.24 3849 2.01 3847 0.52 311-4 4338 4992 3761 7541 54 5.33 3781 2.01 3779 6.63 402-1 2257 4991 2253 4553 14 8.97 2301 2.02 2299 0.66 402-2 2453 4992 2325 4670 21 8.64 2346 2.01 2344 1.71 402-3 1917 4987 1929 3868 10 10.40 1940 2.01 1938 0.78 402-4 4185 4998 3579 7252 78 5.66 3674 2.03 3672 0.83 487-1 4616 4998 4119 8431 182 4.97 4313 2.05 4311 4.27 487-2 4829 4998 3665 7391 63 5.50 3727 2.02 3725 3.11 487-3 4491 4994 3819 7803 162 5.35 3985 2.04 3983 3.33 487-4 4415 4995 3938 8046 171 5.19 4109 2.04 4107 4.23 𝜇 4002.88 4980.32 3438.04 6944.56 70.60 6.15 3507.52 2.02 3505.88 3.22 𝜇 4338 4990 3665 7391 54 5.50 3727 2.02 3725 3.01 𝜎 917.73 21.60 640.80 1306.97 55.39 1.54 667.00 0.01 667.04 2.79 𝛾1 − 1.19 − 1.65 − 1.29 − 1.27 0.72 1.78 − 1.24 0.67 −1.24 1.21 F10.95 13.83 9.71 9.60 5.94 8.52 9.47 3.47 9.46 4.21 Fcritic 3.06 3.06 3.06 3.06 3.06 3.06 3.06 3.06 3.06 3.06 p0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.03 0.00 0.02