Ch. 7: Discussion — Notes

[jathavaan]

Purpose

Working notes for Chapter 7: Discussion of the master thesis
"Benchmarking Cloud-Native and Traditional Geospatial Technologies."

This chapter is currently a placeholder with stated goals.

Discussion goals (from thesis)

• Interpret results through the background
• Frame real-world decisions as complexity and implementation cost weighed against usage cost
• Acknowledge factors that the thesis itself does not measure

Expected content

• Why cloud-native wins/loses on specific workloads (link to §2.1 decoupled architecture, §2.3 format properties)
• When distributed execution pays off vs. coordination overhead dominates (link to §2.4 lifecycle)
• Cost vs. performance trade-offs for practitioners choosing between stacks
• Limitations: single cloud provider, read-only workloads, Norwegian data domain, no write-path benchmarks
• Comparison with prior work from §3.1

How to use this thread

Post notes, draft paragraphs, open questions, and revision requests as comments.

[jathavaan]

From PR #338

Section 7 — Discussion

The spark.driver.maxResultSize fix (PR #338) provides a concrete data point for the broadcast-vs-partitioned discussion: at national scale (~100M buildings × 357 municipalities), the broadcast join's intermediate result serializes to ~4.0 GiB through the driver before the groupBy aggregation reduces it to 357 rows. This is a direct consequence of the broadcast mechanism described in Section 2.4.3 — the small-side broadcast avoids shuffle but routes all intermediate output through the driver, creating a scalability ceiling that the partitioned strategy does not face. If the chapter discusses why broadcast may degrade or fail at larger scales, this serialization bottleneck is the mechanism.

[jathavaan]

From issue #335 / PR #336

Section 7 — Discussion

The transient IMDS failure observed in batch 18/18 of a 3.1h run (issue #335) is a concrete example of the cloud infrastructure variability discussed in Section 4.5. The retry mechanism is a reliability mitigation, not a measurement concern — retries happen at container creation time, outside the @monitor timing window. However, the incident illustrates that orchestration-level flakiness (token endpoint returning HTTP/1.1 000 status code 0) is a practical concern for long-running multi-batch suites on Azure, distinct from the within-benchmark variability the thesis already addresses.

[jathavaan]

From issue #254

§7 — Threats to validity: missing default-strategy baseline

The Sedona default join strategy (no explicit broadcast or repartition hint) was dropped from the experiment suite because iterations consistently timed out, failed, or both — making data collection infeasible within budget and time constraints.

This is a threat to external validity: the default strategy is what a user would get without tuning, so its absence means the results cannot speak to out-of-the-box Sedona performance on national-scale joins. The thesis should note that:

• The broadcast and partitioned strategies represent tuned Sedona configurations.
• Whether the default strategy would converge given sufficient cluster resources or time remains an open question.
• The failure pattern itself (executor losses, timeouts) is informative — it suggests the default strategy is not viable for this workload scale without explicit partitioning hints, which is a finding worth reporting even without precise timing data.

[jathavaan]

From PR #343

Chapter 7 is currently a stub with discussion goals. The following points are relevant when writing the discussion.

Cost model accuracy and RQ2 implications

PR #343 corrected four cost model gaps that systematically underestimated Databricks/Sedona costs relative to single-node configurations. When discussing RQ2 (scaling against single-node), acknowledge:

1. Driver node cost: The previous cost model omitted the driver node, underestimating Databricks compute cost by 6–33% depending on cluster size. This asymmetry meant small clusters (2–4 workers) appeared disproportionately cheaper than they actually are, potentially shifting the crossover point where distributed compute becomes cost-competitive.

2. Cross-region data transfer: Databricks is deployed in Sweden Central while data resides in Norway East. The ~$0.02/GB inter-region egress is a real cost that single-node configurations (all intra-region) do not incur. This is an inherent architectural disadvantage of using Databricks on Azure when the data region does not offer Databricks workspaces.

3. Hardcoded pricing as a limitation: All unit prices are pinned to 2026 rates. Azure pricing changes (especially the Databricks Standard → Premium tier migration on 2026-10-01, which doubles the DBU rate from $0.15 to $0.30) would further increase the distributed configuration cost. The framework does not automatically track pricing changes.