SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
BigData New Added 28 August 2026

dbt: Compilation Error (model depends on a node that was not found)

A ref() or source() points at something dbt cannot resolve: a misspelled model name, a source not declared in a .yml file, or a model excluded by the current selector.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Resolve the graph and see what dbt knows about
dbt parse
dbt ls --select my_model+

# ref() takes the model NAME (the filename without .sql), not the table name
# source() requires a matching entry in a schema .yml

sources:
  - name: raw
    tables:
      - name: orders

# Build a model and everything it needs
dbt build --select +my_model

How to diagnose BigData errors

Distributed data errors are rarely about the line of code that threw them. An executor OOM, a failed checkpoint or a stuck consumer group are usually symptoms of data skew, insufficient partitioning, or a downstream system applying backpressure. The diagnostic instinct that pays off here is to look at the distribution of work across tasks before looking at the exception.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Open the Spark UI (or Flink dashboard) and sort tasks by duration and shuffle read size. If one task is an order of magnitude larger than the median, you have skew, not a memory shortage.
  2. Check the driver log and at least one executor log. The exception the driver reports is often a downstream consequence of the first executor failure.
  3. For streaming, measure consumer lag over time rather than at a point (kafka-consumer-groups --describe). Lag that grows linearly means throughput, lag that spikes and recovers means a poison message or a GC pause.
  4. Confirm whether the job failed or was killed. YARN, Kubernetes and Databricks all kill containers that exceed memory limits, and the resulting message looks like a crash rather than an eviction.
  5. Before increasing memory, try increasing partitions. Doubling spark.sql.shuffle.partitions is cheaper and more often correct than doubling executor memory.

Tools worth reaching for

  • Spark UI
  • kafka-consumer-groups
  • Airflow task logs
  • EXPLAIN / query profile

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

docs.getdbt.com

Related BigData errors

See all 11 BigData errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.