DataEngPrep.tech
QuestionsPracticeAI CoachDashboardPacksBlog
ProLogin
Home/Questions/Spark/Big Data/Design a cost-aware resource strategy for a Databricks workload with spiky and batch jobs. Explain Dynamic Resource Allocation, when to disable it, and how min/max executors and spot instances affect cost and SLAs.

Design a cost-aware resource strategy for a Databricks workload with spiky and batch jobs. Explain Dynamic Resource Allocation, when to disable it, and how min/max executors and spot instances affect cost and SLAs.

Spark/Big Datahard2.9 min readPremium

**Section 1 — The Context (The 'Why')** Databricks workload cost explodes when clusters run idle, jobs are over-provisioned, or spot preemption causes thrashing. The challenge is aligning DPU allocation to actual parallelism while maintaining SLA....

🤖 Practice this in AI Interview
Frequency
Low
Asked at 2 companies
Category
452
questions in Spark/Big Data
Difficulty Split
88E|81M|283H
in this category
Total Bank
1,863
across 7 categories
Asked at these companies
LTIMindtreePWC
Interview Pro Tip

**Pro-Move**: 'We use 70% spot with 2x parallelism so one preemption doesn't double runtime.' **Red Flag**: Running 24/7 clusters for batch jobs.

Key Concepts Tested
joinoptimizationpartition

Why This Question Matters

This hard-level Spark/Big Data question appears frequently in data engineering interviews at companies like LTIMindtree, PWC. While less common, it tests deeper understanding that distinguishes strong candidates. Mastering the underlying concepts (join, optimization, partition) will help you answer variations of this question confidently.

How to Approach This

This is a senior-level question that tests architectural thinking. Lead with the high-level design, then drill into specifics. Discuss trade-offs explicitly - there is rarely one correct answer. Show awareness of scale, fault tolerance, and operational complexity. The expert answer includes a code example that demonstrates the implementation pattern.

Expert Answer
573 wordsIncludes code

Section 1 — The Context (The 'Why')
Databricks workload cost explodes when clusters run idle, jobs are over-provisioned, or spot preemption causes thrashing. The challenge is aligning DPU allocation to actual parallelism while maintaining SLA. Naive fixed clusters waste 40–60% during low-usage hours.

Section 2 — The Diagram

[Workload Types]
Batch | Stream | Ad-hoc
|
v
[Autoscaling Policy]
min/max workers
|
v
[Spot/On-Demand Mix]
70% spot | 30% OD

Section 3 — Component Logic
Cluster policies define instance types and autoscaling. We use partitioning strategies to limit scan scope and reduce DPU-hours. Data skew mitigation prevents a few tasks from dominating—salting for joins. TTL policies on intermediate tables free storage. Spot instances with fallback to on-demand ensure cost savings without indefinite job restarts. Backpressure handling in streaming limits resource growth. Right-size executors: 4-core 16GB typical; avoid 1-core executors (task overhead).

Section 4 — The Trade-offs (The 'Senior' part)

  • CAP Theorem: AP: Clusters are stateless; scale up/down without consistency impact. Job result is consistent after completion.
  • Cost vs. Performance: Databricks: $0.40–0.75/DBU. Spot: 70% savings. Right-sizing saves 30–50%. Compare to EMR: Databricks 2x but fully managed.
  • Blast Radius: Spot preemption: job restarts; checkpoint enables resume. Cluster policy fail: fallback to on-demand. Blast radius: single job.
  • Section 5 — Pro-Tip
    Pro-Move: 'We use 70% spot with 2x parallelism so one preemption doesn't double runtime.' Red Flag: Running 24/7 clusters for batch jobs.

    Supplemental (Senior Context): In production, monitor partition skew, consumer lag, and merge duration. Use correlation IDs for traceability across pipeline stages. Schema evolution: prefer additive changes only; use Schema Registry for streaming to enforce compatibility. Consider data contract tests in CI to catch breaking changes early. Budget 10-20% overhead for replication, checkpoint storage, and DLQ. Data quality gates at each layer prevent bad data propagation. Right-size resources: profile before scaling; over-provisioning wastes budget. Document runbooks for common failures: broker restart, consumer rebalance, sink timeout. Establish SLOs per stage: ingest latency, transform duration, serve freshness. Review partition key choice: avoid high-cardinality keys that cause explosion; use composite keys (date, tenant) for balanced distribution. Test failure injection: kill executors, broker, sink to validate recovery. Optimize for the common case: most queries filter by date. Cold start mitigation: pre-warm connections, cache dimension lookups. Alert on lag exceeding 1hr, error rate above 1%. Cost optimization: lifecycle policies, spot instances, partition pruning. Lineage tracking enables impact analysis. Idempotency keys for replay. Backpressure handling prevents slow consumers from blocking producers. Fan-out patterns allow multiple consumers without re-processing. Exactly-once semantics require replayable source and idempotent sink. Data skew mitigation via salting for high-cardinality joins. Partitioning strategies must align with query patterns for pruning. CAP trade-off: AP for ingest and transform; CP for serve when BI needs accuracy. Blast radius bounded by partition and consumer group. Measure and iterate: latency percentiles, cost per record, error rate. Principal engineer tip: quantify before and after optimizations. Red flag: describing architecture without trade-offs. Glue versus EMR: Glue for bursty sub-2hr jobs; EMR for sustained 8hr+ saving 60%. MSK for Kafka; S3 for lake storage. Self-heal: orchestration retries; idempotent sinks ensure consistency. If primary fails, downstream goes stale but no data loss with replay. Design for operability: runbooks, dashboards, alerts. Avoid tight coupling between stages. Incremental processing reduces compute versus full refresh. Watermark-based deduplication enables idempotency. Partition evolution: add new partitions without rewriting. Retention policies balance cost and compliance. Test at scale: use production-size samples for validation. Always document trade-offs.

    This answer is partially locked

    Unlock the full expert answer with code examples and trade-offs

    Recommended

    Start AI Mock Interview

    Practice real interviews with AI feedback, track progress, and get interview-ready faster.

    • Unlimited AI mock interviews
    • Instant feedback & scoring
    • Full answers to 1,800+ questions
    • Resume analyzer & SQL playground
    Create Free Account

    Pro starts at $19/mo - cancel anytime

    Just need answers for quick revision?

    Download curated PDF interview packs

    Interview Packs
    R
    P
    A
    S

    Trusted by 10,000+ aspiring data engineers

    AmazonGoogleDatabricksSnowflakeMeta
    This answer is in the DE Mastery Vault 2026
    1,863 questions with expert answers across 7 categories →
    Related Study Guide
    ⚡

    PWC Data Engineer Interview Questions & Answers (2026)

    Practice the 41 most asked data engineering questions at PWC. Covers Spark/Big Data, Behavioral, Cloud/Tools and more.

    8 min read →

    Related Spark/Big Data Questions

    mediumWhat is the difference between repartition and coalesce in Apache Spark?FreehardWhat is the difference between SparkSession and SparkContext in Spark?FreemediumWhat is the difference between cache() and persist() in Spark? When would you use each?FreemediumWhat is the difference between groupByKey and reduceByKey in Spark?FreemediumWhat is the difference between narrow and wide transformations in Apache Spark? Explain with examples.Free

    According to DataEngPrep.tech, this is one of the most frequently asked Spark/Big Data interview questions, reported at 2 companies. DataEngPrep.tech maintains a curated database of 1,863+ real data engineering interview questions across 7 categories, verified by industry professionals.

    ← Back to all questionsMore Spark/Big Data questions →