Describe a scenario where partitioning and bucketing would improve query performance.

Situation: An events table with billions of rows serving time-range and user-level analytics. Task: Achieve sub-second query latency while controlling storage and compute costs. Why Partitioning: Partition pruning at read time eliminates entire data scans—a query filtering by date_range only touches relevant partition dirs. This reduces I/O by orders of magnitude (e.g., 365 partitions → scan 1 vs all). Why Bucketing: Bucketing by user_id co-locates rows for the same user across partitions, enabling efficient user-level aggregations and joins without shuffling a massive fact table. Scalability trade-offs: Over-partitioning creates the small-file problem (metadata explosion, S3 listing latency). Under-bucketing leaves hot buckets. Cost: Fewer partitions = fewer small files = lower storage metadata cost and faster listing. Best practice: Partition by low-cardinality, high-selectivity columns; bucket by high-cardinality join keys. Target 128MB–1GB per partition.