Flora: Efficient Cloud Cluster Config Selection

• Flora is a lightweight system that cost-optimizes cloud cluster configurations by aligning resource allocations with big-data job demands.
• It employs a two-class taxonomy based on memory access patterns to select configurations without requiring job-specific profiling.
• Empirical evaluation on 180 Spark executions shows Flora achieves near-optimal cost performance, with average deviations below 6%.

Flora is a lightweight, infrastructure-agnostic system for cost-optimizing cloud cluster configurations for one-off big-data jobs in distributed dataflow systems such as Spark and Flink. It addresses the problem that efficient execution depends on matching memory and CPU allocations to a job’s resource demands, while public-cloud configuration choices are numerous and current resource prices can fluctuate. Flora’s central premise is that suitable cluster resource configurations for a new job can be derived from executions of test jobs in the same category, without profiling the new job itself and without assuming job recurrence. In the reported evaluation on a new dataset comprising 180 Spark job executions on Google Cloud, Flora’s cluster resource selections exhibited an average deviation below 6% from the most cost-optimal solution, with a maximum deviation below 24% (Will et al., 28 Feb 2025).

1. Problem setting and design objective

Distributed dataflow systems permit data-parallel processing of large datasets on cloud clusters, but selecting an appropriate cloud configuration is often nontrivial. Individual resource allocations, such as memory and CPU cores, must satisfy the resource demands of the job, yet the available cloud configurations are plentiful and the current cost of these options can change over time. Flora was introduced as a low-overhead approach to cost-optimizing cloud cluster configurations under these conditions (Will et al., 28 Feb 2025).

The system is explicitly designed for one-off big-data jobs. It does not rely on repeated executions of the target job, and it does not require expensive profiling of that job. Instead, Flora trades on three ideas: infrastructure profiling of a diverse set of test jobs, a simple two-class taxonomy based on memory access patterns, and a cost-ranking procedure that applies up-to-date cloud prices to previously collected profiling data. A plausible implication is that Flora occupies a distinct point in the design space between heavyweight job-specific tuning and naive static instance selection.

2. System architecture and workflow

Flora consists of three major components: a Profiler, a Classifier, and a Cost Ranker (Selector) (Will et al., 28 Feb 2025). The Profiler runs a suite of preselected test jobs over all available cluster configurations and records median runtimes to build a lookup table, denoted as $\mathrm{runtime}(j,c)$. The Classifier is invoked when a new job $j^\*$ is submitted; it asks for a one-time label, either memory-demanding (class A) or memory-yielding (class B). The Cost Ranker then fetches the subset of profiling jobs $P_K$ belonging to the chosen class $K$, computes normalized costs for each configuration $c \in C$ using current hourly prices, and returns the cheapest configuration.

The end-to-end workflow is defined in three steps after an initial setup stage. Step 0 is one-time infrastructure profiling, shared across users. Step 1 is user annotation of the new job as A or B. Step 2 is ranking of all configurations by extrapolated cost, followed by return of the cheapest configuration. Because the selection stage uses only pre-collected profiling data and current price information, Flora imposes effectively no job-side runtime overhead after profiling. The paper characterizes this as a practical, zero-overhead-after-profiling approach (Will et al., 28 Feb 2025).

The architecture is intentionally minimalist. Rather than learning a high-dimensional performance model of arbitrary jobs, Flora reduces the interface to a user-supplied class label and a table lookup plus ranking procedure. This suggests a deliberate bias toward operational simplicity and cross-infrastructure portability over fine-grained predictive modeling.

3. Job classification by data access pattern

Flora partitions jobs into two coarse classes according to how they use memory (Will et al., 28 Feb 2025).

Class A, “Memory-Demanding” (Repeated Specific Data Loading) comprises jobs that repeatedly revisit data items or whose control flow depends on previously seen samples, such as iterative machine-learning algorithms and sorts on large partitions. For such jobs, performance increases continuously as memory is added, up to the point at which all “hot” data fits in memory.

Class B, “Memory-Yielding” (Single Parallelisable Data Loading) comprises jobs that read each record once, or a small constant number of times, in a largely embarrassingly parallel fashion, such as simple scans and row-by-row transformations. These jobs gain little from extra memory beyond caching small input partitions.

In Flora, the user simply chooses class A or class B at submission time. The taxonomy is deliberately coarse. The reported rationale is that data access pattern is sufficiently informative for configuration selection while keeping user burden low. The paper also states that jobs with mixed stages should ideally be split into separate jobs so that each stage can be allocated separately. This suggests that the classification scheme is most natural for workloads whose execution profile is dominated by a single access pattern, and less natural for heterogeneous multi-stage pipelines (Will et al., 28 Feb 2025).

4. Profiling methodology and optimization model

The infrastructure-profiling phase uses 18 Spark programs drawn from nine common algorithms: Grep, Sort, WordCount, K-Means, Linear/Logistic Regression, Join, GroupByCount, and Select-Where-OrderBy, each with two dataset sizes. The configuration space comprises 10 GCP instance-type configurations varying total vCPUs, total memory, and scale-out factor. Each test job $j$ and configuration $c$ is run once, for budget reasons, and the median runtime is recorded as $\mathrm{runtime}(j,c)$. The paper notes that, in practice, one would repeat runs to guard against outliers (Will et al., 28 Feb 2025).

