dbt Analytics Engineering key terms

A SQL file, usually a SELECT statement, that dbt compiles and runs against a warehouse to create a table or view. Models form the core building blocks of a dbt project.

The strategy controlling how dbt persists a model in the warehouse, such as table, view, incremental, or ephemeral. It determines rebuild behavior, storage cost, and query performance.

A model configured to append or merge only new or changed rows on each run instead of rebuilding the whole table. It relies on a filter condition and often a unique key.

A model materialized as a common table expression rather than a warehouse object. Its SQL is inlined into downstream models, so it is never queried directly.

A named temporary result set defined with a WITH clause inside a query. dbt models commonly chain CTEs to break complex transformations into readable, testable steps.

A Jinja function that references another model by name, letting dbt resolve the correct schema and database at compile time and infer dependencies for ordering.

A Jinja function that references a declared source table, resolving its fully qualified name at compile time and recording lineage from raw data into models.

The directed acyclic graph of models, sources, tests, and seeds that dbt builds from ref and source calls. It defines execution order and prevents circular dependencies.

A declaration in a YAML file describing raw tables loaded into the warehouse by another tool. Sources give dbt metadata, lineage, and testability for upstream data.

An individual table or view listed under a source definition, with an identifier and optional columns. It is referenced in models through the source function.

A configuration that compares a timestamp column in a source against a warn and error threshold to flag stale upstream data before it silently reaches models.

An assertion about model or source data that dbt runs as a query and fails when rows violate the expectation. Tests cover uniqueness, nulls, referential integrity, and custom rules.

A reusable, parameterized test defined in YAML and applied to columns or models, such as unique, not_null, or relationships. dbt ships built-in ones and supports custom versions.

A standalone SQL file under the tests directory that returns failing rows. It is written for one specific assertion and is not parameterized or reused across columns.

A generic test that fails when a column contains values outside an explicit allowlist. It enforces categorical domains such as status or country codes.

A generic test verifying that every value in a child column exists in a parent column, enforcing referential integrity across models or sources.

A test setting of warn or error that controls whether a failure blocks downstream execution or only logs a warning. It lets teams phase in stricter quality gates.

One or more columns that identify a row for merge or delete-and-insert logic in incremental models and snapshots. It must be unique in the incoming batch.

A dbt feature that captures change history for a mutable source table by recording validity periods, enabling slowly changing dimension type 2 analysis.

A modeling pattern that preserves historical attribute values over time, usually with valid-from and valid-to timestamps. Snapshots are dbt's built-in way to build type 2 versions.

A CSV file in the seeds directory that dbt loads into the warehouse as a table. Seeds suit small, static reference data such as mappings or country lists.

A reusable Jinja function defined in the macros directory that generates SQL or logic. Macros support DRY code, custom tests, and package-level extensions.

The templating language dbt uses to add logic, loops, and variables to SQL. It renders at compile time, producing the final SQL sent to the warehouse.

A helper that returns true only when an incremental model already exists in the warehouse and is not running in full-refresh mode. It guards the incremental filter logic.

A run flag that drops and rebuilds models from scratch, bypassing incremental logic. It is used after logic changes or to repair corrupted tables.

The dbt_project.yml file that names the project, sets the profile, configures paths, and applies default materializations and settings by folder.

A YAML entry in profiles.yml holding warehouse connection credentials and target settings. It separates environment secrets from the version-controlled project.

A named connection environment within a profile, such as dev or prod. The active target determines which database and schema dbt writes to.

A syntax or YAML definition that chooses which nodes a command runs, using tags, paths, graph operators, or state comparison. Selectors keep runs fast and scoped.

A label attached to models, tests, or sources that selectors can target. Tags group nodes by purpose, such as hourly or finance, for tailored runs.

A selection method that compares the current project against a previous manifest to run only new or modified nodes. It powers efficient CI and slim deployments.

A JSON artifact produced at compile time that describes every node, its configuration, and its dependencies. Tools and state selection read it to understand the project.

Descriptions of models, columns, and sources stored in YAML or markdown and rendered into a browsable site. Good docs make metric logic and ownership discoverable.

A reusable markdown block referenced from YAML to avoid repeating long descriptions across many columns or models. It keeps documentation consistent and maintainable.

A declaration of a downstream consumer such as a dashboard, report, or ML model, linked to the models it depends on. Exposures extend lineage beyond the transformation layer.

A visual and structural map of how sources, models, snapshots, tests, and exposures depend on one another. It supports impact analysis and debugging.

An external dbt project installed as a dependency, providing shared macros, models, or tests. Packages are pinned in packages.yml for reproducible builds.

An automated pipeline that builds and tests changed dbt nodes on each pull request. It catches breakage before merge, often using state comparison for speed.

Scheduling and coordinating dbt runs alongside upstream loads and downstream consumers. Tools trigger jobs, manage dependencies, retry failures, and surface run status.

An isolated deployment context, such as development, staging, or production, with its own credentials, schemas, and schedule. Environments prevent test data from reaching production.