An analytical query scans far more data than it needs. Before adding compute, what layout decisions should be examined?

What to examine

• Partitioning against the actual filter predicates. A table partitioned by ingestion date and queried by event date scans everything. Partitioning must match how the data is queried, which requires knowing the query patterns — and most partitioning schemes are chosen before anyone does.
• Partition cardinality. Too coarse and every query scans a large partition; too fine and the metadata overhead and small-file count dominate, which is the more common error and produces a table that is slow for reasons that look like nothing.
• Clustering or sort order within partitions, which enables data skipping on secondary predicates and is frequently a larger win than partitioning for high-cardinality filters.
• File sizes. Many small files means many open operations and poor scan efficiency; very large files prevent parallelism. Compaction to a target size is routine maintenance that no individual pipeline owns, which is why it must be a platform responsibility.
• Column pruning. Columnar formats read only the columns requested — unless a query selects everything, which is common in generated SQL and is a direct multiplier on cost.
• Statistics and min/max metadata, which enable skipping and which are stale or absent surprisingly often.

Why this comes before compute

Cost is dominated by data scanned, which is a layout property. Adding compute makes a badly-laid-out query finish sooner at higher cost; fixing layout reduces the work — at no recurring cost, which is the difference that matters.

Compute-storage separation does not excuse you from modelling. It makes the cost of bad modelling visible and per-query rather than absorbed into a fixed cluster.

The specific marketplace pattern

Extreme skew in every dimension: a few categories, a few sellers and a few products carry most of the rows. Partitioning on a skewed key produces partitions differing by orders of magnitude, and the job's duration is set by the largest one.

Salting the key or partitioning on a derived, balanced dimension is the usual remedy, and it is a decision that must be made deliberately because the natural key looks correct.

The measurement to run first

Bytes scanned versus bytes returned, per query shape. A ratio in the thousands identifies the problem immediately and points at whether the issue is partitioning, clustering or column selection.