Flora adopts a simple cost model:

$$\mathrm{cost}(j,c)=\mathrm{runtime\_in\_hours}(j,c)\times \mathrm{current\_hourly\_cost}(c).$$

For a new job $j^\*$ of class $j^\*$0, Flora approximates the best configuration by minimizing the sum of normalized costs over the profiling jobs in that class:

$j^\*$1

The normalization assigns value $j^\*$2 to the cheapest configuration for each profiling job and measures every other configuration relative to that optimum. Aggregating normalized costs across all profiling jobs in the selected class yields a total score for each candidate configuration; the configuration with minimum total score is returned.

The configuration-selection algorithm is specified as follows (Will et al., 28 Feb 2025):

1. For each $j^\*$3 and each $j^\*$4, compute $j^\*$5.
2. For each $j^\*$6, find $j^\*$7.
3. Form $j^\*$8.
4. For each $j^\*$9, sum $P_K$0.
5. Return $P_K$1.

The arithmetic complexity of selection is $P_K$2, with all inputs drawn from pre-collected profiling data. A plausible implication is that Flora’s online decision procedure is inexpensive enough to be integrated into routine submission-time scheduling workflows.

5. Empirical evaluation and comparative results

The evaluation uses a dataset of 180 Spark job executions on Google Cloud Platform (Frankfurt), corresponding to 18 jobs over 10 configurations (Will et al., 28 Feb 2025). Raw cost and runtime characteristics are reported as mean cost approximately \$P_K$31\,834$P_K$426.16, and maximum runtime approximately $P_K$5 s.

The baselines include random selection, min/max CPU, min/max memory, Crispy (memory extrapolation), Juggler (iterative jobs), and a Flora variant with a single class and thus no differentiation between memory-demanding and memory-yielding jobs. The main results are normalized so that perfect selection equals $P_K$6, averaged over all 18 jobs. Flora attains mean cost $P_K$7, approximately $P_K$8 above the ideal, with mean runtime $P_K$9. The next-best approaches, Juggler or Flora-one-class, achieve cost approximately $K$0–$K$1, whereas the worst simple baseline, minimizing CPU, yields cost $K$2. The worst-case deviation for Flora remains below $K$3 across all jobs (Will et al., 28 Feb 2025).

Additional experiments reported in the paper show that Flora automatically adapts when vCPU and memory prices are altered over several orders of magnitude. The evaluation also studies classification noise: misclassifying up to approximately $K$4 of jobs still outperforms random selection, while beyond that point Flora-one-class is identified as a safer fallback. These results support the claim that the two-class taxonomy is useful even when labels are imperfect, although the paper does not present it as universally robust to arbitrary misclassification rates (Will et al., 28 Feb 2025).

A concise summary of the main comparative figures is given below.

Method	Mean normalized cost	Notes
Flora	1.052	Mean runtime 1.578
Juggler or Flora-one-class	1.334–1.336	Next best
Minimize CPU	2.126	Worst simple baseline

6. Operational considerations, limitations, and broader usage of the name

Flora’s one-time profiling cost can be amortized across all users of a cloud region or private cluster. The classification step is user-driven; for non-expert users, the paper suggests either defaulting to one class or trying both labels on a first run and adopting the better class for future runs. Flora does not require profiling the new job itself, and it does not assume that jobs recur. These properties define its operational niche: first-run, cost-aware cluster selection with low deployment complexity (Will et al., 28 Feb 2025).

The system’s limitations are also explicit. The two-class taxonomy is coarse and may mislabel certain multi-stage pipelines. Profiling data grows with the number of job classes if the taxonomy is refined. Future extensions proposed in the paper include automating labeling via static code analysis or brief micro-profiling to infer memory access patterns, refining the taxonomy beyond two classes, and integrating spot-price dynamics or carbon-aware scheduling. This suggests a research trajectory in which Flora’s current human-supplied categorical abstraction becomes increasingly automated while preserving the lightweight character of the original formulation (Will et al., 28 Feb 2025).

The name Flora is also used in unrelated research contexts. In computer vision, FLORA denotes a fine-grained low-rank architecture-search framework for Vision Transformers that combines low-rank factorization with one-shot NAS (Chang et al., 2023). In long-context language-model training, Flora refers to a human/LLM-free context-construction strategy based on assembling short instruction-following examples into arbitrarily long training contexts (Chen et al., 26 Jul 2025). Outside machine learning and systems, the term appears in the astronomical literature as the Flora family, an inner main-belt asteroid family whose orbital and reflectance properties and age were characterized in detail (Dykhuis et al., 2014), and in ecological literature on the plant biodiversity of the Bouchebka mountains in central-west Tunisia (Islem et al., 19 Mar 2025). These usages are etymologically shared but substantively independent.