Reviewed by Aditya Kumar · Last reviewed 2026-03-25
**Why It Matters (Architectural Logic)**: Data quality gates prevent downstream corruption, wasted compute, and compliance issues. Systematic validation balances rigor with performance. Data quality validation in PySpark requires systematic checks before persistence. For...
This hard-level Spark/Big Data question appears frequently in data engineering interviews at companies like Dunnhumby. While less common, it tests deeper understanding that distinguishes strong candidates. Mastering the underlying concepts (partition, spark) will help you answer variations of this question confidently.
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.
Why It Matters (Architectural Logic): Data quality gates prevent downstream corruption, wasted compute, and compliance issues. Systematic validation balances rigor with performance.
Data quality validation in PySpark requires systematic checks before persistence. For missing values, iterate over columns and use count() with filter(isnull()): for col in df.columns: null_count = df.filter(F.col(col).isNull()).count(); log or raise if thresholds exceeded. For duplicates: dup_count = df.count() - df.dropDuplicates().count(); use dropDuplicates() with specific columns for business-key deduplication. Best practice: define validation rules (e.g., max 5% nulls per column), run checks in a validation stage, and fail the job with clear metrics if violated. Log results to a data quality dashboard. Before saving: coalesce/repartition appropriately, use schema enforcement (e.g., Delta MERGE with schema evolution disabled for strict writes), and consider idempotent writes with overwrite by partition or merge keys.
Scalability Trade-offs: Validation scales with partition count; design checks to fail fast. Streaming validation adds latency—batch validate when possible.
Cost Implications: Catching bad data early prevents expensive reprocessing. Over-validation (full scans for uniqueness) can 2x cost—use sampling for large datasets.
Pro-Move: Log validation metrics to a DQ dashboard; fail with clear thresholds. Red Flag: Silently accepting >10% nulls—downstream models will fail.
Some links below are affiliate links. If you buy through them we may earn a small commission at no extra cost to you — it helps keep DataEngPrep free.
According to DataEngPrep.tech, this is one of the most frequently asked Spark/Big Data interview questions, reported at 1 company. DataEngPrep.tech maintains an editor-reviewed database of 1,863 data engineering interview questions across 7 categories.